A vGPU management method, device, electronic device and storage medium

Abstract

The present application discloses a vGPU management method, device, electronic device and computer-readable storage medium, the method comprising: if a target virtual machine creation request is received, a target host that meets the target specification is determined; wherein the target virtual machine is a virtual machine bound to a vGPU of the target specification, and the target specification includes a GPU model and a vGPU type; resources in the target host are allocated to the target virtual machine, and the corresponding relationship between the target virtual machine and the target specification is recorded; a target virtual machine is created in the target host, and a communication middleware is created between the target virtual machine and the vGPU of the target specification; and the target virtual machine is started. It can be seen that the present application realizes the function of creating a virtual machine bound to a target specification of vGPU resources, improves the efficiency of creating vGPUs, and provides great convenience and good experience for the use of vGPUs in cloud platforms.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and more specifically, to a vGPU management method, device, electronic device, and computer-readable storage medium. Background Art

[0002] Cloud computing platforms provide computing, network and storage capabilities based on hardware and software resource services. In related technologies, after creating a virtual machine, it is necessary to specify the associated GPU (Graphics Processing Unit) model and vGPU (Virtual Graphics Processing Unit) type for each virtual machine, which is inefficient.

[0003] Therefore, how to improve the efficiency of creating vGPU is a technical problem that technicians in this field need to solve. Summary of the invention

[0004] The purpose of this application is to provide a vGPU management method, device, electronic device and computer-readable storage medium to improve the efficiency of creating vGPU.

[0005] To achieve the above objectives, the present application provides a vGPU management method, including:

[0006] If a target virtual machine creation request is received, a target host that meets the target specification is determined; wherein the target virtual machine is a virtual machine bound to a vGPU of the target specification, and the target specification includes a GPU model and a vGPU type;

[0007] Allocating resources in the target host to the target virtual machine, and recording the corresponding relationship between the target virtual machine and the target specification;

[0008] Creating the target virtual machine in the target host, and creating communication middleware between the target virtual machine and the vGPU of the target specification;

[0009] The target virtual machine is started.

[0010] Wherein, determining a target host that meets the target specification includes:

[0011] Obtain candidate hosts that meet the target specifications;

[0012] Calculate the weight of each candidate host according to the index of each candidate host;

[0013] The candidate host with the highest weight is selected as the target host.

[0014] Wherein, starting the target virtual machine includes:

[0015] Generate an XML file of a virtual machine of the target specification, and call libvirt to start the target virtual machine.

[0016] Among them, it also includes:

[0017] Determine a virtual machine to be bound among the created virtual machines, and allocate vGPU resources to the virtual machine to be bound;

[0018] Creating a communication middleware between the virtual machine to be bound and the vGPU of the specification to be bound;

[0019] The correspondence between the virtual machine to be bound and the vGPU specification to be bound is recorded.

[0020] Among them, it also includes:

[0021] Determine the virtual machine to be unbound, and release the vGPU resources corresponding to the virtual machine to be unbound;

[0022] The communication middleware created between the virtual machine to be unbound and the vGPU of the corresponding specification is deleted, and the corresponding relationship between the virtual machine to be unbound and the corresponding specification is deleted.

[0023] To achieve the above objectives, the present application provides a vGPU management device, including:

[0024] A determination module, configured to determine a target host that meets the target specification if a target virtual machine creation request is received; wherein the target virtual machine is a virtual machine bound to a vGPU of the target specification, and the target specification includes a GPU model and a vGPU type;

[0025] A first recording module, used to allocate resources in the target host to the target virtual machine, and record the corresponding relationship between the target virtual machine and the target specification;

[0026] A first creation module, used to create the target virtual machine in the target host, and to create a communication middleware between the target virtual machine and the vGPU of the target specification;

[0027] A startup module is used to start the target virtual machine.

[0028] Among them, it also includes:

[0029] An allocation module is used to determine a virtual machine to be bound among the created virtual machines and allocate vGPU resources to the virtual machine to be bound;

[0030] A second creation module is used to create a communication middleware between the virtual machine to be bound and the vGPU of the specification to be bound;

[0031] The second recording module is used to record the corresponding relationship between the virtual machine to be bound and the specification of the vGPU to be bound.

[0032] Among them, it also includes:

[0033] A release module is used to determine the virtual machine to be unbound and release the vGPU resources corresponding to the virtual machine to be unbound;

[0034] The deletion module is used to delete the communication middleware created between the virtual machine to be unbound and the vGPU of the corresponding specification, and delete the corresponding relationship between the virtual machine to be unbound and the corresponding specification.

[0035] To achieve the above objectives, the present application provides an electronic device, including:

[0036] Memory for storing computer programs;

[0037] A processor is used to implement the steps of the above-mentioned vGPU management method when executing the computer program.

[0038] To achieve the above objectives, the present application provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the steps of the vGPU management method as described above are implemented.

[0039] It can be seen from the above scheme that a vGPU management method provided by the present application includes: if a target virtual machine creation request is received, determining a target host that meets the target specifications; wherein the target virtual machine is a virtual machine bound to a vGPU of the target specifications, and the target specifications include a GPU model and a vGPU type; allocating resources in the target host to the target virtual machine, and recording the correspondence between the target virtual machine and the target specifications; creating the target virtual machine in the target host, and creating a communication middleware between the target virtual machine and the vGPU of the target specifications; and starting the target virtual machine.

[0040] The vGPU management method provided by this application allows users to customize vGPU specifications, including GPU models and vGPU types, and then select target specifications to batch create virtual machines, and finally create virtual machines bound to vGPU resources of target specifications. It can be seen that this application implements the function of creating virtual machines bound to target specifications of vGPU resources, improves the efficiency of creating vGPUs, and provides great convenience and good experience for the use of vGPUs in cloud platforms. This application also discloses a vGPU management device, an electronic device, and a computer-readable storage medium, which can also achieve the above technical effects.

[0041] It should be understood that the foregoing general description and the following detailed description are exemplary only and are not restrictive of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following is a brief introduction to the drawings required for use in the embodiments or the prior art descriptions. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work. The drawings are used to provide a further understanding of the present disclosure and constitute a part of the specification. Together with the following specific implementation methods, they are used to explain the present disclosure, but do not constitute a limitation to the present disclosure. In the drawings:

[0043] Figure 1 This is a flow chart of a vGPU management method according to an exemplary embodiment;

[0044] Figure 2 A timing diagram of creating a virtual machine using target specifications according to an exemplary embodiment;

[0045] Figure 3 The present invention is a flowchart of another vGPU management method according to an exemplary embodiment;

[0046] Figure 4 This is a timing diagram of a virtual machine mounting a vGPU resource according to an exemplary embodiment;

[0047] Figure 5 The present invention is a flowchart of another vGPU management method according to an exemplary embodiment;

[0048] Figure 6 is a structural diagram of a vGPU management device according to an exemplary embodiment;

[0049] Figure 7 The figure is a structural diagram of an electronic device according to an exemplary embodiment. DETAILED DESCRIPTION

[0050] The technical solutions in the embodiments of the present application will be clearly and completely described below in conjunction with the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in the field without making creative work are within the scope of protection of the present application. In addition, in the embodiments of the present application, "first", "second", etc. are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence.

[0051] In order to understand the vGPU management method provided by the present application, the system to which it is applied is first introduced. The system is specifically OpenStack, an open source cloud computing management platform project, which is a combination of a series of software open source projects. It may include a client, Nova api, Nova conductor, Nova scheduler, Nova compute, a cloud platform resource system, and a hardware acceleration resource system. Nova api is used to provide interfaces related to computing services in OpenStack. Novaconductor is a process for computing related services and database interactions in OpenStack. Nova scheduler is a service process for scheduling hosts and filtering hosts when creating virtual machines in OpenStack, and then finally selecting a suitable host to create a virtual machine. Nova compute is deployed on a computing node to start a virtual machine process service. The cloud platform resource system is a service for the use, scheduling, and management of resources such as CPU, Memory, Disk, PCI / PCIe devices in OpenStack. The hardware acceleration resource system is a management system for managing hardware acceleration resources such as GPU, FPGA, NVMe SSD, SmartNIC, etc. Through this hardware acceleration resource system, hardware acceleration resources in a practical cloud platform can be conveniently used.

[0052] The embodiment of the present application discloses a vGPU management method, which improves the efficiency of creating vGPU.

[0053] See also Figure 1 , according to an exemplary embodiment, a flowchart of a vGPU management method is shown, such as Figure 1 As shown, including:

[0054] S101: If a target virtual machine creation request is received, determine a target host that meets the target specification; wherein the target virtual machine is a virtual machine bound to a vGPU of the target specification, and the target specification includes a GPU model and a vGPU type;

[0055] In this embodiment, the user can customize the vGPU specification, including the GPU model and vGPU type. The combination of GPU model and vGPU type is used to create a virtual machine. For example, Tesla V100+nvidia-180, Tesla P40+nvidia-252, the virtual machine created using this specification will be bound to an nvidia-180vGPU under the Tesla V100 model and an nvidia-252vGPU under the Tesla P40 model.

[0056] In the specific implementation, Figure 2As shown, the user initiates a request to create a virtual machine using the target specification to nova-api. Nova-api sends an asynchronous request to create a virtual machine to nova-condutor. Nova-conductor first calls nova-scheduler to obtain available candidate hosts. Nova-scheduler obtains the list of candidate hosts that meet the target specifications from the cloud platform resource system, and then filters out hosts with higher weights, that is, the steps of determining the target host that meets the target specification include: obtaining candidate hosts that meet the target specifications; calculating the weight of each candidate host based on the indicators of each candidate host; and selecting the candidate host with the highest weight as the target host. The weights of the above-mentioned candidate hosts can be calculated based on the indicators of the candidate hosts, such as CPU, memory, disk usage, etc.

[0057] S102: Allocate resources in the target host to the target virtual machine, and record the corresponding relationship between the target virtual machine and the target specification;

[0058] In this step, the cloud platform resources in the target host are allocated to the virtual machine, and the target host information is returned to the nova-condutor service. Nova-condutor calls the hardware acceleration resource system interface to asynchronously allocate vGPU resources, that is, to bind the corresponding relationship between the target virtual machine and the target specification.

[0059] S103: creating the target virtual machine in the target host, and creating a communication middleware between the target virtual machine and the vGPU of the target specification;

[0060] S104: Start the target virtual machine.

[0061] In the specific implementation, the nova-compute service is called to create a target virtual machine. Nova-compute creates vGPUmdev, which is the middleware for the target virtual machine to communicate with the vGPU of the target specification. Once nova-compute receives the message returned by the hardware acceleration resource system that the binding of the vGPU is completed, nova-compute generates an XML file of the virtual machine, calls libvirt and finally starts the virtual machine bound with the vGPU. That is, the step of starting the target virtual machine includes: generating an XML file of the virtual machine of the target specification, and calling libvirt to start the target virtual machine.

[0062] The vGPU management method provided in the embodiment of the present application allows users to customize vGPU specifications, including GPU models and vGPU types, and then select target specifications to batch create virtual machines, and finally create virtual machines bound with vGPU resources of the target specifications. It can be seen that the embodiment of the present application implements the function of creating virtual machines bound with vGPU resources of the target specifications, improves the efficiency of creating vGPUs, and provides great convenience and good experience for the use of vGPUs in cloud platforms.

[0063] The following describes how to bind the created virtual machine to the vGPU specification.

[0064] See also Figure 3 , a flowchart of another vGPU management method according to an exemplary embodiment is shown, such as Figure 3 As shown, including:

[0065] S201: Determine a virtual machine to be bound from the created virtual machines, and allocate vGPU resources to the virtual machine to be bound;

[0066] S202: Creating a communication middleware between the virtual machine to be bound and the vGPU of the specification to be bound;

[0067] S203: Record the correspondence between the virtual machine to be bound and the specification of the vGPU to be bound.

[0068] In the specific implementation, Figure 4 As shown, the user first selects the vGPU specification to be bound and initiates a request to bind to the virtual machine to be bound to nova-api. Nova-api sends a synchronous request to nova-compute. Nova-compute calls the cloud platform resource system to allocate vGPU resources, then creates a vGPU mdev, and sends an asynchronous request to the hardware acceleration resource system to allocate vGPU resources, that is, to bind the corresponding relationship between the virtual machine to be bound and the vGPU specification to be bound. After Nova-compute receives the notification information of the hardware acceleration resource system to bind the vGPU, it notifies nova-api of the message that the vGPU is successfully bound. Nova-api prompts the user to successfully bind the vGPU.

[0069] It can be seen that this embodiment implements the operation of individually binding GPU resources to a virtual machine.

[0070] The following describes how to unbind vGPU resources from a virtual machine.

[0071] See also Figure 5 , according to an exemplary embodiment, a flowchart of another vGPU management method is shown, as shown in Figure 5 As shown, including:

[0072] S301: Determine a virtual machine to be unbound, and release vGPU resources corresponding to the virtual machine to be unbound;

[0073] S302: Delete the communication middleware created between the virtual machine to be unbound and the vGPU of the corresponding specification, and delete the corresponding relationship between the virtual machine to be unbound and the corresponding specification.

[0074] In the specific implementation, the user first selects the vGPU specification to be unbound and initiates an unbinding request to nova-api. Nova-api sends a synchronization request to nova-compute. Nova-compute releases the resource allocation of the vGPU and releases the vGPU resources for re-creating the virtual machine. Then the mdev information of the virtual machine to be unbound is deleted, and the corresponding relationship between the virtual machine to be unbound and the corresponding specification is deleted. After Nova-compute receives the notification information of the hardware acceleration resource system to unbind the vGPU, it notifies nova-api of the message that the vGPU is successfully unbound. Nova-api prompts the user that the vGPU has been successfully unbound.

[0075] It can be seen that this embodiment implements the operation of unbinding GPU resources from a virtual machine.

[0076] A vGPU management device provided in an embodiment of the present application is introduced below. The vGPU management device described below and the vGPU management method described above can be referenced to each other.

[0077] See also Figure 6 , a structural diagram of a vGPU management device according to an exemplary embodiment is shown, as Figure 6 As shown, including:

[0078] The determination module 601 is used to determine a target host that meets the target specification if a target virtual machine creation request is received; wherein the target virtual machine is a virtual machine bound to a vGPU of the target specification, and the target specification includes a GPU model and a vGPU type;

[0079] A first recording module 602, configured to allocate resources in the target host to the target virtual machine, and record a correspondence between the target virtual machine and the target specification;

[0080] A first creation module 603 is used to create the target virtual machine in the target host and to create a communication middleware between the target virtual machine and the vGPU of the target specification;

[0081] The starting module 604 is used to start the target virtual machine.

[0082] The vGPU management device provided in the embodiment of the present application allows the user to customize the vGPU specifications, including the GPU model and vGPU type, and then select the target specification to batch create virtual machines, and finally create virtual machines bound with vGPU resources of the target specification. It can be seen that the embodiment of the present application realizes the function of creating a virtual machine bound with vGPU resources of the target specification, improves the efficiency of creating vGPU, and provides great convenience and good experience for the use of vGPU in the cloud platform.

[0083] Based on the above embodiments, as a preferred implementation mode, the determination module 601 is specifically a module that, if a target virtual machine creation request is received, obtains candidate hosts that meet the target specifications, calculates the weight of each candidate host according to the indicators of each candidate host, and selects the candidate host with the highest weight as the target host.

[0084] Based on the above embodiment, as a preferred implementation, the startup module 604 is specifically a module that generates an XML file of a virtual machine of the target specification and calls libvirt to start the target virtual machine.

[0085] Based on the above embodiment, as a preferred implementation, it also includes:

[0086] An allocation module is used to determine a virtual machine to be bound among the created virtual machines and allocate vGPU resources to the virtual machine to be bound;

[0087] A second creation module is used to create a communication middleware between the virtual machine to be bound and the vGPU of the specification to be bound;

[0088] The second recording module is used to record the corresponding relationship between the virtual machine to be bound and the specification of the vGPU to be bound.

[0089] Based on the above embodiment, as a preferred implementation, it also includes:

[0090] A release module is used to determine the virtual machine to be unbound and release the vGPU resources corresponding to the virtual machine to be unbound;

[0091] The deletion module is used to delete the communication middleware created between the virtual machine to be unbound and the vGPU of the corresponding specification, and delete the corresponding relationship between the virtual machine to be unbound and the corresponding specification.

[0092] Regarding the device in the above embodiment, the specific manner in which each module performs operations has been described in detail in the embodiment of the method, and will not be elaborated here.

[0093] Based on the hardware implementation of the above program module, and in order to implement the method of the embodiment of the present application, the embodiment of the present application also provides an electronic device, Figure 7 FIG. 1 is a structural diagram of an electronic device according to an exemplary embodiment. Figure 7 As shown, the electronic equipment includes:

[0094] Communication interface 1, capable of exchanging information with other devices such as network devices;

[0095] The processor 2 is connected to the communication interface 1 to implement information exchange with other devices, and is used to execute the vGPU management method provided by one or more technical solutions when running a computer program. The computer program is stored in the memory 3.

[0096] Of course, in actual application, the various components in the electronic device are coupled together through the bus system 4. It can be understood that the bus system 4 is used to realize the connection and communication between these components. In addition to the data bus, the bus system 4 also includes a power bus, a control bus and a status signal bus. However, for the sake of clarity, Figure 7 Various buses are labeled as bus system 4 .

[0097] The memory 3 in the embodiment of the present application is used to store various types of data to support the operation of the electronic device. Examples of such data include: any computer program used to operate on the electronic device.

[0098] It can be understood that the memory 3 can be a volatile memory or a non-volatile memory, and can also include both volatile and non-volatile memories. Among them, the non-volatile memory can be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), a magnetic random access memory (FRAM), a flash memory, a magnetic surface memory, an optical disc, or a compact disc read-only memory (CD-ROM); the magnetic surface memory can be a disk memory or a tape memory. The volatile memory can be a random access memory (RAM), which is used as an external cache. By way of example and not limitation, many forms of RAM are available, such as static random access memory (SRAM), synchronous static random access memory (SSRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDRSDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM, SyncLink Dynamic Random Access Memory), and direct RAM bus random access memory (DRRAM, Direct Rambus Random Access Memory).The memory 2 described in the embodiments of the present application is intended to include but is not limited to these and any other suitable types of memory.

[0099] The method disclosed in the above embodiment of the present application can be applied to the processor 2, or implemented by the processor 2. The processor 2 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by the hardware integrated logic circuit in the processor 2 or the instruction in the form of software. The above processor 2 may be a general-purpose processor, a DSP, or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components, etc. The processor 2 can implement or execute the methods, steps and logic block diagrams disclosed in the embodiments of the present application. The general-purpose processor may be a microprocessor or any conventional processor, etc. In combination with the steps of the method disclosed in the embodiment of the present application, it can be directly embodied as a hardware decoding processor to execute, or it can be executed by a combination of hardware and software modules in the decoding processor. The software module may be located in a storage medium, which is located in the memory 3, and the processor 2 reads the program in the memory 3 and completes the steps of the above method in combination with its hardware.

[0100] When the processor 2 executes the program, the corresponding processes in the various methods of the embodiments of the present application are implemented, which will not be repeated here for the sake of brevity.

[0101] In an exemplary embodiment, the present application also provides a storage medium, namely a computer storage medium, specifically a computer-readable storage medium, for example, a memory 3 storing a computer program, and the computer program can be executed by a processor 2 to complete the steps of the aforementioned method. The computer-readable storage medium can be a memory such as FRAM, ROM, PROM, EPROM, EEPROM, Flash Memory, magnetic surface storage, optical disk, or CD-ROM.

[0102] A person of ordinary skill in the art can understand that: all or part of the steps of implementing the above-mentioned method embodiment can be completed by hardware related to program instructions, and the aforementioned program can be stored in a computer-readable storage medium, which, when executed, executes the steps of the above-mentioned method embodiment; and the aforementioned storage medium includes: various media that can store program codes, such as mobile storage devices, ROM, RAM, disks or optical disks.

[0103] Alternatively, if the above-mentioned integrated unit of the present application is implemented in the form of a software function module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the embodiment of the present application can be essentially or partly reflected in the form of a software product that contributes to the prior art. The computer software product is stored in a storage medium, including several instructions to enable an electronic device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the methods described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as mobile storage devices, ROM, RAM, magnetic disks or optical disks.

[0104] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

Claims

1. A vGPU management method, characterized in that: include: If a request to create a batch of target virtual machines is received, a target host that meets the target specification is determined; wherein the creation request includes the target specification, the target virtual machine is a virtual machine bound to a vGPU of the target specification, and the target specification includes a GPU model and a vGPU type; Allocate resources in the target host to the target virtual machine, and record the corresponding relationship between the target virtual machine and the target specification; wherein Nova-condutor calls the hardware acceleration resource system interface to asynchronously allocate vGPU resources; Creating the target virtual machine in the target host, and creating communication middleware between the target virtual machine and the vGPU of the target specification; Starting the target virtual machine; If a request to create a batch of target virtual machines is received, determining a target host that meets the target specification includes: Nova-api receives the request to create a batch of target virtual machines and sends the creation request to nova-condutor; Nova-condutor calls nova-scheduler to obtain candidate hosts that meet the target specifications; Nova-scheduler calculates the weight of each candidate host according to the index of each candidate host, and selects the candidate host with the highest weight as the target host; Wherein, starting the target virtual machine includes: Nova-compute creates vGPU mdev, generates an XML file of the target virtual machine, and calls libvirt to start the target virtual machine; Among them, it also includes: Determine a virtual machine to be bound among the created virtual machines, and allocate vGPU resources to the virtual machine to be bound; Creating a communication middleware between the virtual machine to be bound and the vGPU of the specification to be bound; Recording the correspondence between the virtual machine to be bound and the vGPU specification to be bound; Among them, it also includes: Determine the virtual machine to be unbound, and release the vGPU resources corresponding to the virtual machine to be unbound; The communication middleware created between the virtual machine to be unbound and the vGPU of the corresponding specification is deleted, and the corresponding relationship between the virtual machine to be unbound and the corresponding specification is deleted.

2. A vGPU management device, characterized in that: include: A determination module, configured to determine a target host that meets the target specification if a request to create a batch of target virtual machines is received; wherein the creation request includes the target specification, the target virtual machine is a virtual machine bound to a vGPU of the target specification, and the target specification includes a GPU model and a vGPU type; A first recording module is used to allocate resources in the target host to the target virtual machine and record the corresponding relationship between the target virtual machine and the target specification; wherein Nova-condutor calls the hardware acceleration resource system interface to asynchronously allocate vGPU resources; A first creation module, used to create the target virtual machine in the target host, and to create a communication middleware between the target virtual machine and the vGPU of the target specification; A startup module, used for starting the target virtual machine; The determination module is specifically used for: Nova-api receives a request to create a batch of target virtual machines, and sends the creation request to nova-condutor; Nova-condutor calls nova-scheduler to obtain candidate hosts that meet the target specifications; Nova-scheduler calculates the weight of each candidate host according to the index of each candidate host, and selects the candidate host with the highest weight as the target host; The startup module is specifically used to: Nova-compute creates a vGPU mdev, generates an XML file of a virtual machine of the target specification, and calls libvirt to start the target virtual machine; Among them, it also includes: An allocation module is used to determine a virtual machine to be bound among the created virtual machines and allocate vGPU resources to the virtual machine to be bound; A second creation module is used to create a communication middleware between the virtual machine to be bound and the vGPU of the specification to be bound; A second recording module is used to record the correspondence between the virtual machine to be bound and the vGPU specification to be bound; Among them, it also includes: A release module is used to determine the virtual machine to be unbound and release the vGPU resources corresponding to the virtual machine to be unbound; The deletion module is used to delete the communication middleware created between the virtual machine to be unbound and the vGPU of the corresponding specification, and delete the corresponding relationship between the virtual machine to be unbound and the corresponding specification.

3. An electronic device, characterized in that: include: Memory for storing computer programs; A processor is used to implement the steps of the vGPU management method as claimed in claim 1 when executing the computer program.

4. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps of the vGPU management method as claimed in claim 1 are implemented.

Images