Virtual machine management and control method and device, electronic equipment and storage medium

Abstract

The invention provides a virtual machine management and control method and device, electronic equipment and a storage medium, and relates to the technical field of computers, in particular to the application fields of cloud services, cloud computing, big data processing and the like. The specific implementation scheme comprises the steps of obtaining a virtual machine management and control request; generating a management and control operation instruction for the target virtual machine based on the virtual machine management and control request by using a computing node service deployed in the smart card; sending the management and control operation instruction to a virtualization management and control program deployed in the physical machine; wherein the virtualization management and control program is used for executing management and control operation for the target virtual machine based on the management and control operation instruction.

Description

Technical Field

[0001] The present disclosure relates to the field of computer technology, and in particular to application fields such as cloud services, cloud computing, and big data processing, and specifically to a virtual machine management and control method, device, electronic device, and storage medium. Background Art

[0002] With the development of computer technology, virtual machine technology has emerged to meet users' needs for more efficient and flexible use of computing resources. Through this technology, multiple virtual machines can be created from a physical machine, and each virtual machine can independently run its own operating system and application programs. Summary of the invention

[0003] The present invention provides a virtual machine management method, device, electronic device and storage medium.

[0004] According to a first aspect of the present disclosure, a virtual machine management and control method is provided, which is applied to a smart card included in a virtual machine management and control system, wherein the virtual machine management and control system also includes a physical machine; the method includes:

[0005] Get virtual machine control request;

[0006] Using the computing node service deployed on the smart card, based on the virtual machine control request, a control operation instruction for the target virtual machine is generated;

[0007] The control operation instruction is sent to the virtualization control program deployed on the physical machine; wherein the virtualization control program is used to perform the control operation on the target virtual machine based on the control operation instruction.

[0008] According to a second aspect of the present disclosure, a virtual machine management and control method is provided, which is applied to a physical machine included in a virtual machine management and control system, wherein the virtual machine management and control system further includes a smart card, the smart card is used to obtain a virtual machine management and control request, and utilize a computing node service deployed on the smart card to generate a management and control operation instruction for a target virtual machine based on the virtual machine management and control request; the method includes:

[0009] Receive control and operation instructions;

[0010] Based on the control operation instruction, perform control operations on the target virtual machine.

[0011] According to a third aspect of the present disclosure, a virtual machine management and control device is provided, which is applied to a smart card included in a virtual machine management and control system, wherein the virtual machine management and control system also includes a physical machine; the device includes:

[0012] A request acquisition unit, used to acquire a virtual machine control request;

[0013] An instruction generating unit, configured to generate a control operation instruction for a target virtual machine based on a virtual machine control request by using a computing node service deployed on a smart card;

[0014] The instruction sending unit is used to send the control operation instruction to the virtualization control program deployed on the physical machine; wherein the virtualization control program is used to perform the control operation on the target virtual machine based on the control operation instruction.

[0015] According to a fourth aspect of the present disclosure, a virtual machine control device is provided, which is applied to a physical machine included in a virtual machine control system, wherein the virtual machine control system further includes a smart card, the smart card is used to obtain a virtual machine control request, and generate a control operation instruction for a target virtual machine based on the virtual machine control request by using a computing node service deployed on the smart card; the device includes:

[0016] An instruction receiving unit, used for receiving control operation instructions;

[0017] The control operation unit is used to perform control operations on the target virtual machine based on the control operation instruction.

[0018] According to a fifth aspect of the present disclosure, there is provided an electronic device, including:

[0019] at least one processor;

[0020] a memory communicatively coupled to the at least one processor;

[0021] 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 the method provided in the first aspect of the present disclosure.

[0022] According to a sixth 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 the method provided according to the first aspect of the present disclosure.

[0023] According to a seventh aspect of the present disclosure, a computer program product is provided, comprising a computer program, which implements the method provided according to the first aspect of the present disclosure when executed by a processor.

[0024] The use of the present disclosure can greatly promote the rational use of physical machine resources and avoid unnecessary waste of resources.

[0025] 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

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

[0027] Figure 1 It is a schematic diagram of resource occupation of a physical machine in the prior art;

[0028] Figure 2 A flowchart of a virtual machine management and control method provided in an embodiment of the present disclosure;

[0029] Figure 3 A schematic diagram of a device mounting process provided by an embodiment of the present disclosure;

[0030] Figure 4 A schematic diagram of a device uninstallation process provided by an embodiment of the present disclosure;

[0031] Figure 5 A schematic diagram of a target virtual machine definition process provided by an embodiment of the present disclosure;

[0032] Figure 6 A schematic diagram of a startup process of a target virtual machine provided in an embodiment of the present disclosure;

[0033] Figure 7 A port allocation diagram provided for an embodiment of the present disclosure;

[0034] Figure 8 A schematic diagram of a shutdown process of a target virtual machine provided in an embodiment of the present disclosure;

[0035] Fig. 9 A schematic diagram of a target virtual machine destruction process provided by an embodiment of the present disclosure;

[0036] Fig.10 A schematic diagram of a target virtual machine deletion process provided by an embodiment of the present disclosure;

[0037] Fig.11 A schematic diagram of an architecture for acquiring network disk monitoring data provided by an embodiment of the present disclosure;

[0038] Fig.12 A flowchart of a virtual machine management and control method provided in an embodiment of the present disclosure;

[0039] Fig.13 A schematic diagram of the overall framework of a virtual machine management and control system provided in an embodiment of the present disclosure;

[0040] Fig.14 A schematic diagram of the logical architecture of a virtual machine management system provided in an embodiment of the present disclosure;

[0041] Fig.15 A schematic structural block diagram of a virtual machine control device provided in an embodiment of the present disclosure;

[0042] Fig.16 A schematic structural block diagram of a virtual machine control device provided in an embodiment of the present disclosure;

[0043] Fig.17 A schematic structural block diagram of an electronic device provided in an embodiment of the present disclosure. DETAILED DESCRIPTION

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

[0045] like Figure 1 As shown, in the prior art, before creating multiple virtual machines from a physical machine, a large proportion of physical machine resources (e.g., more than 16%) is usually reserved to bear virtualization overhead, which will cause serious waste of physical machine resources. For example, to simulate N virtual machines with the specification of "total number of cores of the physical machine M / N", at least two physical machines need to be prepared, and at least one of the two physical machines cannot be effectively used, thus causing serious waste of physical machine resources.

[0046] In view of the above problems, the embodiments of the present disclosure provide a virtual machine management and control method, which can be applied to a smart card included in a virtual machine management and control system. The smart card can be a card-type device that integrates a microprocessor and a storage unit, or it can be understood as a server-like device. In addition, in the embodiments of the present disclosure, the virtual machine management and control system also includes a physical machine. The physical machine can be a server that needs to be used to create multiple virtual machines. Figure 2 The flowchart diagram shown illustrates a virtual machine management and control method provided by an embodiment of the present disclosure. It should be noted that although the logical order is shown in the flowchart diagram, in some cases, the steps shown or described in the flowchart can also be performed in other orders.

[0047] Step S201: Obtain a virtual machine control request.

[0048] The virtual machine control request may be issued by a user to request a control operation to be performed on a target virtual machine.

[0049] Step S202: utilizing the computing node service (Nova Compute) deployed on the smart card to generate a control operation instruction for the target virtual machine based on the virtual machine control request.

[0050] Nova Compute is a service component responsible for managing and controlling a virtual machine (eg, a target virtual machine).

[0051] In the disclosed embodiment, Nova Compute can generate a control operation instruction for the target virtual machine based on the virtual machine control request. In one example, Nova Compute can provide backend resources (e.g., network disk and / or network port) for the target virtual machine based on the virtual machine control request, and generate a control operation instruction for the target virtual machine. The control operation instruction can be a device mount instruction and / or a device uninstall instruction for the target virtual machine, or other operation instructions related to the life cycle of the target virtual machine, for example, at least one of a definition instruction, a power-on instruction, a power-off instruction, a destruction instruction, and a deletion instruction.

[0052] Step S203: Send the control operation instruction to the virtualization control program (Libvirtd) deployed on the physical machine.

[0053] Libvirtd is a daemon process of the virtual machine manager (Libvirt), which is responsible for managing and controlling virtual machines (e.g., target virtual machines). Based on this, in the embodiments of the present disclosure, Libvirtd can be used to perform management and control operations on target virtual machines based on management and control operation instructions.

[0054] In addition, it should be noted that, in the embodiments of the present disclosure, Libvirt may be a virtualization management toolkit, which may specifically provide an open source project with a virtual machine management and control tool.

[0055] The virtual machine control method provided by the embodiment of the present disclosure can obtain a virtual machine control request, and use Nova Compute deployed on the smart card to generate a control operation instruction for the target virtual machine based on the virtual machine control request, and then send the control operation instruction to Libvirtd deployed on the physical machine, so that Libvirtd can perform the control operation on the target virtual machine based on the control operation instruction. In other words, in the embodiment of the present disclosure, a smart card independent of the physical machine is expanded. Based on the smart card, not only can part of the control process for the target virtual machine be transplanted from the physical machine to the smart card, but also Nova Compute deployed on the smart card can be used to provide backend resources for the target virtual machine, which can reduce the virtualization overhead that the physical machine needs to bear. Therefore, it can greatly promote the rational use of physical machine resources and avoid unnecessary waste of resources.

[0056] In one example, “generating a control operation instruction for a target virtual machine based on the virtual machine control request” in step S202 may include:

[0057] Parse the virtual machine control request to obtain the control intention information for the target virtual machine;

[0058] Based on the control intention information, generate control operation instructions for the target virtual machine.

[0059] The control intention represented by the control intention information may include at least one of the following:

[0060] Mount virtual devices on the target virtual machine, uninstall virtual devices from the target virtual machine, define the target virtual machine, power on the target virtual machine, shut down the target virtual machine, destroy the target virtual machine, and delete the target virtual machine.

[0061] After obtaining the control intention information, a control operation instruction for the target virtual machine can be generated based on the control intention information. The control operation instruction may include at least one of a device mount instruction, a device uninstall instruction, a definition instruction, a power-on instruction, a power-off instruction, a destruction instruction, and a deletion instruction. Here, the device mount instruction is used to indicate mounting a virtual device on the target virtual machine; the device uninstall instruction is used to indicate uninstalling a virtual device from the target virtual machine; the definition instruction is used to indicate defining the target virtual machine; the power-on instruction is used to indicate powering on the target virtual machine; the shutdown instruction is used to indicate powering off the target virtual machine; the destruction instruction is used to indicate destroying the target virtual machine; and the deletion instruction is used to indicate deleting the target virtual machine.

[0062] Through the above method, in the embodiment of the present disclosure, the virtual machine control request can be parsed to obtain the control intention information for the target virtual machine, and based on the control intention information, the control operation instructions for the target virtual machine can be generated. In this way, not only can the control operation instructions be highly consistent with the control intention information, but also a solid foundation can be provided for the future expansion and adaptation of new needs of the virtual machine control system through standardized control operation instructions. In addition, in the embodiment of the present disclosure, since the control operation instructions can include at least one of a device mount instruction, a device uninstall instruction, a definition instruction, a power-on instruction, a power-off instruction, a destruction instruction, and a deletion instruction, the flexibility and practicality of the virtual machine control method can be ensured.

[0063] The following will describe the generation process of a device mount instruction, a device unmount instruction, a definition instruction, a power on instruction, a power off instruction, a destruction instruction, and a deletion instruction.

[0064] 1. The process of generating device mount instructions

[0065] (1) When the control intention represented by the control intention information is to mount a virtual device on a target virtual machine, a first virtual device is selected from a plurality of candidate virtual devices allocated to the target virtual machine.

[0066] Among them, multiple candidate virtual devices may include multiple virtual block devices (also known as Virtio Block VF) and multiple virtual network devices. Here, multiple virtual network devices may include multiple auxiliary network cards (also known as Virtio NetVF) and multiple primary network cards (also known as Rdma VF) that support remote direct memory access (RDMA) function. It should be noted that in the disclosed embodiment, each of the multiple candidate virtual devices has its own identification information (for example, index number (also known as Index)). For example, if there are N1 Virtio Block VFs among the multiple candidate virtual devices, the identification information of these N1 Virtio Block VFs can be: 0, 1, 2, 3...N1-1.

[0067] In addition, it should be noted that in the embodiment of the present disclosure, after determining the multiple candidate virtual devices to be allocated to the target virtual machine, a candidate virtual device that matches the management and control intention information and is idle can be selected from the multiple candidate virtual devices as the first virtual device. In one example, a list of unallocated index numbers can be determined from a total index bitmap associated with multiple candidate virtual devices, and an unallocated index number can be obtained from the index number list, and then when the candidate virtual device corresponding to the unallocated index number matches the management and control intention information, the candidate virtual device can be used as the first virtual device. At this time, the "unallocated index number" corresponding to the first virtual device is the identification information of the first virtual device.

[0068] (2) Bind the first virtual device to the first backend resource.

[0069] Among them, the first backend resource can be a cloud storage service (CloudDisk Service, CDS) provided by a block server (Block Server), or it can be a virtual network port created on a smart card, specifically a quantum virtual port (Quantum Virtual Port, QVO), more specifically, it can be a QVO created on the bridge device of the smart card. For the convenience of distinction, the CDS here can be defined as the first network disk. Based on this, in the embodiment of the present disclosure, when the first virtual device belongs to Virtio Block VF, the first network disk can be used as the first backend resource and bound to the first virtual device; when the first virtual device belongs to Virtio Net VF or Rdma VF, the first network port can be used as the first backend resource and bound to the first virtual device.

[0070] (3) Generate a device mounting instruction that carries the control intention information and the first device identifier.

[0071] The first device identifier is the identifier information of the first virtual device.

[0072] After selecting a first virtual device from multiple candidate virtual devices allocated to the target virtual machine and binding the first virtual device to the first backend resource to generate a device mount instruction carrying the control intention information and the first device identifier, the device mount instruction can be sent to Libvirtd deployed on the physical machine, so that Libvirtd can be used to mount the first virtual device on the target virtual machine based on the device mount instruction. Figure 3 , the process is further explained.

[0073] First, enter the preparation stage of the first virtual device:

[0074] Step S301: Nova Compute selects a first virtual device from a plurality of candidate virtual devices allocated to a target virtual machine.

[0075] Step S302: Nova Compute binds the first virtual device to the first backend resource.

[0076] In one example, when the first virtual device belongs to Virtio Block VF, the first network disk can be used as the first backend resource and bound to the first virtual device; when the first virtual device belongs to Virtio Net VF or RdmaVF, the first network port can be used as the first backend resource and bound to the first virtual device. Specifically, when the first virtual device belongs to Virtio Block VF, the first preset script (for example, Bf3-Volume-Ops.Py script) can be called to use the first network disk as the first backend resource and bind to the first virtual device; when the first virtual device belongs to Virtio Net VF or Rdma VF, the second preset script (for example, Bf3-Net-Ops.Py script) can be called to use the first network port as the first backend resource and bind to the first virtual device.

[0077] After Nova Compute calls the first preset script and the second preset script to successfully bind the first virtual device to the first backend resource, the first preset script and the second preset script send first feedback information to Nova Compute to indicate that the first virtual device is successfully bound to the first backend resource.

[0078] After the binding is successful, step S303 may be executed.

[0079] Step S303, Nova Compute generates a device mounting instruction (also called first device XML) carrying the control intention information and the first device identifier.

[0080] As mentioned above, the first device identifier is identification information of the first virtual device.

[0081] Then, enter the stage of mounting the first virtual device in the Live state and the Config state:

[0082] Step S304: Nova Compute sends the first device XML to a virtual machine development tool (Libvirt Python) deployed on the smart card.

[0083] Libvirt Python is an extension library of the Python programming language, which encapsulates some application programming interface (API) calling methods related to Libvirtd. Therefore, Libvirt Python can more easily realize the interaction between Nova Compute and Libvirtd.

[0084] Step S305: Libvirt Python sends the first device XML to Libvirtd deployed on the physical machine.

[0085] In one example, Libvirt Python may call Libvirtd through a preset dynamic library (eg, Libvirt.so dynamic library) deployed on the smart card side, and pass the first device XML to Libvirtd.

[0086] Step S306: Libvirtd parses the first device identifier carried in the first device XML to obtain first device addressing information (Bus, Device, Function, BDF) of the first virtual device.

[0087] Step S307: Libvirtd hosts the first virtual device to a virtual machine host (also called Vfe Vhostd) deployed on the physical machine based on the first BDF.

[0088] In one example, Libvirtd can communicate through virtual machine management and control software (eg, Vfe Vhost Cli) and, based on the first BDF, host the first virtual device to Vfe Vhostd deployed on the physical machine.

[0089] In addition, it can be understood that in the embodiment of the present disclosure, after successfully hosting the first virtual device, Vfe Vhostd will send second feedback information to Libvirtd to indicate that the first virtual device has been successfully hosted to Vfe Vhostd.

[0090] Step S308, Libvirtd sends a device mount request for the target virtual machine to a Quick Emulator (Qemu) deployed on the physical machine.

[0091] Among them, the device mount request is generated based on the first device XML; Qemu can mount the first virtual device to the target virtual machine as a component of the target virtual machine in response to the device mount request; after receiving the device mount request, Qemu will send third feedback information to Libvirtd to indicate that the device mount request has been successfully received; Qemu will also send fourth feedback information to Libvirtd to indicate that the first virtual device has been successfully mounted to the target virtual machine after successfully mounting the first virtual device to the target virtual machine in response to the device mount request.

[0092] In addition, it should be noted that, in the embodiment of the present disclosure, after Libvirtd sends the device mount request for the target virtual machine to Qemu, Qemu can communicate with Vfe Vhostd based on the first BDF.

[0093] Step S309: Libvirtd updates the Live status of the first virtual device.

[0094] The Live state of the first virtual device is the running state of the first virtual device.

[0095] Step S310: Libvirtd updates the Config state of the first virtual device.

[0096] The Config state of the first virtual device is the configuration state of the first virtual device.

[0097] After updating the Live state and the Config state of the first virtual device, Libvirtd sends fifth feedback information indicating that the first virtual device has been mounted to LibvirtPython, and Libvirt Python sends the fifth feedback information to Nova Compute.

[0098] Step S311: Nova Compute requests Libvirtd to check whether the first virtual device is successfully mounted to the target virtual machine.

[0099] Step S312: Libvirtd checks whether the first virtual device is successfully mounted to the target virtual machine.

[0100] Libvirtd can check whether the first virtual device is successfully mounted to the target virtual machine by checking the Live state and the Config state of the first virtual device, and send the sixth feedback information carrying the check result to Nova Compute.

[0101] In the above process, when the control intention represented by the control intention information is to mount a virtual device on the target virtual machine, on the smart card side, Nova Compute is used to select the first virtual device from multiple candidate virtual devices allocated to the target virtual machine, and the first virtual device is bound to the first backend resource, and then a device mounting instruction carrying the control intention information and the first device identifier is generated. In other words, when mounting a virtual device on the target virtual machine, a relatively large number of control processes for the target virtual machine will be completed on the smart card, and Nova Compute will be used to provide the target virtual machine with backend resources (here, specifically the first backend resources, including the first network disk and / or the first network port), thereby reducing the occupation of physical machine resources. Therefore, the virtualization overhead that the physical machine needs to bear can be effectively reduced.

[0102] 2. Generation process of device uninstallation instructions

[0103] When the control intention represented by the control intention information is to uninstall the virtual device from the target virtual machine, a device uninstallation indication carrying the control intention information and the second device identifier is generated.

[0104] The second device identifier is identification information of a second virtual device that needs to be uninstalled from the target virtual machine.

[0105] In one example, after generating a device uninstallation instruction that carries the control intention information and the second device identifier, the device uninstallation instruction can be sent to Libvirtd deployed on the physical machine, so that Libvirtd can uninstall the second virtual device from the target virtual machine based on the device uninstallation instruction. Thereafter, Nova Compute can be used to generate a first recycling instruction for the target virtual machine, and based on the first recycling instruction, the second backend resource bound to the second virtual device is deleted to release the second virtual device, and then the second virtual device is recycled. Figure 4 , the process is further explained.

[0106] Step S401, Nova Compute generates a device uninstallation instruction (also called second device XML) carrying control intention information and a second device identifier.

[0107] As mentioned above, the second device identifier is identification information of the second virtual device.

[0108] Step S402: Nova Compute sends the second device XML to Libvirt Python deployed on the smart card.

[0109] Step S403: Libvirt Python sends the second device XML to Libvirtd deployed on the physical machine.

[0110] Step S404: Libvirtd sends a device deletion request for the target virtual machine to Qemu deployed on the physical machine.

[0111] Among them, the device deletion request is generated based on the second device XML; Qemu can delete the second virtual device from the target virtual machine in response to the device deletion request; after receiving the device deletion request, Qemu will send the seventh feedback information used to indicate that the device deletion request has been successfully received to Libvirtd; Qemu will also send the eighth feedback information used to indicate that the second virtual device has been successfully deleted from the target virtual machine after deleting the second virtual device from the target virtual machine in response to the device deletion request.

[0112] Step S405: Libvirtd parses the second device identifier of the second virtual device carried in the second device XML to obtain a second BDF of the second virtual device.

[0113] Step S406: Libvirtd notifies Vfe Vhostd to release the hosting of the second virtual device based on the second BDF.

[0114] After Vfe Vhostd successfully releases the hosting of the second virtual device, ninth feedback information indicating that the hosting of the second virtual device has been successfully released is sent to Libvirtd.

[0115] Step S407: Libvirtd updates the Live status of the second virtual device.

[0116] The Live state of the second virtual device is the running state of the second virtual device.

[0117] Step S408: Libvirtd updates the Config state of the second virtual device.

[0118] The Config state of the second virtual device is the configuration state of the second virtual device.

[0119] After updating the Live state and the Config state of the second virtual device, Libvirtd sends tenth feedback information indicating that the second virtual device has been completely uninstalled to LibvirtPython, and then Libvirt Python sends the tenth feedback information to Nova Compute.

[0120] Step S409: Nova Compute requests Libvirtd to check whether the second virtual device is uninstalled successfully.

[0121] Step S410, Libvirtd checks whether the second virtual device is uninstalled successfully.

[0122] Libvirtd can check whether the second virtual device is successfully uninstalled by checking the Live state and the Config state of the second virtual device, and send the eleventh feedback information carrying the inspection result to NovaCompute.

[0123] Step S411: Nova Compute generates a first recycling instruction for the target virtual machine, and based on the first recycling instruction, deletes the second backend resource bound to the second virtual device.

[0124] In one example, when the second virtual device belongs to Virtio Block VF, the second backend resource bound to the second virtual device is the second network disk, so the second network disk bound to the second virtual device can be deleted; when the second virtual device belongs to Virtio Net VF or Rdma VF, the second backend resource bound to the second virtual device is the second network port, so the second network port bound to the second virtual device can be deleted. Specifically, when the second virtual device belongs to Virtio Blk VF, the third preset script (for example, Bf3-Volume-Ops.Py script) can be called to delete the second network disk bound to the second virtual device; when the second virtual device belongs to Virtio Net VF or Rdma VF, the fourth preset script (for example, Bf3-Net-Ops.Py script) can be called to delete the second network port bound to the second virtual device.

[0125] After Nova Compute calls the third preset script and the fourth preset script to delete the second network port bound to the second virtual device, the third preset script and the fourth preset script send twelfth feedback information to Nova Compute for indicating that the first virtual device is successfully bound to the first backend resource.

[0126] Step S412: Recycling the second virtual device.

[0127] For example, the second virtual device may be used as an idle candidate virtual device corresponding to the target virtual machine, that is, the second device identifier is put into a list of unassigned index numbers related to the target virtual machine to implement recycling of the second device identifier.

[0128] In the above process, when the control intention represented by the control intention information is to uninstall the virtual device from the target virtual machine, a device uninstallation instruction carrying the control intention information and the second device identifier will be generated, that is, part of the control process for the target virtual machine can be transplanted from the physical machine to the smart card, thereby effectively reducing the virtualization overhead that the physical machine needs to bear; and after the device uninstallation instruction is sent to Libvirtd deployed on the physical machine, and the second virtual device is uninstalled from the target virtual machine based on the device uninstallation instruction by Libvirtd, Nova Compute will be used to generate a first recycling instruction for the target virtual machine, and based on the first recycling instruction, the second backend resource bound to the second virtual device is deleted to release the second virtual device. In this way, the effective use of virtual devices can be achieved through the recycling of the second virtual device.

[0129] 3. Defining the Generation Process of Instructions

[0130] (1) When the control intention represented by the control intention information is to define a target virtual machine, multiple candidate virtual devices are allocated to the target virtual machine.

[0131] In one example, a plurality of candidate virtual devices may be allocated to the target virtual machine according to the specification of the target virtual machine.

[0132] (2) The multiple identification information and the configuration information of the target virtual machine are used together as the overall description information of the target virtual machine.

[0133] Among them, multiple identification information corresponds one-to-one to multiple candidate virtual machines; the configuration information of the target virtual machine may include chipset type, peripheral component interconnect (PCI) bus architecture, device form information (for example, system disk / primary network card, graphics card, serial port, memory (Ballon), keyboard and mouse, clock device form information), firmware information (for example, basic input and output system (BIOS) information, motherboard information), system information, etc.

[0134] (3) Generate definition instructions that carry control intent information and overall description information.

[0135] In one example, after generating a definition instruction carrying control intent information and overall description information, the definition instruction can be sent to Libvirtd deployed on a physical machine, so that Libvirtd can define a target virtual machine based on the definition instruction. Figure 5 , the process is further explained.

[0136] Step S501: Nova Compute allocates multiple candidate virtual devices to a target virtual machine.

[0137] Step S502: Nova Compute sends a definition instruction to Libvirt Python deployed on the smart card.

[0138] The definition indication may carry control intention information and overall description information. Here, the overall description information may include multiple indexes and configuration information of the target virtual machine, and the multiple identification information corresponds to the multiple candidate virtual devices one by one.

[0139] Step S503: Libvirt Python notifies Libvirtd to define a target virtual machine.

[0140] In one example, Libvirt Python may call a first preset interface (eg, LibvirtPythondefineXML interface) to notify Libvirtd to define a target virtual machine.

[0141] After Libvirt Python notifies Libvirtd to define the target virtual machine, Libvirtd enters the process of defining the target virtual machine and sends Libvirt Python the thirteenth feedback information used to indicate that the definition of the target virtual machine has been completed. Libvirt Python then sends the thirteenth feedback information to Nova Compute.

[0142] In the above process, when the control intention represented by the control intention information is to define the target virtual machine, multiple candidate virtual devices will be allocated to the target virtual machine, and multiple indexes and the configuration information of the target virtual machine will be used together as the overall description information of the target virtual machine, and then a definition instruction carrying the control intention information and the overall description information will be generated. In other words, when defining the target virtual machine, relatively more control processes are completed on the smart card, so the virtualization overhead that the physical machine needs to bear can be further reduced.

[0143] 4. The process of generating the power-on instruction

[0144] (1) When the control intention represented by the control intention information is to power on the target virtual machine, a third virtual device is selected from a plurality of candidate virtual devices allocated to the target virtual machine.

[0145] Among them, the multiple candidate virtual devices may include multiple Virtio Blokk VFs and multiple virtual network devices. Here, the multiple virtual network devices may include multiple Virtio Net VFs and multiple Rdma VFs that support RDMA functions. It should be noted that in the disclosed embodiment, each candidate virtual device in the multiple candidate virtual devices has its own identification information. For example, if there are N1 Virtio Block VFs in the multiple candidate virtual devices, the identification information of these N1 Virtio Block VFs can be: 0, 1, 2, 3...N1-1.

[0146] In addition, it should be noted that in the embodiment of the present disclosure, after determining the multiple candidate virtual devices to be allocated to the target virtual machine, a candidate virtual device that matches the management and control intention information and is idle can be selected from the multiple candidate virtual devices as the third virtual device. In one example, a list of unallocated index numbers can be determined from a total index bitmap associated with multiple candidate virtual devices, and an unallocated index number can be selected from the index number list, and then when the candidate virtual device corresponding to the unallocated index number matches the management and control intention information, the candidate virtual device is used as the third virtual device. At this time, the "unallocated index number" corresponding to the third virtual device is the identification information of the third virtual device.

[0147] (2) Bind the third virtual device to the third backend resource.

[0148] Among them, the third backend resource can be a CDS provided by a block server, or it can be a virtual network port created on a smart card, specifically a QVO, and more specifically a QVO created on a bridge device of a smart card. For easy distinction, the CDS here can be defined as a third network disk. Based on this, in the embodiment of the present disclosure, when the third virtual device belongs to Virtio Block VF, the third network disk can be used as the third backend resource and bound to the third virtual device; when the third virtual device belongs to Virtio Net VF or Rdma VF, the third network port can be used as the third backend resource and bound to the third virtual device.

[0149] (3) Send the redefinition instruction carrying the control intent information and overall description information to Libvirtd.

[0150] The overall description information includes a plurality of identification information corresponding to a plurality of candidate virtual devices one by one, and configuration information of the target virtual machine.

[0151] (4) Upon receiving the redefinition feedback information returned by Libvirtd, a power-on instruction carrying the control intention information and the third device identifier is generated.

[0152] As mentioned above, the third device identifier is identification information of the third virtual device.

[0153] After selecting a third virtual device from multiple candidate virtual devices allocated to the target virtual machine, binding the third virtual device to the third backend resource, and sending a redefinition instruction carrying the control intention information and the overall description information to Libvirtd, and then receiving the redefinition feedback information returned by Libvirtd and generating a power-on instruction carrying the control intention information and the third device identifier, the power-on instruction can be sent to Libvirtd deployed on the physical machine, so that the target virtual machine can be powered on by Libvirtd. Figure 6 , the process is further explained.

[0154] Step S601: Nova Compute selects a third virtual device from a plurality of candidate virtual devices allocated to a target virtual machine.

[0155] Step S602: Nova Compute binds the third virtual device to the third backend resource.

[0156] In one example, when the third virtual device belongs to Virtio Block VF, the third network disk can be used as the third backend resource and bound to the third virtual device; when the third virtual device belongs to Virtio Net VF or RdmaVF, the third network port can be used as the third backend resource and bound to the third virtual device. Specifically, when the third virtual device belongs to Virtio Block VF, the fifth preset script (for example, Bf3-Volume-Ops.Py script) can be called to use the third network disk as the third backend resource and bind to the third virtual device; when the third virtual device belongs to Virtio Net VF or Rdma VF, the sixth preset script (for example, Bf3-Net-Ops.Py script) can be called to use the third network port as the third backend resource and bind to the third virtual device.

[0157] After Nova Compute calls the fifth preset script and the sixth preset script to successfully bind the third virtual device to the third backend resource, the fifth preset script and the sixth preset script will send to Nova Compute fourteenth feedback information indicating that the third virtual device is successfully bound to the third backend resource.

[0158] After the binding is successful, step S603 may be executed.

[0159] In step S603, Nova Compute sends a redefinition instruction (also called Define XML) carrying the control intention information and the overall description information to Libvirtd.

[0160] The overall description information includes a plurality of identification information corresponding to a plurality of candidate virtual devices one by one, and configuration information of the target virtual machine.

[0161] In addition, in the embodiment of the present disclosure, after receiving the Define XML, Libvirtd will send a fifteenth feedback message to Nova Compute to indicate that the Define XML has been successfully received.

[0162] Step S604: Nova Compute generates a power-on instruction carrying the control intention information and the third device identifier.

[0163] As mentioned above, the third device identifier is identification information of the third virtual device.

[0164] In one example, Nova Compute can call a second preset interface (e.g., LibvirtPythondefineXML interface) to redefine the domain information of the target virtual machine, and call a third preset interface (e.g., CreateWithFlags interface) to send a power-on request to Libvirtd, that is, generate a power-on instruction carrying the control intent information and the third device identifier, and send it to Libvirtd.

[0165] Step S605, Libvirtd prepares the RDMA device.

[0166] When the third virtual device belongs to Rdma VF, the RDMA device can be obtained based on the third virtual device bound to the third network port; when the third virtual device does not belong to Rdma VF, a virtual device can be reselected from multiple candidate virtual devices to obtain the RDMA device, which will not be described in detail here.

[0167] Step S606, Libvirtd requests Vfe Vhostd deployed on the physical machine to prepare the Vhost device.

[0168] Among them, the preparation of the Vhost device can be to host the third virtual device to the Vhost device.

[0169] In addition, in the embodiment of the present disclosure, after preparing the Vhost device, Vfe Vhostd will send the sixteenth feedback information to Libvirtd to indicate that the preparation of the Vhost device has been completed.

[0170] Step S607, Libvirtd sends a Qemu process start request to Qemu deployed on the physical machine to control the start of the Qemu process.

[0171] After the Qemu process is started, it can communicate with Vfe Vhostd.

[0172] In addition, in the embodiment of the present disclosure, after the Qemu process is started, the seventeenth feedback information is sent to Libvirtd to indicate that the Qemu process has been started.

[0173] Step S608: Libvirtd requests to check the running status of Qemu.

[0174] Libvirtd also receives the eighteenth feedback information sent by Qemu to Nova Compute to characterize the state detection result of Qemu (for example, Power State: Runninglpgopause).

[0175] Step S609: Nova Compute cyclically sends a power status detection request for the target virtual machine to Libvirtd.

[0176] After Nova Compute sends a power status detection request for the target virtual machine to Libvirtd, it receives nineteenth feedback information sent by Libvirtd to characterize the power status of the target virtual machine.

[0177] In the above process, when the control intention represented by the control intention information is to power on the target virtual machine, a third virtual device will be selected from multiple candidate virtual devices allocated to the target virtual machine, and the third virtual device will be bound to the third backend resource, and then the redefinition instruction carrying the control intention information and the overall description information will be sent to Libvirtd, so that when the redefinition feedback information returned by Libvirtd is received, a power-on instruction carrying the control intention information and the third device identifier will be generated. In other words, when the target virtual machine is powered on, a relatively large number of control processes for the target virtual machine will be completed on the smart card, and Nova Compute will be used to provide the target virtual machine with backend resources (here, specifically the third backend resources, including the third network disk and / or the third network port), thereby reducing the occupation of physical machine resources. Therefore, the virtualization overhead that the physical machine needs to bear can be effectively reduced.

[0178] In addition, it should be noted that, in the embodiment of the present disclosure, when generating a power-on instruction carrying the control intention information and the third device identifier, a power-on instruction carrying the control intention information, the third device identifier and the smart card port range data can be specifically generated. In this way, the smart card port range data can be sent to Libvirtd to ensure that the target virtual machine can communicate with the external network normally and stably.

[0179] Relatedly, the disclosed embodiment also provides a second method for sending smart card port range data to Libvirtd. Specifically, multiple port range mapping (also known as Iptbales port mapping) can be used to create source network address translation (SNAT) and destination network address translation (DNAT) rules, thereby implementing virtual network computing (VNC) port allocation.

[0180] Please combine Figure 7For example, when an external network wants to access any virtual machine created on a physical machine, it will first enter through the entry address (i.e., 169.254.62.1), and according to the rules of DNAT, based on the target port number (e.g., a port in the range of 5900 to 6899), the network traffic accessing VNC will be routed to the intermediate address (i.e., 169.254.62.129), and then further routed to the corresponding Qemu virtual machine through a specific port. On the contrary, when a Qemu virtual machine needs to communicate with an external network, it can send the VNC traffic to the external address through the entry address according to the rules of SNAT.

[0181] The following describes the VNC port allocation process:

[0182] Nova Compute calls the sixth preset interface (e.g., CreateWithFlags of the Libvirt Python interface) to start the target virtual machine;

[0183] Libvirt Python calls the seventh preset interface (eg, VirDomainCreateSetMetadata interface) (in Remote Driver) to mount the smart card port range data (ie, port range metadata) into the Live state of the target virtual machine.

[0184] Libvirtd obtains the smart card port range data from the target virtual machine and makes VNC port allocations there.

[0185] 5. The process of generating shutdown instructions

[0186] When the control intention represented by the control intention information is to shut down the target virtual machine, a shutdown instruction carrying the control intention information is generated.

[0187] After generating a shutdown instruction carrying control intention information, the shutdown instruction can be sent to Libvirtd deployed on the physical machine, so that Libvirtd can shut down the target virtual machine based on the shutdown instruction. After that, Nova Compute is used to generate a second recycling instruction for the target virtual machine, and based on the second recycling instruction, the fourth backend resource bound to the fourth virtual device of the target virtual machine is deleted to release the fourth virtual device. Figure 8 , the process is further explained.

[0188] Step S801: Nova Compute generates a shutdown instruction carrying control intention information, and sends the shutdown instruction to Libvirtd.

[0189] In an example, Nova Compute may generate a shutdown instruction carrying the control intention information, and send the shutdown instruction to Libvirtd deployed on the physical machine through a fourth preset interface (eg, LibvirtPython Shudown interface).

[0190] Step S802: After receiving the shutdown instruction, Libvirtd notifies Qemu to shut down the target virtual machine.

[0191] Among them, Libvirtd can notify Qemu to shut down the target virtual machine through the QEMU Machine Protocol (QPM), and Qemu can send an Advanced Configuration and Power Interface (ACPI) interrupt message to a specific software entity running in the target virtual machine, such as the Guest, or pull up the pin of the simulated General-Purpose Input / Output (GPIO), to notify the operating system of the target virtual machine to shut down.

[0192] After receiving the shutdown prompt sent by Libvirtd, Qemu sends the 21st feedback information to Libvirtd, and then Libvirtd sends the 20th feedback information to Nova Compute to indicate that the shutdown instruction has been received.

[0193] Step S803: Qemu sends the virtual machine shutdown result to Libvirtd.

[0194] Step S804: Libvirtd sends a process termination request to Qemu to request the termination of the Qemu process.

[0195] In one example, Libvirtd may first send a Kill-15 instruction to Qemu to request the termination of the Qemu process.

[0196] After receiving the process termination request sent by Libvirtd, Qemu will send twenty-first feedback information to Libvirtd to indicate whether the Qemu process has been terminated.

[0197] Step S805, entering the loop checking phase for the Qemu process.

[0198] Specifically, Libvirtd sends multiple process termination requests to Qemu to request the termination of the Qemu process. In one example, Libvirtd may first send a Kill-15 instruction to Qemu to request the termination of the Qemu process. After receiving the Kill-15 instruction, Qemu will attempt to terminate the Qemu process and send the twenty-second feedback information to Libvirtd to indicate whether the Qemu process is successfully terminated. If the Qemu process is not successfully terminated, Libvirtd may send a Kill-9 instruction to Qemu to request the forced termination of the Qemu process.

[0199] Step S806: Libvirtd sends a removal request for the fourth virtual device to Vfe Vhostd.

[0200] After receiving the removal request for the fourth virtual device, Vfe Vhostd removes the fourth virtual device and sends twenty-third feedback information to Libvirtd to indicate that the fourth virtual device has been removed.

[0201] Step S807: Nova Compute cyclically sends a power status detection request for the target virtual machine to Libvirtd.

[0202] After Nova Compute sends a power status detection request for the target virtual machine to Libvirtd, it receives twenty-fourth feedback information sent by Libvirtd to represent the power status of the target virtual machine.

[0203] Step S808: using Nova Compute, generating a second recycling instruction for the target virtual machine, and based on the second recycling instruction, deleting the fourth backend resource bound to the fourth virtual device of the target virtual machine to release the fourth virtual device.

[0204] In one example, when the fourth virtual device belongs to Virtio Block VF, the fourth backend resource bound to the fourth virtual device is the fourth network disk, so the fourth network disk bound to the fourth virtual device can be deleted; when the fourth virtual device belongs to Virtio Net VF or Rdma VF, the fourth backend resource bound to the fourth virtual device is the fourth network port, so the fourth network port bound to the fourth virtual device can be deleted. Specifically, when the fourth virtual device belongs to Virtio Blk VF, the seventh preset script (for example, Bf3-Volume-Ops.Py script) can be called to delete the fourth network disk bound to the fourth virtual device; when the fourth virtual device belongs to Virtio Net VF or Rdma VF, the eighth preset script (for example, Bf3-Net-Ops.Py script) can be called to delete the fourth network port bound to the fourth virtual device.

[0205] Step S809, shut down the target virtual machine.

[0206] In the above process, when the control intention represented by the control intention information is to shut down the target virtual machine, a shutdown instruction carrying the control intention information is generated, and after the shutdown instruction carrying the control intention information is generated, the shutdown instruction is sent to Libvirtd deployed on the physical machine, so that the target virtual machine is shut down based on the shutdown instruction by Libvirtd, and then Nova Compute is used to generate a second recycling instruction for the target virtual machine, and based on the second recycling instruction, the fourth backend resource bound to the fourth virtual device of the target virtual machine is deleted to release the fourth virtual device. In other words, when the target virtual machine is shut down, a relatively large number of control processes for the target virtual machine will be completed on the smart card, thereby reducing the virtualization overhead that the physical machine needs to bear.

[0207] 6. Generation process of destruction instructions

[0208] When the control intention represented by the control intention information is to destroy the target virtual machine, a destruction indication carrying the control intention information is generated.

[0209] After generating a destruction instruction carrying control intention information, the destruction instruction can be sent to Libvirtd deployed on the physical machine, so that Libvirtd can destroy the target virtual machine based on the destruction instruction. After that, NovaCompute is used to generate a second recycling instruction for the target virtual machine, and based on the second recycling instruction, the fourth backend resource bound to the fourth virtual device of the target virtual machine is deleted to release the fourth virtual device. Fig. 9 , the process is further explained.

[0210] Step S901: Nova Compute generates a destruction instruction that carries control intention information, and sends the destruction instruction to Libvirtd.

[0211] Step S902: After receiving the destruction instruction, Libvirtd enters the destruction process for the target virtual machine.

[0212] Step S903, entering the cyclic destruction phase for the Qemu process.

[0213] Specifically, Libvirtd sends multiple process destruction requests to Qemu to request the destruction of the Qemu process. In one example, Libvirtd may first send a Kill-15 instruction to Qemu to request the destruction of the Qemu process. After receiving the Kill-15 instruction, Qemu will attempt to destroy the Qemu process and send the twenty-fifth feedback information to Libvirtd to indicate whether the Qemu process is successfully destroyed. If the Qemu process is not successfully destroyed, Libvirtd may send a Kill-9 instruction to Qemu to request the forced destruction of the Qemu process.

[0214] Step S904: Libvirtd sends a removal request for the fourth virtual device to Vfe Vhostd.

[0215] After removing the fourth virtual device, Vfe Vhostd sends a feedback message of successful removal to Libvirtd.

[0216] After receiving the removal request for the fourth virtual device, Vfe Vhostd removes the fourth virtual device and sends the twenty-sixth feedback information to Libvirtd. Then, Libvirtd sends the twenty-sixth feedback information to NovaCompute to indicate that the fourth virtual device has been removed.

[0217] Step S905: Nova Compute cyclically sends a power status detection request for the target virtual machine to Libvirtd.

[0218] After Nova Compute sends a power status detection request for the target virtual machine to Libvirtd, it receives twenty-seventh feedback information sent by Libvirtd to represent the power status of the target virtual machine.

[0219] Step S906: using Nova Compute, generating a second recycling instruction for the target virtual machine, and based on the second recycling instruction, deleting the fourth backend resource bound to the fourth virtual device of the target virtual machine to release the fourth virtual device.

[0220] In one example, when the fourth virtual device belongs to Virtio Block VF, the fourth backend resource bound to the fourth virtual device is the fourth network disk, so the fourth network disk bound to the fourth virtual device can be deleted; when the fourth virtual device belongs to Virtio Net VF or Rdma VF, the fourth backend resource bound to the fourth virtual device is the fourth network port, so the fourth network port bound to the fourth virtual device can be deleted. Specifically, when the fourth virtual device belongs to Virtio Blk VF, the seventh preset script (for example, Bf3-Volume-Ops.Py script) can be called to delete the fourth network disk bound to the fourth virtual device; when the fourth virtual device belongs to Virtio Net VF or Rdma VF, the eighth preset script (for example, Bf3-Net-Ops.Py script) can be called to delete the fourth network port bound to the fourth virtual device.

[0221] Step S908, shut down the target virtual machine.

[0222] In the above process, when the control intention represented by the control intention information is to destroy the target virtual machine, a destruction instruction carrying the control intention information will be generated, and after the destruction instruction carrying the control intention information is generated, the destruction instruction will be sent to Libvirtd deployed on the physical machine, so that the target virtual machine can be destroyed based on the destruction instruction by Libvirtd, and then Nova Compute will be used to generate a second recycling instruction for the target virtual machine, and based on the second recycling instruction, the fourth backend resource bound to the fourth virtual device of the target virtual machine will be deleted to release the fourth virtual device. In other words, when the target virtual machine is destroyed, a relatively large number of control processes for the target virtual machine will be completed on the smart card, thereby reducing the virtualization overhead that the physical machine needs to bear.

[0223] 7. Generation process of deletion instructions

[0224] When the control intention represented by the control intention information is to delete the target virtual machine, a deletion instruction carrying the control intention information is generated.

[0225] After generating a deletion instruction carrying the control intention information, the deletion instruction can be sent to Libvirtd deployed on the physical machine, so that Libvirtd can delete the target virtual machine based on the deletion instruction. After that, NovaCompute is used to generate a second recycling instruction for the target virtual machine, and based on the second recycling instruction, the fourth backend resource bound to the fourth virtual device of the target virtual machine is deleted to release the fourth virtual device. Fig.10, the process is further explained.

[0226] Step S1001: Nova Compute generates a deletion instruction that carries control intent information, and sends the deletion instruction to Libvirt Python.

[0227] In one example, after generating the deletion instruction carrying the control intention information, Nova Compute may call a fifth preset interface (eg, Libvirt Python undefine) interface to send the deletion instruction to LibvirtPython.

[0228] Step S1002: Libvirt Python sends a deletion instruction to Libvirtd.

[0229] Libvirtd is used to remove the Domain information of the target virtual machine after receiving the deletion instruction.

[0230] After receiving the removal request for the fourth virtual device, Vfe Vhostd removes the fourth virtual device and sends the twenty-eighth feedback information to Libvirtd. Then, Libvirtd sends the twenty-eighth feedback information to NovaCompute to indicate that the fourth virtual device has been removed.

[0231] Step S1003: using Nova Compute, generating a second recycling instruction for the target virtual machine, and based on the second recycling instruction, deleting the fourth backend resource bound to the fourth virtual device of the target virtual machine to release the fourth virtual device.

[0232] In one example, when the fourth virtual device belongs to Virtio Block VF, the fourth backend resource bound to the fourth virtual device is the fourth network disk, so the fourth network disk bound to the fourth virtual device can be deleted; when the fourth virtual device belongs to Virtio Net VF or Rdma VF, the fourth backend resource bound to the fourth virtual device is the fourth network port, so the fourth network port bound to the fourth virtual device can be deleted. Specifically, when the fourth virtual device belongs to Virtio Blk VF, the seventh preset script (for example, Bf3-Volume-Ops.Py script) can be called to delete the fourth network disk bound to the fourth virtual device; when the fourth virtual device belongs to Virtio Net VF or Rdma VF, the eighth preset script (for example, Bf3-Net-Ops.Py script) can be called to delete the fourth network port bound to the fourth virtual device.

[0233] Step S1004: reclaim the index number of the fourth virtual device.

[0234] In the above process, when the control intention represented by the control intention information is to delete the target virtual machine, a deletion instruction carrying the control intention information is generated, and after the deletion instruction carrying the control intention information is generated, the deletion instruction is sent to Libvirtd deployed on the physical machine, so that the target virtual machine is deleted based on the deletion instruction by Libvirtd, and then Nova Compute is used to generate a second recycling instruction for the target virtual machine, and based on the second recycling instruction, the fourth backend resource bound to the fourth virtual device of the target virtual machine is deleted to release the fourth virtual device. In this process, a large part of the control process is completed on the smart card, so the virtualization overhead required by the physical machine can be further reduced.

[0235] In some optional implementations, the virtual machine management and control method may further include:

[0236] Use the virtualization monitoring component (Libvirt Monitor) deployed on the smart card to obtain the network disk monitoring data of the target virtual machine;

[0237] Send network disk monitoring data to the cloud management server.

[0238] Among them, the network disk monitoring data can be stored in the monitoring log.

[0239] Please combine Fig.11 ,The target virtual machine's network disk monitoring data can be monitored through the snapshot function component (Snap), the target virtual machine's network disk monitoring data can be obtained, and written into the monitoring log for storage, and then Libvirt Monitor reads the target virtual machine's network disk monitoring data from the monitoring log and sends it to the cloud management server.

[0240] Libvirt Monitor also communicates with Libvirtd deployed on the physical machine, and Libvirtd also communicates with the agent component deployed on the physical machine. Here, the agent component can also obtain the health data of some target virtual machines and send it to the cloud management server.

[0241] Through the above method, in the embodiment of the present disclosure, the virtualization monitoring component deployed on the smart card can be used to obtain the network disk monitoring data of the target virtual machine, and the network disk monitoring data can be sent to the cloud management server to realize data monitoring of the target virtual machine and ensure the security of the virtual machine management and control system.

[0242] The embodiments of the present disclosure provide a virtual machine management and control method, which can be applied to a physical machine included in a virtual machine management and control system. The physical machine may be a server that needs to be used to create multiple virtual machines. In addition, in the embodiments of the present disclosure, the virtual machine management and control system also includes a smart card for obtaining a virtual machine management and control request, and using a computing node service deployed on the smart card to generate a management and control operation instruction for a target virtual machine based on the virtual machine management and control request. The smart card may be a card-type device that integrates a microprocessor and a storage unit, or it may be understood as a server-like device. In the following, the smart card may be used to obtain a virtual machine management and control request, and ... operation instruction based on the virtual machine management and control request. Fig.12 The flowchart diagram shown illustrates a virtual machine management and control method provided by an embodiment of the present disclosure. It should be noted that although the logical order is shown in the flowchart diagram, in some cases, the steps shown or described in the flowchart can also be performed in other orders.

[0243] Step S1201, receiving control operation instructions.

[0244] Step S1202: Execute a control operation on the target virtual machine based on the control operation instruction.

[0245] Among them, the management and control operation instructions include at least one of a device mounting instruction, a device uninstalling instruction, a definition instruction, a power-on instruction, a power-off instruction, a destruction instruction and a deletion instruction.

[0246] In the embodiments of the present disclosure, the specific functions and examples of each unit in the virtual machine control method can be found in the relevant descriptions of the corresponding steps in the aforementioned virtual machine control method embodiments, and will not be repeated here.

[0247] Please combine Fig.13 , a virtual machine management and control system provided in an embodiment of the present disclosure, includes a physical machine and a smart card.

[0248] Among them, deployed on the smart card are:

[0249] (1) Nova Compute, a service component responsible for managing virtual machines;

[0250] (2) Bf3-Net-Ops.py script is used to modify the queue, length, and maximum transmission unit (MTU) of the VF network card and its virtual network port;

[0251] (3) Bf3-Volume-Ops.py script, which is used to bind the network disk and virtual device;

[0252] (4) Snap-rpc.py script, used to view the status information of Virtio Block VF on the smart card side;

[0253] (5) Virtnet is a network interface technology used in a virtualized environment, mainly used to create and manage virtual network interfaces in virtual machines;

[0254] (6) Storage Performance Development Kit (Spdk), a collection of tools and libraries designed for writing high-performance, scalable user-mode storage applications;

[0255] (7) Open Virtual Switch (Ovs);

[0256] (8) Snapshot component, used to save the state of a virtual machine at a specific point in time, including memory, disk, and network configuration;

[0257] (9)Virtio Net Controller is a controller implemented based on the Virtio protocol;

[0258] (10) Libvirt.so dynamic library, that is, the shared object library of Libvirt, which implements the Libvirt API, so that other programs can call these APIs through dynamic linking to manage virtual machines;

[0259] (11)Libvirt Python is an extension library of the Python programming language, which encapsulates some application programming interfaces (API calling methods) related to Libvirtd;

[0260] (12) Virtualization monitoring component (Libvirt Monitor), which can use the API and functions provided by the Libvirt library to implement functions such as resource allocation, performance monitoring, fault management, migration and backup of virtual machines.

[0261] Deployed on a physical machine:

[0262] (1) Libvirtd is a daemon process of the virtual machine manager (Libvirt) and is responsible for managing virtual machines;

[0263] (2) Vfe Vhostd is the virtual machine host and a user-mode service process used to convert Virtio BlockVF and / or Virtio Net VF into Vhost User devices;

[0264] (3) Vef Vhostd Cli, a virtual machine management software, is used to send commands to Vfe Vhostd to host the corresponding Virtio Block VF and / or Virtio Net VF to Vfe Vhostd;

[0265] (4) Quick Emulato (Qemu): 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.

[0266] After receiving the virtual machine start command, Nova Compute can call Ovs and Virtnet through Bf3-Net-Ops.py, and call Virtio Net Controller through Virtnet to prepare Virtio Net VF; NovaCompute can also call Spdk and Snap-rpc.py through Bf3-Volume-Ops.py, and call Snap through Snap-rpc.py to prepare Virtio Block VF.

[0267] After Virtio Net VF and Virtio Block VF are prepared, Nova Compute can call LibvirtPython, Libvirt Python calls Libvirtd, and then sends a device loading command to Vfe Vhostd through Vfe-cli to host the prepared Virtio Net VF and Virtio Block VF to Vfe Vhostd. Then, Libvirtd will start Qemu to start the virtual machine, and Qemu can communicate with Vfe Vhostd.

[0268] The following, combined with Fig.14 , describes the logical architecture of the virtual machine management system.

[0269] First, Snap+Spdk can be used to simulate a static block device, that is, Static Block PF. Through this Static Block PF, multiple Virtio Block VFs can be simulated. Then, Virtio BlockVF1 can be untied from the Virtio driver, and then bound to the Vfio driver, encapsulated into Vhost User Block, and hosted to Vfe Vhostd. Vfe Vhostd communicates with Qemu, and Virtio Block VF can be mounted to the physical machine PCI. Ovs+Virtio Net Controller can be used to simulate a static network device, that is, Static Net PF. Through this Static Net PF, multiple Virtio Net VFs can be simulated. Then, Virtio Net VF1 can be untied from the Virtio driver, and then bound to the Vfio driver, encapsulated into Vhost User Net, and hosted to VfeVhostd. Vfe Vhostd communicates with Qemu, and Virtio Net VF can be mounted to the physical machine PCI. The Controller can simulate a Native Net PF, through which multiple Rdma VFs, namely, Vfio Pci, can be simulated. Then, Vfio Pci communicates with Qemu and can mount Vfio Pci to the PCI of the physical machine.

[0270] In summary, the virtual machine control method provided in the embodiment of the present disclosure can obtain a virtual machine control request, and use Nova Compute deployed on the smart card to generate a control operation instruction for the target virtual machine based on the virtual machine control request, and then send the control operation instruction to Libvirtd deployed on the physical machine, so that Libvirtd can perform the control operation on the target virtual machine based on the control operation instruction. In other words, in the embodiment of the present disclosure, a smart card independent of the physical machine is expanded. Based on the smart card, not only can part of the control process for the target virtual machine be transplanted from the physical machine to the smart card, but Snap and Ovs deployed on the smart card can also be used to provide backend resources for the target virtual machine, so as to reduce the virtualization overhead that the physical machine needs to bear. Therefore, it can greatly promote the rational use of physical machine resources and avoid unnecessary waste of resources.

[0271] In order to better implement the aforementioned virtual machine control method applied to the smart card included in the virtual machine control system, the embodiment of the present disclosure also provides a virtual machine control device, which can be integrated into the smart card included in the virtual machine control system. Fig.15 The schematic structural block diagram shown is used to illustrate a virtual machine control device 1500 provided in the disclosed embodiment.

[0272] The virtual machine control device 1500 includes:

[0273] The request acquisition unit 1501 is used to acquire a virtual machine management and control request;

[0274] The instruction generating unit 1502 is used to generate a control operation instruction for a target virtual machine based on a virtual machine control request by using Nova Compute deployed on a smart card;

[0275] The instruction sending unit 1503 is used to send the control operation instruction to Libvirtd deployed on the physical machine; wherein Libvirtd is used to perform the control operation on the target virtual machine based on the control operation instruction.

[0276] In some optional implementations, the indication generating unit 1502 is used to:

[0277] Parse the virtual machine control request to obtain the control intention information for the target virtual machine;

[0278] Based on the control intention information, generate control operation instructions for the target virtual machine.

[0279] In some optional implementations, the management and control operation instruction includes at least one of a device mounting instruction, a device uninstalling instruction, a definition instruction, a power-on instruction, a power-off instruction, a destruction instruction, and a deletion instruction.

[0280] In some optional implementations, the management and control operation instruction includes a device mounting instruction; the instruction generating unit 1502 is used to:

[0281] In a case where the control intention represented by the control intention information is to mount the first virtual device on the target virtual machine, selecting the first virtual device from a plurality of candidate virtual devices allocated to the target virtual machine;

[0282] Binding the first virtual device to the first backend resource;

[0283] Generate a device mounting indication carrying control intention information and a first device identifier; wherein the first device identifier is identification information of the first virtual device.

[0284] In some optional implementations, the indication generating unit 1502 is used to:

[0285] In the case where the first virtual device is a virtual block device, binding the first network disk as a first backend resource to the first virtual device;

[0286] Alternatively, when the first virtual device is a virtual network device, the first network port is bound to the first virtual device as a first backend resource.

[0287] In some optional implementations, the management and control operation instruction includes a device uninstallation instruction; the instruction generation unit 1502 is used to:

[0288] When the control intention represented by the control intention information is to uninstall the virtual device from the target virtual machine, a device uninstallation indication carrying the control intention information and the second device identifier is generated; wherein the second device identifier is the identification information of the second virtual device that needs to be uninstalled from the target virtual machine.

[0289] In some optional implementations, the virtual machine management and control device 1500 further includes a first management and control unit, which is used to:

[0290] Using Nova Compute, generating a first recycling instruction for the target virtual machine;

[0291] Based on the first recycling instruction, delete the second backend resource bound to the second virtual device to release the second virtual device;

[0292] The second virtual device is recycled.

[0293] In some optional implementations, the control operation instruction includes a definition instruction; the instruction generating unit 1502 is used to:

[0294] When the control intention represented by the control intention information is to define a target virtual machine, assign multiple candidate virtual devices to the target virtual machine;

[0295] The plurality of identification information and the configuration information of the target virtual machine are used together as the overall description information of the target virtual machine; wherein the plurality of identification information corresponds to the plurality of candidate virtual machines one by one;

[0296] Generate definition instructions that carry control intent information and overall description information.

[0297] In some optional implementations, the control operation instruction includes a power-on instruction; the instruction generating unit 1502 is used to:

[0298] When the control intention represented by the control intention information is to power on the target virtual machine, selecting a third virtual device from a plurality of candidate virtual devices allocated to the target virtual machine;

[0299] Binding the third virtual device to the third backend resource;

[0300] Sending a redefinition instruction carrying control intention information and overall description information to Libvirtd; wherein the overall description information includes multiple identification information corresponding to multiple candidate virtual devices, and configuration information of the target virtual machine;

[0301] When receiving the redefinition feedback information returned by Libvirtd, a power-on instruction carrying the control intention information and the third device identifier is generated; wherein the third device identifier is the identifier information of the third virtual device.

[0302] In some optional implementations, the indication generating unit 1502 is used to:

[0303] In the case where the third virtual device is a virtual block device, binding the third network disk as a third backend resource to the third virtual device;

[0304] Alternatively, when the third virtual device is a virtual network device, the third network port is bound to the third virtual device as a third backend resource.

[0305] In some optional implementations, the indication generating unit 1502 is used to:

[0306] Generate a power-on instruction that carries control intent information, a third device identifier, and smart card port range data.

[0307] In some optional implementations, the management and control operation instruction includes at least one of a shutdown instruction, a destruction instruction, and a deletion instruction; the instruction generation unit 1502 is used to:

[0308] When the control operation instruction includes a shutdown instruction and the control intention represented by the control intention information is to shut down the target virtual machine, generating a shutdown instruction carrying the control intention information;

[0309] When the control operation instruction includes a destruction instruction and the control intention represented by the control intention information is to destroy the target virtual machine, generating a destruction instruction carrying the control intention information;

[0310] When the control operation instruction includes a deletion instruction and the control intention represented by the control intention information is to delete the target virtual machine, a deletion instruction carrying the control intention information is generated.

[0311] In some optional implementations, the virtual machine management and control device 1500 further includes a second management and control unit, which is used to:

[0312] Using Nova Compute, generating a second recycling instruction for the target virtual machine;

[0313] Based on the second recycling instruction, the fourth backend resource bound to the fourth virtual device of the target virtual machine is deleted to release the fourth virtual device.

[0314] In some optional implementations, the virtual machine management and control device 1500 further includes a third management and control unit, which is used to:

[0315] Use the virtualization monitoring component deployed on the smart card to obtain the network disk monitoring data of the target virtual machine;

[0316] Send network disk monitoring data to the cloud management server.

[0317] In the embodiment of the present disclosure, the specific functions and examples of each unit in the virtual machine control device 1500 can be found in the relevant description of the corresponding steps in the aforementioned virtual machine control method embodiment, and will not be repeated here.

[0318] In order to better implement the aforementioned virtual machine control method applied to a physical machine included in a virtual machine control system, the embodiment of the present disclosure further provides a virtual machine control device, which can be integrated into a physical machine included in the virtual machine control system. Fig.16 The schematic structural block diagram shown illustrates a virtual machine control device 1600 provided in the disclosed embodiment.

[0319] The virtual machine control device 1600 includes:

[0320] The instruction receiving unit 1601 is used to receive the control operation instruction;

[0321] The control operation unit 1602 is used to perform a control operation on the target virtual machine based on the control operation instruction.

[0322] In some optional implementations, the management and control operation instruction includes at least one of a device mounting instruction, a device uninstalling instruction, a definition instruction, a power-on instruction, a power-off instruction, a destruction instruction, and a deletion instruction.

[0323] In the embodiment of the present disclosure, the specific functions and examples of each unit in the virtual machine control device 1600 can be found in the relevant descriptions of the corresponding steps in the aforementioned virtual machine control method embodiment, and will not be repeated here.

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

[0325] The embodiments of the present disclosure also provide an electronic device, a readable storage medium, and a computer program product.

[0326] Fig.17A schematic block diagram of an electronic device 1700 that can be used to implement each example in the disclosed embodiment is shown. The electronic device 1700 is intended to represent various forms of digital computers, such as vehicle-mounted computing devices, laptop computers, desktop computers, workbenches, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device 1700 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.

[0327] like Fig.17 As shown, the electronic device 1700 includes a computing unit 1701, which can perform various appropriate actions and processes according to a computer program stored in a read-only memory (ROM) 1702 or a computer program loaded from a storage unit 1708 to a random access memory (RAM) 1703. In RAM 1703, various programs and data required for the operation of the electronic device 1700 can also be stored. The computing unit 1701, ROM 1702, and RAM 1703 are connected to each other via a bus 1704. An input / output (I / O) interface 1705 is also connected to the bus 1704.

[0328] A number of components in the electronic device 1700 are connected to the I / O interface 1705, including: an input unit 1706, such as a keyboard, a mouse, etc.; an output unit 1707, such as various types of renderers, speakers, etc.; a storage unit 1708, such as a disk, an optical disk, etc.; and a communication unit 1709, such as a network card, a modem, a wireless communication transceiver, etc. The communication unit 1709 allows the electronic device 1700 to exchange information / data with other devices through a computer network such as the Internet and / or various telecommunication networks.

[0329] The computing unit 1701 may be a variety of general and / or special processing components with processing and computing capabilities. Some examples of the computing unit 1701 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 (DSP), and any appropriate processors, controllers, microcontrollers, etc. The computing unit 1701 performs the various methods and processes described above, such as the virtual machine management method. For example, in some embodiments, the virtual machine management method may be implemented as a computer software program, which is tangibly included in a machine-readable medium, such as a storage unit 1708. In some embodiments, part or all of the computer program may be loaded and / or installed on the electronic device 1700 via the ROM 1702 and / or the communication unit 1709. When the computer program is loaded into the RAM 1703 and executed by the computing unit 1701, one or more steps in the virtual machine management method described above may be executed. Alternatively, in other embodiments, the computing unit 1701 may be configured as a virtual machine management and control method in any other appropriate manner (eg, by means of firmware).

[0330] Various embodiments of the systems and techniques described above herein may 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), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may 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 may be a dedicated 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.

[0331] The program code for implementing the method of the present disclosure can be written in any combination of one or more programming languages. These program codes can be provided to a processor or controller of a general-purpose computer, a special-purpose computer or other programmable data optimization 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 can be executed completely on the machine, partially on the machine, partially on the machine as an independent software package and partially on a remote machine or completely on a remote machine or server.

[0332] 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, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, 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 RAM, a ROM, an erasable programmable read-only memory (EPROM) or a 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.

[0333] To provide interaction with a user, the systems and techniques described herein may be implemented on a computer having: a rendering device (e.g., a cathode ray tube (CRT) renderer or a liquid crystal display (LCD)) for rendering 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 are also used to provide interaction with the user; for example, the feedback provided to the user may be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user may be received in any form (including acoustic input, voice input, or tactile input).

[0334] The systems and techniques described herein can 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 can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include: Local Area Network (LAN), Wide Area Network (WAN), and the Internet.

[0335] The 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 between the client and the server is generated by computer programs running on the corresponding computers and having a client-server relationship with each other. The server can be a cloud server, a server of a distributed system, or a server combined with a blockchain.

[0336] The embodiment of the present disclosure also provides a non-transitory computer-readable storage medium storing computer instructions, wherein the computer instructions are used to enable a computer to execute a virtual machine management and control method.

[0337] The embodiments of the present disclosure also provide a computer program product, including a computer program, which implements a virtual machine management and control method when executed by a processor.

[0338] 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 the present disclosure can be executed in parallel, sequentially or in a different order, as long as the desired results of the technical solutions disclosed in the present disclosure can be achieved, and this document does not limit this. In addition, in the present disclosure, relational terms such as "first", "second", "third", etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply the existence of any such actual relationship or order between these entities or operations. In addition, "multiple" in the present disclosure can be understood as at least two.

[0339] 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 management and control method, applied to a smart card included in a virtual machine management and control system, wherein the virtual machine management and control system also includes a physical machine; the method comprises: Get virtual machine control request; Using a computing node service deployed on the smart card, based on the virtual machine control request, a control operation instruction for the target virtual machine is generated; The control operation instruction is sent to a virtualization control program deployed on the physical machine; wherein the virtualization control program is used to perform a control operation on the target virtual machine based on the control operation instruction.

2. The method according to claim 1, wherein: The generating, based on the virtual machine control request, a control operation instruction for the target virtual machine includes: Parsing the virtual machine control request to obtain control intention information for the target virtual machine; Based on the control intention information, the control operation instruction for the target virtual machine is generated.

3. The method according to claim 2, wherein: The management and control operation instruction includes at least one of a device mounting instruction, a device uninstalling instruction, a definition instruction, a power-on instruction, a power-off instruction, a destruction instruction, and a deletion instruction.

4. The method according to claim 2, wherein: The control operation instruction includes a device mounting instruction; and the generating the control operation instruction for the target virtual machine based on the control intention information includes: In a case where the control intention represented by the control intention information is to mount a virtual device on the target virtual machine, selecting a first virtual device from a plurality of candidate virtual devices allocated to the target virtual machine; Binding the first virtual device to the first backend resource; Generate the device mounting indication carrying the control intention information and the first device identifier; wherein the first device identifier is the identification information of the first virtual device.

5. The method according to claim 4, wherein: The binding the first virtual device to the first backend resource includes: In the case where the first virtual device is a virtual block device, the first network disk is used as the first backend resource and is bound to the first virtual device; Alternatively, when the first virtual device is a virtual network device, the first network port is used as the first backend resource and is bound to the first virtual device.

6. The method according to claim 2, wherein: The control operation instruction includes a device uninstallation instruction; and the generating the control operation instruction for the target virtual machine based on the control intention information includes: When the control intention represented by the control intention information is to uninstall the virtual device from the target virtual machine, generate the device uninstallation indication carrying the control intention information and the second device identifier; wherein the second device identifier is the identification information of the second virtual device that needs to be uninstalled from the target virtual machine.

7. The method according to claim 6, further comprising: Using the computing node service, generating a first recycling instruction for the target virtual machine; Based on the first recycling instruction, delete the second backend resource bound to the second virtual device to release the second virtual device; The second virtual device is recycled.

8. The method according to claim 2, wherein: The control operation instruction includes a definition instruction; the generating the control operation instruction for the target virtual machine based on the control intention information includes: In a case where the control intention represented by the control intention information is to define the target virtual machine, allocating a plurality of candidate virtual devices to the target virtual machine; The plurality of identification information and the configuration information of the target virtual machine are used together as the overall description information of the target virtual machine; wherein the plurality of identification information corresponds to the plurality of candidate virtual machines one by one; Generate the definition instruction that carries the control intention information and the overall description information.

9. The method according to claim 2, wherein: The control operation instruction includes a power-on instruction; and the generating the control operation instruction for the target virtual machine based on the control intention information includes: When the control intention represented by the control intention information is to power on the target virtual machine, selecting a third virtual device from a plurality of candidate virtual devices allocated to the target virtual machine; Binding the third virtual device to the third backend resource; Sending a redefinition instruction carrying the control intention information and the overall description information to the virtualization control program; wherein the overall description information includes a plurality of identification information corresponding to the plurality of candidate virtual devices one by one, and the configuration information of the target virtual machine; When the redefinition feedback information returned by the virtualization control program is received, the power-on instruction carrying the control intention information and the third device identifier is generated; wherein the third device identifier is the identification information of the third virtual device.

10. The method according to claim 9, wherein: The step of binding the third virtual device to the third backend resource includes: In the case where the third virtual device is a virtual block device, the third network disk is used as the third backend resource and is bound to the third virtual device; Alternatively, when the third virtual device is a virtual network device, the third network port is used as the third backend resource and is bound to the third virtual device.

11. The method according to claim 9, wherein: The generating the power-on instruction carrying the control intention information and the third device identifier includes: Generate the power-on instruction carrying the control intention information, the third device identifier and the smart card port range data.

12. The method according to claim 2, wherein: The control operation instruction includes at least one of a shutdown instruction, a destruction instruction, and a deletion instruction; and the generating the control operation instruction for the target virtual machine based on the control intention information includes: In a case where the control operation instruction includes the shutdown instruction, and the control intention represented by the control intention information is to shut down the target virtual machine, generating the shutdown instruction carrying the control intention information; In a case where the control operation instruction includes the destruction instruction and the control intention represented by the control intention information is to destroy the target virtual machine, generating the destruction instruction carrying the control intention information; In a case where the control operation instruction includes the deletion instruction, and the control intention represented by the control intention information is to delete the target virtual machine, the deletion instruction carrying the control intention information is generated.

13. The method according to claim 12, further comprising: Using the computing node service, generating a second recycling instruction for the target virtual machine; Based on the second recycling instruction, the fourth backend resource bound to the fourth virtual device of the target virtual machine is deleted to release the fourth virtual device.

14. The method according to any one of claims 1 to 13, further comprising: Using the virtualization monitoring component deployed on the smart card, obtaining the network disk monitoring data of the target virtual machine; The network disk monitoring data is sent to the cloud management server.

15. A virtual machine control method, applied to a physical machine included in a virtual machine control system, the virtual machine control system also including a smart card, the smart card is used to obtain a virtual machine control request, and use a computing node service deployed on the smart card to generate a control operation instruction for a target virtual machine based on the virtual machine control request; The method comprises: Receiving the control operation instruction; Based on the control operation instruction, a control operation is performed on the target virtual machine.

16. The method according to claim 15, wherein: The management and control operation instruction includes at least one of a device mounting instruction, a device uninstalling instruction, a definition instruction, a power-on instruction, a power-off instruction, a destruction instruction, and a deletion instruction.

17. A virtual machine control device, applied to a smart card included in a virtual machine control system, wherein the virtual machine control system also includes a physical machine; the device comprises: A request acquisition unit, used to acquire a virtual machine control request; an instruction generating unit, configured to generate a control operation instruction for a target virtual machine based on the virtual machine control request by using a computing node service deployed on the smart card; An instruction sending unit is used to send the control operation instruction to a virtualization control program deployed on the physical machine; wherein the virtualization control program is used to perform a control operation on the target virtual machine based on the control operation instruction.

18. The device according to claim 17, wherein: The indication generating unit is used for: Parsing the virtual machine control request to obtain control intention information for the target virtual machine; Based on the control intention information, the control operation instruction for the target virtual machine is generated.

19. The device according to claim 18, wherein: The management and control operation instruction includes at least one of a device mounting instruction, a device uninstalling instruction, a definition instruction, a power-on instruction, a power-off instruction, a destruction instruction, and a deletion instruction.

20. The device according to claim 18, wherein The control operation instruction includes a device mounting instruction; the instruction generating unit is used to: In a case where the control intention represented by the control intention information is to mount the first virtual device on the target virtual machine, selecting the first virtual device from a plurality of candidate virtual devices allocated to the target virtual machine; Binding the first virtual device to the first backend resource; Generate the device mounting indication carrying the control intention information and the first device identifier; wherein the first device identifier is the identification information of the first virtual device.

21. The device according to claim 20, wherein: The indication generating unit is used for: In the case where the first virtual device is a virtual block device, the first network disk is used as the first backend resource and is bound to the first virtual device; Alternatively, when the first virtual device is a virtual network device, the first network port is used as the first backend resource and is bound to the first virtual device.

22. The device according to claim 18, wherein The control operation instruction includes a device uninstallation instruction; and the instruction generating unit is used to: When the control intention represented by the control intention information is to uninstall the virtual device from the target virtual machine, generate the device uninstallation indication carrying the control intention information and the second device identifier; wherein the second device identifier is the identification information of the second virtual device that needs to be uninstalled from the target virtual machine.

23. The device according to claim 22, further comprising a first control unit, configured to: Using the computing node service, generating a first recycling instruction for the target virtual machine; Based on the first recycling instruction, delete the second backend resource bound to the second virtual device to release the second virtual device; The second virtual device is recycled.

24. The device according to claim 18, wherein The control operation instruction includes a definition instruction; the instruction generating unit is used to: In a case where the control intention represented by the control intention information is to define the target virtual machine, allocating a plurality of candidate virtual devices to the target virtual machine; The plurality of identification information and the configuration information of the target virtual machine are used together as the overall description information of the target virtual machine; wherein the plurality of identification information corresponds to the plurality of candidate virtual machines one by one; Generate the definition instruction that carries the control intention information and the overall description information.

25. The apparatus of claim 18, wherein: The control operation instruction includes a power-on instruction; and the instruction generating unit is used for: When the control intention represented by the control intention information is to power on the target virtual machine, selecting a third virtual device from a plurality of candidate virtual devices allocated to the target virtual machine; Binding the third virtual device to the third backend resource; Sending a redefinition instruction carrying the control intention information and the overall description information to the virtualization control program; wherein the overall description information includes a plurality of identification information corresponding to the plurality of candidate virtual devices one by one, and the configuration information of the target virtual machine; When the redefinition feedback information returned by the virtualization control program is received, the power-on instruction carrying the control intention information and the third device identifier is generated; wherein the third device identifier is the identification information of the third virtual device.

26. The device according to claim 25, wherein The indication generating unit is used for: In the case where the third virtual device is a virtual block device, the third network disk is used as the third backend resource and is bound to the third virtual device; Alternatively, when the third virtual device is a virtual network device, the third network port is used as the third backend resource and is bound to the third virtual device.

27. The device according to claim 25, wherein: The indication generating unit is used for: Generate the power-on instruction carrying the control intention information, the third device identifier and the smart card port range data.

28. The apparatus of claim 18, wherein: The control operation instruction includes at least one of a shutdown instruction, a destruction instruction, and a deletion instruction; and the instruction generating unit is used to: In a case where the control operation instruction includes the shutdown instruction, and the control intention represented by the control intention information is to shut down the target virtual machine, generating the shutdown instruction carrying the control intention information; In a case where the control operation instruction includes the destruction instruction and the control intention represented by the control intention information is to destroy the target virtual machine, generating the destruction instruction carrying the control intention information; In a case where the control operation instruction includes the deletion instruction, and the control intention represented by the control intention information is to delete the target virtual machine, the deletion instruction carrying the control intention information is generated.

29. The device according to claim 28, further comprising a second control unit, configured to: Using the computing node service, generating a second recycling instruction for the target virtual machine; Based on the second recycling instruction, the fourth backend resource bound to the fourth virtual device of the target virtual machine is deleted to release the fourth virtual device.

30. The device according to any one of claims 17 to 29, further comprising a third control unit, configured to: Using the virtualization monitoring component deployed on the smart card, obtaining the network disk monitoring data of the target virtual machine; The network disk monitoring data is sent to the cloud management server.

31. A virtual machine control device, applied to a physical machine included in a virtual machine control system, the virtual machine control system also including a smart card, the smart card is used to obtain a virtual machine control request, and use a computing node service deployed on the smart card to generate a control operation instruction for a target virtual machine based on the virtual machine control request; The device comprises: An instruction receiving unit, used to receive the control operation instruction; A control operation unit is used to perform a control operation on the target virtual machine based on the control operation instruction.

32. The device according to claim 31, wherein The management and control operation instruction includes at least one of a device mounting instruction, a device uninstalling instruction, a definition instruction, a power-on instruction, a power-off instruction, a destruction instruction, and a deletion instruction.

33. An electronic device comprising: at least one processor; a memory communicatively coupled to the at least one processor; 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 so that the at least one processor can perform the method according to any one of claims 1 to 16.

34. 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 to 16.

35. 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 16.

Images