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

Abstract

The present disclosure provides a virtual machine management method and device, electronic equipment and storage medium, relates to the technical field of computers, and particularly relates to the application fields of cloud services, cloud computing, big data processing and the like. The specific implementation scheme comprises the following steps: obtaining a virtual machine management request; using a computing node service deployed on an intelligent card, generating a management operation instruction for a target virtual machine based on the virtual machine management request; and sending the management operation instruction to a virtualization management program deployed on a physical machine; wherein the virtualization management program is configured to execute the management operation on the target virtual machine based on the management operation instruction.

Description

TECHNICAL FIELD

[0001] The present disclosure relates to the technical field of computers, in particular to the application fields of cloud services, cloud computing, big data processing, and the like, and specifically relates to a virtual machine management and control method and device, an electronic device, and a storage medium. BACKGROUND

[0002] With the development of computer technology, in order to meet the user's demand for more efficient and flexible use of computing resources, virtual machine technology has emerged. 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 program. SUMMARY

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

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

[0005] obtaining a virtual machine management and control request;

[0006] using a computing node service deployed on the smart card, generating a management and control operation instruction for a target virtual machine based on the virtual machine management and control request;

[0007] sending the management and control operation instruction to a virtualization management and control program deployed on the physical machine; wherein the virtualization management and control program is configured to execute the management and control operation for the target virtual machine based on the management and control operation instruction.

[0008] According to a second aspect of the present disclosure, a virtual machine management and control method is provided, applied to a physical machine included in a virtual machine management and control system, the virtual machine management and control system further including a smart card, the smart card being configured to obtain a virtual machine management and control request and use 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] receiving the management and control operation instruction;

[0010] executing the management and control operation for the target virtual machine based on the management and control operation instruction.

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

[0012] a request obtaining unit configured to obtain a virtual machine management and control request;

[0013] The indication generating unit generates the management and control operation indication for the target virtual machine based on the virtual machine management and control request by using the computing node service deployed on the smart card.

[0014] The indication sending unit sends the management and control operation indication to the virtualization management and control program deployed on the physical machine, wherein the virtualization management and control program performs the management and control operation on the target virtual machine based on the management and control operation indication.

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

[0016] The indication receiving unit receives the management and control operation indication.

[0017] The management and control operation unit performs the management and control operation on the target virtual machine based on the management and control operation indication.

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

[0019] At least one processor;

[0020] A memory in communication connection with the at least one processor;

[0021] The memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the method 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 perform the method provided in the first aspect of the present disclosure.

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

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

[0025] It should be understood that the contents described in this part are not intended to identify the key or important features of the embodiments of the present disclosure, nor are they used to limit the scope of the present disclosure. Other features of the present disclosure will become apparent from the following description. BRIEF DESCRIPTION OF DRAWINGS

[0026] The accompanying drawings are used to better understand the present scheme, and do not constitute a limitation on the present disclosure. Among them:

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

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

[0029] Figure 3 A device mounting flowchart provided by an embodiment of the present disclosure;

[0030] Figure 4 A device unloading flowchart provided by an embodiment of the present disclosure;

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

[0032] Figure 6 A startup flowchart of a target virtual machine provided by an embodiment of the present disclosure;

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

[0034] Figure 8 A shutdown flowchart of a target virtual machine provided by an embodiment of the present disclosure;

[0035] Figure 9 A destruction flowchart of a target virtual machine provided by an embodiment of the present disclosure;

[0036] Figure 10 A deletion flowchart of a target virtual machine provided by an embodiment of the present disclosure;

[0037] Figure 11 An acquisition architecture schematic diagram of network disk monitoring data provided by an embodiment of the present disclosure;

[0038] Figure 12 A flowchart of a virtual machine management method provided by an embodiment of the present disclosure;

[0039] Figure 13 A schematic diagram of an overall framework of a virtual machine management system provided by an embodiment of the present disclosure;

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

[0041] Figure 15 A schematic structural block diagram of a virtual machine management device provided by an embodiment of the present disclosure;

[0042] Figure 16 A schematic structural block diagram of a virtual machine management and control device provided by an embodiment of the present disclosure is shown in the following figure.

[0043] Figure 17 A schematic structural block diagram of an electronic device provided by an embodiment of the present disclosure is shown in the following figure. DETAILED DESCRIPTION

[0044] Exemplary embodiments of the present disclosure are described below with reference to the accompanying drawings, which include various details of the embodiments of the present disclosure to assist in understanding them. These should be considered as merely exemplary. Thus, those of ordinary skill in the art will recognize various changes and modifications of the embodiments described herein, which do not depart from the scope of the present disclosure. Also, in the following description, descriptions of well-known functions and constructions are omitted for clarity and conciseness.

[0045] As shown in the following figure, Figure 1 In the prior art, a large proportion of physical machine resources (e.g., more than 16%) are usually reserved for bearing virtualization overhead before multiple virtual machines are created from the physical machine, which causes serious waste of physical machine resources. For example, to simulate N virtual machines with a specification of "total number of physical machine cores M / N", at least two physical machines are needed, and at least one of the two physical machines cannot be effectively utilized, thus causing serious waste of physical machine resources.

[0046] To solve the above problems, an embodiment of the present disclosure provides 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 integrated with a microprocessor and a storage unit, or it can be understood as a server-like device. In addition, in the present embodiment, the virtual machine management and control system further includes a physical machine. The physical machine can be a server needed to create multiple virtual machines. The following will describe the virtual machine management and control method provided by an embodiment of the present disclosure in combination with the flowchart shown in the following figure. Figure 2 It should be noted that, although the logical order is shown in the flowchart, in some cases, the steps shown or described in the flowchart can also be executed in other orders.

[0047] In step S201, a virtual machine management and control request is obtained.

[0048] The virtual machine management and control request can be issued by a user to request a management and control operation on a target virtual machine.

[0049] In step S202, a management and control operation instruction for the target virtual machine is generated based on the virtual machine management and control request by using a compute node service (Nova Compute) deployed on the smart card.

[0050] wherein the Nova Compute is a service component responsible for managing the virtual machine (e.g., the target virtual machine).

[0051] In the embodiments of the present disclosure, the Nova Compute can generate a management operation instruction for the target virtual machine based on the virtual machine management request. In an example, the Nova Compute can provide a backend resource (e.g., a network disk and / or a network port) for the target virtual machine based on the virtual machine management request, and generate the management operation instruction for the target virtual machine. The management operation instruction can be a device mounting instruction and / or a device unloading instruction for the target virtual machine, or can be another operation instruction related to the life cycle of the target virtual machine, such as at least one of a definition instruction, a start instruction, a shutdown instruction, a destroy instruction, and a delete instruction.

[0052] In step S203, the management operation instruction is sent to a virtualization management program (Libvirtd) deployed on the physical machine.

[0053] wherein the Libvirtd is a daemon of a virtual machine manager (Libvirt) responsible for managing the virtual machine (e.g., the target virtual machine). Based on this, in the embodiments of the present disclosure, the Libvirtd can be used to perform the management operation for the target virtual machine based on the management operation instruction.

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

[0055] The virtual machine management method provided by the embodiments of the present disclosure can obtain a virtual machine management request, and use the Nova Compute deployed on the smart card to generate a management operation instruction for the target virtual machine based on the virtual machine management request, and then send the management operation instruction to the Libvirtd deployed on the physical machine, so that the Libvirtd performs the management operation for the target virtual machine based on the management operation instruction. That is, in the embodiments of the present disclosure, an independent smart card of the physical machine is expanded based on the smart card, not only can the part of the management process for the target virtual machine be transplanted from the physical machine to the smart card, but also the Nova Compute deployed on the smart card can be used to provide the backend resource for the target virtual machine, which can reduce the virtualization overhead required to be borne by the physical machine, thereby greatly promoting the rational use of physical machine resources and avoiding unnecessary resource waste.

[0056] In an example, the "generating a management operation instruction for the target virtual machine based on the virtual machine management request" in step S202 can include:

[0057] The virtual machine management request is analyzed to obtain management intention information for the target virtual machine;

[0058] Based on the management intention information, a management operation instruction for the target virtual machine is generated.

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

[0060] mounting a virtual device on the target virtual machine, unmounting a virtual device from the target virtual machine, defining the target virtual machine, powering on the target virtual machine, powering off the target virtual machine, destroying the target virtual machine, and deleting the target virtual machine.

[0061] After obtaining the management intention information, a management operation instruction for the target virtual machine can be generated based on the management intention information. The management operation instruction can include at least one of a device mounting instruction, a device unmounting instruction, a definition instruction, a power-on instruction, a power-off instruction, a destruction instruction, and a deletion instruction. Here, the device mounting instruction is used to indicate mounting a virtual device on the target virtual machine; the device unmounting instruction is used to indicate unmounting 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 power-off 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] In the above manner, in the embodiments of the present disclosure, the virtual machine management request can be analyzed to obtain management intention information for the target virtual machine, and based on the management intention information, a management operation instruction for the target virtual machine can be generated. In this way, not only can the management operation instruction be highly consistent with the management intention information, but also a solid foundation can be provided for future expansion and new demand adaptation of the virtual machine management system through standardized management operation instructions. In addition, in the embodiments of the present disclosure, since the management operation instruction can include at least one of a device mounting instruction, a device unmounting 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 management method can be ensured.

[0063] In the following, the generation processes of the device mounting instruction, the device unmounting instruction, the definition instruction, the power-on instruction, the power-off instruction, the destruction instruction, and the deletion instruction will be described respectively.

[0064] I. Generation process of the device mounting instruction

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

[0066] The plurality of candidate virtual devices can include a plurality of virtual block devices (also referred to as Virtio Block VF) and a plurality of virtual network devices. Here, the plurality of virtual network devices can further include a plurality of auxiliary network cards (also referred to as Virtio Net VF) and a plurality of master network cards supporting Remote Direct Memory Access (RDMA) function (also referred to as Rdma VF). It should be noted that in the embodiments of the present disclosure, each candidate virtual device in the plurality of candidate virtual devices has its own identification information (for example, index number (also referred to as Index)). For example, there are N1 Virtio Block VFs in the plurality of candidate virtual devices, and the identification information of the N1 Virtio Block VFs can be 0, 1, 2, 3, …, N1-1.

[0067] In addition, it should be noted that in the embodiments of the present disclosure, after determining the plurality of candidate virtual devices 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 plurality of candidate virtual devices as the first virtual device. In an example, a list of unallocated index numbers can be determined from a total index bitmap related to the plurality of candidate virtual devices, and an unallocated index number can be obtained from the list of unallocated index numbers. If the candidate virtual device corresponding to the unallocated index number matches the management and control intention information, the candidate virtual device is taken 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) Binding the first virtual device with the first backend resource.

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

[0070] (3) Generating a device mounting instruction carrying the management and control intention information and the first device identification.

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

[0072] After the first virtual device is selected from the plurality of candidate virtual devices allocated for the target virtual machine and the first virtual device is bound with the first backend resource to generate the device mounting instruction carrying the management intent information and the first device identifier, the device mounting instruction can be sent to the Libvirtd deployed on the physical machine to mount the first virtual device on the target virtual machine based on the device mounting instruction by using the Libvirtd. In the following, the process will be further described in combination with Figure 3

[0073] Firstly, the preparation phase of the first virtual device is entered:

[0074] In step S301, the Nova Compute selects the first virtual device from the plurality of candidate virtual devices allocated for the target virtual machine.

[0075] In step S302, the Nova Compute binds the first virtual device with the first backend resource.

[0076] In an example, the first network disk can be taken as the first backend resource and bound with the first virtual device in the case that the first virtual device belongs to Virtio Block VF; the first network port can be taken as the first backend resource and bound with the first virtual device in the case that the first virtual device belongs to Virtio Net VF or Rdma VF. Specifically, the first preset script (for example, Bf3-Volume-Ops.Py script) can be called to take the first network disk as the first backend resource and bind the first network disk with the first virtual device in the case that the first virtual device belongs to Virtio Block VF; the second preset script (for example, Bf3-Net-Ops.Py script) can be called to take the first network port as the first backend resource and bind the first network port with the first virtual device in the case that the first virtual device belongs to Virtio Net VF or Rdma VF.

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

[0078] After the binding is successful, step S303 can be performed.

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

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

[0081] Then, the first virtual device enters a running (Live) state and a configuration (Config) state for mounting:

[0082] Step S304, Nova Compute sends the first device XML to Libvirt Python deployed on the smart card.

[0083] Libvirt Python is an extension library of Python programming language, which encapsulates the calling method of some Application Programming Interface (API) related to Libvirtd, so that the interaction between Nova Compute and Libvirtd can be more easily realized through Libvirt Python.

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

[0085] In an example, Libvirt Python can call Libvirtd through a preset dynamic library (for example, 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 the first device addressing information (Bus, Device, Function, BDF) of the first virtual device.

[0087] Step S307, Libvirtd hosts the first virtual device to Vfe Vhostd deployed on the physical machine based on the first BDF.

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

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

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

[0091] The device mounting request is generated based on the first device XML; the 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 mounting request; the Qemu sends third feedback information to the Libvirtd after receiving the device mounting request, which represents that the device mounting request has been successfully received; and the Qemu sends fourth feedback information to the Libvirtd after successfully mounting the first virtual device to the target virtual machine in response to the device mounting request, which represents that the first virtual device has been successfully mounted to the target virtual machine.

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

[0093] In step S309, the Libvirtd updates the Live state of the first virtual device.

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

[0095] In step S310, the 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, the Libvirtd sends fifth feedback information to the Libvirt Python, which represents that the first virtual device has been mounted, and then the Libvirt Python sends the fifth feedback information to the Nova Compute.

[0098] In step S311, the Nova Compute requests the Libvirtd to check whether the first virtual device has been 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] Wherein, Libvirtd can check the Live state and Config state of the first virtual device to achieve the purpose of checking whether the first virtual device is successfully mounted to the target virtual machine, and send the sixth feedback information carrying the checking result to Nova Compute.

[0101] In the above process, when the management and control intention represented by the management and control intention information is to mount a virtual device on the target virtual machine, on the smart card side, Nova Compute selects the first virtual device from the multiple candidate virtual devices allocated for the target virtual machine, binds the first virtual device with the first backend resource, and then generates a device mounting instruction carrying the management and control intention information and the first device identifier. That is, when mounting a virtual device on the target virtual machine, relatively more management and control processes for the target virtual machine are completed on the smart card, and Nova Compute is also used to provide the target virtual machine with a backend resource (here, specifically the first backend resource, including the first network disk and / or the first network port), thereby reducing the occupation of physical machine resources, and thus effectively reducing the virtualization overhead that the physical machine needs to bear.

[0102] II. Generation process of device unloading instruction

[0103] When the management and control intention represented by the management and control intention information is to unload a virtual device from the target virtual machine, a device unloading instruction carrying the management and control intention information and a second device identifier is generated.

[0104] Wherein, the second device identifier is the identifier information of the second virtual device that needs to be unloaded from the target virtual machine.

[0105] In an example, after generating the device unloading instruction carrying the management and control intention information and the second device identifier, the device unloading instruction can be sent to Libvirtd deployed on the physical machine, so that Libvirtd unloads the second virtual device from the target virtual machine based on the device unloading 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 with the second virtual device is deleted to release the second virtual device, and then the second virtual device is recycled. In the following, the process will be further described in combination with Figure 4 The process will be further described.

[0106] Step S401, Nova Compute generates a device unloading instruction (also referred to as second device XML) carrying the management and control intention information and the second device identifier.

[0107] As described previously, the second device identifier is identification information of the second virtual device.

[0108] In step S402, Nova Compute sends the second device XML to Libvirt Python deployed on the smart card.

[0109] In step S403, Libvirt Python sends the second device XML to Libvirtd deployed on the physical machine.

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

[0111] 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 sends seventh feedback information to Libvirtd, which indicates that the device deletion request has been successfully received; after deleting the second virtual device from the target virtual machine in response to the device deletion request, Qemu sends eighth feedback information to Libvirtd, which indicates that the second virtual device has been successfully deleted from the target virtual machine.

[0112] In step S405, Libvirtd parses the second device identifier of the second virtual device carried in the second device XML to obtain the second BDF of the second virtual device.

[0113] In 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, it sends ninth feedback information to Libvirtd, which indicates that the hosting of the second virtual device has been successfully released.

[0115] In step S407, Libvirtd updates the Live state of the second virtual device.

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

[0117] In 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, the Libvirtd sends tenth feedback information representing that the second virtual device has been successfully uninstalled to the Libvirt Python, and the Libvirt Python sends the tenth feedback information to the Nova Compute.

[0120] In step S409, the Nova Compute requests the Libvirtd to check whether the second virtual device has been successfully uninstalled.

[0121] In step S410, the Libvirtd checks whether the second virtual device has been successfully uninstalled.

[0122] The Libvirtd can check whether the second virtual device has been successfully uninstalled by checking the Live state and the Config state of the second virtual device, and send eleventh feedback information representing the checking result to the Nova Compute.

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

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

[0125] After the Nova Compute invokes 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 representing that the first virtual device is successfully bound to the first backend resource to the Nova Compute.

[0126] In step S412, the second virtual device is recovered.

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

[0128] In the above process, in the case that the management and control intention represented by the management and control intention information is to unload the virtual device from the target virtual machine, a device unloading instruction carrying the management and control intention information and the second device identifier is generated, that is, part of the management and control process for the target virtual machine can be transplanted from the physical machine to the smart card, thereby effectively reducing the virtualization overhead required to be borne by the physical machine; and after the device unloading instruction is sent to the Libvirtd deployed on the physical machine, the Libvirtd unloads the second virtual device from the target virtual machine based on the device unloading instruction, then the Nova Compute generates a first recycling instruction for the target virtual machine, and deletes the second backend resource bound to the second virtual device based on the first recycling instruction, so as to release the second virtual device. In this way, through the recycling of the second virtual device, the effective utilization of the virtual device can be realized.

[0129] III. Generation process of definition instruction

[0130] (1) In the case that the management and control intention represented by the management and control intention information is to define the target virtual machine, a plurality of candidate virtual devices are allocated to the target virtual machine.

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

[0132] (2) The plurality of identifier information and the configuration information of the target virtual machine are taken as the overall description information of the target virtual machine.

[0133] The plurality of identifier information corresponds to the plurality of candidate virtual machines one by one; the configuration information of the target virtual machine can include chipset type, Peripheral Component Interconnect (PCI) bus architecture, device form information (for example, form information of system disk / main network card, graphics card, serial port, Balloon, keyboard and mouse, clock device), firmware information (for example, Basic Input Output System (BIOS) information, motherboard information), system information, etc.

[0134] (3) A definition instruction carrying the management and control intention information and the overall description information is generated.

[0135] In an example, after the definition instruction carrying the management intent information and the overall description information is generated, the definition instruction can be sent to the Libvirtd deployed on the physical machine, so as to define the target virtual machine by the Libvirtd based on the definition instruction. In the following, the process will be further illustrated in combination with Figure 5 The process is further illustrated.

[0136] In step S501, the Nova Compute allocates a plurality of candidate virtual devices for the target virtual machine.

[0137] In step S502, the Nova Compute sends the definition instruction to the Libvirt Python deployed on the smart card.

[0138] The definition instruction can carry the management intent information and the overall description information. Here, the overall description information can include a plurality of indexes and configuration information of the target virtual machine, and the plurality of indexes correspond to the plurality of candidate virtual devices one by one.

[0139] In step S503, the Libvirt Python informs the Libvirtd to define the target virtual machine.

[0140] In an example, the Libvirt Python can call a first preset interface (for example, Libvirt Python defineXML interface) to inform the Libvirtd to define the target virtual machine.

[0141] After the Libvirt Python informs the Libvirtd to define the target virtual machine, the Libvirtd enters the process of defining the target virtual machine, and sends the thirteenth feedback information representing that the target virtual machine has been defined to the Libvirt Python, and the Libvirt Python sends the thirteenth feedback information to the Nova Compute.

[0142] In the above process, when the management intent represented by the management intent information is to define the target virtual machine, a plurality of candidate virtual devices are allocated for the target virtual machine, and the plurality of indexes and the configuration information of the target virtual machine are collectively used as the overall description information of the target virtual machine, and then the definition instruction carrying the management intent information and the overall description information is generated. That is, when the target virtual machine is defined, relatively more management processes are completed on the smart card, and therefore, the virtualization overhead borne by the physical machine can be further reduced.

[0143] IV. Generation process of the boot instruction

[0144] (1) in the case of the management intent represented by the management intent information is to start the target virtual machine, selecting a third virtual device from a plurality of candidate virtual devices allocated to the target virtual machine.

[0145] Wherein, the plurality of candidate virtual devices can include a plurality of Virtio Block VF and a plurality of virtual network devices. Here, the plurality of virtual network devices can include a plurality of Virtio Net VF and a plurality of RDMA function supported Rdma VF. It should be noted that in the embodiments of the present disclosure, each candidate virtual device in the plurality of candidate virtual devices has its own identification information. For example, there are N1 Virtio Block VF in the plurality of candidate virtual devices, and the identification information of the N1 Virtio Block VF can be 0, 1, 2, 3, …, N1-1.

[0146] In addition, it should be noted that in the embodiments of the present disclosure, after determining the plurality of candidate virtual devices allocated to the target virtual machine, a candidate virtual device that matches the management intent information and is idle can be selected from the plurality of candidate virtual devices as the third virtual device. In an example, a list of unallocated index numbers can be determined from a total index bitmap related to the plurality of candidate virtual devices, and an unallocated index number can be selected from the list of unallocated index numbers. If the candidate virtual device corresponding to the unallocated index number matches the management intent information, the candidate virtual device is selected 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) binding the third virtual device with the third backend resource.

[0148] Wherein, the third backend resource can be a CDS provided by a block Block Server, or a virtual network port created on a smart card, which can be a QVO, and more specifically, a QVO created on a network bridge device of a smart card. For convenience of distinction, the CDS here can be defined as a third network disk. Based on this, in the embodiments of the present disclosure, in the case that the third virtual device belongs to Virtio Block VF, the third network disk can be used as the third backend resource and bound with the third virtual device; in the case that 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 with the third virtual device.

[0149] (3) sending a redefinition instruction carrying the management intent information and the overall description information to Libvirtd.

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

[0151] (4) In the case of receiving the redefinition feedback information returned by Libvirtd, generating the startup instruction carrying the management and control intention information and the third device identification.

[0152] As described previously, the third device identification is identification information of the third virtual device.

[0153] After selecting the third virtual device from the plurality of candidate virtual devices allocated for the target virtual machine, binding the third virtual device with the third backend resource, and sending the redefinition instruction carrying the management and control intention information and the overall description information to Libvirtd, and receiving the redefinition feedback information returned by Libvirtd, and generating the startup instruction carrying the management and control intention information and the third device identification, the startup instruction can be sent to Libvirtd deployed on the physical machine to perform the startup operation on the target virtual machine based on Libvirtd. Hereinafter, the process will be further described in combination with Figure 6 , the process will be further described in combination with

[0154] In step S601, Nova Compute selects a third virtual device from the plurality of candidate virtual devices allocated for the target virtual machine.

[0155] In step S602, Nova Compute binds the third virtual device with the third backend resource.

[0156] In an example, in the case that the third virtual device belongs to Virtio Block VF, the third network disk can be taken as the third backend resource and bound with the third virtual device; in the case that the third virtual device belongs to Virtio Net VF or Rdma VF, the third network port can be taken as the third backend resource and bound with the third virtual device. Specifically, in the case that the third virtual device belongs to Virtio Block VF, a fifth preset script (for example, Bf3-Volume-Ops.Py script) can be called to take the third network disk as the third backend resource and bind it with the third virtual device; in the case that the third virtual device belongs to Virtio Net VF or Rdma VF, a sixth preset script (for example, Bf3-Net-Ops.Py script) can be called to take the third network port as the third backend resource and bind it with the third virtual device.

[0157] After the Nova Compute binds the third virtual device to the third backend resource successfully by invoking the fifth preset script and the sixth preset script, the fifth preset script and the sixth preset script send the fourteenth feedback information to the Nova Compute, where the fourteenth feedback information represents that the third virtual device is bound to the third backend resource successfully.

[0158] After the binding is successful, the step S603 can be performed.

[0159] In the step S603, the Nova Compute sends a redefine instruction (also referred to as Define XML) carrying the management intent information and the overall description information to the Libvirtd.

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

[0161] In addition, in the embodiment of the present disclosure, after the Libvirtd receives the Define XML, the Libvirtd sends the fifteenth feedback information to the Nova Compute, where the fifteenth feedback information represents that the Define XML has been received successfully.

[0162] In the step S604, the Nova Compute generates a start instruction carrying the management intent information and the third device identifier.

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

[0164] In an example, the Nova Compute can invoke a second preset interface (for example, a LibvirtPythondefineXML interface) to redefine the domain (Domain) information of the target virtual machine, and invoke a third preset interface (for example, a CreateWithFlags interface) to send a start request to the Libvirtd, that is, generate the start instruction carrying the management intent information and the third device identifier, and send the start instruction to the Libvirtd.

[0165] In the step S605, the Libvirtd prepares an RDMA device.

[0166] In the case that the third virtual device belongs to the Rdma VF, the RDMA device can be obtained based on the third virtual device bound to the third network port; in the case that the third virtual device does not belong to the Rdma VF, a virtual device can be selected from the plurality of candidate virtual devices to obtain the RDMA device, which is not described herein.

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

[0168] In the embodiment of the present disclosure, the preparation of the Vhost device can be hosting the third virtual device to the Vhost device.

[0169] In addition, in the embodiment of the present disclosure, after the Vfe Vhostd prepares the Vhost device, the Vfe Vhostd sends the sixteenth feedback information to the Libvirtd, which is used to represent that the preparation of the Vhost device has been completed.

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

[0171] In the embodiment of the present disclosure, after the Qemu process is started, the Qemu process can communicate with the Vfe Vhostd.

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

[0173] Step S608, Libvirtd requests to check the running state of the Qemu.

[0174] In the embodiment of the present disclosure, the Libvirtd also receives the eighteenth feedback information sent by the Qemu to the Nova Compute, which is used to represent the state detection result (for example, Power State: Runninglpgopause) of the Qemu.

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

[0176] In the embodiment of the present disclosure, after the Nova Compute sends the power state detection request for the target virtual machine to the Libvirtd, the Nova Compute receives the nineteenth feedback information sent by the Libvirtd, which is used to represent the power state of the target virtual machine.

[0177] In the above process, in a case that the control intent represented by the control intent information is to perform a power-on operation on the target virtual machine, a third virtual device is selected from the plurality of candidate virtual devices allocated to the target virtual machine, the third virtual device is bound to a third backend resource, and a redefinition instruction carrying the control intent information and the overall description information is sent to the Libvirtd, so that in a case that redefinition feedback information returned by the Libvirtd is received, a power-on instruction carrying the control intent information and a third device identifier is generated. That is, in the power-on operation on the target virtual machine, relatively more control processes of the target virtual machine are completed on the smart card, and the Nova Compute is also used to provide the target virtual machine with a backend resource (here, specifically, the third backend resource, including a third network disk and / or a third network port), so as to reduce the occupation of the physical machine resources, thereby effectively reducing the virtualization overheads to be borne by the physical machine.

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

[0179] In relation thereto, the embodiment of the present disclosure also provides a second way of sending the smart card port range data to the Libvirtd. Specifically, the rules of source network address translation (SNAT) and destination network address translation (DNAT) can be created by using the multi-port range mapping (also known as Iptbales port mapping) to achieve the allocation of the virtual network computing (VNC) port.

[0180] Please refer to Figure 7For example, when an external network wants to access any virtual machine created on the physical machine, first, it enters through the ingress address (i.e., 169.254.62.1), and according to the DNAT rule, based on the target port number (for example, a port in the port range of 5900-6899), the network traffic accessing the VNC is routed to the intermediate address (i.e., 169.254.62.129), and then through a specific port, further routed to the corresponding Qemu virtual machine. Conversely, when a Qemu virtual machine needs to communicate with the external network, the VNC traffic can be sent to the external address through the ingress address according to the SNAT rule.

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

[0182] Nova Compute invokes the sixth preset interface (for example, the CreateWithFlags of the Libvirt Python interface) to start the target virtual machine;

[0183] Libvirt Python invokes the seventh preset interface (for example, the VirDomainCreateSetMetadata interface) in (the Remote Driver) to mount the smart card port range data (i.e., the port range metadata) to the live state of the target virtual machine.

[0184] Libvirtd obtains the smart card port range data from the target virtual machine and performs VNC port allocation therein.

[0185] Five, the generation process of the shutdown instruction

[0186] In the case where the control intention represented by the control intention information is a shutdown operation on the target virtual machine, a shutdown instruction carrying the control intention information is generated.

[0187] After the shutdown instruction carrying the control intention information is generated, the shutdown instruction can be sent to the Libvirtd deployed on the physical machine, so that the Libvirtd performs a shutdown operation on the target virtual machine based on the shutdown instruction. Thereafter, the Nova Compute generates a second recovery instruction for the target virtual machine, and based on the second recovery instruction, deletes the fourth backend resource bound to the fourth virtual device of the target virtual machine to release the fourth virtual device. The following will further describe the process in combination with Figure 8

[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 can generate a shutdown instruction carrying the management intention information, and send the shutdown instruction to Libvirtd deployed on the physical machine through a fourth preset interface (e.g., Libvirt Python Shudown interface).

[0190] In step S802, Libvirtd notifies Qemu to close the target virtual machine after receiving the shutdown instruction.

[0191] In an example, Libvirtd can notify Qemu to close the target virtual machine through 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, for example, Guest, or pull up the pin of a General-Purpose Input / Output (GPIO) interface, to notify the operating system of the target virtual machine to close.

[0192] After receiving the shutdown prompt sent by Libvirtd, Qemu sends twenty-first feedback information to Libvirtd, and then Libvirtd sends the twentieth feedback information to Nova Compute to represent that the shutdown instruction has been received.

[0193] In step S803, Qemu sends a virtual machine closing result to Libvirtd.

[0194] In step S804, Libvirtd sends a process termination request to Qemu to request to terminate the Qemu process.

[0195] In an example, Libvirtd can first send a Kill-15 instruction to Qemu to request to terminate the Qemu process.

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

[0197] In step S805, a loop checking phase for the Qemu process is entered.

[0198] Specifically, the Libvirtd sends multiple process termination requests to the Qemu to request termination of the Qemu process. In an example, the Libvirtd can first send a Kill-15 instruction to the Qemu to request termination of the Qemu process. After receiving the Kill-15 instruction, the Qemu attempts to terminate the Qemu process and sends twenty-second feedback information to the Libvirtd, which represents whether the Qemu process is successfully terminated. In the case that the Qemu process is not successfully terminated, the Libvirtd can send a Kill-9 instruction to the Qemu to request forced termination of the Qemu process.

[0199] In step S806, the Libvirtd sends a removal request for the fourth virtual device to the Vfe Vhostd.

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

[0201] In step S807, the Nova Compute cyclically sends a power state detection request for the target virtual machine to the Libvirtd.

[0202] After sending the power state detection request for the target virtual machine to the Libvirtd, the Nova Compute receives twenty-fourth feedback information from the Libvirtd, which represents the power state of the target virtual machine.

[0203] In step S808, a second recycling instruction for the target virtual machine is generated by the Nova Compute, 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.

[0204] In an example, in a case that the fourth virtual device belongs to Virtio Block VF, the fourth backend resource bound with the fourth virtual device is a fourth network disk, thus, the fourth network disk bound with the fourth virtual device can be deleted; in a case that the fourth virtual device belongs to Virtio Net VF or Rdma VF, the fourth backend resource bound with the fourth virtual device is a fourth network port, thus, the fourth network port bound with the fourth virtual device can be deleted. Specifically, in a case that the fourth virtual device belongs to Virtio Blk VF, a seventh preset script (for example, a Bf3-Volume-Ops.Py script) can be invoked to delete the fourth network disk bound with the fourth virtual device; in a case that the fourth virtual device belongs to Virtio Net VF or Rdma VF, an eighth preset script (for example, a Bf3-Net-Ops.Py script) can be invoked to delete the fourth network port bound with the fourth virtual device.

[0205] In step S809, the target virtual machine is shut down.

[0206] In the above process, in a case that the management and control intention represented by the management and control intention information is a shutdown operation on the target virtual machine, a shutdown instruction carrying the management and control intention information is generated, and after the shutdown instruction carrying the management and control intention information is generated, the shutdown instruction is sent to the Libvirtd deployed on the physical machine, so that the Libvirtd performs a shutdown operation on the target virtual machine based on the shutdown instruction. Thereafter, the Nova Compute is used to generate a second recovery instruction for the target virtual machine, and based on the second recovery instruction, the fourth backend resource bound with the fourth virtual device of the target virtual machine is deleted to release the fourth virtual device. That is, when the target virtual machine is shut down, relatively more management and control processes for the target virtual machine are completed on the smart card, thereby reducing the virtualization overheads to be borne by the physical machine.

[0207] Six, generation process of the destruction instruction

[0208] In a case that the management and control intention represented by the management and control intention information is to destroy the target virtual machine, a destruction instruction carrying the management and control intention information is generated.

[0209] After the destruction instruction carrying the management and control intention information is generated, the destruction instruction can be sent to the Libvirtd deployed on the physical machine, so that the Libvirtd destroys the target virtual machine based on the destruction instruction. Thereafter, the Nova Compute is used to generate a second recovery instruction for the target virtual machine, and based on the second recovery instruction, the fourth backend resource bound with the fourth virtual device of the target virtual machine is deleted to release the fourth virtual device. In the following, the process will be further described in combination with Figure 9 ​

[0210] Step S901, Nova Compute generates a destroy instruction carrying the management intention information, and sends the destroy instruction to Libvirtd.

[0211] Step S902, Libvirtd enters a destroy process for the target virtual machine after receiving the destroy instruction.

[0212] Step S903, a loop destroy phase for the Qemu process is entered.

[0213] Specifically, Libvirtd sends multiple process destroy requests to Qemu to request the destruction of the Qemu process. In an example, Libvirtd can first send a Kill-15 instruction to Qemu to request the destruction of the Qemu process. After receiving the Kill-15 instruction, Qemu attempts to destroy the Qemu process and sends second twenty-fifth feedback information to Libvirtd, indicating whether the Qemu process is successfully destroyed. If the Qemu process is not successfully destroyed, Libvirtd can send a Kill-9 instruction to Qemu to request 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 feedback information to Libvirtd indicating that the removal is successful.

[0216] After receiving the removal request for the fourth virtual device, Vfe Vhostd removes the fourth virtual device and sends second twenty-sixth feedback information to Libvirtd, which is then sent to Nova Compute by Libvirtd to indicate that the fourth virtual device has been removed.

[0217] Step S905, Nova Compute sends a power state detection request for the target virtual machine to Libvirtd in a loop.

[0218] After sending the power state detection request for the target virtual machine to Libvirtd, Nova Compute receives second twenty-seventh feedback information from Libvirtd indicating the power state of the target virtual machine.

[0219] Step S906, using Nova Compute, a second recovery instruction for the target virtual machine is generated, and based on the second recovery instruction, the fourth backend resource bound to the fourth virtual device of the target virtual machine is deleted to release the fourth virtual device.

[0220] In an example, in a case that the fourth virtual device belongs to Virtio Block VF, the fourth backend resource bound with the fourth virtual device is a fourth network disk, thus, the fourth network disk bound with the fourth virtual device can be deleted; in a case that the fourth virtual device belongs to Virtio Net VF or Rdma VF, the fourth backend resource bound with the fourth virtual device is a fourth network port, thus, the fourth network port bound with the fourth virtual device can be deleted. Specifically, in a case that the fourth virtual device belongs to Virtio Blk VF, a seventh preset script (for example, a Bf3-Volume-Ops.Py script) can be invoked to delete the fourth network disk bound with the fourth virtual device; in a case that the fourth virtual device belongs to Virtio Net VF or Rdma VF, an eighth preset script (for example, a Bf3-Net-Ops.Py script) can be invoked to delete the fourth network port bound with the fourth virtual device.

[0221] In step S908, the target virtual machine is closed.

[0222] In the above process, in a case that the management and control intention represented by the management and control intention information is to destroy the target virtual machine, a destruction instruction carrying the management and control intention information is generated, and after the destruction instruction carrying the management and control intention information is generated, the destruction instruction is sent to the Libvirtd deployed on the physical machine, so that the Libvirtd destroys the target virtual machine based on the destruction instruction, and then, the Nova Compute generates a second recovery instruction for the target virtual machine, and deletes the fourth backend resource bound with the fourth virtual device of the target virtual machine based on the second recovery instruction, so as to release the fourth virtual device. That is to say, when the target virtual machine is destroyed, relatively more management and control processes of the target virtual machine are completed on the smart card, so as to reduce the virtualization overheads to be borne by the physical machine.

[0223] Seven, generation process of deletion instruction

[0224] In a case that the management and control intention represented by the management and control intention information is to delete the target virtual machine, a deletion instruction carrying the management and control intention information is generated.

[0225] After the deletion instruction carrying the management and control intention information is generated, the deletion instruction can be sent to the Libvirtd deployed on the physical machine, so that the Libvirtd deletes the target virtual machine based on the deletion instruction, and then, the Nova Compute generates a second recovery instruction for the target virtual machine, and deletes the fourth backend resource bound with the fourth virtual device of the target virtual machine based on the second recovery instruction, so as to release the fourth virtual device. In the following, the generation process of the second recovery instruction will be described in combination with the generation process of the first recovery instruction. Figure 10The process is further described.

[0226] At step S1001, Nova Compute generates a deletion instruction carrying the management intent information and sends the deletion instruction to Libvirt Python.

[0227] In an example, after generating the deletion instruction carrying the management intent information, Nova Compute can invoke a fifth preset interface (e.g., Libvirt Python undefine) to send the deletion instruction to Libvirt Python.

[0228] At step S1002, Libvirt Python sends the deletion instruction to Libvirtd.

[0229] Libvirtd is configured 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, sends a twenty-eighth feedback to Libvirtd, and sends the twenty-eighth feedback to Nova Compute through Libvirtd to indicate that the fourth virtual device has been removed.

[0231] At step S1003, Nova Compute generates a second recovery instruction for the target virtual machine, and deletes the fourth backend resource bound to the fourth virtual device of the target virtual machine based on the second recovery instruction to release the fourth virtual device.

[0232] In an example, when the fourth virtual device belongs to Virtio Block VF, the fourth backend resource bound to the fourth virtual device is a fourth network disk, and thus 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 a fourth network port, and thus the fourth network port bound to the fourth virtual device can be deleted. Specifically, when the fourth virtual device belongs to Virtio Blk VF, a seventh preset script (e.g., Bf3-Volume-Ops.Py script) can be invoked 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, an eighth preset script (e.g., Bf3-Net-Ops.Py script) can be invoked to delete the fourth network port bound to the fourth virtual device.

[0233] Step S1004, recovering the index number of the fourth virtual device.

[0234] In the above process, in the case that the management and control intention represented by the management and control intention information is to delete the target virtual machine, a deletion instruction carrying the management and control intention information is generated, and after the deletion instruction carrying the management and control intention information is generated, the deletion instruction is sent to the Libvirtd deployed on the physical machine, so that the Libvirtd deletes the target virtual machine based on the deletion instruction. Thereafter, the Nova Compute is used to generate a second recovery instruction for the target virtual machine, and based on the second recovery 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 management and control process is completed on the smart card, and therefore, the virtualization overhead that needs to be borne by the physical machine can be further reduced.

[0235] In some optional embodiments, the virtual machine management method can further include:

[0236] obtaining network disk monitoring data of the target virtual machine by using the virtualization monitoring component (Libvirt Monitor) deployed on the smart card;

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

[0238] The network disk monitoring data can be stored in a monitoring log.

[0239] Please refer to Figure 11 The network disk monitoring data of the target virtual machine can be obtained by monitoring the target virtual machine by using the snapshot function component (Snap), writing the network disk monitoring data of the target virtual machine into a monitoring log for storage, and then reading the network disk monitoring data of the target virtual machine from the monitoring log by the Libvirt Monitor and sending the network disk monitoring data of the target virtual machine to the cloud management server.

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

[0241] In the above manner, in the embodiments 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 of the target virtual machine can be sent to the cloud management server, so as to realize data monitoring of the target virtual machine and ensure the security of the virtual machine management system.

[0242] The embodiment of the disclosure provides a virtual machine management method, which can be applied to a physical machine included in a virtual machine management system. Wherein, the physical machine can be a server needed to create multiple virtual machines. In addition, in the embodiment of the disclosure, the virtual machine management system further includes a smart card, which is used to obtain a virtual machine management request and generate a management operation instruction for a target virtual machine based on the virtual machine management request by using a computing node service deployed on the smart card. Wherein, it can be a card-type device integrated with a microprocessor and a storage unit, or it can be understood as a server-like device. Hereinafter, a virtual machine management method provided by the embodiment of the disclosure will be described in conjunction with the flowchart shown in Figure 12 It should be noted that although the logical order is shown in the flowchart, in some cases, the steps shown or described in the flowchart can also be executed in other orders.

[0243] Step S1201, receiving a management operation instruction.

[0244] Step S1202, based on the management operation instruction, performing a management operation on the target virtual machine.

[0245] Wherein, the management operation instruction includes at least one of device mounting instruction, device unloading instruction, definition instruction, power-on instruction, power-off instruction, destruction instruction and deletion instruction.

[0246] In the embodiment of the disclosure, the specific functions and examples of each unit in the virtual machine management method can be referred to the related description of the corresponding steps in the foregoing virtual machine management method embodiments, which will not be repeated here.

[0247] Please refer to Figure 13 A virtual machine management system provided by the embodiment of the disclosure includes a physical machine and a smart card.

[0248] Wherein, the smart card is deployed with:

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

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

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

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

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

[0254] (6) Storage Performance Development Kit (Spdk) is 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 (Snap) is used to save the state of a virtual machine at a specific point in time, including memory, disk, network configuration, etc.

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

[0258] (10) Libvirt.so dynamic library, that is, Libvirt shared object library, implements 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 for the Python programming language, which encapsulates some application programming interfaces (APIs) related to Libvirtd;

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

[0261] On the physical machine, there are:

[0262] (1) Libvirtd is a daemon of Libvirt, responsible for managing virtual machines;

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

[0264] (3) Vef Vhostd Cli is a virtual machine management software, which 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 Emulator (Qemu): QEMU is a widely used open-source computer emulator and virtual machine software. As a standalone Hypervisor (Virtual Machine Monitor), QEMU can run virtual machines at the application level, while also supporting 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; Nova Compute 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 can call Libvirtd, and then send device loading commands to Vfe Vhostd through Vef-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, in combination with Figure 14 , the logical architecture of the virtual machine management system is described.

[0269] Firstly, a static block device, i.e., Static Block PF, can be simulated by using Snap+Spdk, and a plurality of Virtio Block VFs can be simulated by using the Static Block PF. Then, Virtio Block VF1 can be unbound from the Virtio driver, and bound to the Vfio driver to encapsulate a Vhost User Block and host the Vhost User Block to a Vfe Vhostd. The Vfe Vhostd communicates with Qemu, and Virtio Block VF can be mounted to the PCI of the physical machine. A static network device, i.e., Static Net PF, can be simulated by using Ovs+Virtio Net Controller, and a plurality of Virtio Net VFs can be simulated by using the Static Net PF. Then, Virtio Net VF1 can be unbound from the Virtio driver, and bound to the Vfio driver to encapsulate a Vhost User Net and host the Vhost User Net to the Vfe Vhostd. The Vfe Vhostd communicates with Qemu, and Virtio Net VF can be mounted to the PCI of the physical machine. A Native Net PF can be simulated by using Ovs+Virtio Net Controller, and a plurality of Rdma VFs, i.e., Vfio Pci, can be simulated by using the Native Net PF. Then, the Vfio Pci communicates with Qemu, and the Vfio Pci can be mounted to the PCI of the physical machine.

[0270] In summary, the virtual machine management method provided by the embodiments of the present disclosure can obtain a virtual machine management request, and generate a management operation instruction for a target virtual machine based on the virtual machine management request by using Nova Compute deployed on a smart card. Then, the management operation instruction is sent to Libvirtd deployed on a physical machine, so that Libvirtd performs a management operation on the target virtual machine based on the management operation instruction. That is, in the embodiments of the present disclosure, an independent smart card of the physical machine is expanded, and based on the smart card, not only can part of the management process of the target virtual machine be transplanted from the physical machine to the smart card, but also Snap and Ovs deployed on the smart card can be used to provide a backend resource for the target virtual machine, so as to reduce the virtualization overheads that the physical machine needs to bear. Therefore, the rational use of physical machine resources can be greatly promoted, and unnecessary resource waste can be avoided.

[0271] To better implement the virtual machine management method applied to the smart card included in the virtual machine management system, the embodiment of the disclosure further provides a virtual machine management device which can be integrated into the smart card included in the virtual machine management system. Hereinafter, a virtual machine management device 1500 provided by the embodiment of the disclosure will be described in conjunction with the schematic structural block diagram shown in FIG. 15. Figure 15

[0272] The virtual machine management device 1500 comprises:

[0273] The request obtaining unit 1501 is configured to obtain a virtual machine management request.

[0274] The indication generating unit 1502 is configured to generate, based on the virtual machine management request, a management operation indication for a target virtual machine by using Nova Compute deployed on the smart card.

[0275] The indication sending unit 1503 is configured to send the management operation indication to Libvirtd deployed on a physical machine, wherein Libvirtd is configured to perform a management operation on the target virtual machine based on the management operation indication.

[0276] In some optional embodiments, the indication generating unit 1502 is configured to:

[0277] analyze the virtual machine management request to obtain management intention information for the target virtual machine;

[0278] generate the management operation indication for the target virtual machine based on the management intention information.

[0279] In some optional embodiments, the management operation indication comprises at least one of a device mounting indication, a device unmounting indication, a definition indication, a startup indication, a shutdown indication, a destruction indication, and a deletion indication.

[0280] In some optional embodiments, the management operation indication comprises the device mounting indication, and the indication generating unit 1502 is configured to:

[0281] select a first virtual device from a plurality of candidate virtual devices allocated for the target virtual machine in a case where the management intention represented by the management intention information is to mount the first virtual device on the target virtual machine;

[0282] bind the first virtual device with a first back-end resource;

[0283] generate a device mounting indication carrying the management intention information and a first device identifier, wherein the first device identifier is identification information of the first virtual device.

[0284] In some optional embodiments, the indication generating unit 1502 is configured to: ​

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

[0286] Or, in a case where the first virtual device belongs to a virtual network device, the first network port is bound to the first virtual device as the first backend resource.

[0287] In some optional embodiments, the management operation indication includes a device uninstallation indication; the indication generation unit 1502 is configured to:

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

[0289] In some optional embodiments, the virtual machine management apparatus 1500 further includes a first management unit, configured to:

[0290] Using Nova Compute, a first recovery indication for the target virtual machine is generated;

[0291] Based on the first recovery indication, a second backend resource bound to the second virtual device is deleted to release the second virtual device;

[0292] The second virtual device is recovered.

[0293] In some optional embodiments, the management operation indication includes a definition indication; the indication generation unit 1502 is configured to:

[0294] In a case where the management intention represented by the management intention information is to define the target virtual machine, a plurality of candidate virtual devices are allocated to the target virtual machine;

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

[0296] A definition indication carrying the management intention information and the overall description information is generated.

[0297] In some optional embodiments, the management operation indication includes a startup indication; the indication generation unit 1502 is configured to:

[0298] In a case where the management intention represented by the management intention information is to perform a startup operation on the target virtual machine, a third virtual device is selected from the plurality of candidate virtual devices allocated to the target virtual machine;

[0299] binding the third virtual device with a third backend resource;

[0300] sending a redefinition instruction carrying the management and control intention information and the overall description information to the Libvirtd, wherein the overall description information comprises a plurality of identification information corresponding to the plurality of candidate virtual devices one by one, and configuration information of the target virtual machine;

[0301] in the case of receiving the redefinition feedback information returned by the Libvirtd, generating a startup instruction carrying the management and control intention information and the third device identification, wherein the third device identification is the identification information of the third virtual device.

[0302] In some optional embodiments, the indication generating unit 1502 is configured to:

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

[0304] Or, in the case that the third virtual device belongs to a virtual network device, binding the third network port as the third backend resource with the third virtual device.

[0305] In some optional embodiments, the indication generating unit 1502 is configured to:

[0306] Generating a startup instruction carrying the management and control intention information, the third device identification and the smart card port range data.

[0307] In some optional embodiments, the management and control operation indication comprises at least one of a shutdown instruction, a destruction instruction and a deletion instruction; the indication generating unit 1502 is configured to:

[0308] In the case that the management and control operation indication comprises a shutdown instruction, and the management and control intention represented by the management and control intention information is a shutdown operation on the target virtual machine, generating a shutdown instruction carrying the management and control intention information;

[0309] In the case that the management and control operation indication comprises a destruction instruction, and the management and control intention represented by the management and control intention information is to destroy the target virtual machine, generating a destruction instruction carrying the management and control intention information;

[0310] In the case that the management and control operation indication comprises a deletion instruction, and the management and control intention represented by the management and control intention information is to delete the target virtual machine, generating a deletion instruction carrying the management and control intention information.

[0311] In some optional embodiments, the virtual machine management apparatus 1500 further comprises a second management and control unit, configured to:

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

[0313] based on the second recovery indication, deleting a fourth backend resource bound with a fourth virtual device of the target virtual machine to release the fourth virtual device.

[0314] In some optional embodiments, the virtual machine management apparatus 1500 further comprises a third management unit, configured to:

[0315] obtain the network disk monitoring data of the target virtual machine by using the virtualization monitoring component deployed on the smart card.

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

[0317] In the embodiments of the present disclosure, the specific functions and examples of each unit in the virtual machine management apparatus 1500 can be referred to the related descriptions of the corresponding steps in the foregoing virtual machine management method embodiments, and will not be described here.

[0318] In order to better implement the foregoing virtual machine management method applied to the physical machine included in the virtual machine management system, the embodiments of the present disclosure further provide a virtual machine management apparatus which can be integrated into the physical machine included in the virtual machine management system. Hereinafter, the virtual machine management apparatus 1600 provided by the embodiments of the present disclosure will be described with reference to the schematic structural block diagram shown in FIG. 16. Figure 16

[0319] The virtual machine management apparatus 1600 comprises:

[0320] an indication receiving unit 1601 configured to receive a management operation indication;

[0321] a management operation unit 1602 configured to perform a management operation on a target virtual machine based on the management operation indication.

[0322] In some optional embodiments, the management operation indication comprises at least one of a device mounting indication, a device unmounting indication, a definition indication, a startup indication, a shutdown indication, a destruction indication, and a deletion indication.

[0323] In the embodiments of the present disclosure, the specific functions and examples of each unit in the virtual machine management apparatus 1600 can be referred to the related descriptions of the corresponding steps in the foregoing virtual machine management method embodiments, and will not be described here.

[0324] In the technical solutions of the present disclosure, the acquisition, storage and application of user personal information involved all comply with the relevant legal regulations and do not violate public order and good customs.

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

[0326] Figure 17 ​A schematic structural block diagram of an electronic device 1700 that can be used to implement various examples in embodiments of the present disclosure is shown. The electronic device 1700 is intended to represent various forms of digital computers, such as laptops, desktops, workstations, personal digital assistants, servers, blade servers, mainframes, and other appropriate computers. The electronic device 1700 can also represent various forms of mobile devices, such as personal digital assistants, cellular telephones, smartphones, wearable devices, and other similar computing devices. The components shown here, their connections and relationships, and their functions, are meant to be examples only, and are not intended to limit the implementations of the present disclosure described and / or claimed in this document.

[0327] As shown in Figure 17 The electronic device 1700 includes a computing unit 1701 that can perform various appropriate actions and processes in accordance with a computer program stored in a Read-Only Memory (ROM) 1702 or a computer program loaded into a Random Access Memory (RAM) 1703 from a storage unit 1708. Various programs and data required for the operation of the electronic device 1700 can also be stored in the RAM 1703. The computing unit 1701, the ROM 1702, and the RAM 1703 are connected to each other through a bus 1704. An Input / Output (I / O) interface 1705 is also connected to the bus 1704.

[0328] Various 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, a speaker, etc., a storage unit 1708, such as a magnetic 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 can be various general and / or special purpose 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 special-purpose Artificial Intelligence (AI) computing chips, various computing units running machine learning model algorithms, a Digital Signal Process (DSP), and any appropriate processor, controller, microcontroller, etc. The computing unit 1701 performs various methods and processes described above, e.g., the virtual machine management method. For example, in some embodiments, the virtual machine management method can be implemented as a computer software program tangibly embodied in a machine-readable medium, e.g., the storage unit 1708. In some embodiments, part or all of the computer program can be loaded and / or installed onto the electronic device 1700 via the ROM 1702 and / or the communication unit 1709. When the computer program is loaded onto the RAM 1703 and executed by the computing unit 1701, one or more steps of the virtual machine management method described above can be performed. Alternatively, in other embodiments, the computing unit 1701 can be configured as the virtual machine management method by any other appropriate means, e.g., by means of firmware.

[0330] Various implementations of the systems and techniques described above can be realized in digital electronic circuitry, integrated circuitry, a Field Programmable Gate Array (FPGA), an Application Specific Integrated Circuit (ASIC), an Application Specific Standard Product (ASSP), a System on Chip (SOC), a Complex Programmable Logic Device (CPLD), computer hardware, firmware, software, and / or combinations thereof. These various implementations can include implementation in one or more computer programs that are executable and / or interpretable on a programmable system including at least one programmable processor, which can be special or general purpose, coupled to receive data and instructions from, and to transmit data and instructions to, a storage system, at least one input device, and at least one output device.

[0331] Program code for carrying out methods of the present disclosure can be written in any combination of one or more programming languages. The program code can be provided to a processor or controller of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the program code, when executed by the processor or controller, produces a means for implementing the functions / acts specified in the flowcharts and / or block diagrams. The program code can be executed entirely on a machine, partially on a machine, partially on a machine as a stand-alone software package, partially on a machine and partially on a remote machine or entirely on a remote machine or server.

[0332] In the context of the present disclosure, a machine-readable medium can be a tangible medium that contains or stores a program for use by or in connection with an instruction execution system, apparatus, or device. The machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can include but is not limited to an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of the machine-readable storage medium would include one or more lines of electrical connections, portable computer disks, hard disk drives, RAM, ROM, erasable programmable read-only memory (EPROM) or flash memory, fiber optics, compact disc read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0333] To provide for interaction with a user, the systems and techniques described here can be implemented on a computer having a rendering device (e.g., a Cathode Ray Tube (CRT) or Liquid Crystal Display (LCD) monitor for

[0334] The systems and techniques described here can be implemented in a computing system that includes a back end component (e.g., as a data server), or that includes a middleware component (e.g., an application server), or that includes a front end component (e.g., a user computer having a graphical user interface or a Web browser through which a user can interact with an implementation of the systems and techniques described here), or any combination of such back end, middleware, 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 a local area network (LAN), a wide area network (WAN), and the Internet.

[0335] The computer system can include a user terminal and a server. The user terminal and the server are generally remote from each other and typically interact through a communication network. The relationship of user terminal and server is merely that of two electronic devices that exchange data 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 embodiments of the present disclosure further provide a non-transitory computer-readable storage medium storing computer instructions, wherein the computer instructions are used to cause a computer to execute the virtual machine management method.

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

[0338] It should be understood that the various forms of flow shown above can be used to reorder, add, or delete steps. For example, the steps described in the present disclosure can be executed in parallel, in sequence, or in a different order, as long as the desired results of the technical solutions disclosed in the present disclosure can be achieved, and the present disclosure is not limited herein. In addition, in the present disclosure, relationship 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 any such actual relationship or order between the entities or operations. In addition, in the present disclosure, "a plurality of" can be understood as at least two.

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

Claims

1. A virtual machine management method applied to a smart card included in a virtual machine management system, the virtual machine management system further including a physical machine; the method comprising: obtaining a virtual machine management request; generating, by a computing node service deployed on the smart card, a management operation instruction for a target virtual machine based on the virtual machine management request; sending the management operation instruction to a virtualization management program deployed on the physical machine; wherein the virtualization management program is configured to execute a management operation for the target virtual machine based on the management operation instruction; wherein the generating of the management operation instruction for the target virtual machine based on the virtual machine management request comprises: parsing the virtual machine management request to obtain management intention information for the target virtual machine; generating the management operation instruction for the target virtual machine based on the management intention information; wherein, in the case that the management operation instruction includes a device mounting instruction, the generating of the management operation instruction for the target virtual machine based on the management intention information comprises: in the case that the management intention represented by the management 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 with a first backend resource; and generating the device mounting instruction carrying the management intention information and a first device identifier; wherein the first device identifier is identification information of the first virtual device.

2. The method of claim 1, wherein, The management operation instruction includes at least one of a device mounting instruction, a device unmounting instruction, a definition instruction, a startup instruction, a shutdown instruction, a destruction instruction, and a deletion instruction.

3. The method of claim 1, wherein, The binding of the first virtual device with the first backend resource comprises: in the case that the first virtual device belongs to a virtual block device, binding a first network disk as the first backend resource with the first virtual device; or in the case that the first virtual device belongs to a virtual network device, binding a first network port as the first backend resource with the first virtual device.

4. The method of claim 1, wherein, In the case that the management operation instruction includes a device unmounting instruction, the generating of the management operation instruction for the target virtual machine based on the management intention information comprises: in the case that the management intention represented by the management intention information is to unmount a virtual device from the target virtual machine, generating the device unmounting instruction carrying the management intention information and a second device identifier; wherein the second device identifier is identification information of a second virtual device to be unmounted from the target virtual machine. 5.The method of claim 4, further comprising: generating, by the computing node service, a first recycling instruction for the target virtual machine; based on the first recycling instruction, deleting a second backend resource bound with the second virtual device to release the second virtual device; recycling the second virtual device.

6. The method of claim 1, wherein, In a case where the management operation instruction comprises a definition instruction, the generating, based on the management intention information, of the management operation instruction for the target virtual machine comprises: In a case where the management intention represented by the management intention information is to define the target virtual machine, assigning a plurality of candidate virtual devices to the target virtual machine; taking the plurality of identification information and the configuration information of the target virtual machine as the overall description information of the target virtual machine; generating the definition instruction carrying the management intention information and the overall description information.

7. The method of claim 1, wherein, In a case where the management operation instruction comprises a start-up instruction, the generating, based on the management intention information, of the management operation instruction for the target virtual machine comprises: In a case where the management intention represented by the management intention information is to start up the target virtual machine, selecting a third virtual device from a plurality of candidate virtual devices assigned to the target virtual machine; binding the third virtual device with a third backend resource; sending a redefinition instruction carrying the management intention information and overall description information to the virtualization management program; wherein the overall description information comprises a plurality of identification information corresponding to the plurality of candidate virtual devices, and the configuration information of the target virtual machine; In a case where the virtualization management program returns redefinition feedback information, generating the start-up instruction carrying the management intention information and a third device identification; wherein the third device identification is the identification information of the third virtual device.

8. The method of claim 7, wherein, The binding of the third virtual device with a third backend resource comprises: In a case where the third virtual device belongs to a virtual block device, taking a third network disk as the third backend resource and binding the third virtual device with the third network disk; or, in a case where the third virtual device belongs to a virtual network device, taking a third network port as the third backend resource and binding the third virtual device with the third network port.

9. The method of claim 7, wherein, The generating of the start-up instruction carrying the management intention information and the third device identification comprises: generating the start-up instruction carrying the management intention information, the third device identification and smart card port range data.

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

11. The method of claim 10, further comprising: generating, by the computing node service, a second recycling instruction for the target virtual machine; based on the second recycling instruction, deleting a fourth backend resource bound to a fourth virtual device of the target virtual machine to release the fourth virtual device.

12. The method of any one of claims 1-11, further comprising: obtaining, by a virtualization monitoring component deployed on the smart card, network disk monitoring data of the target virtual machine; sending the network disk monitoring data to a cloud management server.

13. A virtual machine management method, applied to a physical machine included in a virtual machine management system, the virtual machine management system further comprising a smart card, the smart card being configured to acquire a virtual machine management request, and parse the virtual machine management request by using a computing node service deployed on the smart card to obtain management intention information for a target virtual machine, and in a case where a management operation instruction of the target virtual machine comprises a device mounting instruction, and a management intention represented by the management intention information is to mount a virtual device on the target virtual machine, select a first virtual device from a plurality of candidate virtual devices allocated to the target virtual machine; and bind the first virtual device with a first back-end resource. generating the device mounting instruction carrying the management and control intention information and a first device identifier; wherein the first device identifier is identifier information of the first virtual device. The method comprises: receiving the management and control operation instruction; based on the management and control operation instruction, performing a management and control operation on the target virtual machine.

14. The method of claim 13, wherein, The management and control operation instruction includes at least one of a device mounting instruction, a device unmounting instruction, a definition instruction, a startup instruction, a shutdown instruction, a destruction instruction, and a deletion instruction.

15. A virtual machine management and control apparatus applied to a smart card included in a virtual machine management and control system, the virtual machine management and control system further including a physical machine; the apparatus comprising: a request obtaining unit configured to obtain a virtual machine management and control request; an instruction generating unit configured to generate, by a computing node service deployed on the smart card, a management and control operation instruction for a target virtual machine based on the virtual machine management and control request; an instruction sending unit configured to send the management and control operation instruction to a virtualization management and control program deployed on the physical machine; wherein the virtualization management and control program is configured to perform a management and control operation on the target virtual machine based on the management and control operation instruction; wherein the instruction generating unit is configured to: analyze the virtual machine management and control request to obtain management and control intention information for the target virtual machine; based on the management and control intention information, generate the management and control operation instruction for the target virtual machine; wherein in a case where the management and control operation instruction includes a device mounting instruction, the instruction generating unit is configured to: in a case where the management and control intention information represents a management and control intention of mounting a virtual device on the target virtual machine, select a first virtual device from a plurality of candidate virtual devices allocated to the target virtual machine; bind the first virtual device to a first backend resource; and generate the device mounting instruction carrying the management and control intention information and a first device identifier; wherein the first device identifier is identifier information of the first virtual device.

16. The apparatus of claim 15, wherein, The management and control operation instruction includes at least one of a device mounting instruction, a device unmounting instruction, a definition instruction, a startup instruction, a shutdown instruction, a destruction instruction, and a deletion instruction.

17. The apparatus of claim 15, wherein, The instruction generating unit is configured to: in a case where the first virtual device belongs to a virtual block device, bind a first network disk to the first virtual device as the first backend resource. Or, in the case that the first virtual device belongs to a virtual network device, the first network port is taken as the first backend resource and is bound with the first virtual device.

18. The apparatus of claim 15, wherein, In the case that the management and control operation indication comprises a device uninstallation indication, the indication generation unit is configured to: In the case that the management and control intention represented by the management and control intention information is to uninstall a virtual device from the target virtual machine, generate the device uninstallation indication carrying the management and control intention information and a second device identifier; wherein the second device identifier is the identifier information of a second virtual device that needs to be uninstalled from the target virtual machine.

19. The apparatus of claim 18, further comprising a first management and control unit configured to: generate, by using the computing node service, a first recycling indication for the target virtual machine; based on the first recycling indication, delete a second backend resource bound with the second virtual device to release the second virtual device; recycle the second virtual device.

20. The apparatus of claim 15, wherein, In the case that the management and control operation indication comprises a definition indication, the indication generation unit is configured to: In the case that the management and control intention represented by the management and control intention information is to define the target virtual machine, assign a plurality of candidate virtual devices to the target virtual machine; take a plurality of identifier information and configuration information of the target virtual machine as the overall description information of the target virtual machine; wherein the plurality of identifier information corresponds to the plurality of candidate virtual machines one by one; generate the definition indication carrying the management and control intention information and the overall description information.

21. The apparatus of claim 15, wherein, In the case that the management and control operation indication comprises a startup indication, the indication generation unit is configured to: In the case that the management and control intention represented by the management and control intention information is to perform a startup operation on the target virtual machine, select a third virtual device from a plurality of candidate virtual devices assigned to the target virtual machine; bind the third virtual device with a third backend resource; send a redefinition indication carrying the management and control intention information and overall description information to the virtualization management and control program; wherein the overall description information comprises a plurality of identifier information corresponding to the plurality of candidate virtual devices one by one, and configuration information of the target virtual machine; In the case that the redefinition feedback information returned by the virtualization management and control program is received, generate the startup indication carrying the management and control intention information and a third device identifier; wherein the third device identifier is the identifier information of the third virtual device.

22. The apparatus of claim 21, wherein, The indication generation unit is configured to: In the case that the third virtual device belongs to a virtual block device, take a third network disk as the third backend resource and bind it with the third virtual device; Or, in the case that the third virtual device belongs to a virtual network device, take a third network port as the third backend resource and bind it with the third virtual device.

23. The apparatus of claim 21, wherein, The indication generation unit is configured to: generate the startup indication carrying the management and control intention information, the third device identifier and smart card port range data.

24. The apparatus of claim 15, wherein, In the case that the management and control operation indication comprises at least one of a shutdown indication, a destruction indication and a deletion indication, the indication generation unit is configured to: in a case where the management operation indication comprises the shutdown indication and the management intention information represents a management intention of performing a shutdown operation on the target virtual machine, generating the shutdown indication carrying the management intention information; in a case where the management operation indication comprises the destroy indication and the management intention information represents a management intention of destroying the target virtual machine, generating the destroy indication carrying the management intention information; in a case where the management operation indication comprises the delete indication and the management intention information represents a management intention of deleting the target virtual machine, generating the delete indication carrying the management intention information.

25. The apparatus of claim 24, further comprising a second management unit configured to: generate, by using the computing node service, a second recycle indication for the target virtual machine; delete, based on the second recycle indication, a fourth backend resource bound to a fourth virtual device of the target virtual machine to release the fourth virtual device.

26. The apparatus of any one of claims 15-25, further comprising a third management unit configured to: obtain, by using a virtualization monitoring component deployed on the smart card, network disk monitoring data of the target virtual machine; send the network disk monitoring data to a cloud management server. 27.A virtual machine management apparatus, applied to a physical machine included in a virtual machine management system, the virtual machine management system further comprising a smart card, the smart card being configured to acquire a virtual machine management request, and parse the virtual machine management request by using a computing node service deployed on the smart card to obtain management intent information for a target virtual machine, and in a case where a management operation instruction of the target virtual machine comprises a device mounting instruction and the management intent represented by the management intent information is to mount a virtual device on the target virtual machine, select a first virtual device from a plurality of candidate virtual devices allocated to the target virtual machine; and bind the first virtual device with a first back-end resource. generate the device mounting indication carrying the management intention information and a first device identifier; wherein the first device identifier is identifier information of the first virtual device. The apparatus comprises: an indication receiving unit configured to receive the management operation indication; a management operation unit configured to perform a management operation on the target virtual machine based on the management operation indication.

28. The apparatus of claim 27, wherein, The management operation indication comprises at least one of a device mounting indication, a device unmounting indication, a definition indication, a startup indication, a shutdown indication, a destroy indication, and a delete indication.

29. An electronic device comprising: at least one processor; a memory communicatively connected to the at least one processor; the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-14.

30. A non-transitory computer readable storage medium having stored thereon computer instructions, wherein, The computer instructions are used to enable the computer to perform the method of any one of claims 1-14.

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

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

Images