Virtual machine instance management method and device, equipment and storage medium

Abstract

The invention provides a virtual machine instance management method and device, equipment and a storage medium, and relates to the technical field of computers, in particular to the technical fields of cloud computing, cloud services, virtual machines and the like. According to the specific implementation scheme, an operation instruction for a virtual machine instance is sent to a main virtual machine management program of the intelligent card through a computing control plane Nova of the intelligent card; and managing shadow instances of the virtual machine instances based on the operation instruction through the master virtual machine management program, and controlling a slave virtual machine management program in the first host machine to manage the virtual machine instances.

Description

Technical Field

[0001] The present disclosure relates to the field of computer technology, and in particular to technical fields such as cloud computing, cloud services, and virtual machines. Background Art

[0002] A virtual machine (VM) is a computer program or system that simulates the hardware operating environment of a host computer through software, allowing multiple operating systems to run simultaneously on the same host computer. Summary of the invention

[0003] The present disclosure provides a virtual machine instance management method, apparatus, device and storage medium.

[0004] According to one aspect of the present disclosure, a method for managing a virtual machine instance is provided, comprising:

[0005] Sending operation instructions for the virtual machine instance to the main virtual machine hypervisor of the smart card through the computing control plane Nova of the smart card;

[0006] The shadow instance of the virtual machine instance is managed by the master virtual machine hypervisor based on the operation instruction, and the slave virtual machine hypervisor in the first host is controlled to manage the virtual machine instance.

[0007] According to another aspect of the present disclosure, there is provided a virtual machine instance management device, comprising:

[0008] A sending module, used for sending an operation instruction for a virtual machine instance to a main virtual machine hypervisor of the smart card through a computing control plane Nova of the smart card;

[0009] The processing module is used to manage the shadow instance of the virtual machine instance based on the operation instruction through the main virtual machine management program, and control the slave virtual machine management program in the first host machine to manage the virtual machine instance.

[0010] According to another aspect of the present disclosure, there is provided an electronic device, comprising:

[0011] at least one processor; and

[0012] a memory communicatively connected to the at least one processor; wherein,

[0013] The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute any method in the embodiments of the present disclosure.

[0014] According to another aspect of the present disclosure, a non-transitory computer-readable storage medium storing computer instructions is provided, wherein the computer instructions are used to enable the computer to execute any method according to the embodiments of the present disclosure.

[0015] According to another aspect of the present disclosure, a computer program product is provided, including a computer program, which implements any method according to the embodiments of the present disclosure when executed by a processor.

[0016] It should be understood that the content described in this section is not intended to identify the key or important features of the embodiments of the present disclosure, nor is it intended to limit the scope of the present disclosure. Other features of the present disclosure will become easily understood through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] The accompanying drawings are used to better understand the present solution and do not constitute a limitation of the present disclosure.

[0018] Figure 1 is a schematic diagram of the architecture of a virtual machine instance management method according to an embodiment of the present disclosure;

[0019] Figure 2 is a flowchart of a virtual machine instance management method according to an embodiment of the present disclosure;

[0020] Figure 3 is a schematic diagram of a virtual machine instance management method according to a first embodiment of the present disclosure;

[0021] Figure 4 is a schematic diagram of a virtual machine instance management method according to a second embodiment of the present disclosure;

[0022] Figure 5 is a schematic diagram of a virtual machine instance management method according to a third embodiment of the present disclosure;

[0023] Figure 6 is a schematic diagram of a virtual machine instance management method according to a fourth embodiment of the present disclosure;

[0024] Figure 7 is a schematic diagram of a virtual machine instance management method according to a fifth embodiment of the present disclosure;

[0025] Figure 8 is a schematic diagram of a virtual machine instance management method according to a sixth embodiment of the present disclosure;

[0026] Fig. 9 is a schematic diagram of a virtual machine instance management method according to a seventh embodiment of the present disclosure;

[0027] Fig.10 is a structural diagram of a virtual machine instance management device according to an embodiment of the present disclosure;

[0028] Fig.11 It is a block diagram of an electronic device used to implement the virtual machine instance management method of the embodiment of the present disclosure. DETAILED DESCRIPTION

[0029] The following is a description of exemplary embodiments of the present disclosure in conjunction with the accompanying drawings, including various details of the embodiments of the present disclosure to facilitate understanding, which should be considered as merely exemplary. Therefore, it should be recognized by those of ordinary skill in the art that various changes and modifications may be made to the embodiments described herein without departing from the scope of the present disclosure. Similarly, for the sake of clarity and conciseness, the description of well-known functions and structures is omitted in the following description.

[0030] The terms "first", "second", etc. in this disclosure are used to distinguish similar objects, and are not necessarily used to describe a specific order or precedence. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions, for example, including a series of steps or units. The method, system, product or device is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0031] For ease of understanding, the terms involved in the embodiments of the present disclosure are explained below:

[0032] Host Machine: A physical server used to run virtualization software, also known as a physical machine.

[0033] Virtual Machine (VM): Through the simulation of the virtualization layer, the virtual machine appears to the upper-layer software as a real machine. This virtualization layer is generally called a virtual machine monitor (VMM), also known as a hypervisor.

[0034] Virtual machine instance: usually refers to a specific implementation of a virtual machine managed by a cloud service provider in a cloud computing environment. It is a running instance of a virtual machine on which users can install operating systems and applications.

[0035] Shadow Instance: A shadow instance usually refers to an additional instance that runs simultaneously with a virtual machine instance in a cloud computing environment; a virtual machine instance is a running virtual machine that users use directly, while a shadow instance is an auxiliary instance set up to ensure the stability and availability of the virtual machine instance.

[0036] Libvirt (virtual machine manager): also known as a virtualization management toolkit, Libvirt is an open source project that provides a set of tools for managing virtual machine instances. Libvirt itself is a CS architecture, including RPC-Client (Remote Procedure Call Client) and RPC-Server (Remote Procedure Call Server). The RPC channel supports UnixSocket (UNIX Operating System Socket), TCP (Transmission Control Protocol) and other communication methods. Client can interact with other servers.

[0037] Libvirtd (virtual machine hypervisor): is a daemon in Libvirt, which is responsible for scheduling and managing virtual machines.

[0038] Qemu (Quick Emulato): QEMU is a widely used open source computer emulator and virtual machine software. As an independent hypervisor (virtual machine monitor), QEMU can run virtual machines at the application level and also supports compatible virtualization modes.

[0039] QMP (QEMU Machine Protocol) is a JSON-based (a lightweight data exchange format) protocol provided by QEMU. It allows users to query and configure QEMU instances through a socket interface.

[0040] Nova (Computing Control Plane): is a core component in OpenStack (a cloud computing platform), which is mainly responsible for the management and scheduling of computing resources. In the disclosed embodiment, Nova is used to respond to operation requests, call the interface provided by the virtualization library, and send the target instruction corresponding to the operation request to the virtual machine hypervisor.

[0041] Smart card: a card-type device that integrates a microprocessor and a storage unit. It can also be understood as a device similar to a server. In the disclosed embodiment, the smart card integrates key components such as Nova, Libvirtd and Qemu, which are used to manage shadow instances and corresponding virtual machine instances.

[0042] In the related art, the shadow instance on the smart card side is responsible for managing the device operation and hot migration of the virtual machine instance on the host side, and each virtual machine instance corresponds to a shadow instance. Although the related art implements monitoring and management of virtual machine instances based on shadow instances, a method for managing shadow instances has not yet been provided. In view of this, in the smart card scenario, an embodiment of the present disclosure provides a method for managing virtual machine instances, which is used to collaboratively manage virtual machine instances and shadow instances.

[0043] In order to achieve the coordinated management of the shadow instance on the smart card side and the virtual machine instance on the host side, the virtual machine manager (Libvirt) in the embodiment of the present disclosure includes LibvirtMaster (master virtual machine manager) and LibvirtSlave (slave virtual machine manager). LibvirtMaster is located on the smart card side, and LibvirtSlave is located on the host side. LibvirtMaster is used to manage shadow instances and can communicate with LibvirtSlave to achieve management of virtual machine instances on the host side. For details, refer to Figure 1 The architecture shown.

[0044] exist Figure 1 In the embodiment, a host machine and a smart card are included, wherein the host machine side includes LibvirtSlave and at least one virtual machine instance controlled by the LibvirtSlave. The smart card side includes Nova, LibvirtMaster, and at least one shadow instance controlled by the LibvirtMaster. There is a one-to-one mapping relationship between the shadow instance and the virtual machine instance. LibvirtMaster and LibvirtSlave are connected through a control channel between the host machine and the smart card. When Nova receives an operation instruction, it sends the operation instruction to LibvirtMaster, and LibvirtMaster sends it to LibvirtSlave based on the control channel to realize the collaborative work of the virtual machine instance and the shadow instance.

[0045] exist Figure 1 The key components of LibvirtMaster include QemuDriver (Qemu driver), which has a built-in domain connection management object (virConnectPtr). The key components of LibvirtSlave include another QemuDriver (Qemu driver).

[0046] like Figure 1As shown in the figure, RemoteDriver (remote driver) in Nova and QemuDriver in LibvirtMaster form the first layer of CS architecture, and the connection channel between RemoteDriver and LibvirtMaster is UnixSocket (inter-process communication on the same host); virConnectPtr in LibvirtMaster and QemuDriver in LibvirtSlave form the second layer of CS architecture, and the connection channel is the control channel.

[0047] exist Figure 1 Based on the architecture shown, the flowchart of the virtual machine instance management method provided by the embodiment of the present disclosure is as follows Figure 2 As shown, including the following:

[0048] S201, sending an operation instruction for a virtual machine instance to a main virtual machine hypervisor of the smart card through the computing control plane Nova of the smart card.

[0049] S202: managing the shadow instance of the virtual machine instance based on the operation instruction through the primary virtual machine hypervisor, and controlling the secondary virtual machine hypervisor in the first host to manage the virtual machine instance.

[0050] Among them, the shadow instance is developed and modified by the community Qemu and can support QMP messages.

[0051] In addition, it should be noted that, since the virtual machine is implemented by a virtual machine simulator, the virtual machine simulator in the embodiment of the present disclosure is completely located on the host machine and does not need to be split, so as to facilitate later maintenance.

[0052] In the disclosed embodiment, the coordinated management of shadow instances and virtual machine instances can be achieved by using the master virtual machine hypervisor on the smart card side and the slave virtual machine hypervisor on the host side.

[0053] The collaborative management of the disclosed embodiment can be understood as including two aspects: on the one hand, the states of the virtual machine instance and the shadow instance are consistent; on the other hand, the operations on the virtual machine instance and the operations on the shadow instance are consistent.

[0054] In some embodiments, in order to improve the accuracy of collaborative management, the primary virtual machine hypervisor follows at least one of the following management rules:

[0055] 1) When the operation instruction includes querying the status, metadata of the virtual machine instance is returned preferentially.

[0056] Prioritizing returning the metadata of the virtual machine instance ensures that Nova obtains the true status of the virtual machine instance to improve the accuracy of collaborative management.

[0057] 2) When the operation instruction includes creating an instance, the instance is created in the order of shadow instance first and virtual machine instance later.

[0058] Among them, the shadow instance can immediately perform failover when the corresponding virtual machine instance fails, thereby reducing the risk of data loss or interruption to improve business continuity.

[0059] In addition, the shadow instance can be tested and verified before the virtual machine instance to ensure the correctness of the configuration and environment, and then the virtual machine instance can be started, which can reduce the risk of problems after the virtual machine instance is started.

[0060] Therefore, by creating instances based on the order of shadow instances first and virtual machine instances later, preparation can be made for the creation of virtual machine instances to provide higher availability.

[0061] 3) When the operation instruction includes destroying the instance, the instance is destroyed in the order of the virtual machine instance first and the shadow instance later.

[0062] Since shadow instances usually depend on the state and data of the corresponding virtual machine instance, shadow instances can only be safely removed after the virtual machine instance is properly destroyed to reduce problems such as data inconsistency or dependency errors.

[0063] At the same time, when a virtual machine instance is destroyed, resource cleanup operations are required, such as releasing memory, storage space, and network resources. These resource cleanup operations need to be completed before the shadow instance is destroyed to ensure that resources are released correctly and avoid resource leakage.

[0064] If the shadow instance is destroyed before the VM instance, it may result in a failure to quickly recover the VM instance, increasing the risk of data loss.

[0065] Therefore, destroying instances in the order of virtual machine instances first and shadow instances later is to ensure the correct release of resources while ensuring data integrity and system stability.

[0066] 4) When the first host is shut down, clean up the shadow instance based on the operation instruction.

[0067] Among them, cleaning up the shadow instance may include rolling back the operation on the shadow instance and / or stopping the shadow instance process. Among them, the write operation may include creation-type operations and deletion-type operations, wherein the creation-type operation can be understood as operating the shadow instance first and then operating the virtual machine instance. The deletion-type operation can be understood as operating the virtual machine instance first and then operating the shadow instance. For the creation-type operation in the write operation, if the first host is shut down, the operation on the shadow instance can be rolled back to keep the resources of the shadow instance and the virtual machine instance consistent. For the deletion-type operation in the write operation, if the first host is shut down, the shadow instance process can be stopped to release the resources occupied by the shadow instance on the smart card side.

[0068] Examples of creation operations include creating an instance, starting an instance, and mounting a device.

[0069] Examples of deletion operations include deleting an instance, destroying an instance, uninstalling a device, and the like.

[0070] For the query instance in the read operation, when the metadata of the virtual machine instance is obtained first and then the shadow instance is obtained, if the first host is shut down, the shadow instance process can be stopped to release the resources occupied by the shadow instance on the smart card side.

[0071] After the first host is shut down, the resources in the shadow instance are cleaned up to avoid inconsistency between the shadow instance and the virtual machine instance resources.

[0072] During implementation, based on the instruction identifiers corresponding to different operation instructions, the main virtual machine management program can clearly identify the tasks to be performed when receiving the operation instruction, so as to call the corresponding interface to perform the task.

[0073] The aforementioned operation instructions are for illustrative purposes only. If other operation instructions are needed, other operation instructions may also be set so that the main virtual machine hypervisor can perform collaborative management of virtual machine instances and shadow instances.

[0074] In the disclosed embodiment, based on multiple operation instructions, the main virtual machine hypervisor can adapt to more operations, so that the virtual machine instances and shadow instances can collaborate in multiple tasks.

[0075] In some embodiments, the managing the shadow instance of the virtual machine instance based on the operation instruction by the primary virtual machine hypervisor and controlling the secondary virtual machine hypervisor in the first host to manage the virtual machine instance may be specifically implemented as follows:

[0076] Step A1: When the operation instruction includes creating an instance, the instance data of the shadow instance is parsed from the operation instruction by the primary virtual machine hypervisor.

[0077] The instance data of the shadow instance may be data in XML (Extensible Markup Language) format. Since the basic format of XML is standardized, using XML for data transmission can facilitate data parsing.

[0078] Step A2: Create the shadow instance based on the instance data of the shadow instance through the main virtual machine hypervisor.

[0079] Step A3: When the shadow instance is successfully created, the metadata of the shadow instance is converted into instance data of the virtual machine instance suitable for the first host machine through the primary virtual machine hypervisor.

[0080] Because the formats of VM instances and shadow instances may differ, they need to be converted.

[0081] Step A4: The primary virtual machine hypervisor calls the instance definition interface of the secondary virtual machine hypervisor to send the instance data of the virtual machine instance to the secondary virtual machine hypervisor, so that the secondary virtual machine hypervisor creates the virtual machine instance.

[0082] During implementation, when the operation instruction includes creating an instance, the execution flow chart of each component in the smart card is as follows: Figure 3 As shown, including:

[0083] S301, Nova on the smart card side sends the operation instruction to LibvirtMaster.

[0084] S302: When the operation instruction includes creating an instance, LibvirtMaster parses the instance data of the shadow instance from the operation instruction.

[0085] S303, LibvirtMaster creates a shadow instance based on the instance data of the shadow instance.

[0086] S304, when the shadow instance is successfully created, LibvirtMaster converts the metadata of the shadow instance into instance data of the virtual machine instance suitable for the first host machine.

[0087] When the shadow instance is successfully created, the shadow instance domain name is obtained, LibvirtMaster determines the metadata of the shadow instance based on the shadow instance domain name, and converts the metadata of the shadow instance into instance data suitable for the virtual machine instance of the first host.

[0088] S305, LibvirtMaster calls LibvirtSlave instance definition interface.

[0089] S306, LibvirtMaster sends the instance data of the virtual machine instance to LibvirtSlave on the first host machine side.

[0090] S307, LibvirtSlave creates a virtual machine instance based on the instance data of the virtual machine.

[0091] When the virtual machine instance is successfully created, the virtual machine instance domain name is obtained.

[0092] During implementation, the metadata of the virtual machine instance can be obtained based on the virtual machine instance domain name, and carried in the notification of successful creation of the virtual machine instance and sent to the primary virtual machine hypervisor. When the primary virtual machine hypervisor receives the notification that the virtual machine instance is successfully created from the secondary virtual machine hypervisor, the metadata of the virtual machine instance is sent to the Nova.

[0093] In addition, when the primary virtual machine hypervisor receives a failure to create a virtual machine instance or cannot connect to the host machine, it is necessary to roll back the operation on the shadow instance to keep the resources of the shadow instance and the virtual machine instance consistent.

[0094] In the disclosed embodiment, the creation of shadow instances and virtual machine instances can be completed collaboratively through the master virtual machine hypervisor and the slave virtual machine hypervisor.

[0095] In some embodiments, the managing the shadow instance of the virtual machine instance based on the operation instruction by the primary virtual machine hypervisor and controlling the secondary virtual machine hypervisor in the first host to manage the virtual machine instance may be specifically implemented as follows:

[0096] Step B1: When the operation instruction includes deleting an instance, the primary virtual machine management program parses the unique identifier of the virtual machine instance from the operation instruction.

[0097] The purpose of deleting the instance is to delete the virtual machine.

[0098] The unique identifier of the virtual machine instance may be the domain name of the virtual machine instance.

[0099] Step B2: The primary virtual machine hypervisor calls the deletion interface of the secondary virtual machine hypervisor to send the unique identifier of the virtual machine instance to the secondary virtual machine hypervisor, so that the secondary virtual machine hypervisor deletes the virtual machine instance.

[0100] Step B3: When the primary virtual machine hypervisor determines that the secondary virtual machine hypervisor deletes the virtual machine instance, the primary virtual machine hypervisor deletes the shadow instance through the primary virtual machine hypervisor.

[0101] When implemented, the domain name of the shadow instance corresponds to the domain name of the virtual machine instance.

[0102] When the operation instruction includes deleting an instance, the execution flow chart of each component in the smart card is as follows: Figure 4 As shown, including:

[0103] S401, Nova on the smart card side sends the operation instruction to LibvirtMaster.

[0104] S402: When the operation instruction includes deleting an instance, LibvirtMaster parses the unique identifier of the virtual machine instance from the operation instruction.

[0105] S404, LibvirtMaster calls the deletion interface in LibvirtSlave.

[0106] S405, LibvirtMaster sends the unique identifier of the virtual machine instance to LibvirtSlave through the deletion interface.

[0107] S406, LibvirtSlave deletes the virtual machine instance according to the unique identifier of the virtual machine instance.

[0108] After the virtual machine instance is deleted, the instance data XML of the virtual machine instance is cleared.

[0109] S406, LibvirtSlave sends a notification of successful deletion of the virtual machine instance to LibvirtMaster.

[0110] S407, LibvirtMaster deletes the shadow instance based on the notification.

[0111] In addition, in the case that LibvirtMaster deletes the shadow instance, the shadow instance XML also needs to be cleaned up.

[0112] In addition, when the main virtual machine hypervisor receives a virtual machine instance deletion failure or cannot connect to the host machine, it is necessary to stop the shadow instance process and release the resources occupied by the shadow instance on the smart card side.

[0113] In the embodiment of the present disclosure, when the operation instruction is to delete an instance, the master virtual machine hypervisor and the slave virtual machine hypervisor cooperate with each other to facilitate the slave virtual machine hypervisor to delete the virtual machine instance first. After the virtual machine instance is successfully deleted, the master virtual machine hypervisor deletes the corresponding shadow instance, which can improve the stability of the system and the consistency of data, and avoid data loss or system errors during operation.

[0114] In some embodiments, the managing the shadow instance of the virtual machine instance based on the operation instruction by the primary virtual machine hypervisor and controlling the secondary virtual machine hypervisor in the first host to manage the virtual machine instance may be specifically implemented as follows:

[0115] Step C1: when the operation instruction includes a query status, the primary virtual machine management program parses the unique identifier of the virtual machine instance from the operation instruction.

[0116] The purpose of querying the status is to query the status of the virtual machine.

[0117] The unique identifier of the virtual machine instance may be the domain name of the virtual machine instance.

[0118] Step C2: The master virtual machine hypervisor calls the query interface of the slave virtual machine hypervisor to send the unique identifier of the virtual machine instance to the slave virtual machine hypervisor to obtain metadata of the virtual machine instance.

[0119] The metadata of the virtual machine instance may be used to indicate the state of the virtual machine instance.

[0120] Step C3, comparing the metadata of the virtual machine instance and the metadata of the shadow instance through the primary virtual machine hypervisor.

[0121] Step C4, when the primary virtual machine hypervisor determines that the metadata of the virtual machine instance is consistent with the metadata of the shadow instance, the metadata of the virtual machine instance is sent to Nova through the primary virtual machine hypervisor.

[0122] When the operation instruction is in the query state, the execution flow chart is as follows: Figure 5 As shown, including:

[0123] S501: Nova on the smart card side sends the operation instruction to LibvirtMaster.

[0124] S502: When the operation instruction includes querying the status, LibvirtMaster parses the instance data of the shadow instance from the operation instruction.

[0125] S503, LibvirtMaster calls the query interface of LibvirtSlave to send the unique identifier of the virtual machine instance to LibvirtSlave to obtain metadata of the virtual machine instance.

[0126] S504, LibvirtMaster compares the metadata of the virtual machine instance and the metadata of the shadow instance.

[0127] S505 , when LibvirtMaster determines that the metadata of the virtual machine instance is consistent with the metadata of the shadow instance, the metadata of the virtual machine instance is sent to Nova through LibvirtMaster.

[0128] In addition, when the primary virtual machine hypervisor determines that the metadata of the virtual machine instance and the metadata of the shadow instance are inconsistent, an inconsistency prompt is sent to the Nova.

[0129] In addition, when the main virtual machine hypervisor fails to query the virtual machine instance or cannot connect to the host machine, it is necessary to stop the shadow instance process and release the resources occupied by the shadow instance on the smart card side.

[0130] In the disclosed embodiment, the master virtual machine hypervisor and the slave virtual machine hypervisor can collaboratively query the status of the virtual machine instance and return the accurate status to Nova.

[0131] In some embodiments, the managing the shadow instance of the virtual machine instance based on the operation instruction by the primary virtual machine hypervisor and controlling the secondary virtual machine hypervisor in the first host to manage the virtual machine instance may be specifically implemented as follows:

[0132] Step D1, when the operation instruction includes starting an instance, starting the shadow instance through the main virtual machine hypervisor.

[0133] The purpose of starting the virtual machine is to enable the virtual machine to run normally.

[0134] Step D2, when the shadow instance is successfully started, calling the start interface of the slave virtual machine hypervisor through the master virtual machine hypervisor to start the virtual machine instance.

[0135] During implementation, when the operation instruction includes starting an instance, the execution flow chart is as follows: Figure 6 As shown, including:

[0136] S601: Nova on the smart card side sends the operation instruction to LibvirtMaster.

[0137] S602: When the operation instruction includes starting an instance, LibvirtMaster starts a shadow instance.

[0138] S603, when the shadow instance is successfully started, LibvirtMaster calls the startup interface of LibvirtSlave.

[0139] S604, LibvirtSlave starts the virtual machine instance and then feeds back the startup result.

[0140] In the case where LibvirtSlave successfully starts a virtual machine instance, LibvirtMaster sends a notification of the successful startup of the instance to Nova.

[0141] In addition, when the main virtual machine hypervisor receives a message that the virtual machine instance has not been started successfully or cannot connect to the host machine, it is necessary to roll back the operation on the shadow instance to keep the resources of the shadow instance and the virtual machine instance consistent. For example, shut down the started shadow instance.

[0142] In the embodiment of the present disclosure, based on the startup request in the operation instruction, when the shadow instance is successfully started, the master virtual machine hypervisor calls the startup interface of the slave virtual machine hypervisor to start the virtual machine instance, based on the startup order to ensure the stability of the system and the integrity of the data.

[0143] In some embodiments, managing the shadow instance of the virtual machine instance based on the operation instruction by the primary virtual machine hypervisor and controlling the secondary virtual machine hypervisor in the first host to manage the virtual machine instance can be specifically implemented as follows:

[0144] Step E1, when the operation instruction includes destroying an instance, calling a destroy interface of the slave virtual machine hypervisor through the master virtual machine hypervisor to destroy the virtual machine instance.

[0145] The purpose of destroying an instance is to destroy the virtual machine instance so that the virtual machine stops being used.

[0146] Step E2, when the virtual machine instance is successfully destroyed, destroying the shadow instance through the primary virtual machine hypervisor.

[0147] When implemented, when the operation instruction includes destroying the instance, the execution flow chart is as follows Figure 7 As shown, including:

[0148] S701: Nova on the smart card side sends the operation instruction to LibvirtMaster.

[0149] S702: When the operation instruction includes destroying the instance, LibvirtMaster calls the destroy interface of LibvirtSlave.

[0150] S703, LibvirtSlave destroys the virtual machine instance and feeds back the execution result.

[0151] S704: When the virtual machine instance is successfully destroyed, LibvirtMaster destroys the shadow instance.

[0152] In addition, when the main virtual machine hypervisor receives a message that the virtual machine instance was not destroyed successfully and cannot connect to the host machine, it is necessary to stop the shadow instance process and release the resources occupied by the shadow instance on the smart card side.

[0153] In the embodiment of the present disclosure, based on the destruction request in the operation instruction, when the virtual machine instance is successfully destroyed, the main virtual machine hypervisor destroys the shadow instance based on the destruction order to ensure the stability of the system and the integrity of the data.

[0154] In some embodiments, managing the shadow instance of the virtual machine instance based on the operation instruction by the primary virtual machine hypervisor and controlling the secondary virtual machine hypervisor in the first host to manage the virtual machine instance can be specifically implemented as follows:

[0155] Step F1, when the operation instruction includes mounting a first target device, mounting the first target device to the shadow instance based on the operation instruction through the primary virtual machine hypervisor.

[0156] The first target device includes a block device and / or a network device.

[0157] Step F2, when the first target device is successfully mounted in the shadow instance, calling the mount interface of the slave virtual machine hypervisor through the master virtual machine hypervisor to mount the first target device into the virtual machine instance.

[0158] During implementation, when the operation instruction includes mounting the first target device, the execution flow chart is as follows: Figure 8 As shown, including:

[0159] S801: Nova on the smart card side sends the operation instruction to LibvirtMaster.

[0160] S802: When the operation instruction includes mounting the first target device, LibvirtMaster mounts the first target device to the shadow instance based on the operation instruction.

[0161] S803, when the first target device is successfully mounted in the shadow instance, LibvirtMaster calls the mounting interface of LibvirtSlave.

[0162] S804, LibvirtSlave mounts the first target device to the virtual machine instance and feeds back the execution result.

[0163] When LibvirtSlave successfully mounts the first target device to the virtual machine instance, LibvirtMaster sends a successful mount message to Nova. Otherwise, when the primary hypervisor cannot connect to the host, LibvirtMaster cleans up the first device mounted in the shadow instance and needs to roll back the operation on the shadow instance to keep the resources of the shadow instance and the virtual machine instance consistent.

[0164] In the disclosed embodiment, the shadow instances and virtual machine instances can be collaboratively managed in an orderly manner through the master virtual machine hypervisor and the slave virtual machine hypervisor.

[0165] In some embodiments, managing the shadow instance of the virtual machine instance based on the operation instruction by the primary virtual machine hypervisor and controlling the secondary virtual machine hypervisor in the first host to manage the virtual machine instance can be specifically implemented as follows:

[0166] Step G1: when the operation instruction includes uninstalling the second target device, the second target device is uninstalled from the virtual machine instance by calling the uninstall interface of the slave virtual machine hypervisor through the master virtual machine hypervisor.

[0167] The second target device includes a block device and / or a network device.

[0168] Step G2: When the second target device is successfully uninstalled in the virtual machine instance, the second target device is uninstalled from the shadow instance through the primary virtual machine.

[0169] During implementation, when the operation instruction includes uninstalling the second target device, the flowchart is executed as shown in FIG. Fig. 9 As shown, including:

[0170] S901: Nova on the smart card side sends the operation instruction to LibvirtMaster.

[0171] S902: When the operation instruction includes uninstalling the second target device, LibvirtMaster calls the uninstall interface of LibvirtSlave.

[0172] S903, LibvirtSlave uninstalls the second target device from the virtual machine instance and feeds back the execution result.

[0173] S904: When the second target device is successfully uninstalled in the virtual machine instance, LibvirtMaster uninstalls the second target device from the shadow instance.

[0174] In addition, when the main virtual machine hypervisor cannot connect to the host machine, or the virtual machine instance fails to successfully uninstall the second target device, LibvirtMaster needs to stop the shadow instance process and release the resources occupied by the shadow instance on the smart card side.

[0175] In addition, LibvirtMaster will feed back the execution results to Nova.

[0176] In the embodiment of the present disclosure, through the primary virtual machine hypervisor and the secondary virtual machine hypervisor, the second target device in the virtual machine instance is first uninstalled and then the second target device in the shadow instance is uninstalled, so that the operation of uninstalling the device can be kept consistent between the two.

[0177] In some embodiments, the sending of the operation instruction for the virtual machine instance to the main virtual machine hypervisor of the smart card through the computing control plane Nova of the smart card can be specifically implemented as follows:

[0178] Step H1, when the Nova receives the hot migration of the virtual machine instance to the first host machine, the Nova generates an operation instruction for creating an instance to the primary virtual machine management program.

[0179] Step H2, when Nova determines that the main virtual machine hypervisor has successfully created the virtual machine instance and the shadow instance, Nova generates a data migration instruction to the main virtual machine hypervisor to migrate the data to be migrated corresponding to the virtual machine instance from the second host machine to the first host machine.

[0180] During implementation, when Nova receives a request to hot migrate a virtual machine instance to the first host, Nova calls the virtual machine creation interface of LibvirtMaster and sends the operation instruction for creating an instance generated by Nova to LibvirtMaster. The operation instruction for creating an instance includes the instance data of the shadow instance. LibvirtMaster creates the shadow instance based on the instance data of the shadow instance, and the shadow instance is successfully created, and the shadow instance domain name is obtained. The metadata of the shadow instance is converted into the instance data of the virtual machine instance suitable for the first host, and the LibvirtSlave instance definition interface is called and sent to the LibvirtSlave on the host side. LibvirtSlave parses the instance data of the virtual machine and creates a virtual machine instance based on the instance data of the virtual machine to obtain the virtual machine instance domain name (Domain). When Nova determines that LibvirtMaster has successfully created the virtual machine instance and the shadow instance that need to be hot migrated on the first host, Nova generates a data migration instruction to the LibvirtMaster of the second host to migrate the data to be migrated of the virtual machine instance corresponding to the second host to the virtual machine instance of the first host. During implementation, the virtual machine instance of the second host machine and the virtual machine instance of the first host machine perform data transmission to complete data migration.

[0181] In the disclosed embodiment, the primary virtual machine hypervisor and the secondary virtual machine hypervisor can collaboratively complete the hot migration of the virtual machine instance, further improving the stability of the hot migration operation.

[0182] In some embodiments, when Nova determines that the migration of the data to be migrated is complete, the Nova notifies the second host machine through Nova to destroy the virtual machine instance and the shadow instance of the second host machine.

[0183] During implementation, when the hot migration of the virtual machine instance on the second host is completed, the virtual machine instance and shadow instance on the second host need to be destroyed. Specifically, Nova calls the destruction interface of the LibvirtMaster of the second host, sends the destruction instruction to the LibvirtMaster, and the LibvirtMaster parses the domain name of the virtual machine instance from the destruction instruction. LibvirtMaster calls the corresponding LibvirtSlave's destruction interface through the master virtual machine hypervisor to destroy the virtual machine instance on the second host. When the virtual machine instance is successfully destroyed, LibvirtMaster destroys the shadow instance on the second host.

[0184] In the disclosed embodiment, when Nova determines that the migration of the data to be migrated is complete, Nova notifies the second host to destroy the virtual machine instance and the shadow instance to collaboratively complete the processing work after the hot migration.

[0185] In some embodiments, the master virtual machine hypervisor and the slave virtual machine hypervisor communicate through a control channel between the smart card and the first host machine. Figure 1 As shown, virConnectPtr in LibvirtMaster and QemuDriver in LibvirtSlave form the second-layer CS architecture, and the connection channel is the control channel.

[0186] In the disclosed embodiment, a management and control channel is used for communication so that data between the master virtual machine hypervisor and the slave virtual machine hypervisor can be interoperable, thereby improving the collaborative efficiency of the shadow instance and the virtual machine instance.

[0187] In some embodiments, when the Nova uses the first Internet resource identifier URI to establish a connection with the primary virtual machine hypervisor, the Nova instructs the primary virtual machine hypervisor to use the secondary virtual machine hypervisor to collaboratively manage the instance.

[0188] The first Internet resource identifier URI is defined in the following manner:

[0189] virsh -c qemu: / / / system?slave=XX.XX.XX.XX define$shadowinstance.xml

[0190] The slave field value indicates the IP address of the host control channel network card.

[0191] The Define field value represents the instance data of the shadow instance.

[0192] In the disclosed embodiment, a first Internet resource identifier URI is used to instruct the primary virtual machine hypervisor to adopt a collaborative management instance of a secondary virtual machine hypervisor. Based on this indication method, the primary virtual machine hypervisor can conveniently understand the need to implement collaborative management of shadow instances and virtual machine instances. This method is simple, fast and easy to operate.

[0193] In some embodiments, when the Nova uses the second Internet resource identifier URI to establish a connection with the primary virtual machine hypervisor, the Nova instructs the primary virtual machine hypervisor to use a single virtual machine hypervisor model to manage instances.

[0194] During implementation, when the second Internet resource identifier URI is "qemu: / / / system", it is used to instruct the main virtual machine hypervisor to adopt the single virtual machine hypervisor to collaboratively manage the instance, that is, no shadow instance collaborates with the virtual machine instance.

[0195] In the disclosed embodiment, a first Internet resource identifier URI is used to instruct the main virtual machine hypervisor to adopt a single virtual machine hypervisor model to manage instances. Based on this indication method, the main virtual machine hypervisor can be easily informed that there is no need to process shadow instances. This method is simple, fast and easy to operate.

[0196] Based on the same technical concept, the embodiment of the present disclosure also provides a virtual machine instance management device 1000, such as Fig.10 As shown, including:

[0197] A sending module 1001 is used to send an operation instruction for a virtual machine instance to a main virtual machine hypervisor of the smart card through a computing control plane Nova of the smart card;

[0198] The processing module 1002 is used to manage the shadow instance of the virtual machine instance based on the operation instruction through the primary virtual machine hypervisor, and control the secondary virtual machine hypervisor in the first host machine to manage the virtual machine instance.

[0199] In some embodiments, the primary virtual machine hypervisor complies with at least one of the following management rules:

[0200] In case the operation instruction includes querying a status, returning metadata of the virtual machine instance;

[0201] When the operation instruction includes creating an instance, the instance is created in the order of shadow instance first and virtual machine instance later;

[0202] When the operation instruction includes destroying the instance, the instance is destroyed in the order of the virtual machine instance first and the shadow instance later;

[0203] When the first host is shut down, the shadow instance is cleaned up based on the operation instruction.

[0204] In some embodiments, the processing module comprises:

[0205] A first instruction unit, configured to parse the instance data of the shadow instance from the operation instruction through the primary virtual machine hypervisor when the operation instruction includes creating an instance;

[0206] A first creation unit, configured to create the shadow instance based on the instance data of the shadow instance through the primary virtual machine hypervisor;

[0207] a conversion unit, configured to convert the metadata of the shadow instance into instance data applicable to the virtual machine instance of the first host machine through the primary virtual machine hypervisor when the shadow instance is successfully created;

[0208] The second creation unit is configured to call the instance definition interface of the slave virtual machine hypervisor through the master virtual machine hypervisor, and send the instance data of the virtual machine instance to the slave virtual machine hypervisor, so that the slave virtual machine hypervisor creates the virtual machine instance.

[0209] In some embodiments, the processing module comprises:

[0210] A second instruction unit is used to parse the unique identifier of the virtual machine instance from the operation instruction through the primary virtual machine hypervisor when the operation instruction includes deleting the instance;

[0211] A first deleting unit, configured to send the unique identifier of the virtual machine instance to the slave virtual machine hypervisor by invoking the deletion interface of the slave virtual machine hypervisor through the master virtual machine hypervisor, so that the slave virtual machine hypervisor deletes the virtual machine instance;

[0212] The second deleting unit is configured to delete the shadow instance through the primary virtual machine hypervisor when the primary virtual machine hypervisor determines that the secondary virtual machine hypervisor deletes the virtual machine instance.

[0213] In some embodiments, the processing module comprises:

[0214] A third instruction unit is used to parse the unique identifier of the virtual machine instance from the operation instruction through the primary virtual machine management program when the operation instruction includes a query status;

[0215] an acquiring unit, configured to send the unique identifier of the virtual machine instance to the slave virtual machine hypervisor by invoking the query interface of the slave virtual machine hypervisor through the master virtual machine hypervisor, so as to acquire metadata of the virtual machine instance;

[0216] A comparison unit, configured to compare the metadata of the virtual machine instance and the metadata of the shadow instance through the primary virtual machine hypervisor;

[0217] A sending unit is used to send the metadata of the virtual machine instance to Nova through the main virtual machine hypervisor when the main virtual machine hypervisor determines that the metadata of the virtual machine instance is consistent with the metadata of the shadow instance.

[0218] In some embodiments, the processing module comprises:

[0219] A fourth instruction unit, configured to start the shadow instance through the primary virtual machine hypervisor when the operation instruction includes starting the instance;

[0220] A starting unit is used to call the starting interface of the slave virtual machine management program through the master virtual machine management program to start the virtual machine instance when the shadow instance is successfully started.

[0221] In some embodiments, the processing module comprises:

[0222] a fifth instruction unit, configured to, when the operation instruction includes destroying an instance, call a destroy interface of the slave virtual machine hypervisor through the master virtual machine hypervisor to destroy the virtual machine instance;

[0223] A destroying unit is used to destroy the shadow instance through the main virtual machine hypervisor when the virtual machine instance is successfully destroyed.

[0224] In some embodiments, the processing module comprises:

[0225] A sixth instruction unit, configured to, when the operation instruction includes mounting the first target device, mount the first target device to the shadow instance based on the operation instruction through the primary virtual machine hypervisor;

[0226] A mounting unit is used to call the mounting interface of the slave virtual machine hypervisor through the master virtual machine hypervisor when the first target device is successfully mounted in the shadow instance, so as to mount the first target device into the virtual machine instance.

[0227] In some embodiments, the processing module comprises:

[0228] a seventh instruction unit, configured to, when the operation instruction includes uninstalling the second target device, uninstall the second target device from the virtual machine instance by calling the uninstall interface of the slave virtual machine hypervisor through the master virtual machine hypervisor;

[0229] An uninstallation unit is used to uninstall the second target device from the shadow instance through the main virtual machine when the second target device is successfully uninstalled in the virtual machine instance.

[0230] In some embodiments, the sending module is specifically used to:

[0231] When the Nova receives a request to hot migrate the virtual machine instance to the first host machine, generating an operation instruction to create an instance through the Nova to the primary virtual machine hypervisor;

[0232] When Nova determines that the primary virtual machine hypervisor successfully creates the virtual machine instance and the shadow instance, Nova generates a data migration instruction to the primary virtual machine hypervisor to migrate the to-be-migrated data corresponding to the virtual machine instance from the second host machine to the first host machine.

[0233] In some embodiments, a destruction module is further included, which is used to:

[0234] When Nova determines that the migration of the data to be migrated is complete, the Nova notifies the second host machine through Nova to destroy the virtual machine instance and the shadow instance of the second host machine.

[0235] In some embodiments, the primary virtual machine hypervisor and the secondary virtual machine hypervisor communicate through a management and control channel between the smart card and the first host machine.

[0236] In some embodiments, the system further includes a first indication module for:

[0237] When the Nova uses the first Internet resource identifier URI to establish a connection with the primary virtual machine hypervisor, the Nova instructs the primary virtual machine hypervisor to use the secondary virtual machine hypervisor to collaboratively manage the instance.

[0238] In some embodiments, the system further includes a second indication module for:

[0239] When the Nova uses the second Internet resource identifier URI to establish a connection with the primary virtual machine hypervisor, the Nova instructs the primary virtual machine hypervisor to manage the instance in a single virtual machine hypervisor mode.

[0240] For the description of specific functions and examples of each module and submodule of the device in the embodiment of the present disclosure, reference can be made to the relevant description of the corresponding steps in the above method embodiment, which will not be repeated here.

[0241] In the technical solution disclosed herein, the acquisition, storage and application of user personal information involved are in compliance with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0242] According to an embodiment of the present disclosure, the present disclosure also provides an electronic device, a readable storage medium and a computer program product.

[0243] Fig.11A schematic block diagram of an example electronic device 1100 that can be used to implement an embodiment of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital assistants, cellular phones, smart phones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the present disclosure described and / or required herein.

[0244] like Fig.11 As shown, the device 1100 includes a computing unit 1101, which can perform various appropriate actions and processes according to a computer program stored in a read-only memory (ROM) 1102 or a computer program loaded from a storage unit 1108 into a random access memory (RAM) 1103. In the RAM 1103, various programs and data required for the operation of the device 1100 can also be stored. The computing unit 1101, the ROM 1102, and the RAM 1103 are connected to each other via a bus 1104. An input / output (I / O) interface 1105 is also connected to the bus 1104.

[0245] A number of components in the device 1100 are connected to the I / O interface 1105, including: an input unit 1106, such as a keyboard, a mouse, etc.; an output unit 1107, such as various types of displays, speakers, etc.; a storage unit 1108, such as a disk, an optical disk, etc.; and a communication unit 1109, such as a network card, a modem, a wireless communication transceiver, etc. The communication unit 1109 allows the device 1100 to exchange information / data with other devices through a computer network such as the Internet and / or various telecommunication networks.

[0246] The computing unit 1101 may be a variety of general and / or special processing components with processing and computing capabilities. Some examples of the computing unit 1101 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various dedicated artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, digital signal processors (DSPs), and any appropriate processors, controllers, microcontrollers, etc. The computing unit 1101 performs the various methods and processes described above, such as a virtual machine instance management method. For example, in some embodiments, the virtual machine instance management method may be implemented as a computer software program, which is tangibly included in a machine-readable medium, such as a storage unit 1108. In some embodiments, part or all of the computer program may be loaded and / or installed on the device 1100 via the ROM 1102 and / or the communication unit 1109. When the computer program is loaded into the RAM 1103 and executed by the computing unit 1101, one or more steps of the virtual machine instance management method described above may be performed. Alternatively, in other embodiments, the computing unit 1101 may be configured to execute the virtual machine instance management method in any other appropriate manner (eg, by means of firmware).

[0247] Various implementations of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), systems on chips (SOCs), load programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various implementations can include: being implemented in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which can be a special purpose or general purpose programmable processor that can receive data and instructions from a storage system, at least one input device, and at least one output device, and transmit data and instructions to the storage system, the at least one input device, and the at least one output device.

[0248] The program code for implementing the method of the present disclosure may be written in any combination of one or more programming languages. These program codes may be provided to a processor or controller of a general-purpose computer, a special-purpose computer, or other programmable data processing device, so that the program code, when executed by the processor or controller, enables the functions / operations specified in the flow chart and / or block diagram to be implemented. The program code may be executed entirely on the machine, partially on the machine, partially on the machine and partially on a remote machine as a stand-alone software package, or entirely on a remote machine or server.

[0249] In the context of the present disclosure, a machine-readable medium may be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, device, or equipment. A machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium may include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, device, or equipment, or any suitable combination of the foregoing. A more specific example of a machine-readable storage medium may include an electrical connection based on one or more lines, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0250] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user can provide input to the computer. Other types of devices can also be used to provide interaction with the user; for example, the feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including acoustic input, voice input, or tactile input).

[0251] The systems and techniques described herein may be implemented in a computing system that includes back-end components (e.g., as a data server), or a computing system that includes middleware components (e.g., an application server), or a computing system that includes front-end components (e.g., a user computer with a graphical user interface or a web browser through which a user can interact with implementations of the systems and techniques described herein), or a computing system that includes any combination of such back-end components, middleware components, or front-end components. The components of the system may be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include: a local area network (LAN), a wide area network (WAN), and the Internet.

[0252] A computer system may include a client and a server. The client and the server are generally remote from each other and usually interact through a communication network. The relationship of client and server is generated by computer programs running on respective computers and having a client-server relationship with each other. The server may be a cloud server, a server of a distributed system, or a server combined with a blockchain.

[0253] It should be understood that the various forms of processes shown above can be used to reorder, add or delete steps. For example, the steps recorded in this disclosure can be executed in parallel, sequentially or in different orders, as long as the desired results of the technical solutions disclosed in this disclosure can be achieved, and this document does not limit this.

[0254] The above specific implementations do not constitute a limitation on the protection scope of the present disclosure. It should be understood by those skilled in the art that various modifications, combinations, sub-combinations and substitutions can be made according to design requirements and other factors. Any modification, equivalent substitution and improvement made within the principles of the present disclosure shall be included in the protection scope of the present disclosure.

Claims

1. A virtual machine instance management method, comprising: Sending operation instructions for the virtual machine instance to the main virtual machine hypervisor of the smart card through the computing control plane Nova of the smart card; The shadow instance of the virtual machine instance is managed by the master virtual machine hypervisor based on the operation instruction, and the slave virtual machine hypervisor in the first host is controlled to manage the virtual machine instance.

2. The method according to claim 1, wherein: The primary virtual machine hypervisor complies with at least one of the following management rules: In case the operation instruction includes querying a status, returning metadata of the virtual machine instance; When the operation instruction includes creating an instance, the instance is created in the order of shadow instance first and virtual machine instance later; When the operation instruction includes destroying the instance, the instance is destroyed in the order of the virtual machine instance first and the shadow instance later; When the first host is shut down, the shadow instance is cleaned up based on the operation instruction.

3. The method according to claim 2, wherein: The step of managing the shadow instance of the virtual machine instance based on the operation instruction by the primary virtual machine hypervisor and controlling the secondary virtual machine hypervisor in the first host to manage the virtual machine instance includes: In the case where the operation instruction includes creating an instance, parsing the instance data of the shadow instance from the operation instruction by the primary virtual machine hypervisor; Creating the shadow instance based on the instance data of the shadow instance by the primary virtual machine hypervisor; In the case where the shadow instance is successfully created, converting the metadata of the shadow instance into instance data suitable for the virtual machine instance of the first host machine through the primary virtual machine hypervisor; The primary virtual machine hypervisor calls the instance definition interface of the secondary virtual machine hypervisor and sends the instance data of the virtual machine instance to the secondary virtual machine hypervisor, so that the secondary virtual machine hypervisor creates the virtual machine instance.

4. The method according to claim 2, wherein: The step of managing the shadow instance of the virtual machine instance based on the operation instruction by the primary virtual machine hypervisor and controlling the secondary virtual machine hypervisor in the first host to manage the virtual machine instance includes: In a case where the operation instruction includes deleting an instance, parsing the unique identifier of the virtual machine instance from the operation instruction by the primary virtual machine hypervisor; The primary virtual machine hypervisor calls the deletion interface of the secondary virtual machine hypervisor to send the unique identifier of the virtual machine instance to the secondary virtual machine hypervisor, so that the secondary virtual machine hypervisor deletes the virtual machine instance; When the primary virtual machine hypervisor determines that the secondary virtual machine hypervisor deletes the virtual machine instance, the primary virtual machine hypervisor deletes the shadow instance through the primary virtual machine hypervisor.

5. The method according to claim 2, wherein: The step of managing the shadow instance of the virtual machine instance based on the operation instruction by the primary virtual machine hypervisor and controlling the secondary virtual machine hypervisor in the first host to manage the virtual machine instance includes: In the case where the operation instruction includes a query status, the primary virtual machine hypervisor parses the unique identifier of the virtual machine instance from the operation instruction; The master virtual machine hypervisor calls the query interface of the slave virtual machine hypervisor to send the unique identifier of the virtual machine instance to the slave virtual machine hypervisor to obtain metadata of the virtual machine instance; Comparing the metadata of the virtual machine instance and the metadata of the shadow instance by the primary virtual machine hypervisor; When the primary virtual machine hypervisor determines that the metadata of the virtual machine instance is consistent with the metadata of the shadow instance, the metadata of the virtual machine instance is sent to the Nova through the primary virtual machine hypervisor.

6. The method according to claim 2, wherein: The step of managing the shadow instance of the virtual machine instance based on the operation instruction by the primary virtual machine hypervisor and controlling the secondary virtual machine hypervisor in the first host to manage the virtual machine instance includes: In a case where the operation instruction includes starting an instance, starting the shadow instance through the primary virtual machine hypervisor; When the shadow instance is successfully started, the start interface of the slave virtual machine hypervisor is called by the master virtual machine hypervisor to start the virtual machine instance.

7. The method according to claim 2, wherein: The step of managing the shadow instance of the virtual machine instance based on the operation instruction by the primary virtual machine hypervisor and controlling the secondary virtual machine hypervisor in the first host to manage the virtual machine instance includes: In a case where the operation instruction includes destroying an instance, calling a destroy interface of the slave virtual machine hypervisor through the master virtual machine hypervisor to destroy the virtual machine instance; When the virtual machine instance is successfully destroyed, the shadow instance is destroyed by the primary virtual machine hypervisor.

8. The method according to claim 2, wherein: The step of managing the shadow instance of the virtual machine instance based on the operation instruction by the primary virtual machine hypervisor and controlling the secondary virtual machine hypervisor in the first host to manage the virtual machine instance includes: In a case where the operation instruction includes mounting a first target device, mounting the first target device to the shadow instance based on the operation instruction by the primary virtual machine hypervisor; When the first target device is successfully mounted in the shadow instance, the mount interface of the slave virtual machine hypervisor is called by the master virtual machine hypervisor to mount the first target device into the virtual machine instance.

9. The method according to claim 2, wherein: The step of managing the shadow instance of the virtual machine instance based on the operation instruction by the primary virtual machine hypervisor and controlling the secondary virtual machine hypervisor in the first host to manage the virtual machine instance includes: In a case where the operation instruction includes uninstalling the second target device, uninstalling the second target device from the virtual machine instance by calling the uninstall interface of the slave virtual machine hypervisor through the master virtual machine hypervisor; When the second target device is successfully uninstalled in the virtual machine instance, the second target device is uninstalled from the shadow instance through the primary virtual machine.

10. The method according to claim 1, wherein: The sending of the operation instruction for the virtual machine instance to the main virtual machine management program of the smart card through the computing control plane Nova of the smart card includes: When the Nova receives a request to hot migrate the virtual machine instance to the first host machine, generating an operation instruction to create an instance through the Nova to the primary virtual machine hypervisor; When Nova determines that the primary virtual machine hypervisor successfully creates the virtual machine instance and the shadow instance, Nova generates a data migration instruction to the primary virtual machine hypervisor to migrate the to-be-migrated data corresponding to the virtual machine instance from the second host machine to the first host machine.

11. The method according to claim 10, further comprising: When Nova determines that the migration of the data to be migrated is complete, the Nova notifies the second host machine through Nova to destroy the virtual machine instance and the shadow instance of the second host machine.

12. The method according to claim 1, wherein: The primary virtual machine hypervisor and the secondary virtual machine hypervisor communicate through a management and control channel between the smart card and the first host machine.

13. The method according to claim 1, further comprising: When the Nova uses the first Internet resource identifier URI to establish a connection with the primary virtual machine hypervisor, the Nova instructs the primary virtual machine hypervisor to use the secondary virtual machine hypervisor to collaboratively manage the instance.

14. The method according to claim 1, further comprising: When the Nova uses the second Internet resource identifier URI to establish a connection with the primary virtual machine hypervisor, the Nova instructs the primary virtual machine hypervisor to manage the instance in a single virtual machine hypervisor mode.

15. A virtual machine instance management device, comprising: A sending module, used for sending an operation instruction for a virtual machine instance to a main virtual machine hypervisor of the smart card through a computing control plane Nova of the smart card; The processing module is used to manage the shadow instance of the virtual machine instance based on the operation instruction through the main virtual machine management program, and control the slave virtual machine management program in the first host machine to manage the virtual machine instance.

16. The device according to claim 15, wherein: The primary virtual machine hypervisor complies with at least one of the following management rules: In case the operation instruction includes querying a status, returning metadata of the virtual machine instance; When the operation instruction includes creating an instance, the instance is created in the order of shadow instance first and virtual machine instance later; When the operation instruction includes destroying the instance, the instance is destroyed in the order of the virtual machine instance first and the shadow instance later; When the first host is shut down, the shadow instance is cleaned up based on the operation instruction.

17. The device according to claim 16, wherein: The processing module comprises: A first instruction unit, configured to parse the instance data of the shadow instance from the operation instruction through the primary virtual machine hypervisor when the operation instruction includes creating an instance; A first creation unit, configured to create the shadow instance based on the instance data of the shadow instance through the primary virtual machine hypervisor; a conversion unit, configured to convert the metadata of the shadow instance into instance data of a virtual machine instance applicable to the first host machine through the primary virtual machine hypervisor when the shadow instance is successfully created; The second creation unit is configured to call the instance definition interface of the slave virtual machine hypervisor through the master virtual machine hypervisor, and send the instance data of the virtual machine instance to the slave virtual machine hypervisor, so that the slave virtual machine hypervisor creates the virtual machine instance.

18. The device according to claim 16, wherein: The processing module comprises: A second instruction unit is used to parse the unique identifier of the virtual machine instance from the operation instruction through the primary virtual machine hypervisor when the operation instruction includes deleting the instance; A first deleting unit, configured to send the unique identifier of the virtual machine instance to the slave virtual machine hypervisor by invoking the deletion interface of the slave virtual machine hypervisor through the master virtual machine hypervisor, so that the slave virtual machine hypervisor deletes the virtual machine instance; The second deleting unit is configured to delete the shadow instance through the primary virtual machine hypervisor when the primary virtual machine hypervisor determines that the secondary virtual machine hypervisor deletes the virtual machine instance.

19. The device according to claim 16, wherein: The processing module comprises: A third instruction unit is used to parse the unique identifier of the virtual machine instance from the operation instruction through the primary virtual machine management program when the operation instruction includes a query status; an acquiring unit, configured to send the unique identifier of the virtual machine instance to the slave virtual machine hypervisor by invoking the query interface of the slave virtual machine hypervisor through the master virtual machine hypervisor, so as to acquire metadata of the virtual machine instance; A comparison unit, configured to compare the metadata of the virtual machine instance and the metadata of the shadow instance through the primary virtual machine hypervisor; A sending unit is used to send the metadata of the virtual machine instance to Nova through the main virtual machine hypervisor when the main virtual machine hypervisor determines that the metadata of the virtual machine instance is consistent with the metadata of the shadow instance.

20. The device according to claim 16, wherein: The processing module comprises: A fourth instruction unit, configured to start the shadow instance through the primary virtual machine hypervisor when the operation instruction includes starting the instance; A starting unit is used to call the starting interface of the slave virtual machine management program through the master virtual machine management program to start the virtual machine instance when the shadow instance is successfully started.

21. The device according to claim 16, wherein: The processing module comprises: a fifth instruction unit, configured to, when the operation instruction includes destroying an instance, call a destroy interface of the slave virtual machine hypervisor through the master virtual machine hypervisor to destroy the virtual machine instance; A destroying unit is used to destroy the shadow instance through the main virtual machine hypervisor when the virtual machine instance is successfully destroyed.

22. The device according to claim 16, wherein: The processing module comprises: A sixth instruction unit, configured to, when the operation instruction includes mounting the first target device, mount the first target device to the shadow instance based on the operation instruction through the primary virtual machine hypervisor; A mounting unit is used to call the mounting interface of the slave virtual machine hypervisor through the master virtual machine hypervisor when the first target device is successfully mounted in the shadow instance, so as to mount the first target device into the virtual machine instance.

23. The device according to claim 16, wherein: The processing module comprises: a seventh instruction unit, configured to, when the operation instruction includes uninstalling the second target device, uninstall the second target device from the virtual machine instance by calling the uninstall interface of the slave virtual machine hypervisor through the master virtual machine hypervisor; An uninstallation unit is used to uninstall the second target device from the shadow instance through the main virtual machine when the second target device is successfully uninstalled in the virtual machine instance.

24. The device according to claim 15, wherein: The sending module is specifically used for: When the Nova receives a request to hot migrate the virtual machine instance to the first host machine, generating an operation instruction to create an instance through the Nova to the primary virtual machine hypervisor; When Nova determines that the primary virtual machine hypervisor successfully creates the virtual machine instance and the shadow instance, Nova generates a data migration instruction to the primary virtual machine hypervisor to migrate the to-be-migrated data corresponding to the virtual machine instance from the second host machine to the first host machine.

25. The device according to claim 24, further comprising a destruction module, configured to: When Nova determines that the migration of the data to be migrated is complete, the Nova notifies the second host machine through Nova to destroy the virtual machine instance and the shadow instance of the second host machine.

26. The device according to claim 15, wherein: The primary virtual machine hypervisor and the secondary virtual machine hypervisor communicate through a management and control channel between the smart card and the first host machine.

27. The apparatus according to claim 15, further comprising a first indication module, configured to: When the Nova uses the first Internet resource identifier URI to establish a connection with the primary virtual machine hypervisor, the Nova instructs the primary virtual machine hypervisor to use the secondary virtual machine hypervisor to collaboratively manage the instance.

28. The apparatus according to claim 15, further comprising a second indication module, configured to: When the Nova uses the second Internet resource identifier URI to establish a connection with the primary virtual machine hypervisor, the Nova instructs the primary virtual machine hypervisor to manage the instance in a single virtual machine hypervisor mode.

29. An electronic device comprising: at least one processor; as well as a memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the method according to any one of claims 1 to 14.

30. A non-transitory computer-readable storage medium storing computer instructions, wherein: The computer instructions are used to cause the computer to execute the method according to any one of claims 1-14.

31. A computer program product comprising a computer program, which, when executed by a processor, implements the method according to any one of claims 1 to 14.

Images