CN113312155A - Virtual machine creation method, device, equipment, system and computer program product - Google Patents

Abstract

The embodiment of the application provides a virtual machine creating method, a virtual machine creating device, virtual machine creating equipment, a virtual machine creating system and a computer program product. The virtual machine creating method comprises the following steps: acquiring a virtual machine creation request; determining a hardware queue corresponding to the virtual machine creation request in a physical IO device; and establishing a virtual machine based on the hardware queue, and determining a virtual memory corresponding to the virtual machine in the Hypervisor. According to the technical scheme provided by the application, the virtual machines with the number at most equal to that of the hardware queues can be created based on the plurality of hardware queues in the physical IO equipment, the equipment sharing performance is good, and the deployment density is high; after the virtual machines are established, the virtual memories are configured for each virtual machine in the Hypervisor to control the access operation of the virtual machines based on the virtual memories, so that the utilization rate of IO (input/output) equipment resources of the virtual machines is improved when data exchange is carried out between the client and the virtual machines.

Description

Virtual machine creation method, device, equipment, system and computer program product

Technical Field

The present application relates to the field of data processing technologies, and in particular, to a method, an apparatus, a device, a system, and a computer program product for creating a virtual machine.

Background

With the rapid development of scientific technology, mainstream cloud computing manufacturers share one physical device for different tenants through an IO virtualization framework such as virtio/vhost in order to improve the hardware resource utilization rate of the physical IO device (such as a network card, a solid state disk, and the like), and performance loss caused by the scheme is serious, and the tenants with high performance requirements cannot be met. In order to meet the requirement of a user on high performance, the industry provides a scheme of adopting PCI device pass-through, namely, one physical device is completely exposed to one tenant for use, although the performance of the scheme is lossless, one device can only be used by one tenant, and the device slots on a physical machine are limited, so that the deployment density and the resource utilization rate are greatly reduced.

Disclosure of Invention

The embodiment of the application provides a virtual machine creation method, a virtual machine creation device, a virtual machine creation equipment, a virtual machine creation system and a computer program product, which can give consideration to both performance and deployment density, can improve the resource utilization rate of equipment and can greatly reduce the cost of cloud manufacturers besides meeting the performance requirements and the deployment density of users.

In a first aspect, an embodiment of the present application provides a virtual machine creation method, including:

acquiring a virtual machine creation request;

determining a hardware queue corresponding to the virtual machine creation request in a physical IO device;

and establishing a virtual machine based on the hardware queue, and determining a virtual memory corresponding to the virtual machine in the Hypervisor.

In a second aspect, an embodiment of the present application provides a virtual machine creating apparatus, including:

the first acquisition module is used for acquiring a virtual machine creation request;

a first determining module, configured to determine, in a physical IO device, a hardware queue corresponding to the virtual machine creation request;

and the first processing module is used for establishing a virtual machine based on the hardware queue and determining a virtual memory corresponding to the virtual machine in the Hypervisor.

In a third aspect, an embodiment of the present application provides an electronic device, including: a memory, a processor; wherein the memory is configured to store one or more computer instructions, and wherein the one or more computer instructions, when executed by the processor, implement the virtual machine creation method of the first aspect.

In a fourth aspect, an embodiment of the present invention provides a computer storage medium for storing a computer program, where the computer program is used to enable a computer to implement the virtual machine creation method shown in the first aspect when executed.

In a fifth aspect, an embodiment of the present invention provides a computer program product, including: a computer-readable storage medium storing computer instructions which, when executed by one or more processors, cause the one or more processors to perform the steps in the virtual machine creation method described above in the first aspect.

In a sixth aspect, an embodiment of the present invention provides a virtual machine creation system, including:

the client is used for generating a virtual machine creating request and sending the virtual machine creating request to the virtual machine creating equipment;

the virtual machine creating equipment is in communication connection with the client and is used for acquiring a virtual machine creating request; determining a hardware queue corresponding to the virtual machine creation request in a physical IO device; and establishing a virtual machine based on the hardware queue, and determining a virtual memory corresponding to the virtual machine in the Hypervisor.

According to the technical scheme provided by the embodiment of the application, the virtual machine creation request is obtained, the hardware queue corresponding to the virtual machine creation request is determined in the physical IO equipment, and the virtual machine is established based on the hardware queue, so that the virtual machine is effectively established based on the hardware queue included in the physical IO equipment; in addition, after the virtual machines are established, a virtual memory is configured for each virtual machine in the Hypervisor, and then the access operation of the virtual machines can be controlled based on the virtual memories, so that the physical IO performance of the virtual machines can be improved when the client and the virtual machines exchange data; in addition, the technical method is realized through software, and the existing hardware queue does not need to be replaced or redesigned, so that the design cost of a cloud manufacturer is reduced, and the practicability of the virtual machine creating method is further improved.

Drawings

In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings needed to be used in the description of the embodiments or the prior art will be briefly described below, and it is obvious that the drawings in the following description are some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative efforts.

FIG. 1 is a first diagram of an architecture of a system for sharing hardware resources provided in the related art;

FIG. 2 is a second diagram of an architecture of a hardware resource sharing system provided in the related art;

FIG. 3 is a block diagram of a hardware resource sharing system provided in the related art;

fig. 4 is an architecture diagram of a system for sharing hardware resources according to an embodiment of the present application;

fig. 5 is a schematic flowchart of a virtual machine creation method according to an embodiment of the present application;

fig. 6 is a schematic flowchart of determining, in a physical IO device, a hardware queue that satisfies the number of the hardware queues based on the virtual machine creation request according to the embodiment of the present application;

fig. 7 is a schematic flowchart of a process of acquiring all hardware queues included in the physical IO device based on the virtual machine creation request according to the embodiment of the present application;

fig. 8 is a schematic flowchart of another virtual machine creation method according to an embodiment of the present application;

fig. 9 is a schematic flowchart of another virtual machine creation method according to an embodiment of the present application;

fig. 10 is a schematic flowchart of a virtual machine creation method according to an embodiment of the present application;

fig. 11 is a schematic flowchart of another virtual machine creation method according to an embodiment of the present application;

fig. 12 is a schematic structural diagram of a virtual machine creation apparatus according to an embodiment of the present application;

fig. 13 is a schematic structural diagram of an electronic device corresponding to the virtual machine creation apparatus shown in fig. 12.

Detailed Description

In order to make the objects, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are some embodiments of the present application, but not all embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.

The terminology used in the embodiments of the present application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. As used in the examples of this application and the appended claims, the singular forms "a", "an", and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise, and "a" and "an" typically include at least two, but do not exclude the presence of at least one.

It should be understood that the term "and/or" as used herein is merely one type of association that describes an associated object, meaning that three relationships may exist, e.g., a and/or B may mean: a exists alone, A and B exist simultaneously, and B exists alone. In addition, the character "/" herein generally indicates that the former and latter related objects are in an "or" relationship.

The words "if", as used herein, may be interpreted as "at … …" or "at … …" or "in response to a determination" or "in response to a detection", depending on the context. Similarly, the phrases "if determined" or "if detected (a stated condition or event)" may be interpreted as "when determined" or "in response to a determination" or "when detected (a stated condition or event)" or "in response to a detection (a stated condition or event)", depending on the context.

It is also noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a good or system that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such good or system. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a commodity or system that includes the element.

In addition, the sequence of steps in each method embodiment described below is only an example and is not strictly limited.

Definition of terms:

hypervisor: a middle layer of software running between a physical server and a virtual machine operating system provides virtualization of the underlying physical machine, allowing multiple virtual machine operating systems and applications to share a set of underlying physical hardware. For Linux, since a kernel module KVM implements a virtualization function, a Linux system itself is Hypervisor.

Input/output device (IO device): the data transmission with the computer is commonly performed by network card equipment, hard disk equipment and the like.

A multi-queue device: the hardware realizes a plurality of devices for transmitting data and command queues, and is used for improving the throughput performance of the devices, and common multi-queue devices comprise network cards, solid state disks, accelerators and the like.

virtio: an I/O para-virtualization solution is a set of programs for virtualization of general I/O devices, and is an abstraction of a group of general I/O devices in a para-virtualization Hypervisor.

And v host: a high-performance virtio back-end implementation scheme is provided, generally, a virtio back-end driver is implemented in qemu of a user space, and vhost is implemented in a host kernel, so that unnecessary context switching and data copying can be reduced.

PCI equipment direct connection: a technique for allowing a virtual machine to exclusively use a physical PCI device allows the virtual machine to directly access the physical PCI device for data exchange to provide performance comparable to that of the physical machine.

SRIOV: single Root I/O Virtualization, a hardware-based Virtualization solution, can improve performance and scalability. A PCIe device with SRIOV enabled and appropriate hardware and OS support may appear as multiple separate physical devices, each of which may be used exclusively by a different virtual machine in a manner that is pass-through to a PCI device.

And (3) thermal migration: the virtual machine saving/restoring method is to save the running state of the whole virtual machine completely and restore the running state of the whole virtual machine to the original hardware platform or even different hardware platforms quickly. After recovery, the virtual machine is still running smoothly and the user does not perceive any differences.

IOMMU: an Input/Output Memory Management Unit, a physical Memory Management hardware, is used to connect an I/O bus with DMA capability and a main Memory. Conventional memory management units translate virtual addresses accessed by the CPU into actual physical addresses. The IOMMU translates virtual addresses accessed by devices (devices) into physical addresses.

GPA: guest Physical Address, virtual machine Physical Address.

IOVA: IO Virtual Address, the Virtual Address used by the IOMMU page tables.

In order to facilitate those skilled in the art to understand the technical solutions provided in the embodiments of the present application, the following description is provided for the related technologies:

the IO device resource is one of core components of the cloud computing platform, and in order to meet access requirements of different users on the IO device resource, a cloud computing manufacturer needs to solve the following problems:

(1) the problem of device sharing. On one hand, because of the limitation of the number of hardware slots, the IO device resources that can be borne on one physical machine are limited, and the number of virtual machines running on one physical machine is much higher than the actual number of physical IO devices. In order to meet the requirements of multiple virtual machines or multiple tenants on IO device resources, the cloud computing platform must implement device sharing, so that a single physical device resource can be shared and used by multiple virtual machines or multiple tenants, and each user can use the device. On the other hand, in order to improve the utilization rate of the IO device resources, the cloud computing platform also needs to implement sharing of the device resources, so that the IO device has a more effective utilization rate.

(2) Performance issues. For some IO device resources, such as network cards and hard disks, users generally need higher performance. For this reason, the cloud computing platform needs to provide high-performance IO device resources for users. Currently, the mainstream scheme used by cloud computing manufacturers cannot meet the requirements of device sharing capability and performance. In the schemes, good equipment sharing capability is provided, but the performance is relatively poor, and the requirement of a user on high-performance IO cannot be met; or high-performance IO device resources are provided, but the device sharing capability is poor, and the requirements of deployment density and resource utilization rate cannot be met. On the other hand, for the technology that the hardware solution such as SRIOV can solve the above problems, the cost is too high for cloud computing manufacturers due to the long period of design and development, the inflexible operation and maintenance, the higher cost of hardware update, and the like.

Currently, in order to improve the hardware resource utilization rate of physical IO devices (such as a network card and a solid state disk), mainstream cloud computing manufacturers share one physical device for different tenants through an IO virtualization framework such as virtio/vhost. The virtio is a widely used I/O semi-virtualization solution, is a set of framework for virtualization of general I/O equipment, and can improve the IO performance of a client and provide uniform IO interfaces for different platforms. Specifically, referring to fig. 1, a hardware resource sharing system is provided, where the hardware resource sharing system includes clients (client 1,client 2, etc.), physical hardware (such as a network card, a solid state disk, etc.), and a Hypervisor running on the physical hardware, where the clients are in communication connection with the physical hardware through the Hypervisor, a virtio front-end driver is configured in the clients, a virtio back-end driver is configured in the Hypervisor, the virtio back-end driver is a driver running on the Hypervisor and used for driving a physical device, and the virtio front-end driver is a driver running on the clients and used for driving the virtio back-end driver.

On a data path, when a virtual machine is started, a virtio back-end driver creates a section of ring memory buffer area in a memory sharing mode, and the ring memory buffer area is used for realizing data exchange between the virtual machine and a host (comprising physical hardware and Hypervisor running on the physical hardware), so that frequent switching between the virtual machine and the Hypervisor is avoided. IO requests (read-write requests, creation requests, deletion requests and the like) sent by physical hardware in the virtual machine can reach a virtio backend driver for processing (simple processing operations such as encapsulation processing, decapsulation processing and data verification of a data format) first, and then the virtio backend driver forwards the IO requests to the physical hardware for corresponding processing operations. Otherwise, the data on the physical hardware reaches the virtio back-end driver for processing, and then the virtio back-end driver forwards the received data to the virtual machine. On the control path, the virtio implementation mode abandons the traditional interrupt mechanism and adopts an event or callback mechanism to realize the communication between the equipment and the client, thereby reducing the context switching.

The method includes that a vhost is a high-performance virtio back-end driver implementation scheme, generally, the virtio back-end driver is implemented in a user space, and in order to further improve the IO performance, the vhost implements the virtio back-end driver in a host kernel, so that unnecessary context switching and data copying can be reduced.

The advantages of the above implementation are: because virtio/vhost is a set of general IO virtualization framework, IO equipment is simulated for a virtual machine through virtio back-end driving, and thus, the virtual machine natively supports physical equipment sharing. However, the above implementation also has the following drawbacks: although the IO performance is optimized, data transfer needs to be performed through the virtio framework when data exchange is performed between the virtual machine and the physical hardware, so that the performance of virtio/vhost has a larger gap compared with the performance of the physical IO device, the performance loss is serious, and tenants with higher performance requirements cannot be met.

In order to meet the requirement of a user on high performance, the mainstream scheme in the industry is to adopt a PCI device pass-through implementation mode, where the implementation mode refers to that a physical device is completely exposed to a virtual machine for use, the virtual machine can directly access to a physical device resource, and there is no difference from using the physical device on the physical machine. As shown in fig. 2, a sharing system of hardware resources is provided, the sharing system including a plurality of clients (client 1,client 2, etc.), a plurality of physical devices (physical device 1,physical device 2, etc.), and hypervisors running on the plurality of physical devices, wherein a device driver is configured in the client, and the device driver is a driver running on the client for driving the physical devices.

The advantages of the above implementation are: the PCI equipment direct connection implementation mode provides the IO performance equivalent to that of a physical machine, and performance loss is avoided. However, the above implementation also has the following drawbacks: PCI device cut-through requires a virtual machine to monopolize a physical device, meaning that the monopolized device cannot be shared by other virtual machines. Because the PCI slots of the physical machine are limited, the deployment density of the virtual machines with direct communication of the PCI equipment on one physical machine is very low, and the deployment density and the resource utilization rate are greatly reduced. In addition, the high-level characteristics of hot migration and the like are difficult to realize by PCI device direct connection, and challenges are brought to operation, maintenance and scheduling of cloud manufacturers.

With the development of hardware technology, a hardware virtualization scheme SRIOV is proposed in the industry, that is, a physical device is virtualized into a plurality of sub-physical devices on a hardware level. Specifically, SRIOV is a hardware standard, which is a hardware-based IO device virtualization solution that can improve the performance and scalability of IO devices. The standard allows efficient sharing of the same physical PCI device between virtual machines, while achieving I/O performance comparable to physical hardware performance, since the scheme is implemented in hardware. As shown in fig. 3, a hardware resource sharing system is provided, where the hardware resource sharing system includes a plurality of clients (client 1,client 2, etc.), a Physical PCI device, and a Hypervisor running on the plurality of Physical PCI devices, where a Physical Function (PF) and a Virtual Function (VF) are configured in the Physical PCI device, and a Physical Function Driver (PF Driver) is configured in the Hypervisor. Specifically, the method comprises the following steps:

the PF is a hardware module as defined in the SRIOV specification that contains complete PCIe functionality (which is a high-speed serial computer expansion bus standard) for implementation of SR-IOV configuration and management. The PF can be discovered, managed and configured like a normal physical PCI device.

A VF is a device or instance virtualized by a SRIOV enabled physical device and is presented as a stand-alone PCI device, where each VF has its own unique PCI configuration region and may share the same physical resource with other VFs.

The physical function driver is used to provide an interface for a user to configure and manage the PF of a physical device, through which hardware registers of the PF may be accessed for creating, deleting VF, etc. operations. Each SRIOV-enabled physical device may have a physical function PF, and theoretically, each PF may configure up to 64,000 virtual functions VF associated with it, and in particular, a PF may create a VF via a register.

As can be seen by the architecture diagram provided in FIG. 3, after SRIOV is enabled, each created VF on the physical device may interact with the virtual machine and vice versa. Thus, passing the VF through PCI pass-through to the virtual machine uses a layer of virtualization (Hypervisor) that can skip the middle to achieve performance that is nearly a pure physical environment. Although each VF can only be monopolized by one virtual machine, a physical device with SRIOV functionality has very good device sharing capabilities because one physical device can create many VFs.

The advantages of the above implementation are: the physical IO device with SRIOV capability has performance similar to a pure physical environment and has good device sharing capability. However, the above implementation also has the following drawbacks: physical IO equipment needs to be realized again according to SRIOV standard, and the hardware design and manufacturing period is long; cloud manufacturers need to replace old equipment of the stock of the old equipment with new equipment with SRIOV capability, and the old equipment cannot be utilized; SRIOV equipment is costly and it is difficult for equipment with SRIOV capabilities to implement advanced features such as thermomigration.

In order to solve the foregoing technical problem, this embodiment provides a hardware sharing scheme that considers both performance and deployment density, where the sharing scheme is implemented in a software manner, and specifically, an execution main body of the hardware sharing scheme may be a Hypervisor-based virtual machine creation system capable of implementing a virtual machine creation operation, and the virtual machine creation system may include a virtual machine creation device and a client communicatively connected to the virtual machine creation device, where, as shown in fig. 4, the virtual machine creation device may be borne on a physical IO device (such as a network card, a solid state disk, and the like), a Hypervisor runs in the physical IO device, and a physical device driver (a Hypervisor-based virtual machine creation device) is configured on the Hypervisor. Specifically, for a physical IO device, a default number of hardware queues may be configured in the physical IO device, and the hardware queues correspond to a memory cache region for storing a plurality of IO requests, so as to implement corresponding data processing operations. The number of the hardware queues may be determined based on a hardware manufacturer and a hardware driver, and generally, the hardware manufacturer provides a maximum value allowed by the hardware queues, and the specific number of the hardware queues may be determined by the number of the processors CPU in the physical device and the hardware device driver. In some examples, the default number may be 0.

In addition, in order to implement that the Hypervisor is configured with the physical device driver, hardware device information (design specification, device kernel, and the like) and Hypervisor-related information (operation specification, system kernel, and the like) may be acquired, and then the physical device driver is configured on the Hypervisor based on the hardware device information and the Hypervisor-related information, the physical device driver is configured to detect and load a hardware queue included in the physical device, and simultaneously, an interface for configuring and maintaining a virtual device (maintaining an operation state of the virtual device) may be provided to a user, and the user may create and delete the virtual device composed of the hardware queue based on the physical device through the interface.

The following describes specific functions and implementation processes of the physical device driver:

(1) detection, configuration and management of physical devices.

Specifically, when loading the physical device driver, the physical device driver can detect and identify the physical device and the hardware queue located in the physical device, perform necessary initialization operation on the physical device, and record the hardware queue identifier and the number of the hardware queues of the physical device, where the recorded hardware queue identifier and the number of the hardware queues may be stored in a register in the physical device.

(2) Configuration and management of virtual machines.

The physical device driver provides an interface for creating and deleting the virtual machine for a user, and particularly, the user can perform configuration and management operation of the virtual machine through the interface. For example: when a virtual machine needs to be established, a user can specify a hardware queue with the specified number of queues included in the virtual machine through the interface, after the creation interface of the virtual machine is called, the physical device driver allocates the hardware queues with the specified number from the remaining available physical queues of the physical device, and creates a virtual machine based on the allocated hardware queues, wherein at this time, the number of the hardware queues included in the virtual machine is the same as the number of the queues specified by the user. After the virtual machines are established, the physical device driver may simulate a register configuration space (i.e., virtual memory) for each virtual machine in the Hypervisor, and the register configuration space is used for control management of the virtual machines.

In some examples, after the user specifies a name of the virtual device to be deleted and calls a deletion interface of the virtual device, the physical device driver will recycle the physical device queue resource corresponding to the virtual device for subsequent use.

In addition, in order to implement virtual devices configured with consistent interfaces for different vendors and shield hardware differences, the register configuration space of the virtual machine may be designed according to a uniform interface, such as: a virtio standard compatible interface or other standard interface. At this time, the virtual machine corresponds to a virtual register in the Hypervisor and a hardware register which is located in the physical device and is related to a virtual machine hardware queue, the hardware register and the virtual register are in one-to-one correspondence, and when an access request to the virtual machine is related to the virtual machine, the virtual machine can be directly configured into the virtual machine register; if the access request to the virtual machine is related to the hardware queue, the access request can be directly configured into the hardware register, so that the utilization rate of the IO resource of the equipment is improved.

It should be noted that, when implementing the above technical solution, a problem of sharing the same page table entry of the physical IOMMU by multiple tenants may occur, for example, under the x86 platform, one physical PCI device corresponds to one physical IOMMU page table entry, and under the virtual machine scenario, the virtual machine physical address GPA of the virtual machine is equal to the virtual address IOVA used by the IOMMU page table. For example, virtual machine A's GPA range is 0x0000-0xffff, which corresponds to the IOVA in the IOMMU page tables also being 0x0000-0 xffff. Since one physical PCI device is actually shared by a plurality of users in this embodiment, the virtual device used by each user is actually mapped to the same physical device. Since the GPA addresses of the virtual machines used by different tenants may be the same, conflicts arise when configuring the IOMMU page tables. For example, the GPA range 0x0000-0xffff of tenant a and the GPA range 0x0000-0xffff of tenant B may conflict under the same IOMMU page table entry, and both tenant a and tenant B write GPA 0x1000 of each in the virtual machine into the physical queue, so there must be a problem that address 0x1000(GPA) of tenant a performing direct memory access dma operation is the address of tenant a, and since tenant B fills the mapping relationship of GPA- > HPA into the same IOMMU page table entry, tenant a may actually access the memory corresponding to tenant B.

In order to solve the problem of sharing the same page table entry of the physical IOMMU by multiple tenants, the solution provided in this embodiment is to perform the same GPA address allocation operation on all virtual machines on the same physical device, so that each virtual machine has a different GPA address range, and it is ensured that the GPA address ranges corresponding to any two virtual machines are not overlapped.

Further, for a client communicatively connected to a physical device, the client may be any computing device with some data transfer capabilities, and further, the basic structure of the client may include: at least one processor. The number of processors depends on the configuration and type of client. The client may also include a Memory, which may be volatile, such as RAM, or non-volatile, such as Read-Only Memory (ROM), flash Memory, etc., or may include both types. The memory typically stores an Operating System (OS), one or more application programs, and may also store program data and the like. In addition to the processing unit and the memory, the client includes some basic configurations, such as a network card chip, an IO bus, a display component, and some peripheral devices. Alternatively, some peripheral devices may include, for example, a keyboard, a mouse, a stylus, a printer, and the like. Other peripheral devices are well known in the art and will not be described in detail herein. Alternatively, the client may be a pc (personal computer) terminal, a handheld terminal (e.g., a smart phone, a tablet computer), or the like.

In the present embodiment described above, the client may make a network connection with the virtual machine creation device, and the network connection may be a wireless or wired network connection. If the client and the virtual machine creation device are in communication connection, the network format of the mobile network may be any one of 2G (gsm), 2.5G (gprs), 3G (WCDMA, TD-SCDMA, CDMA2000, UTMS), 4G (LTE), 4G + (LTE +), WiMax, 5G, and the like.

In this embodiment, the virtual machine creation device and the client in the virtual machine creation system may be respectively configured to perform the following steps:

the client may generate the virtual machine creation request, and in particular, the embodiment does not limit a specific implementation manner of the client generating or acquiring the virtual machine creation request, for example: the client is provided with an interactive interface, the execution operation input by a user is obtained through the interactive interface, and the virtual machine creation request is obtained through the execution operation; or, a specific interface may be set on the client, and the virtual machine creation request may be acquired through the specific interface, so that the client may stably acquire the virtual machine creation request. In addition, a device driver for realizing the virtual machine creation operation is configured on the client, and after the virtual machine creation request is acquired, the virtual machine creation request can be uploaded to the virtual machine creation device through the device driver, so that the virtual machine creation device can perform the corresponding virtual machine creation operation based on the virtual machine creation request.

The virtual machine creating device is used for receiving a virtual machine creating request uploaded by a client, and then determining a hardware queue corresponding to the virtual machine creating request in the physical device based on the virtual machine creating request, wherein it can be understood that different virtual machine creating requests can correspond to different numbers of hardware queues; after determining the hardware queue corresponding to the virtual machine creation request, the virtual machine may be created based on the hardware queue, where one or more hardware queues are included in the created virtual machine. In addition, in order to improve the utilization rate of hardware resources, after the virtual machine is established, the virtual memory corresponding to the virtual machine can be determined in the Hypervisor, and then the access operation of the virtual machine is conveniently controlled based on the virtual memory.

According to the technical scheme provided by the embodiment, as a large number of hardware queues can be included in the physical IO device, when the virtual machine is constructed based on the hardware queues, one hardware queue or a plurality of hardware queues can be packaged into one virtual machine for a user to use, so that the virtual machine with the number at most equal to that of the hardware queues can be created based on the plurality of hardware queues in the physical IO device, the device sharing performance is good, and the deployment density is high; in addition, after the virtual machines are established, a virtual memory is configured for each virtual machine in the Hypervisor, then the access operation of the virtual machines can be controlled based on the virtual memories, and specifically, when a client exchanges data with the virtual machines, the client can directly access the registers of the hardware queues without transfer operation, so that the improvement of the physical IO performance of the virtual machines is facilitated; in addition, the technical scheme is realized through software, and the existing hardware queue does not need to be replaced or redesigned, so that the design cost of a cloud manufacturer is reduced; meanwhile, the technical scheme can package physical equipment of different hardware manufacturers into virtual equipment with the same interface, shields physical hardware difference, effectively realizes standardized equipment control interface, and further improves the application range and the flexible use degree of the technical scheme.

The following describes a virtual machine creation method, device, and apparatus provided in various embodiments of the present application in detail through an exemplary application scenario.

Fig. 5 is a schematic flowchart of a virtual machine creation method according to an embodiment of the present application; referring to fig. 5, the present embodiment provides a virtual machine creating method, and an execution subject of the method may be a virtual machine creating apparatus, and it is understood that the virtual machine creating apparatus may be implemented as software, or a combination of software and hardware. Specifically, the virtual machine creating apparatus may be implemented as a physical device driver, and when the virtual machine creating apparatus executes the method, the method may include:

step S501: and acquiring a virtual machine creation request.

Step S502: in a physical IO device, a hardware queue corresponding to a virtual machine creation request is determined.

Step S503: and establishing a virtual machine based on the hardware queue, and determining a virtual memory corresponding to the virtual machine in the Hypervisor.

The above steps are explained in detail below:

step S501: and acquiring a virtual machine creation request.

When there is a virtual machine creation requirement, the virtual machine creation apparatus may acquire a virtual machine creation request, where the virtual machine creation request may be automatically generated by the virtual machine creation apparatus, or may also be sent to the virtual machine creation apparatus by another device (for example, a client), as long as the virtual machine creation apparatus can stably acquire the virtual machine creation request.

In addition, for the virtual machine creation request, one virtual machine creation request may be used to create one or more virtual machines, and the number of virtual machine creation requests acquired by the virtual machine creation apparatus may be one or more, and when the number of virtual machine creation requests is multiple, different virtual machine creation requests may come from the same or different requesting terminals/requesting users.

Of course, the specific obtaining manner of the virtual machine creation request is not limited to the implementation manner described above, and those skilled in the art may also use other manners to obtain the virtual machine creation request, as long as the accurate reliability of obtaining the virtual machine creation request can be ensured, which is not described herein again.

Step S502: in a physical IO device, a hardware queue corresponding to a virtual machine creation request is determined.

For the physical IO devices, each physical IO device may be configured with a default number of hardware queues, where the number of the hardware queues is related to a driver of the physical IO device, a CPU attribute, and a hardware vendor, and in some examples, the number of the hardware queues configured in the physical IO device is 0. After the virtual machine creation request is acquired, in order to enable the virtual machine creation operation, a hardware queue corresponding to the virtual machine creation request may be determined in the physical IO device.

In some instances, in the physical IO device, determining the hardware queue corresponding to the virtual machine creation request may include: acquiring the number of hardware queues included in a virtual machine creation request and used for limiting the number of the hardware queues included in the virtual machine; determining, in the physical IO device, a hardware queue satisfying the number of hardware queues based on the virtual machine creation request.

Specifically, in order to accurately implement the virtual machine creation operation, the virtual machine creation request may include a request for limiting the number of hardware queues included in the virtual machine, for example: when the user wants to createvirtual machine 1 andvirtual machine 2, the generated virtual machine creation request for creatingvirtual machine 1 andvirtual machine 2 may include a request for defining the number of hardware queues included in the virtual machine, for example: the number of hardware queues included in thevirtual machine 1 is 3, and the number of hardware queues included in thevirtual machine 2 is 5.

After the virtual machine creation request is obtained, the virtual machine creation request may be analyzed to obtain a number of hardware queues included in the virtual machine creation request for limiting the number of hardware queues included in the virtual machine. After the number of hardware queues and the virtual machine creation request are acquired, a hardware queue satisfying the number of hardware queues may be determined in the physical IO device based on the virtual machine creation request. Specifically, determining, in the physical IO device, a hardware queue satisfying the number of hardware queues based on the virtual machine creation request may include: and acquiring a default hardware queue included in the physical IO device, and when the number of the default hardware queue is greater than or equal to the number of the hardware queues corresponding to the virtual machine creation request, directly determining the hardware queue corresponding to the virtual machine creation request in the default hardware queue. When the number of the default hardware queues is smaller than the number of the hardware queues corresponding to the virtual machine creation request, the default hardware queues included in the physical IO device may be cleared, and a hardware queue corresponding to the virtual machine creation request is established in the physical IO device based on the virtual machine creation request, so as to determine the hardware queue corresponding to the virtual machine creation request in the physical IO device.

In further examples, determining, in the physical IO device, a hardware queue that satisfies the number of hardware queues based on the virtual machine creation request may include: the method comprises the steps of obtaining a default hardware queue included in the physical IO device, and when the number of the default hardware queue is 0, directly establishing a hardware queue meeting the number of the hardware queue in the physical IO device based on the virtual machine creation request, so that the accuracy and reliability of determining the hardware queue corresponding to the virtual machine creation request are effectively realized.

Of course, a person skilled in the art may also implement other ways to determine the hardware queue corresponding to the virtual machine creation request in the physical IO device, as long as the accuracy and reliability of determining the hardware queue corresponding to the virtual machine creation request can be ensured, which is not described herein again.

Step S503: and establishing a virtual machine based on the hardware queue, and determining a virtual memory corresponding to the virtual machine in the Hypervisor.

After determining the hardware queue corresponding to the virtual machine creation request, the virtual machine may be established based on the hardware queue, thereby effectively enabling establishment of the virtual machine based on the hardware queue included in the physical IO device. After the virtual machine is created, the virtual memory corresponding to the virtual machine may be determined in the Hypervisor based on the established virtual machine, and specifically, determining the virtual memory corresponding to the virtual machine in the Hypervisor may include: the method includes the steps of generating a memory generation request corresponding to a virtual machine, sending the memory generation request to a system where the Hypervisor is located, after the system where the Hypervisor is located obtains the memory generation request, applying for and determining a virtual memory corresponding to the virtual machine in the Hypervisor based on the memory generation request, and after determining the virtual memory corresponding to the virtual machine in the Hypervisor, controlling access operation of the virtual machine based on the virtual memory.

In the virtual machine creation method provided by this embodiment, a virtual machine creation request is obtained, then a hardware queue corresponding to the virtual machine creation request is determined in a physical IO device, and a virtual machine is created based on the hardware queue, so that virtual machine creation based on the hardware queue included in the physical IO device is effectively achieved; in addition, after the virtual machines are established, a virtual memory is configured for each virtual machine in the Hypervisor, and then the access operation of the virtual machines can be controlled based on the virtual memories, so that the physical IO performance of the virtual machines can be improved when the client and the virtual machines exchange data; in addition, the technical method is realized through software, and the existing hardware queue does not need to be replaced or redesigned, so that the design cost of a cloud manufacturer is reduced, and the practicability of the virtual machine creating method is further improved.

Fig. 6 is a schematic flowchart of determining, in a physical IO device, a hardware queue that satisfies a number of the hardware queues based on a virtual machine creation request according to an embodiment of the present application; referring to fig. 6, this embodiment provides an implementation manner for determining a hardware queue meeting the number of hardware queues in a physical IO device, and specifically, determining a hardware queue meeting the number of hardware queues in a physical IO device based on a virtual machine creation request in this embodiment may include:

step S601: based on the virtual machine creation request, an allowable available hardware queue included by the physical IO device at the current time is determined.

After the virtual machine creation request is obtained, the virtual machine creation request may be analyzed to determine an allowable available hardware queue included by the physical IO device at the current time, specifically, determining, based on the virtual machine creation request, the allowable available hardware queue included by the physical IO device at the current time may include: acquiring all hardware queues included in the physical IO equipment based on the virtual machine creation request; determining respective corresponding calling states of all hardware queues at the current moment; and determining the hardware queue in the non-calling state in all the hardware queues as an available hardware queue.

After the virtual machine creation request is obtained, scanning operation can be performed on the physical IO device to obtain all hardware queues included in the physical IO device, and for the hardware queues included in the physical IO device, different hardware queues can correspond to different call states at different times; in order to be able to accurately determine the allowed available hardware queues, the respective call states of all hardware queues may be determined at the current time. For example: the hardware queue in the physical IO device may include ahardware queue 1, ahardware queue 2, a hardware queue 3, and a hardware queue 4, where a call state corresponding to thehardware queue 1 may be a non-call state, a call state corresponding to thehardware queue 2 may be a call state, a call state corresponding to the hardware queue 3 is a non-call state, and a call state corresponding to the hardware queue 4 is a call state.

After acquiring the call states corresponding to all the hardware queues, the hardware queue in the non-call state in all the hardware queues may be determined as an available hardware queue, for example: when the calling state corresponding to thehardware queue 1 can be a non-calling state, the calling state corresponding to thehardware queue 2 can be a calling state, the calling state corresponding to the hardware queue 3 is a non-calling state, and the calling state corresponding to the hardware queue 4 is a calling state, thehardware queue 1 and the hardware queue 3 can be determined as an allowable available hardware queue, so that the accurate reliability of determining the allowable available hardware queue is effectively realized.

Step S602: among the allowed available hardware queues, a hardware queue satisfying the number of hardware queues is determined.

After the allowed available hardware queues are obtained, the hardware queues meeting the number of hardware queues can be determined in the allowed available hardware queues. In some examples, among the allowed available hardware queues, determining a hardware queue that satisfies the number of hardware queues may include: acquiring the number of available queues allowing available hardware queues; when the number of the available queues is larger than or equal to the number of the hardware queues, allowing the hardware queues meeting the number of the hardware queues to be determined in the available hardware queues; and when the number of the available queues is less than the number of the hardware queues, prohibiting the hardware queues meeting the number of the hardware queues from being determined in the allowed available hardware queues, and generating prompt information for identifying the virtual machine creation failure.

Specifically, after the allowable available hardware queues are acquired, the number of available queues of the allowable available hardware queues can be statistically acquired, then the number of available queues is analyzed and compared with the number of hardware queues, and when the number of available queues is greater than or equal to the number of hardware queues, it is indicated that the number of allowable available hardware queues at the time is sufficient, so that the hardware queues meeting the number of hardware queues are allowed to be determined in the allowable available hardware queues. When the number of the available queues is smaller than the number of the hardware queues, the number of the allowed available hardware queues at the moment is relatively small, and the hardware queues with the number of the hardware queues cannot be directly determined, so that the hardware queues meeting the number of the hardware queues are forbidden to be determined in the allowed available hardware queues, and prompt information for identifying the virtual machine creation failure can be generated, so that the hardware queues meeting the number of the hardware queues can be accurately and stably determined in the allowed available hardware queues.

In the embodiment, the virtual machine creation request is used for determining the allowable available hardware queues included by the physical IO devices at the current moment, and then the hardware queues meeting the number of the hardware queues are determined in the allowable available hardware queues, so that the accuracy and reliability of determining the hardware queues are effectively ensured, the hardware queues can meet the number of the hardware queues corresponding to the virtual machine creation request, and the stability and reliability of virtual machine creation are ensured; and when the hardware queues meeting the number of the hardware queues cannot be determined normally, normal virtual machine creation operation cannot be performed, and at this time, the user can quickly and directly acquire the state of virtual machine creation failure through the prompt information, so that the user can maintain or adjust the virtual machine creation device in time.

Fig. 7 is a schematic flowchart of a process of acquiring all hardware queues included in a physical IO device based on a virtual machine creation request according to an embodiment of the present application; referring to fig. 7, in a process of determining a hardware queue satisfying the number of hardware queues in a physical IO device, this embodiment provides an implementation manner of obtaining all hardware queues included in the physical IO device, and specifically, obtaining all hardware queues included in the physical IO device based on a virtual machine creation request in this embodiment may include:

step S701: in the Hypervisor, a physical device driver for performing a scan operation on a hardware queue in a physical IO device is established.

In order to implement the virtual machine creation operation, after the virtual machine creation request is obtained, a physical device driver for performing a scanning operation on a hardware queue in a physical IO device may be established in the Hypervisor, and in some examples, the establishing of the physical device driver for performing a scanning operation on the hardware queue in the physical IO device in the Hypervisor may include: acquiring equipment information of physical IO equipment and system information of Hypervisor; in the Hypervisor, a physical device driver is constructed based on the device information of the physical IO device and the system information of the Hypervisor, and the physical device driver is used for scanning and loading a hardware queue in the physical IO device.

Specifically, in order to establish a physical device driver for performing a scanning operation on a hardware queue in a physical IO device in the Hypervisor, device information of the physical IO device and system information of the Hypervisor may be first obtained, where the device information may be stored in a preset area in the physical IO device, and the device information may be obtained by accessing the preset area in the physical IO device; similarly, the system information may be stored in a preset area in the Hypervisor, and the system information may be obtained by accessing the preset area in the Hypervisor.

After the device information and the system information are acquired, a physical device driver may be constructed based on the device information of the physical IO device and the system information of the Hypervisor, the physical device driver is used to scan and load a hardware queue in the physical IO device, and the physical device driver may also provide an interface for performing configuration and maintenance operations on the virtual machine. For the interface provided by the physical device driver, in order to avoid the differentiation of hardware devices, a unified interface design standard may be adopted to configure the interface, for example: a virtio standard compatible interface or other standard interfaces, etc., so that physical devices of different hardware vendors can all be packaged into virtual devices with the same interface.

Step S702: and performing queue scanning operation on the physical IO device by using the physical device driver and the virtual machine creation request to obtain all hardware queues included in the physical IO device, and recording hardware queue identifications and hardware queue numbers corresponding to all the hardware queues respectively.

After the physical device driver is established, the physical device driver and the virtual machine creation request can be used for performing queue scanning operation on the physical IO device, so that all hardware queues included in the physical IO device can be obtained, and the hardware queue identifications and the hardware queue numbers corresponding to all the obtained hardware queues can be stored in a pre-configured register, so that all the hardware queues included in the physical IO device can be effectively recorded and stored.

In this embodiment, a physical device driver for performing a scanning operation on a hardware queue in a physical IO device is established in the Hypervisor, and a queue scanning operation is performed on the physical IO device by using the physical device driver and a virtual machine creation request, so as to obtain all hardware queues included in the physical IO device, and record hardware queue identifiers and hardware queue numbers corresponding to all the hardware queues, thereby effectively achieving stable reliability of obtaining all the hardware queues included in the physical IO device, and further improving quality and efficiency of the creation operation on the virtual machine.

In some application scenarios, in the process of data communication of the physical IO device, a user may perform an update operation on a physical device driver corresponding to the physical IO device based on design requirements and usage requirements, and at this time, all hardware queues included in the physical IO device may also perform the update operation along with the update of the physical device driver. In order to update all hardware queues included in the physical IO device, after recording the hardware queue identifiers and the number of the hardware queues corresponding to all the hardware queues, the method in this embodiment may further include: and when a drive update request of the physical device drive is acquired, clearing a hardware queue included in the physical IO device based on the drive update request.

Specifically, when a user has an update demand for a physical device driver, a driver update request may be generated and sent to the virtual machine creation device, and when the virtual machine creation device obtains the driver update request for the physical device driver, a physical queue included in the physical IO device may be cleared based on the driver update request.

For example, the physical IO device corresponds to thephysical device driver 1, the number of the hardware queues corresponding to thephysical device driver 1 is 10, and when a driver update request for updating thephysical device driver 1 to thephysical device driver 2 is obtained, the 10 hardware queues included in the physical IO device may be cleared to 0 based on the driver update request, that is, at this time, the physical IO device includes 0 hardware queues.

Further, after clearing the hardware queue included in the physical IO device based on the driver update request, the method in this embodiment may further include: acquiring a target device driver based on the driver update request; determining a target hardware queue corresponding to a target device driver; and updating the hardware queue included in the virtual machine into a target hardware queue.

After the drive update request is acquired, update operation can be performed on the drive of the physical IO device based on the drive update request; and during or after the drive update operation, analyzing the drive update request to obtain a target device drive, where the target device drive is different from the physical device drive corresponding to the physical IO device. After the target device driver is obtained, analyzing the target device driver to determine a target hardware queue corresponding to the target device driver, specifically, obtaining a mapping relationship for identifying the target device driver and the target hardware queue, and determining the target hardware queue corresponding to the target device driver based on the hardware relationship and the target device driver, it can be understood that different target device drivers may correspond to different target hardware queues; after the target hardware queue is obtained, the hardware queue included in the virtual machine can be updated to the target hardware queue, so that the drive updating and hardware queue updating operations of the physical IO device are effectively realized, and the safety and reliability of the operation of the physical IO device are further improved.

For example, the physical IO device corresponds to thephysical device driver 1, the number of the hardware queues corresponding to thephysical device driver 1 is 10, and when a driver update request for updating thephysical device driver 1 to thephysical device driver 2 is acquired, thephysical device driver 1 of the physical IO device may be updated to thephysical device driver 2 based on the driver update request. And, the 10 hardware queues included in the physical IO device may be cleared to 0 based on the drive update request, that is, at this time, the physical IO device includes 0 hardware queue, and then a target hardware queue corresponding to thephysical device drive 2 is determined, and when the target hardware queue is 5, the hardware queues in the physical IO device may be updated to 5, so that the target hardware queue included in the physical IO device corresponds to thephysical device 2, and the safety and reliability of the operation of the physical device IO device are ensured.

Fig. 8 is a schematic flowchart of another virtual machine creation method according to an embodiment of the present application; referring to fig. 8, the method in the present embodiment may further include:

step S801: in the physical IO device, determining a hardware memory corresponding to the hardware queue.

Step S802: and controlling the access operation of the virtual machine based on the virtual memory and the hardware memory.

After the virtual machine is established based on the hardware queue and the virtual memory corresponding to the virtual machine is determined in the Hypervisor, the access operation of the virtual machine may be controlled based on the virtual memory, and in order to achieve quality and efficiency of controlling the access operation of the virtual machine, the hardware memory corresponding to the hardware queue may be determined in the physical IO device, and it can be understood that one virtual machine may correspond to one hardware memory and one virtual memory. After determining the virtual memory and the hardware memory, access operations of the virtual machine may be controlled based on the virtual memory and the hardware memory. In some examples, controlling access operations of the virtual machine based on the virtual memory and the hardware memory may include: acquiring a virtual machine access request; determining the request attribute of the virtual machine access request; determining a target memory corresponding to the virtual machine access request based on the request attribute, wherein the target memory comprises any one of a virtual memory and a hardware memory; and controlling the access operation of the virtual machine based on the target memory and the virtual machine access request.

Specifically, when there is an access requirement for a virtual machine, a virtual machine access request may be obtained, where the virtual machine access request may include a data write request and a data read request; after the virtual machine access request is acquired, the virtual machine access request may be analyzed to determine a request attribute corresponding to the virtual machine access request, where the request attribute may include any one of: a request corresponding to a virtual machine, a request corresponding to a hardware queue in the virtual machine.

After the request attribute is obtained, the request attribute may be analyzed to determine a target memory corresponding to the virtual machine access request, and it is understood that different request attributes may correspond to different target memories, where the target memory includes any one of a virtual memory and a hardware memory. In some examples, determining, based on the request attributes, the target memory corresponding to the virtual machine access request may include: when the request attribute corresponds to the virtual machine, determining that a target memory corresponding to the virtual machine access request is a virtual memory; when the request attribute corresponds to a hardware queue included in the virtual machine, determining that the target memory corresponding to the virtual machine access request is a hardware memory, thereby effectively ensuring the accuracy and reliability of determining the target memory.

After the target memory is obtained, the access operation of the virtual machine can be controlled based on the target memory and the virtual machine access request, specifically, when the target memory is the virtual memory, the client can directly access the virtual memory through the Hypervisor without transfer operation; when the target memory is a hardware memory, and data exchange is performed between the client and the virtual machine, the hardware memory corresponding to the hardware queue can be directly accessed without transfer operation, so that the running performance of the physical IO device is improved, and the stability and reliability of controlling the access operation of the virtual machine are ensured.

In this embodiment, the hardware memory corresponding to the hardware queue is determined in the physical IO device, and then the access operation of the virtual machine is controlled based on the virtual memory and the hardware memory, so that the stability and reliability of controlling the access operation of the virtual machine are effectively ensured, and the performance of the physical IO device is improved.

Fig. 9 is a schematic flowchart of another virtual machine creation method according to an embodiment of the present application; on the basis of any one of the above embodiments, referring to fig. 9, the method in this embodiment may further include:

step S901: and acquiring a virtual machine deletion request.

Step S902: and determining the target identity included in the virtual machine deleting request.

Step S903: and deleting the virtual machine corresponding to the target identity identifier, and recycling the memory resource corresponding to the deleted virtual machine.

When there is a virtual machine deletion demand, the virtual machine creation apparatus may obtain a virtual machine deletion request, it is understood that the virtual machine deletion request may be sent to the virtual machine creation apparatus by another device (for example, a client), or the virtual machine deletion request may be generated by a user inputting an execution operation through the virtual machine creation apparatus, so that the virtual machine creation apparatus can stably obtain the virtual machine deletion request.

After the virtual machine deletion request is acquired, the virtual machine deletion request may be analyzed to determine a target identity included in the virtual machine deletion request. After the target identity is acquired, the virtual machine corresponding to the target identity can be deleted, so that the virtual machine can be effectively deleted, and after the virtual machine is deleted, the memory resources corresponding to the deleted virtual machine can be recovered, wherein the memory resources comprise a virtual memory and a hardware memory, and are used by other virtual machines.

For example, the created virtual machines may includevirtual machine 1,virtual machine 2, virtual machine 3, virtual machine 4, and virtual machine 5, and after the virtual machine deletion request is obtained, the virtual machine deletion request may be analyzed to determine a target identity included in the virtual machine deletion request, for example: the target identity may be the identity 3 corresponding to the virtual machine 3. When the target identity is the identity 3, the virtual machine 3 can be deleted, so that the virtual machine is effectively deleted, and then the memory resource corresponding to the deleted virtual machine 3 is recycled so as to be used by other virtual machines.

In this embodiment, by obtaining the virtual machine deletion request, determining the target identity included in the virtual machine deletion request, deleting the virtual machine corresponding to the target identity, and recovering the memory resource corresponding to the deleted virtual machine, the deletion operation of the virtual machine is effectively implemented, and the practicability of the method is further improved.

Fig. 10 is a schematic flowchart of a virtual machine creation method according to an embodiment of the present application; on the basis of any one of the above embodiments, referring to fig. 10, the method in this embodiment may further include:

step S1001: and acquiring a virtual machine configuration request.

Step S1002: the target identity included in the virtual machine configuration request is determined.

Step S1003: and carrying out configuration operation on the virtual machine corresponding to the target identity.

When there is a virtual machine configuration requirement, the virtual machine creating device may obtain a virtual machine configuration request, where the virtual machine configuration request includes: the virtual machine attribute configuration request is used for realizing configuration operation on the attributes of the virtual machine, and the virtual machine maintenance request is used for carrying out maintenance operation on the virtual machine. It is understood that the virtual machine configuration request may be sent by other devices (e.g., clients) to the virtual machine creation apparatus, so that the virtual machine creation apparatus can stably obtain the virtual machine configuration request.

After the virtual machine configuration request is obtained, the virtual machine configuration request may be analyzed to determine the target identity included in the virtual machine configuration request. After the target identity is acquired, the virtual machine corresponding to the target identity can be configured, so that the virtual machine can be effectively configured. It will be appreciated that different virtual machine configuration requests may correspond to different configuration operations.

For example, the created virtual machines may includevirtual machine 1,virtual machine 2, virtual machine 3, virtual machine 4, and virtual machine 5, and after the virtual machine configuration request is obtained, the virtual machine configuration request may be analyzed to determine a target identity included in the virtual machine configuration request, for example: the target identity may be theidentity 2 corresponding to thevirtual machine 2. When the target identity is theidentity 2, performing virtual machine configuration operation on thevirtual machine 2 corresponding to theidentity 2, and specifically, performing configuration operation on the attribute of the virtual machine; or, the maintenance operation on the running state of the virtual machine can be realized.

In this embodiment, the practicability of the method is further improved by obtaining the virtual machine configuration request, determining the target identity included in the virtual machine configuration request, and then performing configuration operation on the virtual machine corresponding to the target identity.

Fig. 11 is a schematic flowchart of another virtual machine creation method according to an embodiment of the present application; on the basis of any one of the above embodiments, referring to fig. 11, after the virtual machine is established based on the hardware queue, the method in this embodiment may further include:

step S1101: and acquiring all virtual machines included in the physical IO device.

Step S1102: and performing virtual machine physical address allocation operation on all the virtual machines to obtain virtual machine physical addresses corresponding to all the virtual machines, wherein the virtual machine physical address ranges corresponding to all the virtual machines are different, and no overlapping area exists between the virtual machine physical address ranges corresponding to any two virtual machines.

After the virtual machines are established based on the hardware queues, in order to avoid the situation that a user accesses memory spaces of other users by mistake, all the virtual machines included in the physical IO equipment can be obtained, and after all the virtual machines included in the physical IO equipment are obtained, allocation operation of virtual machine physical addresses can be carried out on all the virtual machines, so that virtual machine physical addresses corresponding to all the virtual machines can be obtained, wherein the virtual machine physical address ranges corresponding to all the virtual machines are different, and an overlapping area does not exist between the virtual machine physical address ranges corresponding to any two virtual machines, so that the problem that multiple tenants share the same page table entry of the physical IOMMU can be effectively avoided and solved, and the running stability and reliability of the virtual machines are further ensured.

Fig. 12 is a schematic structural diagram of a virtual machine creation apparatus according to an embodiment of the present application; referring to fig. 12, the present embodiment provides a virtual machine creating apparatus, where the virtual machine creating apparatus may be configured to execute the virtual machine creating method in fig. 5, and specifically, the virtual machine creating apparatus may include a first obtainingmodule 11, a first determiningmodule 12, and a first processing module 13:

a first obtainingmodule 11, configured to obtain a virtual machine creation request;

a first determiningmodule 12, configured to determine, in the physical IO device, a hardware queue corresponding to the virtual machine creation request;

thefirst processing module 13 is configured to establish a virtual machine based on the hardware queue, and determine a virtual memory corresponding to the virtual machine in the Hypervisor.

In some examples, when the first determiningmodule 12 determines, in the physical IO device, the hardware queue corresponding to the virtual machine creation request, the first determiningmodule 12 is configured to perform: acquiring the number of hardware queues included in a virtual machine creation request and used for limiting the number of the hardware queues included in the virtual machine; determining, in the physical IO device, a hardware queue satisfying the number of hardware queues based on the virtual machine creation request.

In some examples, when the first determiningmodule 12 determines, based on the virtual machine creation request, a hardware queue satisfying the number of hardware queues in the physical IO device, the first determiningmodule 12 is configured to perform: determining an allowable available hardware queue included by the physical IO device at the current moment based on the virtual machine creation request; among the allowed available hardware queues, a hardware queue satisfying the number of hardware queues is determined.

In some examples, when the first determiningmodule 12 determines, based on the virtual machine creation request, that the available hardware queue is allowed to be included by the physical IO device at the current time, the first determiningmodule 12 is configured to perform: acquiring all hardware queues included in the physical IO equipment based on the virtual machine creation request; determining respective corresponding calling states of all hardware queues at the current moment; and determining the hardware queue in the non-calling state in all the hardware queues as an available hardware queue.

In some examples, when the first determiningmodule 12 obtains all hardware queues included in the physical IO device based on the virtual machine creation request, the first determiningmodule 12 is configured to perform: in the Hypervisor, establishing a physical device driver for scanning a hardware queue in the physical IO device; and performing queue scanning operation on the physical IO device by using the physical device driver and the virtual machine creation request to obtain all hardware queues included in the physical IO device, and recording hardware queue identifications and hardware queue numbers corresponding to all the hardware queues respectively.

In some examples, when the first determiningmodule 12 establishes a physical device driver for performing a scan operation on a hardware queue in a physical IO device in the Hypervisor, the first determiningmodule 12 is configured to: acquiring equipment information of physical IO equipment and system information of Hypervisor; in the Hypervisor, a physical device driver is constructed based on the device information of the physical IO device and the system information of the Hypervisor, and the physical device driver is used for scanning and loading a hardware queue in the physical IO device.

In some examples, after recording the hardware queue identifications and the number of hardware queues corresponding to all the hardware queues, thefirst processing module 13 in this embodiment is configured to perform: and when a drive update request of the physical device drive is acquired, clearing a hardware queue included in the physical IO device based on the drive update request.

In some examples, after clearing the hardware queue included in the physical IO device based on the driver update request, the first obtainingmodule 11, the first determiningmodule 12, and thefirst processing module 13 in this embodiment are respectively configured to perform the following steps:

a first obtainingmodule 11, configured to obtain a target device driver based on the driver update request;

a first determiningmodule 12, configured to determine a target hardware queue corresponding to a target device driver;

thefirst processing module 13 is configured to update a hardware queue included in the virtual machine to a target hardware queue.

In some examples, when the first determiningmodule 12 determines a hardware queue satisfying the number of hardware queues among the available hardware queues allowed, the first determiningmodule 12 is configured to perform: acquiring the number of available queues allowing available hardware queues; when the number of the available queues is larger than or equal to the number of the hardware queues, allowing the hardware queues meeting the number of the hardware queues to be determined in the available hardware queues; and when the number of the available queues is less than the number of the hardware queues, prohibiting the hardware queues meeting the number of the hardware queues from being determined in the allowed available hardware queues, and generating prompt information for identifying the virtual machine creation failure.

In some examples, the first determiningmodule 12 and thefirst processing module 13 in this embodiment are configured to perform the following steps:

a first determiningmodule 12, configured to determine, in the physical IO device, a hardware memory corresponding to the hardware queue;

thefirst processing module 13 is configured to control an access operation of the virtual machine based on the virtual memory and the hardware memory.

In some examples, when thefirst processing module 13 controls access operations of the virtual machine based on the virtual memory and the hardware memory, thefirst processing module 13 is configured to perform: acquiring a virtual machine access request; determining the request attribute of the virtual machine access request; determining a target memory corresponding to the virtual machine access request based on the request attribute, wherein the target memory comprises any one of a virtual memory and a hardware memory; and controlling the access operation of the virtual machine based on the target memory and the virtual machine access request.

In some examples, when thefirst processing module 13 determines the target memory corresponding to the virtual machine access request based on the request attribute, thefirst processing module 13 is configured to perform: when the request attribute corresponds to the virtual machine, determining that a target memory corresponding to the virtual machine access request is a virtual memory; and when the request attribute corresponds to a hardware queue included in the virtual machine, determining that a target memory corresponding to the virtual machine access request is a hardware memory.

In some examples, the first obtainingmodule 11, the first determiningmodule 12 and thefirst processing module 13 in this embodiment are respectively configured to perform the following steps:

a first obtainingmodule 11, configured to obtain a virtual machine deletion request;

a first determiningmodule 12, configured to determine a target identity included in the virtual machine deletion request;

thefirst processing module 13 is configured to delete the virtual machine corresponding to the target identity, and recycle the memory resource corresponding to the deleted virtual machine.

In some examples, the first obtainingmodule 11, the first determiningmodule 12 and thefirst processing module 13 in this embodiment are respectively configured to perform the following steps:

a first obtainingmodule 11, configured to obtain a virtual machine configuration request;

a first determiningmodule 12, configured to determine a target identity included in the virtual machine configuration request;

and thefirst processing module 13 is configured to perform configuration operation on the virtual machine corresponding to the target identity.

In some examples, after the virtual machine is established based on the hardware queue, the first obtainingmodule 11 and thefirst processing module 13 in this embodiment are respectively configured to perform the following steps:

a first obtainingmodule 11, configured to obtain all virtual machines included in a physical IO device;

thefirst processing module 13 is configured to perform virtual machine physical address allocation operation on all virtual machines to obtain virtual machine physical addresses corresponding to the virtual machines, where physical address ranges of the virtual machines corresponding to each virtual machine are different, and an overlapping area does not exist between physical address ranges of the virtual machines corresponding to any two virtual machines.

The apparatus shown in fig. 12 can perform the method of the embodiment shown in fig. 4-11, and the detailed description of this embodiment can refer to the related description of the embodiment shown in fig. 4-11. The implementation process and technical effect of the technical solution are described in the embodiments shown in fig. 4 to 11, and are not described herein again.

In one possible design, the structure of the virtual machine creation apparatus shown in fig. 12 may be implemented as an electronic device, which may be a mobile phone, a tablet computer, a server, or other devices. As shown in fig. 13, the electronic device may include: afirst processor 21 and afirst memory 22. Thefirst memory 22 is used for storing a program for executing the virtual machine creation method provided in the embodiments shown in fig. 4 to 11, and thefirst processor 21 is configured to execute the program stored in thefirst memory 22.

The program comprises one or more computer instructions, wherein the one or more computer instructions, when executed by thefirst processor 21, are capable of performing the steps of: acquiring a virtual machine creation request; determining a hardware queue corresponding to a virtual machine creation request in physical IO equipment; and establishing a virtual machine based on the hardware queue, and determining a virtual memory corresponding to the virtual machine in the Hypervisor.

Further, thefirst processor 21 is also used to execute all or part of the steps in the embodiments shown in fig. 4 to 11.

The electronic device may further include afirst communication interface 23 for communicating with other devices or a communication network.

In addition, an embodiment of the present invention provides a computer storage medium for storing computer software instructions for an electronic device, which includes a program for executing the virtual machine creation method in the method embodiments shown in fig. 4 to 11.

Furthermore, an embodiment of the present invention provides a computer program product, including: a computer-readable storage medium storing computer instructions which, when executed by one or more processors, cause the one or more processors to perform the steps in the virtual machine creation method in the method embodiments of fig. 4-11 described above.

The above-described embodiments of the apparatus are merely illustrative, and the units described as separate parts may or may not be physically separate, and the parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of the present embodiment. One of ordinary skill in the art can understand and implement it without inventive effort.

Through the above description of the embodiments, those skilled in the art will clearly understand that each embodiment can be implemented by adding a necessary general hardware platform, and of course, can also be implemented by a combination of hardware and software. With this understanding in mind, the above-described technical solutions and/or portions thereof that contribute to the prior art may be embodied in the form of a computer program product, which may be embodied on one or more computer-usable storage media having computer-usable program code embodied therein (including but not limited to disk storage, CD-ROM, optical storage, etc.).

The present application is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the application. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

In a typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

The memory may include forms of volatile memory in a computer readable medium, Random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.

Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), Digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.

Finally, it should be noted that: the above embodiments are only used for illustrating the technical solutions of the present application, and not for limiting the same; although the present application has been described in detail with reference to the foregoing embodiments, it should be understood by those of ordinary skill in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some or all of the technical features may be equivalently replaced; and the modifications or the substitutions do not make the essence of the corresponding technical solutions depart from the scope of the technical solutions of the embodiments of the present application.

Claims (14)

1. A virtual machine creation method, comprising:

acquiring a virtual machine creation request;

determining a hardware queue corresponding to the virtual machine creation request in a physical IO device;

and establishing a virtual machine based on the hardware queue, and determining a virtual memory corresponding to the virtual machine in the Hypervisor.

2. The method of claim 1, determining, in a physical IO device, a hardware queue corresponding to the virtual machine creation request, comprising:

acquiring the number of hardware queues included in the virtual machine creation request and used for limiting the number of the hardware queues included in the virtual machine;

and determining a hardware queue meeting the hardware queue number in the physical IO device based on the virtual machine creation request.

3. The method of claim 2, determining, in a physical IO device, a hardware queue that satisfies the number of hardware queues based on the virtual machine creation request, comprising:

determining an allowable available hardware queue included by the physical IO device at the current moment based on the virtual machine creation request;

determining a hardware queue satisfying the number of hardware queues from the allowed available hardware queues.

4. The method of claim 3, determining, based on the virtual machine creation request, an allowed available hardware queue included by the physical IO device at the current time, comprising:

acquiring all hardware queues included in the physical IO equipment based on the virtual machine creation request;

determining respective corresponding calling states of all hardware queues at the current moment;

and determining the hardware queue in the non-calling state in all the hardware queues as the allowed available hardware queue.

5. The method of claim 4, wherein obtaining all hardware queues included in the physical IO device based on the virtual machine creation request comprises:

in the Hypervisor, establishing a physical device driver for scanning a hardware queue in the physical IO device;

and performing queue scanning operation on the physical IO equipment by using the physical equipment driver and the virtual machine creation request, obtaining all hardware queues included in the physical IO equipment, and recording hardware queue identifications and hardware queue numbers corresponding to all the hardware queues.

6. The method of claim 5, wherein in the Hypervisor, establishing a physical device driver for performing a scan operation on a hardware queue in a physical IO device comprises:

acquiring equipment information of physical IO equipment and system information of Hypervisor;

in the Hypervisor, a physical device driver is constructed based on the device information of the physical IO device and the system information of the Hypervisor, and the physical device driver is used for scanning and loading a hardware queue in the physical IO device.

7. The method of any of claims 1-6, further comprising:

determining a hardware memory corresponding to the hardware queue in the physical IO device;

and controlling the access operation of the virtual machine based on the virtual memory and the hardware memory.

8. The method of claim 7, controlling access operations of the virtual machine based on the virtual memory and the hardware memory, comprising:

acquiring a virtual machine access request;

determining a request attribute of the virtual machine access request;

determining a target memory corresponding to the virtual machine access request based on the request attribute, wherein the target memory comprises any one of a virtual memory and a hardware memory;

and controlling the access operation of the virtual machine based on the target memory and the virtual machine access request.

9. The method of claim 8, determining, based on the request attributes, a target memory corresponding to the virtual machine access request, comprising:

when the request attribute corresponds to the virtual machine, determining that a target memory corresponding to the virtual machine access request is the virtual memory;

and when the request attribute corresponds to a hardware queue included in the virtual machine, determining that a target memory corresponding to the virtual machine access request is the hardware memory.

10. The method of any of claims 1-6, after establishing a virtual machine based on the hardware queue, the method further comprising:

acquiring all virtual machines included in the physical IO equipment;

and performing virtual machine physical address allocation operation on all the virtual machines to obtain virtual machine physical addresses corresponding to all the virtual machines, wherein the virtual machine physical address ranges corresponding to all the virtual machines are different, and no overlapping area exists between the virtual machine physical address ranges corresponding to any two virtual machines.

11. A virtual machine creation system, comprising:

the client is used for generating a virtual machine creating request and sending the virtual machine creating request to the virtual machine creating equipment;

the virtual machine creating equipment is in communication connection with the client and is used for acquiring a virtual machine creating request; determining a hardware queue corresponding to the virtual machine creation request in a physical IO device; and establishing a virtual machine based on the hardware queue, and determining a virtual memory corresponding to the virtual machine in the Hypervisor.

12. An electronic device, comprising: a memory, a processor; wherein the memory is configured to store one or more computer instructions, wherein the one or more computer instructions, when executed by the processor, implement the virtual machine creation method of any of claims 1-10.

13. A computer storage medium storing a computer program that causes a computer to implement the virtual machine creation method according to any one of claims 1 to 10 when executed.

14. A computer program product, comprising: a computer-readable storage medium storing computer instructions that, when executed by one or more processors, cause the one or more processors to perform the steps in the virtual machine creation method of any one of claims 1-10.

Images