Virtual machine instance management methods, apparatus, devices, and storage media

Abstract

This disclosure provides a method, apparatus, device, and storage medium for managing virtual machine instances, relating to the field of computer technology, particularly to cloud computing, cloud services, and virtual machines. The specific implementation involves: sending operation instructions for virtual machine instances to the main virtual machine management program of the smart card via the Nova computing control plane; managing shadow instances of the virtual machine instances based on the operation instructions through the main virtual machine management program; and controlling the slave virtual machine management program within the first host machine to manage the virtual machine instances.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and in particular to the fields of cloud computing, cloud services, virtual machines, etc. Background Technology

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

[0003] This disclosure provides a method, apparatus, device, and storage medium for managing virtual machine instances.

[0004] According to one aspect of this disclosure, a virtual machine instance management method is provided, comprising:

[0005] The smart card's computing control plane, Nova, sends operation instructions for the virtual machine instance to the smart card's main virtual machine management program.

[0006] The master hypervisor manages the shadow instances of the virtual machine instance based on the operation instructions, and controls the slave hypervisor within the first host machine to manage the virtual machine instance.

[0007] According to another aspect of this disclosure, a virtual machine instance management apparatus is provided, comprising:

[0008] The sending module is used to send operation instructions 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;

[0009] The processing module is used to manage shadow instances of virtual machine instances based on the operation instructions through the master virtual machine hypervisor, and to control the slave virtual machine hypervisor in the first host machine to manage the virtual machine instances.

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

[0011] At least one processor; and

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

[0013] The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform any of the methods described in the present disclosure.

[0014] According to another aspect of this disclosure, a non-transitory computer-readable storage medium is provided storing computer instructions, wherein the computer instructions are used to cause the computer to perform any of the methods according to embodiments of this disclosure.

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

[0016] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0017] The accompanying drawings are provided to better understand this solution and do not constitute a limitation of this disclosure. Wherein:

[0018] Figure 1 This 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 This is a flowchart illustrating a virtual machine instance management method according to an embodiment of the present disclosure;

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

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

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

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

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

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

[0026] Figure 9 This is a schematic diagram of a virtual machine instance management method according to the seventh embodiment of this disclosure;

[0027] Figure 10 This is a schematic diagram of the structure of a virtual machine instance management device according to an embodiment of the present disclosure;

[0028] Figure 11 This is a block diagram of an electronic device used to implement the virtual machine instance management method of the embodiments of this disclosure. Detailed Implementation

[0029] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0030] The terms “first,” “second,” etc., used in this disclosure are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover non-exclusive inclusion, such as including a series of steps or units. A method, system, product, or apparatus is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to these processes, methods, products, or apparatuses.

[0031] For ease of understanding, the terms used in the embodiments of this 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 as a real machine to the upper-layer software. This virtualization layer is generally called the Virtual Machine Monitor (VMM) or Hypervisor.

[0034] Virtual machine instance: This typically 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 typically refers to an additional instance that runs concurrently with a virtual machine instance in a cloud computing environment. A virtual machine instance is a running virtual machine that is directly used by the user, 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 client-server architecture, including an RPC-Client (Remote Procedure Call Client) and an RPC-Server (Remote Procedure Call Server). The RPC channel supports communication methods such as UnixSocket (UNIX Operating System Socket) and TCP (Transmission Control Protocol). The client can interact with other servers.

[0037] Libvirtd (hypervisor): is a daemon in Libvirt that 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 a standalone hypervisor, QEMU can run virtual machines at the application level and also supports compatible virtualization modes.

[0039] QMP (QEMU Machine Protocol, Qemu monitoring protocol): It is a JSON-based protocol provided by QEMU that allows users to query and configure QEMU instances through a socket interface.

[0040] Nova (Compute Control Plane): A core component of OpenStack (a cloud computing platform), primarily responsible for the management and scheduling of computing resources. In this embodiment, Nova is used to respond to operation requests, calling interfaces provided by the virtualization library to send the target instructions corresponding to the operation request to the hypervisor.

[0041] A smart card is a card-type device that integrates a microprocessor and storage unit. It can also be understood as a server-like device. In this embodiment, the smart card integrates key components such as Nova, Libvirtd, and Qemu for managing shadow instances and corresponding virtual machine instances.

[0042] In related technologies, a shadow instance on the smart card side is responsible for managing the device operation and hot migration of virtual machine instances on the host side, with each virtual machine instance corresponding to one shadow instance. Although related technologies implement 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, this disclosure provides a method for managing virtual machine instances, used for collaborative management of virtual machine instances and shadow instances.

[0043] To achieve collaborative management of shadow instances on the smart card side and virtual machine instances on the host side, the virtual machine manager (Libvirt) in this embodiment includes LibvirtMaster (master hypervisor) and LibvirtSlave (slave hypervisor). LibvirtMaster is located on the smart card side, and LibvirtSlave is located on the host side. LibvirtMaster manages the shadow instances and can communicate with LibvirtSlave to manage the virtual machine instances on the host side. See details... Figure 1 The architecture shown.

[0044] exist Figure 1 The system comprises a host machine and a smart card. The host machine includes LibvirtSlave and at least one virtual machine instance managed by that LibvirtSlave. The smart card includes Nova, LibvirtMaster, and at least one shadow instance managed by LibvirtMaster. There is a one-to-one mapping between shadow instances and virtual machine instances. LibvirtMaster and LibvirtSlave are connected via a control channel between the host machine and the smart card. When Nova receives an operation command, it sends the command to LibvirtMaster, which then sends it to LibvirtSlave via the control channel, enabling collaborative work between the virtual machine instance and the shadow instance.

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

[0046] like Figure 1As shown, the RemoteDriver in Nova and the QemuDriver in LibvirtMaster constitute the first-layer client-server architecture. The connection channel between RemoteDriver and LibvirtMaster is UnixSocket (inter-process communication on the same host). The virConnectPtr in LibvirtMaster and the QemuDriver in LibvirtSlave constitute the second-layer client-server architecture, and the connection channel is the management channel.

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

[0048] S201 sends operation instructions for the virtual machine instance to the smart card's main virtual machine management program via the smart card's computing control plane Nova.

[0049] S202, the master hypervisor manages the shadow instances of virtual machine instances based on operation instructions, and controls the slave hypervisor within the first host machine to manage virtual machine instances.

[0050] Among them, the shadow instance is implemented by the community Qemu through development and modification, and can support QMP messages.

[0051] Furthermore, it should be noted that since the virtual machine is implemented through a virtual machine emulator, the virtual machine emulator in this embodiment is completely located on the host machine and does not need to be split up, so as to facilitate later maintenance.

[0052] In this embodiment of the disclosure, the collaborative management of shadow instances and virtual machine instances can be achieved by using the master virtual machine management program on the smart card side and the slave virtual machine management program on the host side.

[0053] The collaborative management of this disclosure embodiment can be understood to include two aspects: firstly, the states of the virtual machine instance and the shadow instance are consistent; secondly, the operations on the virtual machine instance and the operations on the shadow instance are consistent.

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

[0055] 1) If the operation instruction includes querying the status, the metadata of the virtual machine instance shall be returned first.

[0056] Prioritizing the return of virtual machine instance metadata ensures that Nova obtains the true state of the virtual machine instance, thereby improving the accuracy of collaborative management.

[0057] 2) If the operation instruction includes creating an instance, the instance shall be created in the order of shadow instance first, followed by virtual machine instance.

[0058] Shadow instances can immediately switch over in the event of a failure in the corresponding virtual machine instance, thereby reducing the risk of data loss or interruption and improving business continuity.

[0059] In addition, shadow instances can be tested and verified before virtual machine instances to ensure the correctness of the configuration and environment before starting the virtual machine instance. This can reduce the risk of problems occurring after the virtual machine instance starts.

[0060] Therefore, creating instances in the order of shadow instance first and virtual machine instance later can prepare for the creation of virtual machine instances, thus providing higher availability.

[0061] 3) If the operation instruction includes destroying the instance, the instance shall be destroyed in the order of virtual machine instance first, shadow instance second.

[0062] Since shadow instances typically depend on the state and data of their corresponding virtual machine instances, they can only be safely removed after the virtual machine instance has been properly destroyed. This reduces the risk of data inconsistencies 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 must be completed before the shadow instance is destroyed to ensure that resources are released correctly and to avoid resource leaks.

[0064] If the shadow instance is destroyed before the virtual machine instance, it may result in the virtual machine instance failing to recover quickly, thereby increasing the risk of data loss.

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

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

[0067] Cleaning up shadow instances can include rolling back operations on the shadow instance and / or stopping the shadow instance process. Write operations can include creation and deletion operations. Creation operations can be understood as operating on the shadow instance first, then the virtual machine instance. Deletion operations can be understood as operating on the virtual machine instance first, then the shadow instance. For creation operations within write operations, if the primary host is shut down, the operations on the shadow instance can be rolled back to maintain resource consistency between the shadow instance and the virtual machine instance. For deletion operations within write operations, if the primary host is shut down, the shadow instance process can be stopped, releasing the resources occupied by the shadow instance on the smart card side.

[0068] Examples of creation operations include creating instances, starting instances, and mounting devices.

[0069] Examples of deletion operations include deleting instances, destroying instances, and uninstalling devices.

[0070] For querying instances during read operations, if the metadata of the virtual machine instance is obtained first and then the shadow instance is obtained, and the primary host is shut down, the shadow instance process can be stopped, releasing the resources occupied by the shadow instance on the smart card side.

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

[0072] During implementation, based on the instruction identifier corresponding to different operation instructions, the main virtual machine management program can clearly identify the task to be executed when it receives the operation instruction, so as to call the corresponding interface to execute the task.

[0073] The aforementioned operation instructions are illustrative examples. If other operation instructions are required, other operation instructions can also be set so that the main virtual machine management program can perform collaborative management of virtual machine instances and shadow instances.

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

[0075] In some embodiments, the step of managing the shadow instance of the virtual machine instance through the master hypervisor based on the operation instructions, and controlling the slave hypervisor within the first host machine to manage the virtual machine instance, can be specifically implemented as follows:

[0076] Step A1: If the operation instruction includes creating an instance, the instance data of the shadow instance is parsed from the operation instruction by the main virtual machine management program.

[0077] The instance data of the shadow instance can be in XML (Extensible Markup Language) format. Since the basic format of XML is standardized, using XML for data transmission facilitates 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: If the shadow instance is successfully created, the metadata of the shadow instance is converted into instance data suitable for the virtual machine instance of the first host machine through the main virtual machine hypervisor.

[0080] Because virtual machine instances and shadow instances may have different formats, they need to be converted.

[0081] Step A4: The master hypervisor calls the instance definition interface of the slave hypervisor to send the instance data of the virtual machine instance to the slave hypervisor, so that the slave hypervisor can create the virtual machine instance.

[0082] During implementation, when the operation instructions include instance creation, the execution flowchart of each component within the smart card is as follows: Figure 3 As shown, it includes:

[0083] S301, Nova on the smart card side sends the operation command 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 shadow instances based on the instance data of the shadow instances.

[0086] S304. If the shadow instance is successfully created, LibvirtMaster converts the shadow instance's metadata into instance data suitable for the virtual machine instance on the first host machine.

[0087] In this process, once the shadow instance is successfully created, the shadow instance domain name is obtained. LibvirtMaster then determines the shadow instance's metadata based on the shadow instance domain name and converts the shadow instance's metadata into instance data suitable for the virtual machine instance on the first host machine.

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

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

[0090] S307, LibvirtSlave creates virtual machine instances based on virtual machine instance data.

[0091] If the virtual machine instance is created successfully, obtain the virtual machine instance domain name.

[0092] In implementation, the metadata of the virtual machine instance can be obtained based on the virtual machine instance domain name and included in a notification of successful virtual machine instance creation, which is then sent to the main hypervisor. Upon receiving a notification that a virtual machine instance has been successfully created from the hypervisor, the main hypervisor sends the virtual machine instance's metadata to Nova.

[0093] In addition, if the main hypervisor receives a message that the virtual machine instance creation failed or cannot connect to the host machine, it is necessary to roll back the operations on the shadow instance in order to maintain resource consistency between the shadow instance and the virtual machine instance.

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

[0095] In some embodiments, the step of managing the shadow instance of the virtual machine instance through the master hypervisor based on the operation instructions, and controlling the slave hypervisor within the first host machine to manage the virtual machine instance, can be specifically implemented as follows:

[0096] Step B1: If the operation instruction includes deleting an instance, the unique identifier of the virtual machine instance is parsed from the operation instruction by the master virtual machine management program.

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

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

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

[0100] Step B3: If the master hypervisor determines that the slave hypervisor has deleted the virtual machine instance, the master hypervisor deletes the shadow instance through the master hypervisor.

[0101] During implementation, the domain name of the shadow instance corresponds to the domain name of the virtual machine instance.

[0102] In practice, when the operation instruction includes deleting an instance, the execution flowchart of each component within the smart card is as follows: Figure 4 As shown, it includes:

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

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

[0105] S404, LibvirtMaster calls the delete 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 a virtual machine instance based on its unique identifier.

[0108] When a virtual machine instance is deleted, its instance data XML is cleared.

[0109] S406, LibvirtSlave sends a notification to LibvirtMaster that the virtual machine instance has been successfully deleted.

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

[0111] In addition, if a shadow instance is deleted from LibvirtMaster, the XML of that shadow instance also needs to be cleaned up.

[0112] In addition, if the main hypervisor receives a message that the virtual machine instance deletion failed or it 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 this embodiment of the disclosure, when the operation command is to delete an instance, the master virtual machine management program and the slave virtual machine management program cooperate with each other to allow the slave virtual machine management program to delete the virtual machine instance first. After the virtual machine instance is successfully deleted, the master virtual machine management program deletes the corresponding shadow instance. This can improve the stability of the system and the consistency of data, and avoid data loss or system errors during the operation.

[0114] In some embodiments, the step of managing the shadow instance of the virtual machine instance through the master hypervisor based on the operation instructions, and controlling the slave hypervisor within the first host machine to manage the virtual machine instance, can be specifically implemented as follows:

[0115] Step C1: If the operation instruction includes querying the status, the unique identifier of the virtual machine instance is parsed from the operation instruction by the main virtual machine management program.

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

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

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

[0119] The metadata of a virtual machine instance can be used to represent the state of the virtual machine instance.

[0120] Step C3: The metadata of the virtual machine instance and the metadata of the shadow instance are compared by the main virtual machine hypervisor.

[0121] Step C4: If the main hypervisor determines that the metadata of the virtual machine instance and the metadata of the shadow instance are consistent, the main hypervisor sends the metadata of the virtual machine instance to Nova.

[0122] During implementation, when the operation instruction is in a query state, the execution flowchart is as follows: Figure 5 As shown, it includes:

[0123] S501, Nova on the smart card side sends the operation command 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 in order to obtain the metadata of the virtual machine instance.

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

[0127] S505: If LibvirtMaster determines that the metadata of the virtual machine instance and the metadata of the shadow instance are consistent, it sends the metadata of the virtual machine instance to Nova through LibvirtMaster.

[0128] Furthermore, if the main hypervisor determines that the metadata of the virtual machine instance and the metadata of the shadow instance are inconsistent, it will send a notification of inconsistency to Nova.

[0129] In addition, if the main hypervisor cannot find 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 this embodiment of the disclosure, the master hypervisor and the slave hypervisor can collaboratively query the status of the virtual machine instance and return the accurate status to Nova.

[0131] In some embodiments, the step of managing the shadow instance of the virtual machine instance through the master hypervisor based on the operation instructions, and controlling the slave hypervisor within the first host machine to manage the virtual machine instance, can be specifically implemented as follows:

[0132] Step D1: If the operation instruction includes starting an instance, start the shadow instance through the main hypervisor.

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

[0134] Step D2: If the shadow instance is successfully started, the master hypervisor calls the startup interface of the slave hypervisor to start the virtual machine instance.

[0135] In practice, when the operation instruction includes starting an instance, the execution flowchart is as follows: Figure 6 As shown, it includes:

[0136] S601, Nova on the smart card side sends the operation command to LibvirtMaster.

[0137] S602, when the operation command includes starting an instance, LibvirtMaster starts a shadow instance.

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

[0139] S604, LibvirtSlave returns the startup result after starting the virtual machine instance.

[0140] When LibvirtSlave starts a virtual machine instance, LibvirtMaster sends a notification of successful instance startup to Nova.

[0141] Furthermore, if the hypervisor receives a message indicating that a virtual machine instance has failed to start or cannot connect to the host machine, it is necessary to roll back operations on the shadow instance to maintain resource consistency between the shadow instance and the virtual machine instance. For example, shutting down a running shadow instance.

[0142] In this embodiment of the disclosure, based on the startup request in the operation instruction, if 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 this startup order, the stability of the system and the integrity of the data are guaranteed.

[0143] In some embodiments, the master hypervisor manages the shadow instance of the virtual machine instance based on the operation instructions, and controls the slave hypervisor within the first host machine to manage the virtual machine instance. Specifically, this can be implemented as follows:

[0144] Step E1: If the operation instruction includes destroying the instance, the master hypervisor calls the destruction interface of the slave hypervisor to destroy the virtual machine instance.

[0145] The purpose of destroying an instance is to destroy the virtual machine instance and make the virtual machine stop being used.

[0146] Step E2: If the virtual machine instance is successfully destroyed, the shadow instance is destroyed through the main virtual machine hypervisor.

[0147] During implementation, when the operation instructions include destroying instances, the execution flowchart is as follows: Figure 7 As shown, it includes:

[0148] In S701, Nova on the smart card side sends operation commands to LibvirtMaster.

[0149] S702, when the operation instruction includes destroying the instance, LibvirtMaster calls the destruction interface of LibvirtSlave.

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

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

[0152] In addition, if the main hypervisor receives a message that the virtual machine instance has not been successfully destroyed 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 this embodiment of the disclosure, based on the destruction request in the operation instruction, if the virtual machine instance is successfully destroyed, the main virtual machine management program destroys the shadow instance. Based on this destruction order, the stability of the system and the integrity of the data are ensured.

[0154] In some embodiments, the master hypervisor manages the shadow instance of the virtual machine instance based on the operation instructions, and controls the slave hypervisor within the first host machine to manage the virtual machine instance. Specifically, this can be implemented as follows:

[0155] Step F1: If the operation instruction includes mounting the first target device, the main virtual machine hypervisor mounts the first target device to the shadow instance based on the operation instruction.

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

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

[0158] During implementation, when the operation instructions include mounting the first target device, the execution flowchart is as follows: Figure 8 As shown, it includes:

[0159] S801, Nova on the smart card side sends the operation command to LibvirtMaster.

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

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

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

[0163] If LibvirtSlave successfully mounts the first target device to the virtual machine instance, LibvirtMaster sends a successful mount message to Nova. Otherwise, if the primary hypervisor cannot connect to the host machine, LibvirtMaster needs to roll back the operations on the shadow instance to clean up the first device mounted in the shadow instance in order to maintain resource consistency between the shadow instance and the virtual machine instance.

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

[0165] In some embodiments, the master hypervisor manages the shadow instance of the virtual machine instance based on the operation instructions, and controls the slave hypervisor within the first host machine to manage the virtual machine instance. Specifically, this can be implemented as follows:

[0166] Step G1: If the operation instruction includes unloading the second target device, the second target device is unloaded from the virtual machine instance by calling the unload interface of the slave virtual machine instance through the master virtual machine hypervisor.

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

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

[0169] During implementation, when the operation instruction includes unloading the second target device, the execution flowchart is as follows: Figure 9 As shown, it includes:

[0170] In S901, Nova on the smart card side sends operation commands to LibvirtMaster.

[0171] S902, when the operation instruction includes unloading the second target device, LibvirtMaster calls the unloading interface of LibvirtSlave.

[0172] S903, LibvirtSlave unloads the second target device from the virtual machine instance and returns the execution result.

[0173] S904: If the second target device is successfully unloaded in the virtual machine instance, LibvirtMaster will unload the second target device from the shadow instance.

[0174] In addition, if the main hypervisor cannot connect to the host machine, or if the virtual machine instance fails to unload 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 send the execution results back to Nova.

[0176] In this embodiment of the disclosure, by using the master virtual machine management program and the slave virtual machine management program, 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 uninstallation operation can be kept consistent between the two.

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

[0178] Step H1: When Nova receives the request to hot migrate the virtual machine instance to the first host machine, Nova generates an operation instruction to create an instance and sends it to the main virtual machine management program.

[0179] In step H2, if Nova determines that the main hypervisor has successfully created the virtual machine instance and the shadow instance, Nova generates a data migration instruction for the main 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 machine, Nova calls the virtual machine creation interface of LibvirtMaster and sends the instance creation operation instructions generated by Nova to LibvirtMaster. These instructions include the instance data of the shadow instance. LibvirtMaster creates the shadow instance based on this data. Upon successful creation, the shadow instance domain name is obtained. The metadata of the shadow instance is converted into instance data suitable for the virtual machine instance on the first host machine, and the LibvirtSlave instance definition interface is called to send it to the LibvirtSlave on the host machine. The LibvirtSlave parses the instance data and creates the virtual machine instance based on it, obtaining the virtual machine instance domain name. Once Nova confirms that LibvirtMaster has successfully created the virtual machine instance to be hot-migrated and the shadow instance on the first host machine, Nova generates a data migration instruction for the LibvirtMaster on the second host machine to migrate the data to be migrated from the virtual machine instance on the second host machine to the virtual machine instance on the first host machine. During implementation, the virtual machine instances on the second host machine and the virtual machine instances on the first host machine perform data transfer to complete the data migration.

[0181] In this embodiment of the disclosure, the hot migration of virtual machine instances can be completed collaboratively by the master virtual machine hypervisor and the slave virtual machine hypervisor, thereby further improving the stability of the hot migration operation.

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

[0183] During implementation, after the live migration of the virtual machine instance on the second host is complete, it is necessary to destroy both the virtual machine instance and its shadow instance on the second host. Specifically, Nova calls the destruction interface of the LibvirtMaster on the second host, sending a destruction command to the LibvirtMaster. The LibvirtMaster resolves the domain name of the virtual machine instance from the destruction command. The LibvirtMaster then calls the corresponding LibvirtSlave destruction interface through the hypervisor to destroy the virtual machine instance on the second host. If the virtual machine instance is successfully destroyed, the LibvirtMaster destroys the shadow instance on the second host.

[0184] In this embodiment of the disclosure, when Nova determines that the data to be migrated has been migrated, Nova notifies the second host to destroy the virtual machine instance and shadow instance in order to collaboratively complete the post-hot migration processing.

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

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

[0187] In some embodiments, when the Nova establishes a connection with the master hypervisor using a first Internet Resource Identifier (URI), the Nova instructs the master hypervisor to use the slave 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$shadow instance.XML

[0190] The slave field value represents the IP address of the host machine's management channel network interface card.

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

[0192] In this embodiment of the disclosure, the first Internet Resource Identifier (URI) is used to instruct the main virtual machine hypervisor to adopt the collaborative management of the instance by the slave virtual machine hypervisor. Based on this instruction method, the main virtual machine hypervisor can conveniently understand that collaborative management of shadow instances and virtual machine instances needs to be implemented. This method is simple, fast, and easy to operate.

[0193] In some embodiments, when the Nova establishes a connection with the main hypervisor using a second Internet Resource Identifier URI, the Nova instructs the main hypervisor to manage instances using a single hypervisor model.

[0194] In practice, when the second Internet resource identifier URI is “qemu: / / / system”, it is used to instruct the main virtual machine management program to use the single virtual machine management program to collaboratively manage the instance, that is, the shadowless instance and the virtual machine instance collaborate.

[0195] In this embodiment of the disclosure, the first Internet Resource Identifier (URI) is used to instruct the main virtual machine management program to manage instances using a single virtual machine management program model. Based on this instruction method, the main virtual machine management program can easily understand 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, this disclosure also provides a virtual machine instance management device 1000, such as... Figure 10 As shown, it includes:

[0197] The sending module 1001 is used to send operation instructions 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;

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

[0199] In some embodiments, the hypervisor follows at least one of the following management rules:

[0200] If the operation instruction includes querying the status, return the 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, followed by virtual machine instance;

[0202] If the operation instruction includes destroying an instance, the instances are destroyed in the order of virtual machine instance first, followed by shadow instance;

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

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

[0205] The first instruction unit is configured to, when the operation instruction includes creating an instance, parse the instance data of the shadow instance from the operation instruction through the main virtual machine management program;

[0206] The first creation unit is used to create the shadow instance based on the instance data of the shadow instance through the main virtual machine management program;

[0207] The conversion unit is used to convert the metadata of the shadow instance into instance data suitable for the virtual machine instance of the first host machine through the main virtual machine hypervisor when the shadow instance is successfully created.

[0208] The second creation unit is used to call the instance definition interface of the slave virtual machine hypervisor through the master virtual machine hypervisor to 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 includes:

[0210] The second instruction unit is used to parse the unique identifier of the virtual machine instance from the operation instruction by the main virtual machine management program when the operation instruction includes deleting the instance;

[0211] The first deletion unit is used to send the unique identifier of the virtual machine instance to the slave virtual machine instance by calling the deletion interface of the slave virtual machine instance through the master virtual machine instance instance, so that the slave virtual machine instance instance is deleted by the slave virtual machine instance instance;

[0212] The second deletion unit is used by the main hypervisor to delete the shadow instance when it determines that the slave hypervisor is deleting the virtual machine instance.

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

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

[0215] The acquisition unit is used to send the unique identifier of the virtual machine instance to the slave virtual machine hypervisor by calling the query interface of the slave virtual machine hypervisor through the master virtual machine hypervisor, so as to obtain the metadata of the virtual machine instance;

[0216] The comparison unit is used to compare the metadata of the virtual machine instance and the metadata of the shadow instance through the main virtual machine hypervisor;

[0217] The sending unit is configured 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 and the metadata of the shadow instance are consistent.

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

[0219] The fourth instruction unit is used to start the shadow instance through the main virtual machine hypervisor when the operation instruction includes starting an instance;

[0220] The startup unit is used to start the virtual machine instance by calling the startup interface of the slave virtual machine hypervisor through the master virtual machine hypervisor when the shadow instance is successfully started.

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

[0222] The fifth instruction unit is used to destroy the virtual machine instance by calling the destruction interface of the slave virtual machine hypervisor through the master virtual machine hypervisor when the operation instruction includes destroying the instance;

[0223] The destruction unit is used to destroy the shadow instance through the main virtual machine hypervisor if the virtual machine instance is successfully destroyed.

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

[0225] The sixth instruction unit is configured to, when the operation instruction includes mounting the first target device, mount the first target device to the shadow instance through the main virtual machine management program based on the operation instruction;

[0226] The mounting unit is used to mount the first target device to the virtual machine instance by calling 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.

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

[0228] The seventh instruction unit is configured to, when the operation instruction includes unloading the second target device, call the unloading interface of the slave virtual machine hypervisor through the master virtual machine hypervisor to unload the second target device from the virtual machine instance;

[0229] An unloading unit is used to unload the second target device from the shadow instance through the main virtual machine if the second target device is successfully unloaded in the virtual machine instance.

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

[0231] When Nova receives a request to hot migrate the virtual machine instance to the first host machine, it generates an operation instruction to create an instance and sends it to the main virtual machine management program.

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

[0233] In some embodiments, a destruction module is also included, for:

[0234] Once the Nova determines that the data to be migrated has been migrated, it notifies the second host machine to destroy the virtual machine instance and the shadow instance on the second host machine.

[0235] 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.

[0236] In some embodiments, a first indication module is further included, for:

[0237] When the Nova establishes a connection with the master hypervisor using the first Internet Resource Identifier URI, the Nova instructs the master hypervisor to use the slave hypervisor to collaboratively manage the instance.

[0238] In some embodiments, a second indicating module is further included, for:

[0239] When the Nova establishes a connection with the main hypervisor using the second Internet Resource Identifier URI, the Nova instructs the main hypervisor to manage instances in a single hypervisor mode.

[0240] The specific functions and examples of each module and submodule of the apparatus in this disclosure can be found in the relevant descriptions of the corresponding steps in the above method embodiments, and will not be repeated here.

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

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

[0243] Figure 11A schematic block diagram of an example electronic device 1100 that can be used to implement embodiments 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 may also represent various forms of mobile devices, such as personal digital assistants, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

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

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

[0246] The computing unit 1101 can be various general-purpose and / or special-purpose 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 special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 1101 performs the various methods and processes described above, such as virtual machine instance management methods. For example, in some embodiments, the virtual machine instance management method may be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 1108. In some embodiments, part or all of the computer program may be loaded and / or installed on device 1100 via ROM 1102 and / or communication unit 1109. When the computer program is loaded into 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, computing unit 1101 may be configured to perform virtual machine instance management methods by any other suitable means (e.g., by means of firmware).

[0247] Various embodiments 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-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0248] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0249] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, 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 for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, 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 sound input, voice input, or tactile input).

[0251] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with embodiments of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0252] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact via communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other. Servers can be cloud servers, servers in distributed systems, or servers incorporating blockchain technology.

[0253] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this disclosure can be achieved, and this is not limited herein.

[0254] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A method for managing virtual machine instances, comprising: The smart card's computing control plane, Nova, sends operation instructions for the virtual machine instance to the smart card's main virtual machine management program. The master hypervisor manages the shadow instances of the virtual machine instance based on the operation instructions, and controls the slave hypervisor in the first host machine to manage the virtual machine instance. The main virtual machine hypervisor follows at least one of the following management rules: If the operation instruction includes querying the status, return the 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, followed by virtual machine instance; If the operation instruction includes destroying an instance, the instances are destroyed in the order of virtual machine instance first, followed by shadow instance; When the first host is shut down, the shadow instance is cleaned up based on the operation instructions.

2. The method according to claim 1, wherein, The process of managing shadow instances of virtual machine instances through the master hypervisor based on the operation instructions, and controlling slave hypervisors within the first host machine to manage the virtual machine instances, includes: If the operation instruction includes creating an instance, the instance data of the shadow instance is parsed from the operation instruction by the main virtual machine hypervisor; The shadow instance is created by the main hypervisor based on the instance data of the shadow instance; If the shadow instance is successfully created, the metadata of the shadow instance is converted into instance data suitable for the virtual machine instance of the first host machine by the main virtual machine hypervisor. The master hypervisor calls the instance definition interface of the slave hypervisor to send the instance data of the virtual machine instance to the slave hypervisor, so that the slave hypervisor can create the virtual machine instance.

3. The method according to claim 1, wherein, The process of managing shadow instances of virtual machine instances through the master hypervisor based on the operation instructions, and controlling slave hypervisors within the first host machine to manage the virtual machine instances, includes: If the operation instruction includes deleting an instance, the unique identifier of the virtual machine instance is parsed from the operation instruction by the main virtual machine hypervisor; The master hypervisor calls the deletion interface of the slave hypervisor to send the unique identifier of the virtual machine instance to the slave hypervisor, so that the slave hypervisor deletes the virtual machine instance; If the master hypervisor determines that the slave hypervisor has deleted the virtual machine instance, it deletes the shadow instance through the master hypervisor.

4. The method according to claim 1, wherein, The process of managing shadow instances of virtual machine instances through the master hypervisor based on the operation instructions, and controlling slave hypervisors within the first host machine to manage the virtual machine instances, includes: If the operation instruction includes querying the status, the unique identifier of the virtual machine instance is parsed from the operation instruction by the main virtual machine hypervisor; The master hypervisor calls the query interface of the slave hypervisor to send the unique identifier of the virtual machine instance to the slave hypervisor in order to obtain the metadata of the virtual machine instance; The main hypervisor compares the metadata of the virtual machine instance with the metadata of the shadow instance. If the hypervisor determines that the metadata of the virtual machine instance and the metadata of the shadow instance are consistent, the hypervisor sends the metadata of the virtual machine instance to Nova.

5. The method according to claim 1, wherein, The process of managing shadow instances of virtual machine instances through the master hypervisor based on the operation instructions, and controlling slave hypervisors within the first host machine to manage the virtual machine instances, includes: If the operation instruction includes starting an instance, the shadow instance is started through the main hypervisor. If the shadow instance is successfully started, the master hypervisor calls the startup interface of the slave hypervisor to start the virtual machine instance.

6. The method according to claim 1, wherein, The process of managing shadow instances of virtual machine instances through the master hypervisor based on the operation instructions, and controlling slave hypervisors within the first host machine to manage the virtual machine instances, includes: If the operation instruction includes destroying the instance, the virtual machine instance is destroyed by calling the destruction interface of the slave virtual machine hypervisor through the master virtual machine hypervisor; If the virtual machine instance is successfully destroyed, the shadow instance is destroyed through the main hypervisor.

7. The method according to claim 1, wherein, The process of managing shadow instances of virtual machine instances through the master hypervisor based on the operation instructions, and controlling slave hypervisors within the first host machine to manage the virtual machine instances, includes: If the operation instruction includes mounting a first target device, the main virtual machine management program mounts the first target device to the shadow instance based on the operation instruction; If the first target device is successfully mounted in the shadow instance, the master hypervisor calls the mount interface of the slave hypervisor to mount the first target device into the virtual machine instance.

8. The method according to claim 1, wherein, The process of managing shadow instances of virtual machine instances through the master hypervisor based on the operation instructions, and controlling slave hypervisors within the first host machine to manage the virtual machine instances, includes: If the operation instruction includes unloading the second target device, the second target device is unloaded from the virtual machine instance by calling the unloading interface of the slave virtual machine instance through the master virtual machine hypervisor; If the second target device is successfully uninstalled in the virtual machine instance, the second target device is uninstalled from the shadow instance through the main virtual machine.

9. The method according to claim 1, wherein, The step of sending operation instructions for the virtual machine instance to the main virtual machine management program of the smart card through the Nova computing control plane of the smart card includes: When Nova receives a request to hot migrate the virtual machine instance to the first host machine, it generates an operation instruction to create an instance and sends it to the main virtual machine management program. If the Nova determines that the main hypervisor has successfully created the virtual machine instance and the shadow instance, the Nova generates a data migration instruction for the main hypervisor to migrate the data to be migrated corresponding to the virtual machine instance from the second host machine to the first host machine.

10. The method of claim 9, further comprising: Once the Nova determines that the data to be migrated has been migrated, it notifies the second host machine to destroy the virtual machine instance and the shadow instance on the second host machine.

11. The method according to claim 1, wherein, The master virtual machine management program and the slave virtual machine management program communicate through the control channel between the smart card and the first host machine.

12. The method according to claim 1, further comprising: When the Nova establishes a connection with the master hypervisor using the first Internet Resource Identifier URI, the Nova instructs the master hypervisor to use the slave hypervisor to collaboratively manage the instance.

13. The method according to claim 1, further comprising: When the Nova establishes a connection with the main hypervisor using the second Internet Resource Identifier URI, the Nova instructs the main hypervisor to manage instances in a single hypervisor mode.

14. A virtual machine instance management device, comprising: The sending module is used to send operation instructions 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; The processing module is used to manage the shadow instances of virtual machine instances through the master virtual machine hypervisor based on the operation instructions, and to control the slave virtual machine hypervisor in the first host machine to manage the virtual machine instances. The main virtual machine hypervisor follows at least one of the following management rules: If the operation instruction includes querying the status, return the 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, followed by virtual machine instance; If the operation instruction includes destroying an instance, the instances are destroyed in the order of virtual machine instance first, followed by shadow instance; When the first host is shut down, the shadow instance is cleaned up based on the operation instructions.

15. The apparatus according to claim 14, wherein, The processing module includes: The first instruction unit is configured to, when the operation instruction includes creating an instance, parse the instance data of the shadow instance from the operation instruction through the main virtual machine management program; The first creation unit is used to create the shadow instance based on the instance data of the shadow instance through the main virtual machine management program; The conversion unit is used to convert the metadata of the shadow instance into instance data suitable for the virtual machine instance of the first host machine through the main virtual machine hypervisor when the shadow instance is successfully created. The second creation unit is used to call the instance definition interface of the slave virtual machine hypervisor through the master virtual machine hypervisor to 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.

16. The apparatus according to claim 14, wherein, The processing module includes: The second instruction unit is used to parse the unique identifier of the virtual machine instance from the operation instruction by the main virtual machine management program when the operation instruction includes deleting the instance; The first deletion unit is used to send the unique identifier of the virtual machine instance to the slave virtual machine instance by calling the deletion interface of the slave virtual machine instance through the master virtual machine instance instance, so that the slave virtual machine instance instance is deleted by the slave virtual machine instance instance; The second deletion unit is used by the main hypervisor to delete the shadow instance when it determines that the slave hypervisor is deleting the virtual machine instance.

17. The apparatus according to claim 14, wherein, The processing module includes: The third instruction unit is used to parse the unique identifier of the virtual machine instance from the operation instruction through the main virtual machine management program when the operation instruction includes a query status. The acquisition unit is used to send the unique identifier of the virtual machine instance to the slave virtual machine hypervisor by calling the query interface of the slave virtual machine hypervisor through the master virtual machine hypervisor, so as to obtain the metadata of the virtual machine instance; The comparison unit is used to compare the metadata of the virtual machine instance and the metadata of the shadow instance through the main virtual machine hypervisor; The sending unit is configured 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 and the metadata of the shadow instance are consistent.

18. The apparatus according to claim 14, wherein, The processing module includes: The fourth instruction unit is used to start the shadow instance through the main virtual machine hypervisor when the operation instruction includes starting an instance; The startup unit is used to start the virtual machine instance by calling the startup interface of the slave virtual machine hypervisor through the master virtual machine hypervisor when the shadow instance is successfully started.

19. The apparatus according to claim 14, wherein, The processing module includes: The fifth instruction unit is used to destroy the virtual machine instance by calling the destruction interface of the slave virtual machine hypervisor through the master virtual machine hypervisor when the operation instruction includes destroying the instance; The destruction unit is used to destroy the shadow instance through the main virtual machine hypervisor if the virtual machine instance is successfully destroyed.

20. The apparatus according to claim 14, wherein, The processing module includes: The sixth instruction unit is configured to, when the operation instruction includes mounting the first target device, mount the first target device to the shadow instance through the main virtual machine management program based on the operation instruction; The mounting unit is used to mount the first target device to the virtual machine instance by calling 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.

21. The apparatus according to claim 14, wherein, The processing module includes: The seventh instruction unit is configured to, when the operation instruction includes unloading the second target device, call the unloading interface of the slave virtual machine hypervisor through the master virtual machine hypervisor to unload the second target device from the virtual machine instance; An unloading unit is used to unload the second target device from the shadow instance through the main virtual machine if the second target device is successfully unloaded in the virtual machine instance.

22. The apparatus according to claim 14, wherein, The sending module is specifically used for: When Nova receives a request to hot migrate the virtual machine instance to the first host machine, it generates an operation instruction to create an instance and sends it to the main virtual machine management program. If the Nova determines that the main hypervisor has successfully created the virtual machine instance and the shadow instance, the Nova generates a data migration instruction for the main hypervisor to migrate the data to be migrated corresponding to the virtual machine instance from the second host machine to the first host machine.

23. The apparatus of claim 22, further comprising a destruction module, configured to: Once the Nova determines that the data to be migrated has been migrated, it notifies the second host machine to destroy the virtual machine instance and the shadow instance on the second host machine.

24. The apparatus according to claim 14, wherein, The master virtual machine management program and the slave virtual machine management program communicate through the control channel between the smart card and the first host machine.

25. The apparatus of claim 14, further comprising a first indicating module, configured to: When the Nova establishes a connection with the master hypervisor using the first Internet Resource Identifier URI, the Nova instructs the master hypervisor to use the slave hypervisor to collaboratively manage the instance.

26. The apparatus of claim 14, further comprising a second indicating module, configured to: When the Nova establishes a connection with the main hypervisor using the second Internet Resource Identifier URI, the Nova instructs the main hypervisor to manage instances in a single hypervisor mode.

27. 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 to enable the at least one processor to perform the method of any one of claims 1-13.

28. A non-transitory computer-readable storage medium storing computer instructions, wherein, The computer instructions are used to cause the computer to perform the method according to any one of claims 1-13.

29. A computer program product comprising a computer program that, when executed by a processor, implements the method according to any one of claims 1-13.

Images