WO2024131368A1 - 虚拟机的调度方法、装置、芯片以及计算机可读存储介质 - Google Patents

虚拟机的调度方法、装置、芯片以及计算机可读存储介质 Download PDF

Info

Publication number
WO2024131368A1
WO2024131368A1 PCT/CN2023/130566 CN2023130566W WO2024131368A1 WO 2024131368 A1 WO2024131368 A1 WO 2024131368A1 CN 2023130566 W CN2023130566 W CN 2023130566W WO 2024131368 A1 WO2024131368 A1 WO 2024131368A1
Authority
WO
WIPO (PCT)
Prior art keywords
virtual machine
load
thread
target
accelerator card
Prior art date
Application number
PCT/CN2023/130566
Other languages
English (en)
French (fr)
Inventor
金鑫
徐新海
Original Assignee
华为技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Publication of WO2024131368A1 publication Critical patent/WO2024131368A1/zh

Links

Definitions

  • the present application relates to the field of communication technology, and in particular to a virtual machine scheduling method, device, chip and computer-readable storage medium.
  • cloud servers are equipped with central processing units (CPU) and accelerator cards. Some computing tasks of the CPU can be offloaded to the accelerator card, which executes these computing tasks. This allows more processing power and memory of the cloud server to be freed up for tenants' virtual machines (VM).
  • CPU central processing units
  • accelerator cards Some computing tasks of the CPU can be offloaded to the accelerator card, which executes these computing tasks. This allows more processing power and memory of the cloud server to be freed up for tenants' virtual machines (VM).
  • VM virtual machines
  • the acceleration card as an encryption card as an example
  • the data encryption and data decryption functions in the CPU are unloaded to the encryption card, and the encryption card is virtualized into multiple virtual function (VF) units.
  • Each VF unit is bound to a VM in the cloud server. Any VM sends a data encryption/decryption request to the processing queue of the bound VF unit to communicate with the bound VF unit.
  • the encryption card processes the data encryption/decryption requests in the processing queues of multiple VF units in a polling manner.
  • the embodiments of the present application provide a virtual machine scheduling method, device, chip and computer-readable storage medium, which can improve the flexibility of the communication mode between the virtual machine and the accelerator card.
  • the technical solution is as follows:
  • a virtual machine scheduling method is provided, and the method is applied to a computer device, wherein the computer device is configured with at least one accelerator card, multiple virtual machines and multiple threads, the accelerator card includes multiple virtual function units, and the virtual machine communicates with at least one virtual function unit through at least one thread; in this method, virtual function units, threads or accelerator cards are different types of communication units, and the load of the communication unit is related to multiple virtual machines.
  • the load of at least one communication unit of the computer device is first obtained; then, based on the load of at least one communication unit, a target communication unit is allocated to a target virtual machine in at least one accelerator card, and the target communication unit is a virtual function unit, a thread or an accelerator card; thereafter, the target virtual machine is scheduled to the target communication unit so that the target virtual machine can communicate with the target communication unit.
  • This method allocates a target communication unit to a target virtual machine in a computer device based on the load of a virtual function unit, a thread and at least one communication unit in an accelerator card of the computer device, and schedules the target virtual machine to the allocated target communication unit so that the target virtual machine can communicate with the target communication unit. Since the target communication unit can be allocated to the target virtual machine, the virtual function unit that can communicate with the target virtual machine is not fixed, and there is no need to bind the target virtual machine to the fixed virtual function unit. As the target virtual machine is scheduled between different communication units of the accelerator card, the target virtual machine can flexibly communicate with different virtual function units, thereby improving the flexibility of the communication method between the virtual machine and the accelerator card.
  • the communication unit is a virtual function unit
  • the load of at least one communication unit includes the load of each virtual function unit in at least one accelerator card
  • the target communication unit is a virtual function unit.
  • the process of allocating the target communication unit to the target virtual machine in at least one accelerator card based on the load of at least one communication unit includes: first determining the first virtual function unit and the second virtual function unit based on the load of each virtual function unit in at least one accelerator card; if the first load difference between the first virtual function unit and the second virtual function unit is greater than or equal to the first threshold, allocating the second virtual function unit to the target virtual machine in at least one first virtual machine; wherein the first virtual function unit is the virtual function unit with the largest load in at least one accelerator card, the second virtual function unit is the virtual function unit with the smallest load in at least one accelerator card, and the first virtual machine is a virtual machine among multiple virtual machines that communicates with the first virtual function unit.
  • the communication unit is a thread
  • the load of at least one communication unit includes the loads of multiple threads
  • the target communication unit is a thread.
  • the process of allocating the target communication unit to the target virtual machine in at least one accelerator card based on the load of at least one communication unit includes: first determining the first thread and the second thread based on the load of multiple threads; then, allocating the second thread to the target virtual machine in at least one second virtual machine, the second virtual machine is a virtual machine among the multiple virtual machines that communicates with the first thread, wherein the first thread is the thread with the largest load among the multiple threads, and the second thread is the thread with the smallest load among the multiple threads.
  • a second thread is allocated to the target virtual machine in at least one second virtual machine so that the target virtual machine can be scheduled from the first thread to the second thread, so as to avoid the subsequent data processing requests of the target virtual machine waiting in line for processing in the first thread for a long time, thereby improving the data processing efficiency of the target virtual machine, reducing the load of the first thread, improving the processing efficiency of the first thread, and enabling the resources provided by the second thread to be fully utilized, thereby avoiding waste of resources of the second thread.
  • the process of allocating a second thread to a target virtual machine in at least one second virtual machine includes: for a first candidate virtual machine in at least one second virtual machine, first predicting the load of the first thread and the load of the second thread based on a first total load provided by the first candidate virtual machine for the first thread, the load of the first thread, and the load of the second thread, to obtain a first predicted load and a second predicted load; if the absolute value of the difference between the first predicted load and the second predicted load is less than or equal to a second threshold, allocating the second thread to the first candidate virtual machine, wherein the first predicted load is the load of the first thread after the first candidate virtual machine is scheduled to the second thread, and the second predicted load is the load of the second thread after the first candidate virtual machine is scheduled to the second thread.
  • the second thread by allocating the second thread to the first candidate virtual machine when the absolute value of the difference between the first predicted load and the second predicted load is less than or equal to the second threshold, so that after the first candidate virtual machine is scheduled to the second thread, the load of the first thread reaches the first predicted load, and the load of the second thread reaches the second predicted load. Since the absolute value of the difference between the first predicted load and the second predicted load is less than the second threshold, the first thread and the second thread are load balanced after scheduling, that is, the load is predicted in advance to ensure that the first thread and the second thread are load balanced after scheduling.
  • the communication unit is a thread
  • the load of at least one resource includes the loads of multiple threads
  • the target communication unit is a thread.
  • the process of allocating the target communication unit to the target virtual machine in at least one accelerator card based on the load of at least one communication unit includes: first, based on the loads of multiple threads, determining a third thread and a fourth thread from multiple threads; and then allocating the fourth thread to the target virtual machine in at least one third virtual machine, wherein the load of the third thread is greater than or equal to a third threshold, and the load of the fourth thread is less than the load of the third thread.
  • the third virtual machine is a virtual machine with which the third thread communicates among the multiple virtual machines.
  • the process of allocating a fourth thread to a target virtual machine in at least one third virtual machine includes: for a second candidate virtual machine in at least one third virtual machine, first predicting the load of the third thread and the load of the fourth thread based on the second total load provided by the second candidate virtual machine for the third thread, the load of the third thread, and the load of the fourth thread, respectively, to obtain a third predicted load and a fourth predicted load; if the absolute value of the difference between the third predicted load and the fourth predicted load is less than or equal to a fourth threshold, then allocating the fourth thread to the second candidate virtual machine, wherein the third predicted load is the load of the third thread after the second candidate virtual machine is scheduled to the fourth thread, and the fourth predicted load is the load of the fourth thread after the second candidate virtual machine is scheduled to the fourth thread.
  • the fourth thread by allocating the fourth thread to the second candidate virtual machine when the absolute value of the difference between the third predicted load and the fourth predicted load is less than or equal to the fourth threshold, so that after the second candidate virtual machine is scheduled to the fourth thread, the load of the third thread reaches the third predicted load, and the load of the fourth thread reaches the fourth predicted load. Since the absolute value of the difference between the third predicted load and the fourth predicted load is less than the fourth threshold, the third thread and the fourth thread after scheduling are load balanced, that is, the load is predicted in advance to ensure that the third thread and the fourth thread after scheduling are load balanced.
  • the communication unit is a thread
  • the load of at least one communication unit includes the loads of multiple threads
  • the target communication unit is a thread.
  • the process of allocating the target communication unit to the target virtual machine in the at least one accelerator card based on the load of at least one communication unit includes: firstly determining multiple fifth threads from the multiple threads based on the loads of the multiple threads; and then allocating a sixth thread from the multiple fifth threads to the fourth virtual machine, wherein the sum of the loads of the multiple fifth threads is less than or equal to the fifth threshold value, and the fourth virtual machine
  • the machine is a virtual machine communicating with a seventh thread among the plurality of fifth threads, and the seventh thread is a thread among the plurality of fifth threads except the sixth thread.
  • the sixth thread is responsible for communicating with each fourth virtual machine, thereby avoiding wasting thread resources.
  • the communication unit is an accelerator card
  • at least one accelerator card includes multiple accelerator cards
  • the load of at least one communication unit includes the loads of multiple accelerator cards
  • the target communication unit is an accelerator card.
  • the process of allocating the target communication unit to the target virtual machine in at least one accelerator card based on the load of at least one communication unit includes: first determining the first accelerator card and the second accelerator card based on the load of multiple accelerator cards; and then allocating the second accelerator card to the target virtual machine in at least one fifth virtual machine, wherein the first accelerator card is the accelerator card with the largest load among the multiple accelerator cards, the second accelerator card is the accelerator card with the smallest load among the multiple accelerator cards, and the fifth virtual machine is a virtual machine among the multiple virtual machines that communicates with the first accelerator card.
  • a second accelerator card is allocated to a target virtual machine in at least one fifth virtual machine so that the target virtual machine can be scheduled from the first accelerator card to the second accelerator card to avoid data processing requests of subsequent target virtual machines waiting in queue for processing on the first accelerator card for a long time, thereby improving the data processing efficiency of the target virtual machine, reducing the load of the first accelerator card, improving the processing efficiency of the first accelerator card, and enabling the resources provided by the second accelerator card to be fully utilized, thereby avoiding waste of resources of the second accelerator card.
  • the process of allocating a second accelerator card to a target virtual machine in at least one fifth virtual machine includes: for a third candidate virtual machine in at least one fifth virtual machine, first predicting the load of the first accelerator card and the load of the second accelerator card based on the third total load provided by the third candidate virtual machine for the first accelerator card, the load of the first accelerator card, and the load of the second accelerator card, respectively, to obtain a fifth predicted load and a sixth predicted load; if the absolute value of the difference between the fifth predicted load and the sixth predicted load is less than or equal to a sixth threshold, then allocating a second accelerator card to the third candidate virtual machine, wherein the fifth predicted load is the load of the first accelerator card after the third candidate virtual machine is scheduled to the second accelerator card, and the sixth predicted load is the load of the second accelerator card after the third candidate virtual machine is scheduled to the second accelerator card.
  • the second accelerator card is allocated to the third candidate virtual machine only when the absolute value of the difference between the fifth predicted load and the sixth predicted load is less than or equal to the sixth threshold value, so that the third candidate virtual machine is scheduled to the second accelerator card, so that the load of the first accelerator card reaches the fourth predicted load, and the load of the second accelerator card reaches the sixth predicted load. Since the absolute value of the difference between the fourth predicted load and the sixth predicted load is less than the sixth threshold value, the first accelerator card and the second accelerator card are load balanced after scheduling, that is, the load is predicted in advance to ensure that the first accelerator card and the second accelerator card are load balanced after scheduling.
  • the method further includes the following steps: if the first accelerator card and the second accelerator card are of different types, querying session information of the target virtual machine from a session information library of multiple virtual machines, the session information library being used to store session information of multiple virtual machines; and storing the session information of the target virtual machine in a session pool of the second accelerator card, the session pool being used to store session information of virtual machines that communicate with the second accelerator card.
  • the second acceleration card can obtain session information of the application from its own session pool according to the session identifier carried in the data processing request.
  • the communication unit is an accelerator card
  • at least one accelerator card includes multiple accelerator cards
  • the load of at least one communication unit includes the loads of multiple accelerator cards
  • the target communication unit is an accelerator card.
  • the process of allocating the target communication unit to the target virtual machine in at least one accelerator card based on the load of at least one communication unit includes: first determining the first accelerator card based on the loads of multiple accelerator cards; if the load of the first accelerator card is greater than or equal to a seventh threshold, and there are idle accelerator cards among the multiple accelerator cards, then allocating the idle accelerator card to the target virtual machine in at least one fifth virtual machine, wherein the first accelerator card is the accelerator card with the largest load among the multiple accelerator cards, and the fifth virtual machine is a virtual machine among the multiple virtual machines that communicates with the first accelerator card.
  • an idle acceleration card is allocated to a target virtual machine in at least one fifth virtual machine so that the target virtual machine can be scheduled from the first acceleration card to the idle acceleration card, so as to avoid the data processing requests of the subsequent target virtual machines from queuing for processing on the first acceleration card for a long time, thereby improving the data processing efficiency of the target virtual machine, reducing the load of the first accelerator card, improving the processing efficiency of the first accelerator card, and enabling the resources provided by the idle acceleration card to be fully utilized, thereby avoiding waste of resources of the idle acceleration card.
  • the communication unit is an accelerator card
  • at least one accelerator card includes multiple accelerator cards
  • the load of at least one communication unit includes the loads of multiple accelerator cards
  • the target communication unit is an accelerator card.
  • the process of allocating the target communication unit to the target virtual machine in at least one accelerator card based on the load of at least one communication unit includes: firstly determining multiple third accelerator cards from multiple accelerator cards based on the loads of the multiple accelerator cards; and then allocating a fourth accelerator card from the multiple third accelerator cards to the sixth virtual machine, the sixth virtual machine being a virtual machine communicating with a fifth accelerator card from the multiple third accelerator cards, wherein the sum of the loads of the multiple third accelerator cards is less than or equal to an eighth threshold. value
  • the fifth accelerator card is an accelerator card among the plurality of third accelerator cards except the fourth accelerator card.
  • a fourth acceleration card is allocated to the sixth virtual machine on each fifth acceleration card among multiple third acceleration cards, so that each sixth virtual machine is scheduled to a fourth acceleration card among the multiple third acceleration cards, and the fourth acceleration card is responsible for communicating with each sixth virtual machine, thereby avoiding occupying too many acceleration cards.
  • a virtual machine scheduling device which is used to execute the virtual machine scheduling method.
  • the virtual machine scheduling device includes a functional module for executing the virtual machine scheduling method provided by the first aspect or any optional manner of the first aspect.
  • a chip comprising a processor, wherein the processor is used to execute program code so that the chip executes to implement the operations performed by the above-mentioned virtual machine scheduling method.
  • a computer device comprising a processor, wherein the processor is used to execute program code so that the computer device performs operations performed by the above-mentioned virtual machine scheduling method.
  • a computer-readable storage medium in which at least one program code is stored.
  • the program code is read by a processor in a chip/computer device to enable the chip/computer device to execute the operating steps of the scheduling method of the virtual machine as described above.
  • a computer program product or a computer program which includes a program code, and the program code is stored in a computer-readable storage medium.
  • a processor of a chip/computer device reads the program code from the computer-readable storage medium, and the processor executes the program code, so that the chip/computer device executes the method provided in the above-mentioned first aspect or various optional implementations of the first aspect.
  • FIG1 is a schematic diagram of a computer device for implementing a scheduling method for a virtual machine according to an embodiment of the present application
  • FIG2 is a flow chart of a virtual machine scheduling method provided in an embodiment of the present application.
  • FIG3 is a flow chart of a scheduling method for a virtual machine based on scheduling strategy 1 provided in an embodiment of the present application;
  • FIG4 is a schematic diagram of scheduling a virtual machine based on scheduling strategy 1 provided in an embodiment of the present application.
  • FIG5 is a flow chart of a scheduling method for a virtual machine based on scheduling strategy 2 provided in an embodiment of the present application;
  • FIG6 is a schematic diagram of scheduling a virtual machine based on scheduling strategy 2 provided in an embodiment of the present application.
  • FIG. 7 is a flow chart of a scheduling method for a virtual machine based on scheduling strategy 3 provided in an embodiment of the present application;
  • FIG8 is a schematic diagram of scheduling a virtual machine based on scheduling strategy 3 provided in an embodiment of the present application.
  • FIG. 9 is a flow chart of a scheduling method for a virtual machine based on scheduling strategy 4 provided in an embodiment of the present application.
  • FIG10 is a schematic diagram of scheduling a virtual machine based on scheduling strategy 4 provided in an embodiment of the present application.
  • FIG. 11 is a flowchart of a scheduling method for a virtual machine based on scheduling strategy 5 provided in an embodiment of the present application;
  • FIG12 is a schematic diagram of scheduling a virtual machine based on scheduling strategy 5 provided in an embodiment of the present application.
  • FIG. 13 is a flowchart of a scheduling method for a virtual machine based on scheduling strategy 6 provided in an embodiment of the present application;
  • FIG14 is a schematic diagram of scheduling a virtual machine based on scheduling strategy 6 provided in an embodiment of the present application.
  • 15 is a flowchart of a scheduling method for a virtual machine based on scheduling strategy 7 provided in an embodiment of the present application;
  • FIG16 is a schematic diagram of scheduling a virtual machine based on scheduling strategy 7 provided in an embodiment of the present application.
  • FIG17 is a schematic diagram of a virtual machine migration process provided in an embodiment of the present application.
  • FIG18 is a schematic diagram of the structure of a virtual machine scheduling device provided in an embodiment of the present application.
  • FIG19 is a schematic diagram of the structure of a chip provided in an embodiment of the present application.
  • FIG. 20 is a schematic diagram of the structure of a computer device provided in an embodiment of the present application.
  • Host A physical machine that is configured as a server, such as a cloud server, a local server, or a server in a data center.
  • the server's usage environment is not limited.
  • the server may be an x86 system architecture server, an advanced RISC machine (ARM) standard Linux system server, or a server of other architectures. This application does not limit the architecture of the server involved.
  • Virtual machine It is a server virtualized on the host using virtualization technology, which can run x86 system or ARM Linux system.
  • a virtual machine is a complete computer system with complete hardware system functions and running in a completely isolated environment that is simulated by software. All the work that can be done in a server can be done in a virtual machine.
  • part of the hard disk and memory capacity of the physical machine needs to be used as the hard disk and memory capacity of the virtual machine.
  • Each virtual machine has an independent hard disk and operating system, and the user of the virtual machine can operate the virtual machine like using a server.
  • Virtualization technology It mainly consists of computing virtualization and input-output (IO) virtualization. As the core technology of cloud scenarios, it uses virtual machines as the granularity to share a physical server with multiple tenants, allowing tenants to use physical resources conveniently and flexibly under the premise of secure isolation, and can greatly improve the utilization rate of physical resources. Virtualization technologies include Linux kernel-based virtual machines (KVM) and virtual machine monitors (Xen).
  • KVM Linux kernel-based virtual machines
  • Xen virtual machine monitors
  • Computing virtualization It is to provide computing resources such as the server's processor and memory to virtual instances.
  • virtual instances are virtual machines.
  • virtual instances are containers and bare metal servers.
  • Input and output virtualization includes network virtualization and storage virtualization.
  • Network virtualization refers to providing part of the functions of the server's network card (such as bandwidth) to the virtual machine
  • storage virtualization refers to providing part of the server's disk to the virtual machine.
  • APP any application running in a virtual machine that requires the use of an accelerator card.
  • Accelerator card used to undertake some computing tasks for the processor in the server, or it can also be understood as offloading some computing tasks or some data processing functions of the processor in the server to the accelerator card, which is used to implement this part of the computing tasks or this part of the data processing functions.
  • the accelerator card can also be called an offload card. Take a virtual customer premises equipment (vCPE) deployed in a software defined wide area network (SD-WAN) as an example.
  • vCPE virtual customer premises equipment
  • SD-WAN software defined wide area network
  • the vCPE needs data encryption and/or data decryption (referred to as data encryption and decryption) services
  • the data encryption and decryption services are offloaded from the processor to the accelerator card.
  • the accelerator card provides data encryption and decryption services for the vCPE.
  • the accelerator card can also be called an encryption card.
  • Encryption cards include quick assist technology (QAT) accelerator cards and network expansion cards (Mellanox, MLX).
  • QAT quick assist technology
  • Mellanox, MLX network expansion cards
  • data decompression referred to as data decompression services are offloaded from the server's processor to an accelerator card, which provides data decompression services for applications in the virtual machine, where data decompression, for example, decompresses IO requests of the application.
  • Standard paravirtualized IO device model (towards a de-facto standard for virtual IO devices, virtio): is a set of general IO device virtualization programs, as a virtual device between a virtual machine and an accelerator card, for providing a communication link between an application in the virtual machine and the accelerator card.
  • the standard paravirtualized IO device model includes a front-end driver and a back-end driver, wherein the front-end driver runs in the virtual machine and is used to communicate with the application and the back-end driver in the virtual machine, and the front-end driver and the back-end driver are used together to undertake data processing requests issued by the application.
  • the back-end driver runs in the operating system of the computer device (relative to the operating system of the virtual machine, it can be called the host operating system) to communicate with the front-end driver and the accelerator card, for example, the back-end driver forwards the data processing request issued by the application to the accelerator card and returns the data processing response returned by the accelerator card to the application through the front-end driver.
  • the virtual machine manager is used to implement computing virtualization, network virtualization and storage virtualization of the virtual machine, and is responsible for managing the virtual machine.
  • the front-end driver and the back-end driver are respectively called the virtual IO device front-end and the virtual IO device back-end.
  • the front-end driver is referred to as virtio
  • the back-end driver is referred to as virtual host (vhost).
  • vhost virtual host
  • Virtual Function Unit A virtual peripheral component interconnect (PCI) device presented by the accelerator card through the single-root I/O virtualization (SR-IOV) technology.
  • PCI peripheral component interconnect
  • SR-IOV single-root I/O virtualization
  • an accelerator card can virtualize multiple virtual function units, and these multiple virtual function units share the physical resources in the accelerator card, among which physical resources include CPU resources and memory resources.
  • Thread Also known as a forwarding thread, it consumes the server's CPU resources and memory resources to transmit data processing requests issued by the application and data processing responses returned by the accelerator card between the backend driver and the accelerator card.
  • the computer device 100 is also called a host and can be configured as a server, such as a cloud server, a local server, or a server in a data center.
  • the computer device 100 is configured with at least one accelerator card 101, such as the accelerator cards 101a-101b in FIG. 1 .
  • the accelerator card 101 is configured as a physical hardware device at the hardware layer of the computer device 100.
  • the accelerator card 101 can be inserted into the computer device 100.
  • the types of the multiple accelerator cards 101 may be the same or different.
  • the computer device 100 shown in FIG1 includes two types of accelerator cards, QAT and MLX. It should be understood that the two types of accelerator cards 101 shown in FIG1 are examples and should not limit the types of accelerator cards 101 in the computer device 100.
  • the embodiment of the present application does not limit the number and type of accelerator cards 101 in the computer device 100.
  • each accelerator card 101 includes a plurality of virtual function units 110, and the virtual function units 110 in the same accelerator card 101 share the hardware resources in the accelerator card 101.
  • the accelerator card 101 also includes a plurality of queue pairs, each queue pair includes a second request queue and a second response queue, the second request queue is used to store the data processing request of the application, and the second response queue is used for the accelerator card 101 to respond to the data processing request in the first request queue.
  • the data processing request indicates that the data processing request indicates that the accelerator card 101 processes the target data.
  • the data processing request is a data encryption and decryption request indicating that the accelerator card 101 performs encryption or decoding processing on the target data
  • the data processing response includes the processing result of the target data in the data processing request.
  • the computer device 100 is also configured with multiple virtual machines 102, such as virtual machines 102a-102c in FIG. 1 , each virtual machine 102 runs at least one application, and the virtual machine 102 corresponds to at least one standard virtualized IO device model, and the front-end driver in the corresponding standard paravirtualized IO device model runs in the virtual machine 102, and the back-end driver runs in the operating system of the computer device 100.
  • the standard virtualized IO device model is configured with a first request queue and a first response queue, and the first request queue is used to store the data processing request sent by the application to the accelerator card 101.
  • the first response queue is used to store the data processing response of the accelerator card 101 to the data processing request.
  • the computer device 100 is further configured with a plurality of threads 103 , such as threads 103 a - 103 d in FIG. 1 .
  • the threads 103 are used for communication between the backend driver and the virtual function unit 110 .
  • the computer device 100 is further configured with a scheduler 104, and the scheduler 104 manages the communication units in the computer device 100, wherein the communication units in the computer device 100 include multiple different types of communication units such as an accelerator card 101, a virtual function unit 110, and a thread 103.
  • the scheduler 104 supports the pooling of virtual function units.
  • the scheduler 104 scans the virtual function units 110 of each accelerator card 101 in the computer device 100, and abstracts each scanned virtual function unit 110 as a physical forwarding port, obtains the port information of each physical forwarding port, and stores the port information of each physical forwarding port in a physical port pool (or virtual function pool), wherein the port information of each physical forwarding port includes the port identifier of the physical forwarding port and the accelerator card identifier of the accelerator card to which the physical forwarding port belongs.
  • the port information is the description information of the virtual function unit, and the port identifier in the port information is also the identifier of the virtual function unit.
  • the scheduler 104 is also used to establish a VF channel between the virtual machine 102 and the accelerator card 101, so that the application in the virtual machine 102 communicates with the accelerator card 101 through the VF channel.
  • the scheduler 104 configures at least one standard paravirtualized IO device model for each virtual machine 102, and for any standard paravirtualized IO device model configured for each virtual machine 102, at least one physical forwarding port is allocated to the virtualized IO device model from the physical port pool, thereby allocating a virtual function unit to the virtual machine to which the paravirtualized IO device model belongs.
  • a thread 103 is established between the back-end driver and the physical forwarding port in the standard paravirtualized IO device model, and the back-end driver is connected to the physical forwarding port through the thread 103, so that the virtualized IO device model, the thread 103 and the physical forwarding port constitute at least one VF channel of the virtual machine 102.
  • the scheduler 104 stores the channel information of each VF channel, wherein the channel information includes the model identifier of a standard virtualized IO device model, the thread identifier of a thread, and the port information of the physical forwarding port virtualized by a virtual function unit.
  • the model identifier in the channel information may also be replaced with a program identifier of a backend driver in the standard virtualized IO device model.
  • the scheduler 104 is also used to send the channel information of the VF channel where each thread 103 is located to each thread 103, so that each thread 103 forwards messages between the backend driver and the physical forwarding port of the corresponding VF channel according to the channel information.
  • the following is an introduction to the process of any virtual machine 102 communicating with any accelerator card 101 through the VF channel:
  • the application sends a data processing request to the front-end driver of any standard virtualized IO device model configured for the virtual machine 102.
  • the front-end driver receives a data processing request, it adds the data processing request to the first request queue of the back-end driver in the virtualized IO device model.
  • the first request queue is used to store the data processing requests of the application.
  • the thread 103 records the channel information of at least one VF channel provided by the scheduler 104.
  • the thread 103 reads the data processing request from the first request queue of the back-end driver according to the program identifier of the back-end driver in the channel information, and adds the program identifier in the data read request to indicate the source of the data read request. Afterwards, the thread 103 forwards the data processing request to the second request queue of the virtual function unit corresponding to the physical forwarding port according to the port information of the physical forwarding port in the channel information.
  • the accelerator card 101 reads the data processing request from the second request queue.
  • the accelerator card 101 processes the data processing request, processes the target data in the data processing request according to the hardware communication unit assigned to the virtual function, and obtains a data processing response.
  • the accelerator card 101 After adding the program identifier in the data processing request to the data processing response, the accelerator card 101 adds the data processing response to the second response request queue corresponding to the virtual function unit, wherein the processing process of the data processing request by the accelerator card 101 can also be understood as the process of the data processing request by the virtual function unit 110.
  • the thread 103 reads the data processing response from the second response queue of the corresponding virtual function unit according to the port information in the channel information of any VF channel recorded, and sends the data processing request to the first response queue of the corresponding back-end driver according to the program identifier in the data processing response.
  • the back-end driver sends the data processing request in the first response queue to the front-end driver corresponding to the back-end driver, and the front-end driver sends the data processing response to the application.
  • the application receives the data processing response of any data processing request, it means that each communication unit on the VF channel has completed processing the data processing request.
  • the scheduler 104 is also used to allocate a virtual function unit 110, a thread 103, and at least one communication unit of the acceleration card 101 to the virtual machine 102 by executing the virtual machine scheduling method proposed in the present application, and schedule the virtual machine 102 to the allocated communication unit so that the virtual machine 102 can communicate with the allocated communication unit.
  • the scheduler 104 introduced above is implemented by software, hardware or a combination of software and hardware.
  • the scheduler 104 includes code running on a computing instance.
  • the computing instance includes at least one of a virtual machine and a container.
  • the above computing instance can be one or more.
  • the scheduler 104 includes code running on multiple virtual machines/containers.
  • the multiple virtual machines 102/containers used to run the code may be distributed in the same region (region) or in different regions.
  • the multiple virtual machines/containers used to run the code may be distributed in the same availability zone (AZ) or in different AZs, each AZ including one data center or multiple data centers with close geographical locations. Among them, usually a region can include multiple AZs.
  • VPC virtual private cloud
  • a VPC is set in a region, and cross-region communication between two VPCs in the same region and between VPCs in different regions requires a communication gateway to be set in each VPC, and interconnection between VPCs is achieved through the communication gateway.
  • the scheduler 104 may be a device implemented by an application-specific integrated circuit (ASIC) or a programmable logic device (PLD).
  • the PLD may be a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), a data processing unit (DPU), a system on chip (SoC), or any combination thereof.
  • CPLD complex programmable logical device
  • FPGA field-programmable gate array
  • GAL generic array logic
  • DPU data processing unit
  • SoC system on chip
  • Figure 2 is a flowchart of a virtual machine scheduling method provided in an embodiment of the present application.
  • the method is applied to a computer device, which is configured with at least one accelerator card, multiple virtual machines and multiple threads.
  • the accelerator card includes multiple virtual function units.
  • the virtual machine communicates with at least one virtual function unit through at least one thread.
  • the method is executed by a scheduler in the computer device, and the method includes the following steps.
  • a scheduler obtains a load of at least one communication unit of the computer device, where the communication unit is a virtual function unit, a thread, or an accelerator card, and the load of the communication unit is related to the multiple virtual machines.
  • the computer device has at least three types of communication units, namely, virtual function units, threads, and accelerator cards.
  • the at least one communication unit includes at least one of the three types of communication units.
  • the load of the at least one communication unit includes the load of each virtual function unit in at least one accelerator card in the computer device.
  • the communication unit is the thread
  • the load of the at least one communication unit includes the load of the multiple threads.
  • the load of the at least one communication unit includes the load of the at least one accelerator card.
  • the load of any virtual function unit is the sum of the load provided by at least one virtual machine to the virtual function unit during the target duration, wherein the at least one virtual machine is a virtual machine that communicates with the virtual function unit during the target duration, and the load provided by any virtual machine to the virtual function unit is equal to the number of standard virtualized IO device models between the any virtual machine and the virtual function unit. For example, if a virtual machine communicates with the virtual function unit through 2 standard virtualized IO device models, the load provided by the virtual machine to the virtual function unit is 2.
  • the target duration can be set according to the specific implementation scenario. Here, the embodiment of the present application does not limit the target duration.
  • the load of any backend driver is the number of data processing requests processed by the backend driver per unit time.
  • the unit time is, for example, 1 second.
  • the load of any backend driver is the number of input/output operations per second (IOPS) of the backend driver.
  • IOPS input/output operations per second
  • the length of the unit time may also have other values.
  • the embodiment of the present application does not limit the length of the unit time.
  • the load of any thread is the sum of the loads of the backend drivers that communicate with the thread during the target duration.
  • the load of any accelerator card is the sum of the loads provided to the accelerator card by at least one virtual machine during the target duration, wherein the at least one virtual machine is a virtual machine that communicates with the virtual function unit in the accelerator card during the target duration.
  • the load provided by any virtual machine to the virtual function unit of the accelerator card is equal to the sum of the loads of at least one backend driver corresponding to the virtual machine and communicating with the accelerator card. If the virtual machine communicates with the virtual function unit of the accelerator card through one backend driver during the target duration, the load provided by the virtual machine to the virtual function unit of the accelerator card is the load of the backend driver; if the virtual machine communicates with the virtual function unit of the accelerator card through multiple backend drivers during the target duration, the load provided by the virtual machine to the virtual function unit of the accelerator card is the sum of the loads of the multiple backend drivers.
  • the scheduler is configured with at least one of the following seven scheduling strategies, each of which corresponds to a communication unit of a computer device, to indicate that corresponding communication units are allocated to some virtual machines in the computer device based on the load of the corresponding communication unit, and these virtual machines are scheduled to the allocated communication units so that these virtual machines can communicate with the allocated communication units. Based on this, the scheduler obtains the load of the communication unit corresponding to the at least one scheduling strategy at each target interval based on the configured at least one scheduling strategy. The process is described as follows in combination with these seven scheduling strategies:
  • Scheduling strategy 1 Scheduling virtual machines across virtual function units
  • the communication unit corresponding to scheduling strategy 1 is a virtual function unit, and scheduling strategy 1 indicates that based on the load of the virtual function unit of the computer device, virtual function units are allocated to some virtual machines in the computer device, and these virtual machines are scheduled to the allocated virtual function units.
  • the scheduler is configured to schedule virtual machines using scheduling strategy 1, when executing this step 201, the scheduler counts the load of each virtual function unit in the computer device every time the target time passes. This process is described in detail in step 301 and will not be repeated here. Since each virtual function unit corresponds to a physical forwarding port, scheduling virtual machines across virtual function units is also scheduling virtual machines across physical forwarding ports.
  • Scheduling strategy 2 cross-thread forwarding scheduling virtual machine
  • the communication unit corresponding to scheduling strategy 2 is a thread
  • scheduling strategy 2 indicates that based on the load of the thread in the computer device, threads are allocated to some virtual machines in the computer device, and these virtual machines are scheduled to the allocated threads.
  • the scheduler when executing this step 201, the scheduler counts the load of each thread in the computer device every time the target time passes. This process is described in detail in step 501 and will not be repeated here.
  • Scheduling strategy 3 Scheduling virtual machines by dynamically adding threads
  • the communication unit corresponding to scheduling strategy 3 is a thread
  • scheduling strategy 3 indicates that based on the load of the thread in the computer device, threads are added to some virtual machines in the computer device to achieve the allocation of threads to these virtual function units, and these virtual machines are scheduled to the allocated threads.
  • the scheduler when executing this step 201, the scheduler counts the load of each thread in the computer device every time the target time passes. This process is described in detail in step 501 and will not be repeated here.
  • scheduling strategy 3 is used to add threads to some virtual machines in the computer device every time a target duration has passed. After multiple target durations have passed, dynamic addition of threads is achieved.
  • Scheduling strategy 4 Dynamically reduce thread scheduling virtual machines
  • the communication unit corresponding to scheduling strategy 4 is a thread
  • scheduling strategy 4 indicates that based on the load of the thread in the computer device, threads are reduced for some virtual machines in the computer device to achieve the allocation of threads to these virtual function units.
  • the scheduler when executing this step 201, the scheduler counts the load of each thread in the computer device every time the target time passes. This process is described in detail in step 501 and will not be repeated here.
  • scheduling strategy 4 is used to reduce threads for some virtual machines in the computer device every time a target time has passed. After multiple target time periods have passed, dynamic thread reduction is achieved.
  • Scheduling strategy 5 Scheduling virtual machines across accelerator cards
  • the communication unit corresponding to scheduling strategy 5 is an accelerator card
  • scheduling strategy 5 indicates that based on the load of the accelerator card in the computer device, accelerator cards are allocated to some virtual machines in the computer device, and these virtual machines are scheduled to the allocated accelerator cards.
  • the scheduler is configured to schedule virtual machines using scheduling strategy 5, when executing this step 201, the scheduler counts the load of each accelerator card in the computer device every time the target time passes. This process is described in detail in step 1101 and will not be repeated here.
  • Scheduling strategy 6 Scheduling virtual machines by dynamically adding accelerator cards
  • the communication unit corresponding to scheduling strategy 6 is an accelerator card
  • scheduling strategy 6 indicates that based on the load of the accelerator card in the computer device, by adding accelerator cards to some virtual machines in the computer device, acceleration is allocated to these virtual function units, and these virtual machines are scheduled to the allocated accelerator cards.
  • the scheduler is configured to schedule virtual machines using scheduling strategy 6, when executing this step 201, the scheduler counts the load of each accelerator card in the computer device every time the target time passes. This process is described in detail in step 1101 and will not be repeated here.
  • scheduling strategy 6 is used to add accelerator cards to some virtual machines in the computer device every time a target duration has passed. After multiple target durations have passed, dynamic addition of accelerator cards is achieved.
  • Scheduling strategy 7 Dynamically reduce the number of accelerator cards to schedule virtual machines
  • the communication unit corresponding to scheduling strategy 7 is an accelerator card
  • scheduling strategy 7 indicates that based on the load of the accelerator card in the computer device, by reducing the accelerator card for some virtual machines in the computer device, the accelerator card is allocated to these virtual function units.
  • the scheduler is configured to schedule virtual machines using scheduling strategy 7, when executing this step 201, the scheduler counts the load of each accelerator card in the computer device every time the target time passes. This process is described in detail in step 1101 and will not be repeated here.
  • scheduling strategy 7 is used to reduce accelerator cards for some virtual machines in the computer device every time a target time has passed. After multiple target time periods have passed, dynamic reduction of accelerator cards is achieved.
  • the scheduler allocates a target communication unit to a target virtual machine in the at least one accelerator card based on the load of the at least one communication unit, where the target communication unit is a virtual function unit, a thread, or an accelerator card.
  • the target virtual machine is the virtual machine to be scheduled this time
  • the target communication unit is the communication unit allocated to the target virtual machine this time.
  • the scheduler schedules the target virtual machine in different ways based on different scheduling strategies.
  • the execution process of this step 202 under different scheduling strategies will be described in detail later in conjunction with Figures 3-16, and will not be repeated here.
  • the scheduler schedules the target virtual machine to the target communication unit, so that the target virtual machine can communicate with the target communication unit.
  • the scheduler generates target channel information of a target VF channel based on the target virtual machine and the target communication unit.
  • the target VF channel is used to connect the target communication unit of the target virtual machine.
  • the target VF channel includes a backend driver corresponding to the target virtual machine, the target thread, and a target physical forwarding port.
  • the target communication unit is a virtual function unit (i.e., a target virtual function unit) corresponding to the target thread and the target physical forwarding port, or an accelerator card (i.e., a target accelerator card) to which the target virtual function unit belongs.
  • the scheduler sends the target channel information to the target thread in the target VF channel, so that the target thread establishes a target VF channel between the target virtual function unit and the target virtual machine based on the target channel information, so as to schedule the target virtual machine to the target communication unit, so that the target virtual machine can communicate with the target communication unit through the target VF channel.
  • the target thread forwards messages between the backend driver corresponding to the target virtual machine and the target virtual function unit for the target VF channel, so that the target virtual machine can communicate with each part in the target VF channel and the target virtual function unit.
  • communication with the target accelerator card is also achieved.
  • the method provided in the embodiment of the present application allocates a target communication unit to a target virtual machine in a computer device based on the virtual function units, threads of the computer device and the load of at least one communication unit in an accelerator card, and schedules the target virtual machine to the allocated target communication unit so that the target virtual machine can communicate with the target communication unit. Since the target communication unit can be allocated to the target virtual machine based on the load of at least one communication unit, the virtual function unit that communicates with the target virtual machine is not fixed, and there is no need to bind the target virtual machine to a fixed virtual function unit. As the target virtual machine is scheduled between different communication units of the accelerator card, the target virtual machine can flexibly communicate with different virtual function units, thereby improving the flexibility of the communication method between the virtual machine and the accelerator card.
  • Figure 3 is a flow chart of a scheduling method for a virtual machine based on scheduling strategy 1 provided in an embodiment of the present application.
  • the method is applied to a computer device configured with at least one accelerator card, multiple virtual machines and multiple threads.
  • the accelerator card includes multiple virtual function units.
  • the virtual machine communicates with at least one virtual function unit through at least one thread.
  • the method is executed by a scheduler in the computer device. The method includes the following steps.
  • a scheduler obtains a load of each virtual function unit in at least one accelerator card of a computer device, where the load is related to the multiple virtual machines in the computer device.
  • the load of each virtual function unit in the at least one accelerator card is the communication load of the virtual function unit in the computer device.
  • the load of the unit is the communication load of the virtual function unit in the computer device.
  • the scheduler When the scheduler is configured to schedule virtual machines using scheduling strategy 1, for each virtual function unit in the computer device, the scheduler counts the number of back-end drivers that communicate with the virtual function unit during the target duration every time a target duration elapses, and uses the number as the load of the virtual function unit.
  • the scheduler determines a first virtual function unit and a second virtual function unit based on the load of each virtual function unit in the at least one accelerator card, wherein the first virtual function unit is the virtual function unit with the largest load in the at least one accelerator card, and the second virtual function unit is the virtual function unit with the smallest load in the at least one accelerator card.
  • the first virtual function unit and the second virtual function unit are respectively the maximum load virtual function unit and the minimum load virtual function unit in the at least one acceleration card in the target duration.
  • the first virtual function unit and the second virtual function unit may belong to the same acceleration card or may belong to different acceleration cards.
  • the virtual function unit with the largest load in the at least one accelerator card is determined as the first virtual function unit, and the virtual function unit with the smallest load in the at least one accelerator card is determined as the second virtual function unit.
  • the scheduler allocates the second virtual function unit to a target virtual machine in at least one first virtual machine, where the first virtual machine is a virtual machine in the multiple virtual machines that communicates with the first virtual function unit.
  • the first load difference is the difference between the load of the first virtual function unit and the load of the second virtual function unit.
  • the first threshold is greater than 0, and the first threshold can be set according to the specific implementation scenario.
  • the embodiment of the present application does not limit the value of the first threshold.
  • the at least one first virtual machine is all virtual machines that communicate with the first virtual function unit, and the second virtual function unit is the target virtual function unit allocated to the target virtual machine this time.
  • the computer device shown in Figure 4 is configured with an acceleration card 400, virtual machines 410-420 and thread 1. Before scheduling, it is assumed that the virtual function unit 401 in the acceleration card 400 is the first virtual function unit, and the virtual function unit 401 communicates with the virtual machines 410-420 through thread 1, then the virtual machines 410-420 are the first virtual machines.
  • the scheduler subtracts the load of the first virtual function unit from the load of the second virtual function unit to obtain a first load difference. If the first load difference is greater than or equal to a first threshold, the first virtual power unit and the second virtual function unit meet the scheduling conditions, triggering the allocation of the second virtual function unit to some of the at least one first virtual machine, so that these virtual machines can be subsequently scheduled to the second virtual function unit to reduce the load of the first virtual function unit.
  • the scheduler Before allocating the second virtual function unit to the plurality of virtual machines, the scheduler queries the first VF channel where the physical forwarding port corresponding to the first virtual function unit is located within the target duration, and takes the virtual machine connected to each first VF channel as the first virtual machine to determine at least one first virtual machine associated with the first virtual function unit.
  • the virtual machine connected to any VF channel is the virtual machine corresponding to the backend driver in the VF channel.
  • the scheduler After determining at least one first virtual machine, the scheduler selects a target virtual machine from the at least one first virtual machine, and the scheduler allocates the second virtual function unit to the target virtual machine.
  • the scheduler selects the target virtual machine in any of the following ways 1 or 2.
  • Method 1 The resource scheduler determines a first number based on a first load difference, determines a plurality of first back-end drivers corresponding to the at least one virtual machine based on a first virtual function unit, determines a first back-end driver of a first number among the plurality of first back-end drivers as a target back-end driver, and the first virtual machine to which the target back-end driver belongs is a target virtual machine.
  • the first number is the number of target backend drivers to be scheduled, and the difference between the first number and the first load difference of 1/2 is less than or equal to 1. If the first load difference of 1/2 is an integer, the scheduler uses the integer as the first number. If the first load difference of 1/2 is not an integer, a value that is 1 greater or less than the integer of the first load difference of 1/2 is used as the first number. For example, if the first load difference of 1/2 is 3.2, 2 or 4 is used as the first number.
  • the multiple first backend drivers are backend drivers between the at least one first virtual machine and the first virtual machine function unit, and each first virtual machine communicates with the first virtual machine function unit through at least one first backend driver.
  • the load of the virtual function unit 402 is 0, and the first load difference between the virtual function unit 401 and the virtual function unit 402 is 2.
  • the first threshold is 2
  • the first load difference between the virtual function unit 401 and the virtual function unit 402 is greater than or equal to 2.
  • the scheduler uses 1 as the first number, the backend driver corresponding to the virtual function unit 402 as the target backend driver, and the virtual machine 420 as the target virtual machine to be scheduled, and allocates the virtual function unit 402 to the virtual machine 420 and the virtual function unit 402 corresponds to the backend driver.
  • the difference between the first number and 1/2 of the first load difference is less than or equal to 1, even if the target back-end driver of the first number is assigned to the second virtual function unit, after the target back-end driver is scheduled from the first virtual function unit to the second virtual function unit, the difference between the load of the second virtual function unit and the first virtual function unit is less than or equal to 1, so that the scheduled second virtual function unit and the first virtual function unit achieve load balance.
  • Method 2 The resource scheduler randomly selects a second number of first backend drivers from the multiple first backend drivers as the target backend drivers, wherein the second number is a preset number.
  • the embodiment of the present application does not limit the second number.
  • the VF channel between the target backend driver and the first virtual function unit is the source VF channel of the target backend driver
  • the channel information of the source VF channel is the source VF channel
  • the thread in the source VF channel is the source thread of the backend driver
  • the physical forwarding port corresponding to the first virtual function unit in the source VF channel is the source physical forwarding port
  • the port information of the source physical forwarding port is the source port information
  • the physical forwarding port corresponding to the second virtual function unit is the target physical forwarding port
  • the port information of the target physical forwarding port is the target port information
  • the scheduler queries the source channel information of the target backend driver, replaces the source port information in the queried source channel information with the target port information, obtains the target channel information, and allocates the second virtual function unit to the target virtual machine to which the target backend driver belongs, that is, allocates the second virtual function unit to the target virtual machine to which the target backend driver belongs.
  • step 302 to step 303 is an implementation of step 202 .
  • the scheduler schedules the target virtual machine to the second virtual function unit, so that the target virtual machine can communicate with the second virtual function unit.
  • the target channel information of the target backend driver is obtained.
  • the scheduler sends a channel information update request to the source thread where the target backend driver is located based on the thread identifier in the target channel information.
  • the channel information update request indicates that the source channel information of the target backend driver is updated to the target channel information.
  • the source thread updates the stored source channel information to the target channel information based on the channel information update request.
  • a target VF channel is established to schedule the target backend driver to the second virtual function unit.
  • the target VF channel includes the target backend driver, the source thread, and the target physical forwarding port.
  • the source thread is the target thread for the target virtual machine to which the target backend driver belongs.
  • the source thread also deletes the source VF channel where the target backend driver is located.
  • the target backend driver is scheduled from the first virtual function unit to the second virtual function unit, that is, the target virtual machine to which the target backend driver belongs is scheduled from the first virtual function unit to the second virtual function unit.
  • the physical forwarding port A and thread 1 are the source physical forwarding port and source thread of the virtual machine 420 respectively, and thread 1 deletes the source VF channel 403 between the physical forwarding port A and the virtual machine 420, and establishes the target VF channel 404 between the virtual machine 402 and the physical forwarding port B, thereby scheduling the virtual machine 420 from the virtual function unit 401 to the virtual function unit 420, and realizing the cross-virtual function unit scheduling of the virtual machine 420 from the source virtual function unit (i.e., the virtual function unit 401) to the destination virtual function unit (i.e., the virtual function unit 420).
  • the source virtual function unit i.e., the virtual function unit 401
  • the destination virtual function unit i.e., the virtual function unit 420
  • the scheduler establishes a target thread for the target back-end driver and sends target channel information to the target thread.
  • the target channel information includes the program identifier of the target back-end driver, the thread identifier of the target thread, and the port information of the target physical forwarding port corresponding to the second virtual function unit.
  • the target thread establishes a target VF channel based on the target channel information to schedule the target back-end driver to the second virtual function unit.
  • the target VF channel includes the target back-end driver, the source thread, and the target physical forwarding port.
  • the target thread in the target VF channel forwards messages between the target backend driver and the second virtual function unit, so that the target virtual machine communicates with the second virtual function unit through the target VF channel.
  • the above is introduced by taking the example of scheduling some back-end drivers on the maximum load virtual function unit in the computer device to the minimum load virtual function unit. Every time the target duration passes, the scheduler executes the scheduling process shown in steps 301 to 304. After multiple target durations, the scheduler completes multiple scheduling processes, so that the load of each virtual function unit in the computer device is balanced.
  • the scheduler may also schedule some virtual machines on the second largest load virtual function unit in the computer device to the second smallest load virtual function unit, or schedule some virtual machines on the second largest load virtual function unit in the computer device to the second smallest load virtual function unit.
  • the sequential scheduling process can schedule virtual machines on multiple virtual function units to reduce the number of scheduling times before the load of each virtual function unit in the computer device reaches a balance.
  • the method embodiment shown in Figure 3 can achieve the beneficial effects of the method embodiment shown in Figure 2, and because the virtual function units in the same accelerator card share the hardware resources of the entire card, the efficiency of a single data processing request processed by each virtual machine function unit is similar, but the more back-end drivers that communicate with the first virtual machine function unit, the longer the waiting time for the data processing request of each back-end driver will be.
  • the method embodiment shown in Figure 3 schedules the target virtual machine that communicates with the first virtual machine function unit to the second virtual function unit to avoid the subsequent target virtual machine's data processing requests queuing in the first virtual function unit for a long time waiting for processing, thereby improving the data processing efficiency of the target virtual machine and reducing the load on the first virtual function unit.
  • Figure 5 is a flow chart of a scheduling method for a virtual machine based on scheduling strategy 2 provided in an embodiment of the present application.
  • the method is applied to a computer device, which is configured with at least one accelerator card, multiple virtual machines and multiple threads.
  • the accelerator card includes multiple virtual function units.
  • the virtual machine communicates with at least one virtual function unit through at least one thread.
  • the method is executed by a scheduler in the computer device, and the method includes the following steps.
  • a scheduler obtains a load of the multiple threads in a computer device, where the load is related to the multiple virtual machines in the computer device.
  • the load of any thread is the sum of the loads of the backend drivers that communicate with the thread during the target duration.
  • the scheduler When the scheduler is configured to schedule the virtual machine using the scheduling strategy 2, the scheduler counts the load of each of the multiple threads every time the target time passes.
  • the scheduler queries at least one VF channel where the thread is located, obtains the load of the back-end driver in the at least one VF channel within the target duration, and takes the sum of the loads of the back-end drivers in the at least one VF channel as the load of the thread.
  • the back-end driver in the at least one VF channel is also the back-end driver that communicates with the thread.
  • step 501 is an implementation of step 201 .
  • the scheduler determines a first thread and a second thread based on the loads of the multiple threads, wherein the first thread is a thread with the largest load among the multiple threads, and the second thread is a thread with the smallest load among the multiple threads.
  • the first thread is the maximum load thread among the multiple threads of the computer device in the target duration.
  • the second thread is the minimum load thread among the multiple threads of the computer device in the target duration, and the second thread is the target thread allocated to the target virtual machine to be scheduled this time.
  • the thread with the largest load among the multiple threads is determined as the first thread, and the thread with the smallest load among the multiple threads is determined as the second thread.
  • the scheduler allocates the second thread to a target virtual machine in at least one second virtual machine
  • the third virtual function unit is a virtual function unit in the at least one acceleration card that communicates with the second thread
  • the second virtual machine is a virtual machine in the multiple virtual machines that communicates with the first thread.
  • the at least one second virtual machine is all virtual machines that communicate with the first thread.
  • the computer device shown in Figure 6 is configured with an acceleration card 600, virtual machines 610-630 and threads 1-2.
  • thread 1 is the first thread and thread 2 is the second thread
  • thread 1 communicates with virtual machines 610 and 630
  • virtual machines 610 and 630 are both second virtual machines.
  • the scheduler queries multiple second VF channels where the first thread is located within the target duration, and uses the virtual machine connected to each second VF channel as the second virtual machine, wherein the multiple second VF channels may be connected to multiple second virtual machines or may be connected to one second virtual machine.
  • the second thread is triggered to be allocated to some of the at least one second virtual machine, so that these virtual machines are subsequently scheduled to the second thread to reduce the load of the first thread.
  • the scheduler refers to the backend drivers in the multiple second VF channels as second backend drivers, and each second VF channel has a second backend driver. Then, the multiple second VF channels have multiple second backend drivers, and the multiple second backend drivers are also the backend drivers that communicate with the first thread during the target duration.
  • the scheduler selects the third number of second backend drivers from the multiple second backend drivers as the target backend driver to be scheduled this time, and allocates a second thread to the target backend driver, wherein the second virtual machine to which the target backend driver belongs is also the target virtual machine, and allocating the second thread to the target backend driver is to allocate the second thread to the target virtual machine.
  • the third number is a preset number, and the third number is not limited in the embodiment of the present application.
  • the second thread is allocated to a target virtual machine in at least one second virtual machine through the process shown in the following steps 5031-5032.
  • Step 5031 For the first candidate virtual machine among the at least one second virtual machine, the scheduler predicts the load of the first thread and the load of the second thread based on the first total load provided by the first candidate virtual machine for the first thread, the load of the first thread, and the load of the second thread to obtain a first predicted load and a second predicted load.
  • the first candidate virtual machine is a candidate for the target virtual machine in at least one second virtual machine
  • the first total load is the sum of the loads provided by each first candidate virtual machine for the first thread
  • the load provided by any first candidate virtual machine for the first thread is the total load of at least one second backend driver between the first candidate virtual machine and the first thread.
  • the first predicted load is the load of the first thread after the first candidate virtual machine is scheduled to the second thread
  • the second predicted load is the load of the second thread after the first candidate virtual machine is scheduled to the second thread.
  • the scheduler sorts the loads of the m second back-end drivers in order from small to large to obtain a first load sequence, and takes the second virtual machine corresponding to the second back-end drivers to which the first i loads in the first load sequence belong as the first candidate virtual machine.
  • the first i loads are summed to obtain a first total load, where i is an integer greater than or equal to 1 and less than m, and m is an integer greater than 1.
  • the scheduler uses the difference between the load of the first thread and the first total load as the first predicted load, and uses the sum of the load of the second thread and the first total load as the second predicted load.
  • the first predicted load indicates the load of the first thread after the i second backend drivers to which the first i loads belong are scheduled to the second thread, which can also be understood as the load of the first thread after the first i second backend drivers are transferred away from the first thread.
  • the second predicted load indicates the load of the second thread after the first i second backend drivers are scheduled to the first thread. Since each backend driver belongs to only one virtual machine, scheduling the i second backend drivers from the first thread to the second thread means scheduling the first candidate virtual machine to which the i second backend drivers belong from the first thread to the second thread.
  • Step 5032 If the absolute value of the difference between the first predicted load and the second predicted load is less than or equal to the second threshold, the scheduler allocates the second thread to the first candidate virtual machine.
  • the second threshold is greater than 0, and the second threshold can be set according to the specific implementation scenario.
  • the embodiment of the present application does not limit the second threshold.
  • the scheduler will assign the second thread to the i second backend drivers to which the first i loads belong.
  • the i second backend drivers are also the target backend drivers to be scheduled this time
  • the second virtual machines i.e., the first candidate virtual machines
  • the load of the first thread reaches the first predicted load
  • the load of the second thread reaches the second predicted load. Since the absolute value of the difference between the first predicted load and the second predicted load is less than the second threshold, the first thread and the second thread after scheduling are load balanced.
  • the scheduler When the absolute value of the difference between the first predicted load and the second predicted load is greater than the second threshold, the scheduler sums the first i+1 loads in the first load sequence to obtain a new first total load, and executes steps 5031-5032 based on the new first total load until multiple loads are found such that the absolute value of the difference between the first predicted load and the second predicted load is less than or equal to the second threshold. This situation is further explained below based on the following formula (1).
  • the scheduler makes i judgments on the above formula (1) based on the load of the first thread, the load of the second thread and the first load sequence.
  • the scheduler takes the second virtual machine corresponding to the second backend driver to which the first i loads in the first load sequence belong as the first candidate virtual machine, and inputs the load of the first thread, the load of the second thread and the first i loads into formula (1). If formula (1) is not true, the i-th judgment process ends and enters the i+1-th judgment process. If formula (1) is true, the judgment of formula (1) ends.
  • the scheduler takes the second backend driver to which the first i loads belong as the target backend driver and the first candidate virtual machine as the target virtual machine, and allocates the second thread to the i backend drivers to achieve the allocation of the second thread to the target virtual machine.
  • the scheduler selects at least one target virtual function unit (i.e., the third virtual function unit) from at least one virtual function unit communicating with the second thread.
  • the function unit generates at least one target channel information based on the target backend driver, the second thread and at least one target virtual function unit to allocate the second thread to the target backend driver.
  • Each target channel information includes a program identifier of the target backend driver, a thread identifier of the second thread and target port information of a target physical forwarding port corresponding to a target virtual function unit.
  • the second thread is also the target thread.
  • Thread 1 is the first thread and thread 2 is the second thread.
  • Thread 1 communicates with virtual function units 601 and 602 in the acceleration card 600.
  • the backend driver corresponding to virtual machine 610 provides a load of 2M IOPS for thread 1
  • the backend driver corresponding to virtual machine 630 provides a load of 1M IOPS for thread 1. If it is predicted that threads 1 and 2 will achieve load balance after the backend driver corresponding to virtual machine 630 is scheduled to thread 2, the scheduler will assign the virtual function unit 603 served by thread 2 to the backend driver corresponding to virtual machine 630.
  • steps 502 - 503 is an implementation of step 202 .
  • the scheduler schedules the target virtual machine to the second thread, so that the target virtual machine can communicate with the second thread.
  • the target channel information of the target backend driver is obtained.
  • the scheduler sends a channel establishment request to the target thread (i.e., the second thread) based on the thread identifier in the target channel information.
  • the channel establishment request instructs the target thread to establish a target VF channel according to the target channel information.
  • the target thread establishes a target VF channel according to the target channel information storage request to schedule the target backend driver to the second thread.
  • the target VF channel includes the target backend driver, the target thread, and the target physical forwarding port.
  • the target thread also stores the target channel information so that the target thread can perform message forwarding between the target backend driver and the target virtual function unit according to the target channel information later, so that the target backend driver corresponds to the target virtual machine through the target VF channel and the target thread.
  • the scheduler also sends a channel deletion request to the source thread (i.e., the first thread) of the target back-end driver, and the channel deletion request indicates the deletion of the source VF channel where the target back-end driver is located.
  • the source thread After receiving the channel deletion request, the source thread deletes the source VF channel and the source channel information of the source VF channel to prevent subsequent source threads from continuing to communicate on the source VF channel according to the source channel information.
  • the above is introduced by taking the example of scheduling some virtual machines on the maximum load thread in the computer device to the minimum load thread. Every time the target duration passes, the scheduler executes the scheduling process shown in steps 501-504. After multiple target durations, the scheduler completes multiple scheduling processes, so that the load of each thread in the computer device is balanced.
  • the scheduler may also schedule some virtual machines on the second largest load thread in the computer device to the second smallest load thread, or schedule some virtual machines on the second largest load thread in the computer device to the second smallest load thread.
  • the scheduling methods of these two scheduling methods can refer to the above steps 502-503.
  • the scheduling process can schedule virtual machines on multiple threads in sequence to reduce the number of scheduling times before the load of each thread in the computer device is balanced.
  • the method embodiment shown in Figure 5 can achieve the beneficial effects of the method embodiment shown in Figure 2.
  • the data processing request of the second virtual machine may be waiting to be forwarded by the first thread.
  • the method embodiment shown in Figure 5 schedules the target virtual machine in at least one second virtual machine to the second thread to avoid the subsequent data processing requests of the target virtual machine waiting in line for processing in the first thread for a long time, thereby improving the data processing efficiency of the target virtual machine, reducing the load of the first thread, improving the processing efficiency of the first thread, and enabling the resources provided by the second thread to be fully utilized, thereby avoiding waste of resources of the second thread.
  • Figure 7 is a flow chart of a scheduling method for a virtual machine based on scheduling strategy 3 provided in an embodiment of the present application.
  • the method is applied to a computer device, which is configured with at least one accelerator card, multiple virtual machines and multiple threads.
  • the accelerator card includes multiple virtual function units.
  • the virtual machine communicates with at least one virtual function unit through at least one thread.
  • the method is executed by a scheduler in the computer device, and the method includes the following steps.
  • a scheduler obtains a load of multiple threads in a computer device, where the load is related to the multiple virtual machines in the computer device.
  • this step 701 is the same as step 501, and here, the embodiment of the present application will not repeat this step 701.
  • the scheduler determines a third thread and a fourth thread from the multiple threads based on the loads of the multiple threads, the load of the third thread is greater than or equal to a third threshold, and the load of the fourth thread is less than the load of the third thread.
  • the third threshold is greater than 0, and the value of the third threshold can be set according to the specific implementation scenario.
  • the embodiment of the present application sets the third threshold.
  • the third threshold is not limited. There is at least one third thread among the multiple threads, and the fourth thread is a target thread allocated to the target virtual machine to be scheduled this time, and there is at least one fourth thread.
  • the loads of the n threads are sorted in order from small to large or from large to small to obtain a second load sequence, and each thread in the second load sequence whose load is greater than a third threshold is used as a third thread.
  • the first thread is used as the third thread.
  • the scheduler selects at least one target load from these remaining loads, and uses the thread to which the at least one selected target load belongs as the fourth thread.
  • the remaining load of the third number with the smallest load is selected from these remaining loads, and the third number is 2.
  • the target load selected is the smallest 2 loads among the loads of n threads.
  • the fourth thread at this time is the second thread among the n threads.
  • the third number is a preset number, and the third number can be set according to the specific implementation scenario.
  • the scheduler does not set the third number, does not select the second thread through the third number, but uses the thread with the smallest load among multiple threads as the fourth thread.
  • the scheduler may ultimately determine that there may be at least one third thread and at least one fourth thread.
  • the following introduction is made using one third thread and one fourth thread as an example.
  • the scheduling method when there is one third thread and one fourth thread may be referred to.
  • the scheduler allocates the fourth thread to a target virtual machine in at least one third virtual machine.
  • the at least one third virtual machine is all virtual machines that communicate with the third thread.
  • the computer device shown in Figure 8 is configured with an acceleration card 800, virtual machines 810-820 and thread 1.
  • thread 1 is the third thread, and thread 1 communicates with virtual function units 801 and 802 in the acceleration card 800, then virtual function units 801 and 802 are both third virtual machines.
  • the scheduler queries multiple third VF channels where the third thread is located within the target duration, and uses the virtual machine connected to each third VF channel as the third virtual machine.
  • the multiple third VF channels may be connected to multiple third virtual machines, or may be connected to one third virtual machine.
  • the fourth thread is triggered to be allocated to some of the at least one third virtual machine, so that these virtual machines are subsequently scheduled to the fourth thread to reduce the load of the third thread.
  • the scheduler refers to the backend drivers in the multiple third VF channels as the third backend drivers, and each second VF channel has a third backend driver, so the multiple second VF channels have multiple third backend drivers, and the multiple third backend drivers are also the backend drivers that communicate with the third thread during the target duration.
  • the scheduler selects a fourth number of third backend drivers from the multiple third backend drivers as the target backend drivers to be scheduled this time, and allocates a fourth thread to the target backend driver, wherein the third virtual machine to which the target backend driver belongs is also the target virtual machine, and allocating the fourth thread to the target backend driver is to allocate the fourth thread to the target virtual machine.
  • the fourth number is a preset number, and the fourth number is not limited in the embodiment of the present application.
  • the fourth virtual function unit is allocated to at least one second virtual machine among the plurality of second virtual machines through the process shown in the following steps 7031 to 7032 .
  • Step 7031 For the second candidate virtual machine among the at least one third virtual machine, the scheduler predicts the load of the third thread and the load of the fourth thread based on the second total load provided by the second candidate virtual machine for the third thread, the load of the third thread, and the load of the fourth thread, to obtain a third predicted load and a fourth predicted load.
  • the second total load is the sum of the loads provided by the at least one third virtual machine for the third thread, and the load provided by any third virtual machine for the third thread is the total load of at least one backend driver between the third virtual machine and the first thread.
  • the third predicted load is the load of the third thread after the second candidate virtual machine is scheduled to the fourth virtual function unit
  • the fourth predicted load is the load of the fourth thread after the second candidate virtual machine is scheduled to the fourth virtual function unit.
  • the scheduler sorts the loads of the p third back-end drivers in order from small to large to obtain a third load sequence, and takes the third virtual machine corresponding to the third back-end drivers to which the first j loads in the third load sequence belong as the second candidate virtual machine.
  • the first j loads are summed to obtain the second total load, where j is an integer greater than or equal to 1 and less than p, and p is an integer greater than 1.
  • the scheduler uses the difference between the load of the third thread and the second total load as the third predicted load, and uses the sum of the load of the fourth thread and the second total load as the fourth predicted load.
  • the third predicted load indicates the load of the third thread after the j third backend drivers to which the first j loads belong are scheduled to the fourth thread. It can also be understood as the load of the third thread after the j third backend drivers are transferred away from the third thread.
  • the second predicted load indicates that the j third backend drivers are scheduled to the fourth thread. Since each backend driver belongs to only one virtual machine, the j third backend drivers are scheduled from the third thread to the fourth thread, that is, the second candidate virtual machines to which the j third backend drivers belong are scheduled from the third thread to the fourth thread.
  • Step 7032 If the absolute value of the difference between the third predicted load and the fourth predicted load is less than or equal to a fourth threshold, the scheduler allocates the fourth thread to the second candidate virtual machine.
  • the fourth threshold is greater than 0, and the fourth threshold can be set according to the specific implementation scenario.
  • the embodiment of the present application does not limit the fourth threshold.
  • the scheduler allocates the fourth thread to the j third backend drivers to which the first j loads belong.
  • the j third backend drivers are also the target backend drivers to be scheduled this time
  • the third virtual machines i.e., the first candidate virtual machines
  • the load of the third thread reaches the third predicted load
  • the load of the fourth thread reaches the fourth predicted load. Since the absolute value of the difference between the third predicted load and the fourth predicted load is less than the fourth threshold, the third thread and the fourth thread are load balanced after scheduling.
  • the scheduler When the absolute value of the difference between the third predicted load and the fourth predicted load is greater than the fourth threshold, the scheduler sums the first j+1 loads in the third load sequence to obtain a new second total load, and executes steps 7031-7032 based on the new second total load until multiple loads are found such that the absolute value of the difference between the third predicted load and the fourth predicted load is less than or equal to the second threshold. This situation is further explained below based on the following formula (2).
  • the scheduler makes j decisions on the above formula (2) based on the load of the third thread, the load of the fourth thread and the third load sequence.
  • the scheduler takes the third virtual machine corresponding to the third backend driver to which the first j loads in the third load sequence belong as the second candidate virtual machine, and inputs the load of the third thread, the load of the fourth thread and the first j loads into formula (2). If formula (2) is not true, the jth decision process ends and enters the j+1th decision process. If formula (2) is true, the decision of formula (2) ends.
  • the scheduler takes the third backend driver to which the first j loads belong as the target backend driver and the second candidate virtual machine as the target virtual machine, and allocates the fourth thread to the j third backend drivers to achieve allocation of the fourth thread to the target virtual machine.
  • the scheduler After determining at least one target backend driver from the plurality of third backend drivers, for any target backend driver, the scheduler generates target channel information based on the target backend driver, the fourth thread and the source virtual function unit of the target backend driver to allocate the fourth thread to the target backend driver.
  • the source virtual function unit is a virtual function unit to which the target backend driver is connected through the third thread, and the target channel information includes the program identifier of the target backend driver, the thread identifier of the fourth thread and the source port information of the source physical forwarding port corresponding to a source virtual function unit, and the fourth thread is also the target thread.
  • steps 702 - 703 is an implementation of step 202 .
  • the scheduler schedules the target virtual machine to the fourth thread, so that the target virtual machine can communicate with the fourth thread.
  • the target channel information of the target backend driver is obtained.
  • the scheduler sends a channel establishment request to the target thread (i.e., the fourth thread) based on the thread identifier in the target channel information.
  • the channel establishment request instructs the target thread to establish a target VF channel according to the target channel information.
  • the target thread establishes a target VF channel according to the target channel information storage request carried by the target channel information to schedule the target backend driver to the fourth thread.
  • the target VF channel includes the target backend driver, the target thread, and the source physical forwarding port.
  • the target thread also stores the target channel information so that the target thread can perform message forwarding between the target backend driver and the source virtual function unit according to the target channel information later, so that the target virtual machine corresponding to the target backend driver communicates with the target thread through the target VF channel.
  • the scheduler also sends a channel deletion request to the source thread (i.e., the third thread) of the target backend driver, and the channel deletion request indicates to delete the source VF channel where the target backend driver is located.
  • the source thread After receiving the channel deletion request, the source thread deletes the source VF channel.
  • the source channel and the source channel information of the source VF channel are used to prevent subsequent source threads from continuing to communicate on the source VF channel according to the source channel information.
  • thread 1 is the source thread and thread 2 is the target thread
  • thread 2 when the backend driver corresponding to virtual machine 820 is scheduled to thread 2, thread 1 deletes the source VF channel 803 where the backend driver corresponding to virtual machine 820 is located, and thread 2 establishes the target VF channel 804 between virtual machine 820 and virtual function unit 802 according to the target channel information, thereby scheduling virtual machine 820 and its corresponding backend driver from thread 1 to thread 2.
  • thread 2 is a newly added thread, that is, scheduling virtual machines by adding threads is realized.
  • the scheduler after determining the third thread, the scheduler no longer determines the fourth thread from the existing threads, but divides the p third backend drivers into multiple backend driver groups according to the load of the p third backend drivers connected to the third thread, wherein the backend driver groups include at least one third backend driver, and the total load difference of each backend driver group is less than a fourth threshold, so as to ensure the load balancing of each backend driver group, and any backend driver group in the multiple backend driver groups continues to be connected to the third thread.
  • the scheduler For each remaining backend driver group in the multiple backend driver groups except the any backend driver group, the scheduler creates a target thread for the remaining backend driver group, and the target thread establishes a target VF channel for the remaining backend driver group, so that the target thread can then forward messages between the remaining backend driver group and the source virtual function unit of the remaining backend driver according to the target channel information of the target VF channel.
  • the method embodiment shown in Figure 7 can achieve the beneficial effects of the method embodiment shown in Figure 2.
  • the data processing request of the third virtual machine may be waiting for forwarding in the third thread.
  • the method embodiment shown in Figure 7 schedules the target virtual machine in at least one third virtual machine to the fourth thread, thereby avoiding the data processing requests of subsequent target virtual machines from queuing for processing in the third thread for a long time, thereby improving the data processing efficiency of the target virtual machine, reducing the load of the third thread, improving the processing efficiency of the third thread, and enabling the resources provided by the second thread to be fully utilized, thereby avoiding waste of resources of the second thread.
  • Figure 9 is a flow chart of a scheduling method for a virtual machine based on scheduling strategy 4 provided in an embodiment of the present application.
  • the method is applied to a computer device, which is configured with at least one accelerator card, multiple virtual machines and multiple threads.
  • the accelerator card includes multiple virtual function units.
  • the virtual machine communicates with at least one virtual function unit through at least one thread.
  • the method is executed by a scheduler in the computer device, and the method includes the following steps.
  • a scheduler obtains a load of multiple threads in a computer device, where the load is related to the multiple virtual machines in the computer device.
  • this step 901 is the same as step 501, and here, the embodiment of the present application will not repeat this step 901.
  • the scheduler determines a plurality of fifth threads from the plurality of threads based on the loads of the plurality of threads, and a sum of the loads of the plurality of fifth threads is less than or equal to a fifth threshold.
  • the fifth threshold is greater than 0, and the value of the fifth threshold can be set according to the specific implementation scenario.
  • the embodiment of the present application does not limit the fifth threshold.
  • the loads of the n threads are sorted in order from small to large to obtain a second load sequence, and the first t loads in the second load sequence are summed. If the sum is greater than the fifth threshold, t is subtracted by 1 and the step of summing the first t loads in the second load sequence is performed again until the sum of the first t-g loads in the second load sequence is less than or equal to the fifth threshold. Then, each thread corresponding to the first t-g loads is taken as the fifth thread, where t is an integer greater than 0 and less than n, g is an integer greater than or equal to 0 and less than or equal to t-2, and n is an integer greater than 2.
  • each thread corresponding to the first t-g loads is taken as the fifth thread only when the sum of the first t-g loads in the second load sequence is less than or equal to the fifth threshold, when multiple fifth threads are merged into one target thread, as many threads as possible can be merged into one target thread while ensuring the performance of the target thread.
  • the scheduler determines the thread with the smallest load and the thread with the second smallest load among the multiple threads based on the load of the multiple threads. If the total load of the thread with the smallest load and the thread with the second smallest load is less than or equal to the fifth threshold, the thread with the smallest load and the thread with the second smallest load are both determined as the fifth thread.
  • the scheduler allocates a sixth thread among the multiple fifth threads to a fourth virtual machine, where the fourth virtual machine is a virtual machine that communicates with a seventh thread among the multiple fifth threads.
  • the sixth thread is any thread among the plurality of fifth threads
  • the seventh thread is a thread among the plurality of fifth threads except the sixth thread, that is, the plurality of fifth threads include one sixth thread and at least one seventh thread.
  • the sixth thread is the target thread assigned to the target virtual machine to be scheduled this time
  • each fourth virtual machine communicating with at least one seventh thread is the target virtual machine to be scheduled this time.
  • the scheduler selects any thread from multiple fifth threads as the sixth thread, and each thread except the sixth thread in the multiple fifth threads is used as the seventh thread. For any seven threads, the fourth VF channel where any seventh thread is located is queried, and the virtual machine connected to the fourth VF channel is determined as the fourth virtual machine. For any fourth virtual machine, the scheduler allocates the fourth virtual machine to the sixth thread.
  • the scheduler sets the backend driver corresponding to the fourth virtual machine as the target backend driver, and generates target channel information based on the target backend driver, the sixth thread, and the source virtual function unit of the target backend driver to allocate the sixth thread to the target backend driver and the fourth virtual machine.
  • the source virtual function unit is a virtual function unit to which the target backend driver is connected through the seventh thread
  • the target channel information includes the program identifier of the target backend driver, the thread identifier of the sixth thread, and the source port information of the source physical forwarding port corresponding to the source virtual function unit, and the sixth thread is also the target thread.
  • the computer device shown in Figure 10 is configured with an acceleration card 1000, virtual machines 1010-1020 and threads 1-2, wherein the acceleration card includes virtual function units 1001-1002.
  • the acceleration card includes virtual function units 1001-1002.
  • steps 902 - 903 is an implementation of step 202 .
  • the scheduler schedules the fourth virtual machine to the sixth thread, so that the fourth virtual machine can communicate with the sixth thread.
  • the scheduler After obtaining the target channel information of the fourth virtual machine, the scheduler sends a channel establishment request to the target thread (i.e., the sixth thread) based on the thread identifier in the target channel information, and the channel establishment request instructs the target thread to establish a target VF channel according to the target channel information.
  • the target thread After receiving the channel establishment request, the target thread establishes a target VF channel according to the target channel information storage request carried by the channel information to schedule the target backend driver to the sixth thread, and the target VF channel includes the backend driver corresponding to the fourth virtual machine (i.e., the target backend driver), the target thread, and the source physical forwarding port.
  • the target thread also stores the target channel information so that the target thread can perform message forwarding between the target backend driver and the source virtual function unit according to the target channel information later, so that the fourth virtual machine corresponding to the target backend driver communicates with the target thread through the target VF channel.
  • the seventh thread serves as the source thread of the fourth virtual machine, and the scheduler also deletes each seventh thread in the fifth thread. Since the sixth thread is not deleted, and the fourth virtual machine on each seventh thread schedules the sixth thread, it is equivalent to merging each seventh thread into the sixth thread, reducing the number of threads, that is, reducing the number of thread scheduling virtual machines.
  • thread 1 is the sixth thread and thread 2 is the seventh thread
  • the scheduler schedules the virtual machine 1020 from thread 2 to thread 1
  • the scheduler deletes thread 2.
  • the method embodiment described in Figure 9 can achieve the beneficial effects of the method embodiment shown in Figure 2.
  • the resource scheduler schedules the fourth virtual machine on each seventh thread among the multiple fifth threads to the sixth thread among the multiple fifth threads, and the sixth thread is responsible for communicating with each fourth virtual machine, thereby avoiding wasting thread resources.
  • Figure 11 is a flow chart of a scheduling method for a virtual machine based on scheduling strategy 5 provided in an embodiment of the present application.
  • the method is applied to a computer device, in which a plurality of acceleration cards, a plurality of virtual machines and a plurality of threads are configured.
  • the acceleration card includes a plurality of virtual function units.
  • the virtual machine communicates with at least one virtual function unit through at least one thread.
  • the method is executed by a scheduler in the computer device. The method includes the following steps.
  • a scheduler obtains a load of a plurality of accelerator cards in a computer device, where the load is related to the plurality of virtual machines in the computer device.
  • the load of any accelerator card is the sum of the loads provided to the accelerator card by at least one virtual machine during the target duration.
  • the scheduler When the scheduler is configured to schedule the virtual machine using scheduling strategy 5, the scheduler counts the load of each accelerator card among the multiple accelerator cards every time a target time has passed.
  • the process of obtaining the load of any accelerator card can be: the scheduler queries the VF channel where the physical forwarding port corresponding to each virtual function unit of the accelerator card is located during the target duration, determines the backend driver communicating with the virtual function unit of the accelerator card from the queried VF channel, obtains the load of each queried backend driver, and uses the sum of the load of each queried backend driver as the load of the accelerator card.
  • the process of obtaining the load of the backend driver has been introduced above and will not be repeated here.
  • step 1101 is an implementation of step 201 .
  • the scheduler determines a first accelerator card and a second accelerator card based on the load of the multiple accelerator cards.
  • the first accelerator card is used for the multiple accelerator cards.
  • the first accelerator card is an accelerator card with the largest load among the accelerator cards
  • the second accelerator card is an accelerator card with the smallest load among the multiple accelerator cards.
  • the first accelerator card is the accelerator card with the largest load in the computer device during the target duration
  • the second accelerator card is the accelerator card with the smallest load in the computer device during the target duration
  • the second accelerator card is the target accelerator card allocated to the target virtual machine to be scheduled this time.
  • an accelerator card with the largest load among the multiple accelerator cards is determined as a first accelerator card, and an accelerator card with the smallest load among the multiple accelerator cards is determined as a second accelerator card.
  • the scheduler allocates the second acceleration card to a target virtual machine in at least one fifth virtual machine, where the fifth virtual machine is a virtual machine in the multiple virtual machines that communicates with the first acceleration card.
  • the at least one fifth virtual machine is all virtual machines that communicate with the virtual function unit in the first acceleration card.
  • the computer device shown in Figure 12 is configured with acceleration cards A-B, virtual machines 1210-1230 and thread 1.
  • acceleration card A is the first acceleration card
  • acceleration card A is the second acceleration card
  • acceleration card A communicates with virtual machines 1210 and 1230
  • virtual machines 1210 and 1230 are both fifth virtual machines.
  • the scheduler queries multiple fifth VF channels that communicate with the virtual function unit in the first accelerator card within the target duration, and uses the virtual machine connected to each fifth VF channel as the fifth virtual machine, wherein the multiple fifth VF channels may be connected to multiple fifth virtual machines or may be connected to one fifth virtual machine.
  • the second accelerator card is triggered to be allocated to some of the at least one fifth virtual machines, so that these virtual machines are subsequently scheduled to the second accelerator card to reduce the load of the first accelerator card.
  • the scheduler refers to the backend drivers in the multiple fifth VF channels as the fourth backend drivers, and each fifth VF channel has a fourth backend driver, so the multiple fifth VF channels have multiple fourth backend drivers, and the multiple fourth backend drivers are also the backend drivers that communicate with the first accelerator card during the target duration.
  • the scheduler selects the fifth number of fourth backend drivers from the multiple fourth backend drivers as the target backend drivers to be scheduled this time, and allocates the second accelerator card to the target backend driver, wherein the fifth virtual machine to which the target backend driver belongs is also the target virtual machine, and allocating the second accelerator card to the target backend driver is to allocate the second accelerator card to the target virtual machine.
  • the fifth number is a preset number, and here, the embodiment of the present application does not limit the third number.
  • the second acceleration card is allocated to a target virtual machine in at least one fifth virtual machine through the process shown in the following steps 1131-1132.
  • Step 1131 For a third candidate virtual machine among the at least one fifth virtual machine, the scheduler predicts the load of the first accelerator card and the load of the second accelerator card based on the third total load provided by the third candidate virtual machine for the first accelerator card, the load of the first accelerator card, and the load of the second accelerator card, respectively, to obtain a fifth predicted load and a sixth predicted load.
  • the third candidate virtual machine is a candidate for the target virtual machine in at least one fifth virtual machine
  • the third total load is the sum of the loads provided by each third candidate virtual machine for the first accelerator card
  • the load provided by any third candidate virtual machine for the first accelerator card is the total load of at least one fourth backend driver between the third candidate virtual machine and the first accelerator card.
  • the fifth predicted load is the load of the first accelerator card after the third candidate virtual machine is scheduled to the second accelerator card
  • the sixth predicted load is the load of the second accelerator card after the third candidate virtual machine is scheduled to the second accelerator card.
  • the scheduler sorts the loads of the w fourth back-end drivers in order from small to large to obtain a fourth load sequence, and takes the fifth virtual machine corresponding to the fourth back-end drivers to which the first r loads in the fourth load sequence belong as the third candidate virtual machine.
  • the first r loads are summed to obtain the third total load, where r is an integer greater than or equal to 1 and less than w, and w is an integer greater than 1.
  • the scheduler uses the difference between the load of the first accelerator card and the third total load as the fifth predicted load, and uses the sum of the load of the second accelerator card and the third total load as the sixth predicted load.
  • the fifth predicted load indicates the load of the first accelerator card after the r fourth back-end drivers to which the first r loads belong are scheduled to the second accelerator card, which can also be understood as the load of the first accelerator card after the first r fourth back-end drivers are transferred away from the first accelerator card.
  • the sixth predicted load indicates the load of the second accelerator card after the first r fourth back-end drivers are scheduled to the first accelerator card. Since each back-end driver belongs to only one virtual machine, scheduling the r fourth back-end drivers from the first accelerator card to the second accelerator card means scheduling the third candidate virtual machine to which the r fourth back-end drivers belong from the first accelerator card to the second accelerator card.
  • Step 1132 If the absolute value of the difference between the fifth predicted load and the sixth predicted load is less than or equal to a sixth threshold, the scheduler allocates the second accelerator card to the third candidate virtual machine.
  • the sixth threshold is greater than 0, and the sixth threshold can be set according to the specific implementation scenario.
  • the embodiment of the present application does not limit the sixth threshold.
  • the scheduler allocates the second accelerator card to the r fourth backend drivers to which the first r loads belong.
  • the r fourth backend drivers are also the target backend drivers to be scheduled this time
  • the fifth virtual machine i.e., the first candidate virtual machine
  • the load of the first accelerator card reaches the fourth predicted load
  • the load of the second accelerator card reaches the sixth predicted load. Since the absolute value of the difference between the fourth predicted load and the sixth predicted load is less than the sixth threshold, the first accelerator card and the second accelerator card after scheduling are load balanced.
  • the scheduler When the absolute value of the difference between the fourth predicted load and the sixth predicted load is greater than the sixth threshold, the scheduler sums the first r+1 loads in the fourth load sequence to obtain a new third total load, and executes steps 1131-1132 based on the new third total load until multiple loads are found such that the absolute value of the difference between the fourth predicted load and the sixth predicted load is less than or equal to the sixth threshold. This situation is further explained below based on the following formula (3).
  • the scheduler makes r decisions on the above formula (3) based on the load of the first accelerator card, the load of the second accelerator card and the fourth load sequence.
  • the scheduler takes the fifth virtual machine corresponding to the fourth backend driver to which the first r loads in the fourth load sequence belong as the third candidate virtual machine, and inputs the load of the first accelerator card, the load of the second accelerator card and the first r loads into formula (3). If formula (3) is not established, the rth decision process ends and enters the r+1th decision process. If formula (3) is established, the decision of formula (3) ends.
  • the scheduler takes the fourth backend driver to which the first r loads belong as the target backend driver and the third candidate virtual machine as the target virtual machine, and allocates the second accelerator card to the r backend drivers to achieve the allocation of the second accelerator card to the target virtual machine.
  • the scheduler After determining at least one target backend driver from the plurality of fourth backend drivers, for any target backend driver, the scheduler selects at least one target virtual function unit from the virtual function units of the second accelerator card, and for any target virtual function unit, selects a target thread for the target virtual function unit from the thread communicating with the first accelerator card, or establishes a target thread for the target virtual function unit, and generates target channel information based on the target backend driver, the target thread, and the target virtual function unit to allocate the second accelerator card to the target backend driver.
  • the target channel information includes a program identifier of the target backend driver, a thread identifier of the target thread, and target port information of a target physical forwarding port corresponding to the target virtual function unit.
  • accelerator card A is the first accelerator card and accelerator card B is the second accelerator card.
  • the virtual function units A1-A2 in accelerator card A communicate with virtual machines 1210 and 1230 respectively through thread 1.
  • the backend driver corresponding to virtual machine 1210 provides a load of 2M IOPS for thread 1
  • the backend driver corresponding to virtual machine 1230 provides a load of 1M IOPS for thread 1.
  • the scheduler takes virtual machine 1230 as the target virtual machine and the backend driver corresponding to virtual machine 1230 as the target backend driver, randomly selects virtual function unit B1 from virtual function units B1 and B2 of accelerator card B as the target virtual function unit, and assigns virtual function unit B1 to the backend driver corresponding to virtual machine 1230, so as to assign virtual machine 1230 to accelerator card B.
  • steps 1102 - 1103 is an implementation of step 202 .
  • the scheduler schedules the target virtual machine to the second acceleration card, so that the target virtual machine can communicate with the second acceleration card.
  • the scheduler After the target channel information of the target backend driver corresponding to the target virtual machine is obtained, the scheduler sends a channel establishment request to the target thread based on the thread identifier in the target channel information. After receiving the channel establishment request, the target thread establishes a target VF channel according to the target channel information storage request carried by the target channel information to schedule the target backend driver to the second accelerator card. At this time, the target VF channel includes the target backend driver, the target thread and the target physical forwarding port. The target thread also stores the target channel information so that the target thread can perform message forwarding between the target backend driver and the target virtual function unit according to the target channel information, so that the target backend driver can communicate with the target thread corresponding to the target virtual machine through the target VF channel.
  • the scheduler also sends a channel deletion request to the source thread of the target backend driver, and the channel deletion request indicates the deletion of the source VF channel where the target backend driver is located.
  • the source thread After receiving the channel deletion request, the source thread deletes the source VF channel and the source channel information of the source VF channel to prevent subsequent source threads from continuing to communicate on the source VF channel according to the source channel information.
  • thread 1 deletes the source VF channel 1201 where the backend driver corresponding to virtual machine 1230 is located, and establishes the target VF channel 1202 between virtual machine 1230 and virtual function unit B1 according to the target channel information, thereby merging virtual machine 1230 and its corresponding backend driver.
  • the driver schedules from accelerator card A to accelerator card B, realizing virtual machine scheduling across accelerator cards.
  • the method embodiment shown in Figure 11 can achieve the beneficial effects of the method embodiment shown in Figure 2.
  • the data processing request of the fifth virtual machine may wait for processing on the first acceleration card.
  • the method embodiment shown in Figure 11 schedules the target virtual machine in at least one fifth virtual machine to the second acceleration card to avoid the data processing requests of subsequent target virtual machines waiting in line for processing on the first acceleration card for a long time, thereby improving the data processing efficiency of the target virtual machine, reducing the load of the first acceleration card, improving the processing efficiency of the first acceleration card, and enabling the resources provided by the second acceleration card to be fully utilized, thereby avoiding waste of resources of the second acceleration card.
  • Figure 13 is a flow chart of a scheduling method for a virtual machine based on scheduling strategy 6 provided in an embodiment of the present application.
  • the method is applied to a computer device, in which a plurality of accelerator cards, a plurality of virtual machines and a plurality of threads are configured.
  • the accelerator card includes a plurality of virtual function units.
  • the virtual machine communicates with at least one virtual function unit through at least one thread.
  • the method is executed by a scheduler in the computer device. The method includes the following steps.
  • the scheduler obtains the load of multiple acceleration cards in a computer device, where the load is related to the multiple virtual machines in the computer device.
  • this step 1301 is the same as step 1101, and here, the embodiment of the present application will not repeat this step 1301.
  • the scheduler determines a first accelerator card based on the loads of the multiple accelerator cards, where the first accelerator card is an accelerator card with the largest load among the multiple accelerator cards.
  • step 1102 The process of determining the first acceleration card is described in step 1102 , and the embodiment of the present application will not repeat step 1302 here.
  • the scheduler allocates an idle accelerator card to a target virtual machine in at least one fifth virtual machine, where the fifth virtual machine is a virtual machine among the multiple virtual machines that communicates with the first accelerator card.
  • the seventh threshold is greater than 0, and the seventh threshold can be set according to the specific implementation scenario.
  • the embodiment of the present application does not limit the seventh threshold.
  • the idle accelerator card is not assigned to the accelerator card used by the virtual machine.
  • the at least one third virtual machine is all virtual machines that communicate with the third thread. Taking the schematic diagram of scheduling virtual machines based on scheduling strategy 6 provided by the embodiment of the present application shown in Figure 14 as an example, the computer device shown in Figure 14 is configured with accelerator cards A-B, virtual machines 1410-1430 and thread 1.
  • accelerator card A is the first accelerator card and accelerator card B is not connected to any virtual machine
  • accelerator card B is an idle accelerator card, wherein accelerator card A includes virtual function units A1-A2, and accelerator card B includes virtual function units B1-B2.
  • the scheduler records the status of multiple accelerator cards. If the load of the first accelerator card is greater than or equal to the seventh threshold, the scheduler queries and records the status of multiple accelerator cards. If the status of any accelerator card is in use, then the accelerator card is not an idle accelerator card. If the status of any accelerator card is idle, then the accelerator card is regarded as an idle accelerator card.
  • an accelerator card with a load of 0 is queried from multiple accelerator cards. If the load of any accelerator card is 0, the accelerator card is regarded as an idle accelerator card.
  • the scheduler issues an accelerator card addition request, which indicates adding an idle accelerator card.
  • the accelerator card addition request can be a text message or a voice message to prompt the user to add an idle accelerator card.
  • the load of the first accelerator card is greater than or equal to the seventh threshold, and there is an idle accelerator card among the multiple accelerator cards, it is triggered to allocate the idle accelerator card to some virtual machines in the at least one fifth virtual machine, so that these virtual machines can be subsequently scheduled to the idle accelerator card to reduce the load of the first accelerator card.
  • the scheduler queries multiple fourth back-end drivers corresponding to the at least one fifth virtual machine, and uses half of the multiple fourth back-end drivers as target drivers, or, based on the load of the multiple fourth back-end drivers, divides the multiple fourth back-end drivers into a first driver group and a second driver group, the first driver group and the second driver group both include at least one fourth back-end driver, and the load difference between the first driver group and the second driver group is less than a ninth threshold, and uses the first driver group or the fourth back-end driver in the first driver group as the target driver to ensure that after the target driver is scheduled to the idle acceleration card, the idle acceleration and the first acceleration card achieve load balancing.
  • the scheduler After determining at least one target backend driver from the plurality of fourth backend drivers, for any target backend driver, the scheduler selects at least one target virtual function unit from the virtual function units of the idle accelerator card, and for any target virtual function unit, selects a target thread for the target virtual function unit from the thread communicating with the first accelerator card, or establishes a target thread for the target virtual function unit, and generates target channel information based on the target backend driver, the target thread, and the target virtual function unit, so as to allocate the second accelerator card thread to the target backend driver.
  • the target channel information includes the program identifier of the target backend driver, the thread identifier of the target thread, and the target port information of the target physical forwarding port corresponding to the target virtual function unit.
  • steps 1302 - 1303 is an implementation of step 202 .
  • the scheduler schedules the target virtual machine to the idle acceleration card, so that the target virtual machine can communicate with the idle acceleration card.
  • this step 1304 is the same as step 1104, and here, the embodiment of the present application will not repeat this step 1304.
  • the total load provided by the backend driver corresponding to virtual machine 1410 for thread 1 is 2M IOPS, of which 1M IOPS is provided to accelerator card A through VF channel 1401, and 1M IOPS is provided to accelerator card A through VF channel 1402.
  • VF channel 1402 is used as the source VF channel
  • virtual function unit A2 connected to VF channel 1402 is used as the source virtual function unit of the backend driver corresponding to virtual machine 1410.
  • the scheduler uses thread 1 as the source thread and the target thread, schedules the backend driver corresponding to virtual machine 1410 from virtual function unit A2 to virtual function unit B1 in accelerator card B2, deletes VF channel 1402, and establishes VF channel 1403 between virtual machine 1410 and virtual function unit B1.
  • accelerator card B is a newly added accelerator card, which means that the virtual machine is scheduled by adding an accelerator card.
  • the method embodiment shown in Figure 13 can achieve the beneficial effects of the method embodiment shown in Figure 2.
  • the data processing request of the fifth virtual machine may be waiting for processing on the first acceleration card.
  • the method embodiment shown in Figure 13 schedules the target virtual machine in at least one fifth virtual machine to an idle acceleration card to avoid the data processing requests of subsequent target virtual machines waiting in line for processing on the first acceleration card for a long time, thereby improving the data processing efficiency of the target virtual machine, reducing the load of the first acceleration card, improving the processing efficiency of the first acceleration card, and enabling the resources provided by the idle acceleration card to be fully utilized, thereby avoiding waste of resources of the idle acceleration card.
  • Figure 15 is a flow chart of a scheduling method for a virtual machine based on scheduling strategy 7 provided in an embodiment of the present application.
  • the method is applied to a computer device, which is configured with at least one accelerator card, multiple virtual machines and multiple threads.
  • the accelerator card includes multiple virtual function units.
  • the virtual machine communicates with at least one virtual function unit through at least one thread.
  • the method is executed by a scheduler in the computer device, and the method includes the following steps.
  • the scheduler obtains the load of multiple acceleration cards in the computer device, where the load is related to the multiple virtual machines in the computer device.
  • this step 1501 is the same as step 1101, and here, the embodiment of the present application will not repeat this step 1501.
  • the scheduler determines a plurality of third accelerator cards from the plurality of accelerator cards based on the loads of the plurality of accelerator cards, wherein a sum of the loads of the plurality of third accelerator cards is less than or equal to an eighth threshold.
  • the multiple third acceleration cards are threads to be merged this time, the eighth threshold is greater than 0, and the value of the eighth threshold can be set according to a specific implementation scenario.
  • the embodiment of the present application does not limit the eighth threshold.
  • the loads of the s accelerator cards are sorted in order from small to large to obtain a fifth load sequence, and the first k loads in the fifth load sequence are summed. If the sum is greater than the eighth threshold, k is subtracted by 1 and the step of summing the first k loads in the fifth load sequence is performed again until the sum of the first k-h loads in the fifth load sequence is less than or equal to the eighth threshold. Then, each accelerator card corresponding to the first k-h loads is used as the third accelerator card, wherein k is an integer greater than 0 and less than s, h is an integer greater than or equal to 0 and less than or equal to k-2, and s is an integer greater than 2.
  • each accelerator card corresponding to the first k-h loads is used as the third accelerator card only when the sum of the first k-h loads in the fifth load sequence is less than or equal to the eighth threshold, when one third accelerator card is reserved for use, as many accelerator cards as possible can be vacated while ensuring the performance of the third accelerator card.
  • the scheduler determines the accelerator card with the smallest load and the accelerator card with the second smallest load from among multiple threads based on the load of the multiple accelerator cards; if the total load of the accelerator card with the smallest load and the accelerator card with the second smallest load is less than or equal to an eighth threshold, the accelerator card with the smallest load and the accelerator card with the second smallest load are both determined as the third accelerator card.
  • the scheduler allocates a fourth accelerator card among the multiple third accelerator cards to a sixth virtual machine, where the sixth virtual machine is a virtual machine that communicates with a fifth accelerator card among the multiple third accelerator cards.
  • the fourth accelerator card is any accelerator card among the plurality of third accelerator cards
  • the fifth accelerator card is an accelerator card among the plurality of third accelerator cards except the fourth accelerator card, that is, the plurality of third accelerator cards include a fourth accelerator card and at least one fifth accelerator card.
  • the fourth accelerator card is the target thread assigned to the target virtual machine to be scheduled this time
  • each sixth virtual machine communicating with at least one fifth accelerator card is the target virtual machine to be scheduled this time.
  • the scheduler selects any one accelerator card from multiple third accelerator cards as the fourth accelerator card, and each accelerator card except the fourth accelerator card among the multiple third accelerator cards is used as the fifth accelerator card.
  • the scheduler queries the VF channel where the physical forwarding interface of the virtual function unit of any fifth accelerator card is located, and determines the virtual machine connected to the queried VF channel as the sixth virtual machine.
  • the scheduler allocates the sixth virtual machine to the fourth accelerator card.
  • the scheduler uses each backend driver corresponding to the sixth virtual machine as a target backend driver, and for any target backend driver
  • the scheduler selects at least one target virtual function unit from the virtual function units of the fourth accelerator card, and for any target virtual function unit, selects a target thread for the target virtual function unit from the thread communicating with the fourth accelerator card, or establishes a target thread for the target virtual function unit.
  • the scheduler generates target channel information based on the target backend driver, the target thread, and the target virtual function unit to allocate the fourth accelerator card to the target backend driver and the sixth virtual machine.
  • the target channel information includes the program identifier of the target backend driver, the thread identifier of the target thread, and the target port information of the target physical forwarding port corresponding to the target virtual function unit.
  • steps 1502 - 1503 is an implementation of step 202 .
  • the scheduler schedules the sixth virtual machine to the fourth acceleration card, so that the sixth virtual machine can communicate with the fourth acceleration card.
  • this step 1504 is the same as step 1104, and here, the embodiment of the present application will not repeat this step 1504.
  • the computer device shown in Figure 16 is configured with acceleration cards A-B, virtual machines 1610-1630 and thread 1.
  • acceleration card A includes virtual function units A1-A2
  • acceleration card B includes virtual function units B1-B2.
  • virtual machine 1610 provides 10K IOPS load to virtual function unit A1 and virtual function unit B1 respectively through thread 1.
  • the scheduler uses thread 1 as the source thread and target thread, and virtual function unit 1610 as the sixth virtual machine, and schedules virtual machine 1610 and its corresponding back-end driver from virtual function unit B1 to virtual function unit A2.
  • the number of acceleration cards allocated to virtual machine 1610 is reduced, thereby achieving scheduling of virtual machines by reducing acceleration cards.
  • the fifth acceleration card becomes an idle acceleration card.
  • the method embodiment shown in FIG15 can achieve the beneficial effects of the method embodiment shown in FIG2 .
  • the resource scheduler schedules the sixth virtual machines on each fifth accelerator card among the plurality of third accelerator cards to the fourth accelerator card among the plurality of third accelerator cards, and the fourth accelerator card is responsible for communicating with each sixth virtual machine, thereby avoiding occupying too many accelerator cards.
  • a backend driver corresponding to a virtual machine can only bind to a virtual function unit through a VF channel, and a virtual function unit can only bind to one backend driver, which, on the one hand, leads to an inflexible communication mode between the backend virtual program and the virtual function unit, and on the other hand, leads to low reuse efficiency of the virtual function unit.
  • the backend driver is scheduled between multiple virtual function units, so that the backend virtual program can flexibly communicate with multiple virtual function units, and can also achieve a maximum of X backend drivers sharing the same virtual function unit (or physical forwarding port) to improve the reuse rate of the virtual function unit.
  • the number of backend drivers served by the accelerator card is increased from 1*QVF to X*QVF, where the X value is determined by the memory resources allocated to the VF, and QVF is the number of virtual function units in the accelerator card.
  • each accelerator card is configured with a session pool, which is used to store session information of virtual machines communicating with the accelerator card.
  • the session information of the virtual machine includes session information of a session established by an application in the virtual machine, and the session information includes a session identifier (identity, ID) of the session.
  • the scheduler also provides a session information cache service.
  • the scheduler is configured with a session information library of multiple virtual machines in the computer device, and the session information library is used to store the session information of the multiple virtual machines.
  • the session information library includes a copy session pool of each accelerator card, and each copy session pool is used to cache a copy of the session information in the corresponding accelerator card session pool.
  • the application caches the session information of the session to the session information library in the scheduler (such as the copy session pool of the accelerator card in the session information library) through the standard semi-virtualized IO device model corresponding to the virtual machine, and then the scheduler copies the session information in the session information library to the session pool in the accelerator card, so that when a data processing request issued by a subsequent application during the session reaches the accelerator card, the accelerator card can query the corresponding session information in the session pool according to the session ID carried in the data processing request, and perform corresponding processing operations on the data processing request according to the queried session information.
  • the scheduler such as the copy session pool of the accelerator card in the session information library
  • the scheduler includes a session information library 1203, the accelerator card A includes a session pool A3, the accelerator card B includes a session pool B3, the session information of the virtual machine 1210 and the session information of the virtual machine 1230 are stored in the session pool A3, and the session information library 1203 also stores copies of the session information in the session pools A3 and B3.
  • the scheduler 104 in FIG. 1 includes a session information library.
  • the scheduler queries the session information of the target virtual machine from the session information library. For example, the scheduler queries the session information of the target virtual machine from the copy session pool of the first accelerator card in the session information library. After the session information of the target virtual machine is queried, the scheduler stores the queried session information of the target virtual machine in the session pool in the second accelerator card, so that after the subsequent data processing request of the application in the target virtual machine is sent to the second accelerator card, the second accelerator card can obtain the session information from itself according to the session ID carried in the data processing request. The session information of the application is queried from the session pool.
  • the scheduler after the scheduler schedules the target virtual machine to the idle accelerator card, if the first accelerator card and the idle accelerator card are of different types, the scheduler queries the session information of the target virtual machine from the session information library, and stores the queried session information of the target virtual machine in the session pool in the idle accelerator card, so that after a subsequent data processing request of an application in the target virtual machine is sent to the idle accelerator card, the idle accelerator card can query the session information of the application from its own session pool according to the session ID carried in the data processing request.
  • the scheduler queries the session information of the sixth virtual machine from the session information library, and stores the queried session information of the sixth virtual machine in the session pool in the fourth accelerator card, so that after the subsequent data processing request of the application in the sixth virtual machine is sent to the fourth accelerator card, the fourth accelerator card can query the session information of the application from its own session pool according to the session ID carried in the data processing request.
  • the scheduler when a virtual machine in a computer device migrates, can also provide the target computer device with session information of the virtual machine.
  • the virtual machine migration needs to ensure that the tenant of the virtual machine is unaware of the migration process, so it is also called virtual machine online migration or hot migration.
  • the virtual machine to be migrated is called the source virtual machine
  • the computer device where the source virtual machine is located is called the source device
  • the scheduler in the source device is called the source scheduler.
  • the back-end driver After receiving the session information, the back-end driver stores the session information in the session information library of the source scheduler, and the source scheduler copies the session information to the session pool of the accelerator card.
  • the cloud management platform in the source device notifies the cloud management platform client of another computer device (i.e., the destination device) to create a destination virtual machine, and the specifications of the destination virtual machine are the same as those of the source virtual machine.
  • the same front-end driver and back-end driver as the source virtual machine are created for the target virtual machine.
  • the cloud management platform in the source device sends the memory page data corresponding to the source virtual machine to the memory space corresponding to the target virtual machine in the destination device.
  • the session information cached by the front-end driver of the source virtual machine is also sent to the memory space corresponding to the target virtual machine.
  • the session information of the source virtual machine in the session information library of the source scheduler cannot be synchronized to the destination device, and the session information of the source virtual machine in the session pool of the accelerator card corresponding to the source virtual machine in the source device cannot be synchronized to the destination device.
  • the target scheduler After the migration is completed, during the operation of the target virtual machine, after the data processing request issued by the application in the target virtual machine during the session reaches the target scheduler (such as the thread managed by the target scheduler), the target scheduler will query the session information of the session in the session information library according to the session ID of the session carried in the data processing request. Since the session information library of the target scheduler does not store the session information of the application, when the target scheduler queries the session information according to the session ID, the session information is missing (miss), triggering the target scheduler to send a session information acquisition request to the front-end driver through the back-end driver, and the session information acquisition request indicates to obtain the session information indicated by the session ID.
  • the front-end driver After obtaining the session information acquisition request, the front-end driver queries the session information indicated by the session ID from the cached session information based on the session ID carried in the session information acquisition request, and sends the queried session information to the target scheduler through the back-end driver.
  • the target scheduler stores the session information returned by the front-end driver in its own session information library and the session pool in the accelerator card that communicates with the target virtual machine, so that the accelerator card performs corresponding processing operations on the data processing request based on the session information.
  • the destination scheduler receives the data processing request in the session in the destination virtual machine for the first time, it only needs to trigger the acquisition of session information from the front-end driver once, without the need to acquire it multiple times.
  • the destination scheduler obtains session information for the accelerator card from the front-end driver, thereby avoiding the loss of session information after migration due to the inability to migrate the session information in the accelerator card to the destination device during hot migration.
  • FIG. 18 is a schematic diagram of the structure of a scheduling device for a virtual machine provided in an embodiment of the present application.
  • the device 1800 shown in FIG. 18 may be the scheduler or part of the scheduler in the previous embodiments or FIGS. 2-17 , and is used to execute the method executed by the scheduler.
  • the device 1800 is applied to a computer device, and the computer device is configured with at least one accelerator card, a plurality of virtual machines, and a plurality of threads.
  • the accelerator card includes a plurality of virtual function units, and the virtual machine communicates with at least one virtual function unit through at least one thread.
  • the device 1800 includes:
  • An acquisition module 1801 is used to acquire a load of at least one communication unit of the computer device, where the communication unit is the virtual function unit, the thread or the accelerator card, and the load of the communication unit is related to the multiple virtual machines;
  • An allocation module 1802 is configured to allocate a target communication unit to a target virtual machine in the at least one accelerator card based on the load of the at least one communication unit, wherein the target communication unit is the virtual function unit, the thread or the accelerator card;
  • the scheduling module 1803 is used to schedule the target virtual machine to the target communication unit so that the target virtual machine can communicate with the target communication unit.
  • the communication unit is the virtual function unit
  • the load of the at least one communication unit includes the load of each virtual function unit in the at least one accelerator card
  • the target communication unit is the virtual function unit
  • the allocation module 1802 is used to:
  • the first virtual function unit is a virtual function unit with the largest load in the at least one accelerator card
  • the second virtual function unit is a virtual function unit with the smallest load in the at least one accelerator card
  • the second virtual function unit is allocated to a target virtual machine in at least one first virtual machine, where the first virtual machine is a virtual machine among the multiple virtual machines that communicates with the first virtual function unit.
  • the communication unit is the thread
  • the load of the at least one communication unit includes the load of the multiple threads
  • the target communication unit is the thread
  • the allocation module 1802 includes:
  • a determination submodule configured to determine a first thread and a second thread based on the loads of the multiple threads, wherein the first thread is a thread with the largest load among the multiple threads, and the second thread is a thread with the smallest load among the multiple threads;
  • the allocation submodule is used to allocate the second thread to a target virtual machine in at least one second virtual machine, where the second virtual machine is a virtual machine in the multiple virtual machines that communicates with the first thread.
  • the allocation submodule is used to:
  • first candidate virtual machine among the at least one second virtual machine For a first candidate virtual machine among the at least one second virtual machine, based on a first total load provided by the first candidate virtual machine for the first thread, the load of the first thread, and the load of the second thread, respectively predict the load of the first thread and the load of the second thread to obtain a first predicted load and a second predicted load, wherein the first predicted load is the load of the first thread after the first candidate virtual machine is scheduled to the second thread, and the second predicted load is the load of the second thread after the first candidate virtual machine is scheduled to the second thread;
  • the second thread is allocated to the first candidate virtual machine.
  • the communication unit is the thread
  • the load of the at least one resource includes the loads of the multiple threads
  • the target communication unit is the thread
  • the allocation module 1802 includes:
  • a determination submodule configured to determine, based on the loads of the multiple threads, a third thread and a fourth thread from the multiple threads, wherein the load of the third thread is greater than or equal to a third threshold, and the load of the fourth thread is less than the load of the third thread;
  • the allocation submodule is used to allocate the fourth thread to a target virtual machine in at least one third virtual machine, where the third virtual machine is a virtual machine among the multiple virtual machines with which the third thread communicates.
  • the allocation submodule is used to:
  • a second candidate virtual machine among the at least one third virtual machine based on a second total load provided by the second candidate virtual machine for the third thread, the load of the third thread, and the load of the fourth thread, respectively predict the load of the third thread and the load of the fourth thread to obtain a third predicted load and a fourth predicted load, the third predicted load being the load of the third thread after the second candidate virtual machine is scheduled to the fourth thread, and the fourth predicted load being the load of the fourth thread after the second candidate virtual machine is scheduled to the fourth thread;
  • the fourth thread is allocated to the second candidate virtual machine.
  • the communication unit is the thread
  • the load of the at least one communication unit includes the loads of the multiple threads
  • the target communication unit is the thread
  • the allocation module 1802 is used to:
  • a sixth thread among the plurality of fifth threads is allocated to a fourth virtual machine, the fourth virtual machine being a virtual machine communicating with a seventh thread among the plurality of fifth threads, the seventh thread being a thread among the plurality of fifth threads except the sixth thread.
  • the communication unit is the acceleration card
  • the at least one acceleration card includes a plurality of acceleration cards
  • the load of the at least one communication unit includes the loads of the plurality of acceleration cards
  • the target communication unit is the acceleration card
  • a determination submodule configured to determine a first accelerator card and a second accelerator card based on the loads of the multiple accelerator cards, wherein the first accelerator card is an accelerator card with the largest load among the multiple accelerator cards, and the second accelerator card is an accelerator card with the smallest load among the multiple accelerator cards;
  • the allocation submodule is used to allocate the second acceleration card to a target virtual machine in at least one fifth virtual machine, where the fifth virtual machine is a virtual machine in the multiple virtual machines that communicates with the first acceleration card.
  • the allocation submodule is used to:
  • a third candidate virtual machine among the at least one fifth virtual machine based on a third total load provided by the third candidate virtual machine for the first accelerator card, the load of the first accelerator card, and the load of the second accelerator card, respectively predict the load of the first accelerator card and the load of the second accelerator card to obtain a fifth predicted load and a sixth predicted load, the fifth predicted load being the load of the first accelerator card after the third candidate virtual machine is scheduled to the second accelerator card, and the sixth predicted load being the load of the second accelerator card after the third candidate virtual machine is scheduled to the second accelerator card;
  • the second acceleration card is allocated to the third candidate virtual machine.
  • the device 1800 further includes:
  • a query module configured to query the session information of the target virtual machine from a session information base of the multiple virtual machines if the types of the first accelerator card and the second accelerator card are different, wherein the session information base is used to store the session information of the multiple virtual machines;
  • a storage module is used to store the session information of the target virtual machine in the session pool of the second acceleration card, and the session pool is used to store the session information of the virtual machines communicating with the second acceleration card.
  • the communication unit is the acceleration card
  • the at least one acceleration card includes a plurality of acceleration cards
  • the load of the at least one communication unit includes the loads of the plurality of acceleration cards
  • the target communication unit is the acceleration card
  • the allocation module 1802 is used to:
  • the load of the first accelerator card is greater than or equal to a seventh threshold, and there is an idle accelerator card among the multiple accelerator cards, allocate the idle accelerator card to a target virtual machine in at least one fifth virtual machine, and the fifth virtual machine is a virtual machine among the multiple virtual machines that communicates with the first accelerator card.
  • the communication unit is the acceleration card
  • the at least one acceleration card includes a plurality of acceleration cards
  • the load of the at least one communication unit includes the loads of the plurality of acceleration cards
  • the target communication unit is the acceleration card
  • the allocation module 1802 is used to:
  • a fourth accelerator card among the plurality of third accelerator cards is allocated to a sixth virtual machine, the sixth virtual machine being a virtual machine communicating with a fifth accelerator card among the plurality of third accelerator cards, and the fifth accelerator card being an accelerator card among the plurality of third accelerator cards except the fourth accelerator card.
  • device 1800 corresponds to the scheduler in the above-mentioned method embodiment, and the various modules in device 1800 and the above-mentioned other operations and/or functions are respectively for implementing the various steps and methods implemented by the scheduler in the method embodiment.
  • the specific details can be found in the above-mentioned method embodiment. For the sake of brevity, they will not be repeated here.
  • the device 1800 schedules a virtual machine, only the division of the above-mentioned functional modules is used as an example.
  • the above-mentioned functions can be assigned to different functional modules as needed, that is, the internal structure of the device 1800 is divided into different functional modules to complete all or part of the functions described above.
  • the device 1800 provided in the above embodiment and the above method embodiment belong to the same concept, and the specific implementation process is detailed in the above method embodiment, which will not be repeated here.
  • FIG19 is a schematic diagram of the structure of a chip provided by an embodiment of the present application.
  • FIG19 is a schematic diagram of the structure of a chip provided by the present application.
  • the chip 1900 includes a processor 1901 and an interface circuit 1902, wherein the interface circuit 1902 is used to receive instructions and transmit them to the processor 1901.
  • the processor 1901 can be, for example, a specific implementation form of the device 1800, and can be used to execute the scheduling method of the above-mentioned virtual machine.
  • the processor 1901 is coupled to the memory 1903, and the memory 1903 is used to store program codes.
  • the program codes are executed by the processor 1901, the chip system composed of the processor 1901, the interface circuit 1902 and the memory 1903 implements the operation steps of the method in any method embodiment in Figures 2 to 17 above.
  • the processor 1901 may be a CPU or other general-purpose processor.
  • the processor 1901 may also be one or more integrated circuits for implementing the solution of the present application, such as a digital signal processor (DSP), ASIC, PLD, FPGA or other programmable logic device, discrete gate or transistor logic device, discrete hardware component, etc.
  • DSP digital signal processor
  • ASIC application specific integrated circuit
  • PLD physical layer deposition
  • FPGA field-programmable gate
  • discrete gate or transistor logic device discrete hardware component
  • the general-purpose processor may be a microprocessor or any conventional processor, etc.
  • the memory 1903 in the chip system may be one or more.
  • the memory 1903 may be integrated with the processor 1901, or may be separately arranged with the processor 1901, which is not limited in this application.
  • the memory 1903 may be integrated with the processor 1901 on the same chip, as shown in FIG19 , or the memory 1903 may be arranged on different chips from the processor 1901, and this application does not specifically limit the type of the memory 1903 and the arrangement of the memory 1903 and the processor 1901.
  • the memory 1903 may include a read-only memory and a random access memory, and provide instructions and data to the processor 1901.
  • the memory 1903 may also include a non-volatile random access memory.
  • the memory 1903 may also store information about the device type.
  • the memory 1903 may also be a volatile memory, or may include both volatile and non-volatile memories.
  • 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) or a flash memory.
  • the volatile memory can be a random access memory (RAM), which is used as an external cache.
  • RAM random access memory
  • many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous connection dynamic random access memory (SLDRAM) and direct memory bus random access memory (DR RAM).
  • the chip system can be an FPGA, an ASIC, a SoC, a CPU, a network processor (NP), a digital signal processing circuit (DSP), a microcontroller (MCU), a PLD or other integrated chips.
  • NP network processor
  • DSP digital signal processing circuit
  • MCU microcontroller
  • Figure 20 is a schematic diagram of the structure of a computer device provided in an embodiment of the present application.
  • the computer device 2000 includes a processor 2001, a memory 2002, a communication interface 2003 and a bus 2004.
  • the processor 2001, the memory 2002, and the communication interface 2003 communicate through the bus 2004, and can also communicate through other means such as wireless transmission.
  • the memory 2002 is used to store instructions
  • the processor 2001 is used to execute the program code stored in the memory 2002.
  • the processor 2001 can call the program code stored in the memory 2002 to execute the steps provided by the scheduling method of the above-mentioned virtual machine (such as the above-mentioned Figures 2 to 17).
  • the processor 2001 may include one or more CPUs.
  • the computer device 2000 may include multiple processors 2001, each of which may be a single-core processor (single-CPU) or a multi-core processor (multi-CPU).
  • the processor here may refer to one or more devices, circuits, and/or processing cores for processing data (such as computer program instructions).
  • the implementation method of the processor 2001 is similar to that of the processor 1901 in FIG. 19
  • the implementation method of the memory 2002 is similar to that of the memory 1903 in FIG. 19 .
  • the implementation method of the processor 2001 and the memory 2002 are not elaborated in detail in the embodiments of the present application.
  • the communication interface 2003 uses any transceiver-like device for communicating with other devices or communication networks.
  • the communication interface 2004 includes a wired communication interface and may also include a wireless communication interface.
  • the wired communication interface may be, for example, an Ethernet interface.
  • the Ethernet interface may be an optical interface, an electrical interface, or a combination thereof.
  • the wireless communication interface may be a wireless local area network (WLAN) interface, a cellular network communication interface, or a combination thereof, etc.
  • WLAN wireless local area network
  • the bus 2004 is used to transmit information between the above components.
  • the bus 2004 may also include a power bus and a status signal bus.
  • various buses are marked as bus 2004 in the figure.
  • the communication bus can be divided into an address bus, a data bus, a control bus, etc.
  • the communication bus can be a Peripheral Component Interconnect Express (PCIe) bus, an extended industry standard architecture (EISA) bus, a unified bus (Ubus or UB), a compute express link (CXL) or a cache coherent interconnect for accelerators (CCIX), etc.
  • PCIe Peripheral Component Interconnect Express
  • EISA extended industry standard architecture
  • Ubus or UB unified bus
  • CXL compute express link
  • CIX cache coherent interconnect for accelerators
  • the computer device further includes a storage device, which may be a ROM or other memory device capable of storing static information and instructions. It can be a static storage device of other types, or a RAM or other types of dynamic storage devices that can store information and instructions, or an EEPROM, a compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compressed optical disc, laser disc, optical disc, digital versatile disc, Blu-ray disc, etc.), a magnetic disk storage medium or other magnetic storage device, or any other medium that can be used to carry or store the desired program code in the form of instructions or data structures and can be accessed by the processor 2001, and the storage device includes at least one memory 2002, but is not limited thereto.
  • the storage device can exist independently and be connected to the processor 2001 through the bus 2004.
  • the storage device can also be integrated with the processor 2001.
  • the computer device 2000 may also include an output device and an input device 2005.
  • the output device communicates with the processor 2001 and can display information in a variety of ways.
  • the output device may be a liquid crystal display (LCD), a light emitting diode (LED) display device, a cathode ray tube (CRT) display device, or a projector.
  • the input device 2005 communicates with the processor 2001 and can receive user input in a variety of ways.
  • the input device 2005 may be an accelerator card, a mouse, a keyboard, a touch screen device, or a sensor device.
  • the computer device 2000 used to implement virtual machine scheduling according to the present application may correspond to the computer device where the scheduler in the embodiment of the present application is located, and may correspond to the corresponding subject in the scheduling method of the virtual machine according to the embodiment of the present application, and the above-mentioned and other operations and/or functions of each module in the computer device 2000 are respectively for implementing the corresponding processes of each method in Figures 2 to 17, and for the sake of brevity, they will not be repeated here.
  • the present application also provides a computer-readable storage medium, such as a memory including a program code, which can be executed by a processor in a computer device (or chip) to complete the scheduling method of the virtual machine in the above embodiment.
  • a computer-readable storage medium such as a memory including a program code, which can be executed by a processor in a computer device (or chip) to complete the scheduling method of the virtual machine in the above embodiment.
  • the implementation of the computer-readable storage medium can refer to the memory 1903 in Figure 19.
  • the present application also provides a computer program product or a computer program, which includes a program code, and the program code is stored in a computer-readable storage medium.
  • a processor of a computer device or chip reads the program code from the computer-readable storage medium, and the processor executes the program code, so that the computer device (or chip) executes the above-mentioned virtual machine scheduling method.
  • the present application also provides a device, which can specifically be a chip, component or module, and the device may include a connected processor and memory; wherein the memory is used to store computer execution instructions, and when the device is running, the processor can execute the computer execution instructions stored in the memory so that the chip executes the scheduling method of the virtual machine in the above-mentioned method embodiments.
  • the devices, equipment, computer-readable storage media, computer program products or chips provided in this application are all used to execute the corresponding methods provided above. Therefore, the beneficial effects that can be achieved can refer to the beneficial effects in the corresponding methods provided above, and will not be repeated here.
  • the above embodiments can be implemented in whole or in part by software, hardware, firmware or any other combination.
  • the above embodiments can be implemented in whole or in part in the form of a computer program product.
  • the computer program product includes one or more computer instructions.
  • the computer program instructions When the computer program instructions are loaded or executed on a computer, the process or function described in the embodiment of the present application is generated in whole or in part.
  • the computer can be a general-purpose computer, a special-purpose computer, a computer network or other programmable device.
  • the computer instructions can be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium.
  • the computer instructions can be transmitted from one website, computer, server or data center to another website, computer, server or data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.).
  • the computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server or data center that contains one or more available media sets.
  • the available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD) or a semiconductor medium.
  • the semiconductor medium can be a solid state disk (SSD).

Landscapes

  • Computer And Data Communications (AREA)

Abstract

本申请公开了一种虚拟机的调度方法、装置、芯片以及计算机可读存储介质，属于通信技术领域。本方法通过基于计算机设备的虚拟功能单元、线程以及加速卡中至少一种通信单元的负载量，为计算机设备中的目标虚拟机分配目标通信单元，将目标虚拟机调度到分配的目标通信单元，使得目标虚拟机与目标通信单元能够进行通信，由于能够为目标虚拟机分配目标通信单元，从而使得能够与目标虚拟机通信的虚拟功能单元并不固定，也就无需将目标虚拟机与固定的虚拟功能单元绑定，随着目标虚拟机在加速卡的不同通信单元之间进行调度，使得目标虚拟机能够与不同的虚拟功能单元灵活通信，从而提高了虚拟机与加速卡之间通信方式的灵活性。

Description

虚拟机的调度方法、装置、芯片以及计算机可读存储介质
本申请要求于2022年12月23日提交的申请号为202211666451.X、发明名称为“虚拟机的调度方法、装置、芯片以及计算机可读存储介质”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及通信技术领域，特别涉及一种虚拟机的调度方法、装置、芯片以及计算机可读存储介质。
背景技术
随着云计算时代的到来，对云服务器的数据处理的要求越来越高，目前，云服务器中配置有中央处理器(central processing unit，CPU)以及加速卡，CPU的部分计算任务可卸载到加速卡上，由加速卡执行这部分计算任务，使得云服务器的处理能力和内存可以更多的腾出来给租户的虚拟机(virtual machine，VM)使用。
以加速卡为加密卡为例，将CPU中的数据加密和数据解密功能卸载到加密卡上，将加密卡虚拟出多个虚拟功能(virtual function，VF)单元，每个VF单元与云服务器中的一个VM绑定，任一VM将数据加密/解密请求发送到绑定的VF单元的处理队列，以和绑定的VF单元通信，由加密卡以轮询的方式，处理多个VF单元的处理队列中的该数据加密/解密请求。
由于每个虚拟机只能与加速卡中绑定的VF单元通信，导致虚拟机与加速卡之间的通信方式不灵活。
发明内容
本申请实施例提供了一种虚拟机的调度方法、装置、芯片以及计算机可读存储介质，能够提高虚拟机与加速卡之间通信方式的灵活性。该技术方案如下：
第一方面，提供了一种虚拟机的调度方法，此方法应用于计算机设备，其中，该计算机设备中配置有至少一个加速卡、多个虚拟机以及多个线程，加速卡包括多个虚拟功能单元，虚拟机通过至少一个线程与至少一个虚拟功能单元通信；在此方法中，以虚拟功能单元、线程或加速卡为不同种类的通信单元，通信单元的负载量与多个虚拟机有关，基于此，先获取计算机设备的至少一种通信单元的负载量；然后，基于至少一种通信单元的负载量，为至少一个加速卡中的目标虚拟机分配目标通信单元，目标通信单元为虚拟功能单元、线程或加速卡；再之后，将目标虚拟机调度到目标通信单元，以使目标虚拟机与目标通信单元能够通信。
此方法通过基于计算机设备的虚拟功能单元、线程以及加速卡中至少一种通信单元的负载量，为计算机设备中的目标虚拟机分配目标通信单元，将目标虚拟机调度到分配的目标通信单元，使得目标虚拟机与目标通信单元能够进行通信，由于能够为目标虚拟机分配目标通信单元，从而使得能够与目标虚拟机通信的虚拟功能单元并不固定，也就无需将目标虚拟机与固定的虚拟功能单元绑定，随着目标虚拟机在加速卡的不同通信单元之间进行调度，使得目标虚拟机能够与不同的虚拟功能单元灵活通信，从而提高了虚拟机与加速卡之间通信方式的灵活性。
在一种可能的实现方式中，通信单元为虚拟功能单元，至少一种通信单元的负载量包括至少一个加速卡中各个虚拟功能单元的负载量，目标通信单元为虚拟功能单元，基于此，上述基于至少一种通信单元的负载量，为至少一个加速卡中的目标虚拟机分配目标通信单元的过程包括：先基于至少一个加速卡中各个虚拟功能单元的负载量，确定第一虚拟功能单元以及第二虚拟功能单元；若第一虚拟功能单元与第二虚拟功能单元之间的第一负载量差值大于或等于第一阈值，为至少一个第一虚拟机中的目标虚拟机分配第二虚拟功能单元；其中，第一虚拟功能单元为至少一个加速卡中负载量最大的虚拟功能单元，第二虚拟功能单元为至少一个加速卡中负载量最小的虚拟功能单元，第一虚拟机为多个虚拟机中与第一虚拟功能单元通信的虚拟机。
基于上述可能的实现方式，通过为至少一个第一虚拟机中的目标虚拟机分配第二虚拟功能单元，以便 将与第一虚拟机功能单元通信的目标虚拟机调度到第二虚拟功能单元，以避免后续目标虚拟机的数据处理请求长时间在第一虚拟功能单元排队等待处理，提高了目标虚拟机的数据处理效率，降低了第一虚拟功能单元的负载量。
在一种可能的实现方式中，通信单元为线程，至少一种通信单元的负载量包括多个线程的负载量，目标通信单元为线程，基于此，上述基于至少一种通信单元的负载量，为至少一个加速卡中的目标虚拟机分配目标通信单元的过程包括：先基于多个线程的负载量，确定第一线程以及第二线程；然后，为至少一个第二虚拟机中的目标虚拟机分配第二线程，第二虚拟机为多个虚拟机中与第一线程通信的虚拟机，其中，第一线程为多个线程中负载量最大的线程，第二线程为多个线程中负载量最小的线程。
基于上述可能的实现方式，通过为至少一个第二虚拟机中的目标虚拟机分配第二线程，以便将目标虚拟机从第一线程调度到第二线程，以避免后续目标虚拟机的数据处理请求长时间在第一线程排队等待处理，提高了目标虚拟机的数据处理效率，降低了第一线程的负载量，提高了第一线程的处理效率，也能使得第二线程提供的资源能够被充分使用，避免第二线程的资源浪费。
在一种可能的实现方式中，上述为至少一个第二虚拟机中的目标虚拟机分配第二线程的过程包括：对于至少一个第二虚拟机中的第一候选虚拟机，先基于第一候选虚拟机为第一线程提供的第一总负载量、第一线程的负载量以及第二线程的负载量，分别对第一线程的负载量以及第二线程的负载量进行预测，得到第一预测负载量以及第二预测负载量；若第一预测负载量与第二预测负载量之间的差值的绝对值小于或等于第二阈值，再为第一候选虚拟机分配第二线程，其中，第一预测负载量为将第一候选虚拟机调度到第二线程后第一线程的负载量，第二预测负载量为将第一候选虚拟机调度到第二线程后第二线程的负载量。
基于上述可能的实现方式，通过在第一预测负载量与第二预测负载量之间的差值的绝对值小于或等于第二阈值的情况下，为第一候选虚拟机分配第二线程，以便将第一候选虚拟机调度到第二线程后，使得第一线程的负载量达到第一预测负载量，使得第二线程的负载量达到第二预测负载量，由于在第一预测负载量与第二预测负载量之间的差值的绝对值小于第二阈值，从而使得调度后的第一线程和第二线程达到负载均衡，即通过提前预测负载量确保调度后的第一线程和第二线程达到负载均衡。
在一种可能的实现方式中，通信单元为线程，至少一种资源的负载量包括多个线程的负载量，目标通信单元为线程，基于此，上述基于至少一种通信单元的负载量，为至少一个加速卡中的目标虚拟机分配目标通信单元的过程包括：先基于多个线程的负载量，从多个线程中，确定第三线程以及第四线程；再为至少一个第三虚拟机中的目标虚拟机分配第四线程，其中，第三线程的负载量大于或等于第三阈值，第四线程的负载量小于第三线程的负载量第三虚拟机为多个虚拟机中第三线程通信的虚拟机。
基于上述可能的实现方式，通过为至少一个第三虚拟机中的目标虚拟机分配第四线程，以便将目标虚拟机从第三线程调度到第四线程，避免后续目标虚拟机的数据处理请求长时间在第三线程排队等待处理，提高了目标虚拟机的数据处理效率，降低了第三线程的负载量，提高了第三线程的处理效率，也能使得第二线程提供的资源能够被充分使用，避免第二线程的资源浪费。
在一种可能的实现方式中，上述为至少一个第三虚拟机中的目标虚拟机分配第四线程的过程包括：对于至少一个第三虚拟机中的第二候选虚拟机，先基于第二候选虚拟机为第三线程提供的第二总负载量、第三线程的负载量以及第四线程的负载量，分别对第三线程的负载量以及第四线程的负载量进行预测，得到第三预测负载量以及第四预测负载量；若第三预测负载量与第四预测负载量之间的差值的绝对值小于或等于第四阈值，再为第二候选虚拟机分配第四线程，其中，第三预测负载量为将第二候选虚拟机调度到第四线程后第三线程的负载量，第四预测负载量为将第二候选虚拟机调度到第四线程后第四线程的负载量。
基于上述可能的实现方式，通过在第三预测负载量与第四预测负载量之间的差值的绝对值小于或等于第四阈值的情况下，为第二候选虚拟机分配第四线程，以便将第二候选虚拟机调度到第四线程后，使得第三线程的负载量达到第三预测负载量，使得第四线程的负载量达到第四预测负载量，由于在第三预测负载量与第四预测负载量之间的差值的绝对值小于第四阈值，从而使得调度后的第三线程和第四线程达到负载均衡，即通过提前预测负载量确保调度后的第三线程和第四线程达到负载均衡。
在一种可能的实现方式中，通信单元为线程，至少一种通信单元的负载量包括多个线程的负载量，目标通信单元为线程，基于此，上述基于至少一种通信单元的负载量，为至少一个加速卡中的目标虚拟机分配目标通信单元的过程包括：先基于多个线程的负载量，从多个线程中，确定多个第五线程；再为第四虚拟机分配多个第五线程中的第六线程，其中，多个第五线程的负载量之和小于或等于第五阈值，第四虚拟 机为与多个第五线程中的第七线程通信的虚拟机，第七线程为多个第五线程中除第六线程以外的线程。
基于上述可能的实现方式，通过将多个第五线程中各个第七线程上的第四虚拟机分配给多个第五线程中的第六线程，以便后续将各个第四虚拟机调度到第六线程，由第六线程负责与各个第四虚拟机通信，从而避免浪费线程资源。
在一种可能的实现方式中，通信单元为加速卡，至少一个加速卡包括多个加速卡，至少一种通信单元的负载量包括多个加速卡的负载量，目标通信单元为加速卡，基于此，上述基于至少一种通信单元的负载量，为至少一个加速卡中的目标虚拟机分配目标通信单元的过程包括：先基于多个加速卡的负载量，确定第一加速卡和第二加速卡；再为至少一个第五虚拟机中的目标虚拟机分配第二加速卡，其中，第一加速卡为多个加速卡中负载量最大的加速卡，第二加速卡为多个加速卡中负载量最小的加速卡，第五虚拟机为多个虚拟机中与第一加速卡通信的虚拟机。
基于上述可能的实现方式，通过为至少一个第五虚拟机中的目标虚拟机分配第二加速卡，以便将目标虚拟机从第一加速卡调度到第二加速卡，以避免后续目标虚拟机的数据处理请求长时间在第一加速卡排队等待处理，提高了目标虚拟机的数据处理效率，降低了第一加速卡的负载量，提高了第一加速卡的处理效率，也能使得第二加速卡提供的资源能够被充分使用，避免第二加速卡的资源浪费。
在一种可能的实现方式中，上述为至少一个第五虚拟机中的目标虚拟机分配第二加速卡的过程包括：对于至少一个第五虚拟机中的第三候选虚拟机，先基于第三候选虚拟机为第一加速卡提供的第三总负载量、第一加速卡的负载量以及第二加速卡的负载量，分别对第一加速卡的负载量以及第二加速卡的负载量进行预测，得到第五预测负载量以及第六预测负载量；若第五预测负载量与第六预测负载量之间的差值的绝对值小于或等于第六阈值，再为第三候选虚拟机分配第二加速卡，其中，第五预测负载量为将第三候选虚拟机调度到第二加速卡后第一加速卡的负载量，第六预测负载量为将第三候选虚拟机调度到第二加速卡后第二加速卡的负载量。
基于上述可能的实现方式，通过在第五预测负载量与第六预测负载量之间的差值的绝对值小于或等于第六阈值的情况下，才为第三候选虚拟机分配第二加速卡，以便将第三候选虚拟机调度到第二加速卡，使得第一加速卡的负载量达到第四预测负载量，使得第二加速卡的负载量达到第六预测负载量，由于在第四预测负载量与第六预测负载量之间的差值的绝对值小于第六阈值，从而使得调度后的第一加速卡和第二加速卡达到负载均衡，即通过提前预测负载量确保调度后的第一加速卡和第二加速卡达到负载均衡。
在一种可能的实现方式中，为至少一个第五虚拟机中的目标虚拟机分配第二加速卡之后，此方法还包括如下步骤：若第一加速卡和第二加速卡的类型不同，从多个虚拟机的会话信息库，查询目标虚拟机的会话信息，会话信息库用于存储多个虚拟机的会话信息；将目标虚拟机的会话信息存储至第二加速卡的会话池，会话池用于存储与第二加速卡通信的虚拟机的会话信息。
基于上述可能的实现方式，以便后续目标虚拟机中应用程序的数据处理请求在下发到第二加速卡后，第二加速卡根据数据处理请求携带的会话标识，能够从自己的会话池中该应用程序的会话信息。
在一种可能的实现方式中，通信单元为加速卡，至少一个加速卡包括多个加速卡，至少一种通信单元的负载量包括多个加速卡的负载量，目标通信单元为加速卡，基于此，上述基于至少一种通信单元的负载量，为至少一个加速卡中的目标虚拟机分配目标通信单元的过程包括：先基于多个加速卡的负载量，确定第一加速卡；若第一加速卡的负载量大于或等于第七阈值，且多个加速卡中存在空闲加速卡，再为至少一个第五虚拟机中的目标虚拟机分配空闲加速卡，其中，第一加速卡为多个加速卡中负载量最大的加速卡，第五虚拟机为多个虚拟机中与第一加速卡通信的虚拟机。
基于上述可能的实现方式，通过为至少一个第五虚拟机中的目标虚拟机分配空闲加速卡，以便将目标虚拟机从第一加速卡调度到空闲加速卡，以避免后续目标虚拟机的数据处理请求长时间在第一加速卡排队等待处理，提高了目标虚拟机的数据处理效率，降低了第一加速卡的负载量，提高了第一加速卡的处理效率，也能使得空闲加速卡提供的资源能够被充分使用，避免空闲加速卡的资源浪费。
在一种可能的实现方式中，通信单元为加速卡，至少一个加速卡包括多个加速卡，至少一种通信单元的负载量包括多个加速卡的负载量，目标通信单元为加速卡，基于此，上述基于至少一种通信单元的负载量，为至少一个加速卡中的目标虚拟机分配目标通信单元的过程包括：先基于多个加速卡的负载量，从多个加速卡中，确定多个第三加速卡；再为第六虚拟机分配多个第三加速卡中的第四加速卡，第六虚拟机为与多个第三加速卡中的第五加速卡通信的虚拟机，其中，多个第三加速卡的负载量之和小于或等于第八阈 值，第五加速卡为多个第三加速卡中除第四加速卡以外的加速卡。
基于上述可能的实现方式，通过为多个第三加速卡中各个第五加速卡上的第六虚拟机分配第四加速卡，以便将各个第六虚拟机都调度到多个第三加速卡中的第四加速卡，由第四加速卡负责与各个第六虚拟机通信，从而避免占用过多的加速卡。
第二方面，提供了一种虚拟机的调度装置，用于执行上述虚拟机的调度方法。具体地，该虚拟机的调度装置包括用于执行上述第一方面或上述第一方面的任一种可选方式提供的虚拟机的调度方法的功能模块。
第三方面，提供一种芯片，该芯片包括处理器，所述处理器用于执行程序代码，使得芯片执行以实现如上述虚拟机的调度方法所执行的操作。
第四方面，提供一种计算机设备，该计算设备包括处理器，所述处理器用于执行程序代码，使得计算机设备执行以实现如上述虚拟机的调度方法所执行的操作。
第五方面，提供一种计算机可读存储介质，该存储介质中存储有至少一条程序代码，该程序代码由芯片/计算机设备中的处理器读取以使芯片/计算机设备执行如上述虚拟机的调度方法的操作步骤。
第六方面，提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括程序代码，该程序代码存储在计算机可读存储介质中，芯片/计算机设备的处理器从计算机可读存储介质读取该程序代码，处理器执行该程序代码，使得该芯片/计算机设备执行上述第一方面或第一方面的各种可选实现方式中提供的方法。
本申请在上述各方面提供的实现方式的基础上，还可以进行进一步组合以提供更多实现方式。
附图说明
图1是本申请实施例提供的一种应用虚拟机的调度方法的计算机设备示意图；
图2是本申请实施例提供的一种虚拟机的调度方法的流程图；
图3是本申请实施例提供的一种基于调度策略1的虚拟机的调度方法流程图；
图4是本申请实施例提供的一种基于调度策略1调度虚拟机的示意图；
图5是本申请实施例提供的一种基于调度策略2的虚拟机的调度方法流程图；
图6是本申请实施例提供的一种基于调度策略2调度虚拟机的示意图；
图7是本申请实施例提供的一种基于调度策略3的虚拟机的调度方法流程图；
图8是本申请实施例提供的一种基于调度策略3调度虚拟机的示意图；
图9是本申请实施例提供的一种基于调度策略4的虚拟机的调度方法流程图；
图10是本申请实施例提供的一种基于调度策略4调度虚拟机的示意图；
图11是本申请实施例提供的一种基于调度策略5的虚拟机的调度方法流程图；
图12是本申请实施例提供的一种基于调度策略5调度虚拟机的示意图；
图13是本申请实施例提供的一种基于调度策略6的虚拟机的调度方法流程图；
图14是本申请实施例提供的一种基于调度策略6调度虚拟机的示意图；
图15是本申请实施例提供的一种基于调度策略7的虚拟机的调度方法流程图；
图16是本申请实施例提供的一种基于调度策略7调度虚拟机的示意图；
图17是本申请实施例提供的一种虚拟机迁移过程的示意图；
图18是本申请实施例提供的一种虚拟机的调度装置的结构示意图；
图19是本申请实施例提供的一种芯片的结构示意图；
图20是本申请实施例提供的一种计算机设备的结构示意图。
具体实施方式
为了便于本申请提出的技术方案，在此，对本申请涉及的部分名词进行如下解释：
主机(host)：物理机，主机被配置为服务器，该服务器例如云服务器、本地服务器或者数据中心的服务器，在此，对服务器的使用环境不做限定。该服务器可能是x86系统架构的服务器、进阶精简指令集机器(advanced RISC machine，ARM)的标准Linux系统服务器或者其他架构的服务器，在此，本申请对涉及的服务器的架构不做限定。
虚拟机：是在主机上利用虚拟化技术虚拟出来的服务器，内部可运行x86系统或者ARM Linux系统。换言之，虚拟机是通过软件模拟的具有完整硬件系统功能的、运行在一个完全隔离环境中的完整计算机系统。在服务器中能够完成的工作在虚拟机中都能够实现。在服务器中创建虚拟机时，需要将实体机的部分硬盘和内存容量作为虚拟机的硬盘和内存容量，每个虚拟机都有独立的硬盘和操作系统，虚拟机的用户可以像使用服务器一样对虚拟机进行操作。
虚拟化技术：主要由计算虚拟化、输入输出(input out，IO)虚拟化组成，作为云场景的核心技术，它以虚拟机为粒度将一台物理服务器共享给多个租户使用，使租户能在安全隔离的前提下方便灵活地使用物理资源，并且能极大提升物理资源的利用率。虚拟化技术例如基于Linux内核的虚拟机(Kernel-based virtual machine，KVM)以及虚拟机监视器(Xen)等。
计算虚拟化：是将服务器的处理器和内存等计算资源提供给虚拟实例使用，虚拟实例例如为虚拟机，在其他应用场景中，虚拟实例为容器、裸金属服务器。
输入输出虚拟化：包括网络虚拟化以及存储虚拟化，其中，网络虚拟化是指将服务器中网卡的部分功能(如带宽)提供给虚拟机，存储虚拟化是指将服务器中部分磁盘提供给虚拟机。
应用程序(application，APP)：是虚拟机中运行的需要使用到加速卡的任一应用程序。
加速卡：用于为服务器中的处理器承担部分计算任务，或者，也可以理解为，将服务器中处理器的部分计算任务或者部分数据处理功能卸载到加速卡，由加速卡来实现这部分计算任务或这部分数据处理功能，加速卡也可以称为卸载卡。以服务器中的某一应用程序为软件定义的广域网(software defined wide area network，SD-WAN)中部署的虚拟客户端设备(virtual customer premises equipment，vCPE)为例，在vCPE需要数据加密和/或数据解密(简称为数据加解密)服务的情况下，将数据加解密服务从处理器卸载到加速卡上，此时由加速卡为vCPE提供数据加解密服务，此时，该加速卡也可以称为加密卡，加密卡例如快速辅助技术(quick assist technology，QAT)加速卡以及网络扩充卡(Mellanox，MLX)等。再例如，将数据压缩和/或数据解压(简称为数据解压缩)服务从服务器的处理器卸载到加速卡上，由加速卡为虚拟机中的应用程序提供数据解压缩服务，其中，数据解压缩例如解压缩应用程序的IO请求。
标准的半虚拟化IO设备模型(towards a de-facto standard for virtual IO devices，virtio)：是一套通用IO设备虚拟化的程序，作为虚拟机与加速卡之间的虚拟设备，用于为虚拟机中的应用程序与加速卡之间的通信提供通信链路。标准的半虚拟化IO设备模型包括前端驱动程序以及后端驱动程序，其中，前端驱动程序运行在虚拟机中，用于和虚拟机中的应用程序以及后端驱动程序通信，前端驱动程序和后端驱动程序配合使用，以承接应用程序下发的数据处理请求。后端驱动程序运行在计算机设备的操作系统(相对虚拟机的操作系统可称为宿主机操作系统)中，以和前端驱动程序以及加速卡通信，例如，后端驱动程序将应用程序下发的数据处理请求转发给加速卡以及通过前端驱动程序将加速卡返回的数据处理响应返回给应用程序。其中，虚拟机管理器用于实现虚拟机的计算虚拟化、网络虚拟化以及存储虚拟化，并负责管理虚拟机。在一些实施例中，前端驱动程序和后端驱动程序分别称为虚拟IO设备前端和虚拟IO设备后端。在另一些实施例中，前端驱动程序简称为virtio，后端驱动程序简称虚拟主机(virtual host，vhost)，示例性地，以加速卡为加密(crypto)卡为例，与加密卡配套的前端驱动程序简称为virtio_crypto，与加密卡配套的后端驱动程序简称为vhost_crypto。
虚拟功能单元：加速卡通过单根I/O虚拟化(single-root I/O virtualization，SR-IOV)技术呈现出来的虚拟的外设组件互连标准(peripheral component interconnect，PCI)设备。其中，一个加速卡可以虚拟出多个虚拟功能单元，这多个虚拟功能单元共享加速卡中的物理资源，其中，物理资源例如CPU资源以及内存资源等)。
线程：也称为转发线程，通过消耗服务器的CPU资源和内存资源，在后端驱动程序与加速卡之间传递应用程序下发的数据处理请求以及加速卡返回的数据处理响应。
为使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请实施方式作进一步地详细描述。
图1是本申请实施例提供的一种应用虚拟机的调度方法的计算机设备示意图，计算机设备100也称为主机，可以被配置为服务器，如云服务器、本地服务器或者数据中心的服务器。
如图1所示，计算机设备100中配置有至少一个加速卡101，如图1中的加速卡101a-101b，加速卡101作为物理硬件设备配置在计算机设备100的硬件层，示例性地，加速卡101可插置到计算机设备100 的PCI插槽。在计算机设备100中的加速卡101有多个的情况下，多个加速卡101的类型可能相同，也可能不同，如图1所示的计算机设备100包括QAT以及MLX这两种类型的加速卡，应当理解，图1示出的这两种加速卡101为示例不应当对计算机设备100内加速卡101的类型构成限定，在此，本申请实施例对计算机设备100中加速卡101的个数以及类型不做限定。
如图1所示，每个加速卡101包括多个虚拟功能单元110，同一加速卡101中的虚拟功能单元110共享这个加速卡101中的硬件资源。另外，该加速卡101还包括多个队列对，每个队列对包括第二请求队列以及第二响应队列，第二请求队列用于存储应用程序的数据处理请求，第二响应队列用于加速卡101对第一请求队列中数据处理请求的数据处理响应。其中，数据处理请求指示数据处理请求指示加速卡101对目标数据进行处理，加速卡101为加密卡为例，该数据处理请求为数据加解密请求指示加速卡101对目标数据进行加密处理或解码处理，该数据处理响应包括数据处理请求中目标数据的处理结果。
如图1所示，计算机设备100中还配置有多个虚拟机102，如图1中的虚拟机102a-102c，每个虚拟机102中运行有至少一个应用程序，虚拟机102对应至少一个标准的虚拟化IO设备模型，其对应的标准的半虚拟化IO设备模型中的前端驱动程序运行在虚拟机102中，后端驱动程序运行在计算机设备100的操作系统。其中，该标准的虚拟化IO设备模型中配置有第一请求队列和第一响应队列，第一请求队列用于存储应用程序向加速卡101发送的数据处理请求。第一响应队列用于存储加速卡101对数据处理请求的数据处理响应。
如图1所示，计算机设备100中还配置有多个线程103，如图1中的线程103a-103d，线程103用于在后端驱动程序以及虚拟功能单元110之间进行通信。
如图1所示，计算机设备100还配置有调度器104，调度器104对计算机设备100中的通信单元进行管理，其中，计算机设备100中的通信单元包括加速卡101、虚拟功能单元110以及线程103等多种不同类型的通信单元。以对虚拟功能通信单元进行管理为例，调度器104支持虚拟功能单元池化。示例性，初始化时，调度器104扫描计算机设备100中各个加速卡101的虚拟功能单元110，将扫描到的每个虚拟功能单元110分别抽象为一个物理转发端口，得到每个物理转发端口的端口信息，将每个物理转发端口的端口信息都存储在物理端口池(或称为虚拟功能池)中，其中，每个物理转发端口的端口信息包括物理转发端口的端口标识以及该物理转发端口所属加速卡的加速卡标识，换言之，端口信息为虚拟功能单元的描述信息，端口信息中的端口标识也即是虚拟功能单元的标识。
调度器104还用于建立虚拟机102与加速卡101之间的VF通道，以便虚拟机102中的应用程序通过VF通道与加速卡101进行通信，示例性地，初始化时，调度器104为每个虚拟机102分别配置至少一个标准的半虚拟化IO设备模型，对于为每个虚拟机102配置的任一个标准的半虚拟化IO设备模型，从物理端口池中为该虚拟化IO设备模型分配至少一个物理转发端口，从而实现为该半虚拟化IO设备模型所属的虚拟机分配虚拟功能单元。另外，在该标准的半虚拟化IO设备模型中的后端驱动程序与物理转发端口之间建立线程103，通过线程103连接后端驱动程序与物理转发端口，从而虚拟化IO设备模型、该线程103以及该物理转发端口组成该虚拟机102的至少一个VF通道。另外，该调度器104存储每个VF通道的通道信息，其中，该通道信息包括一个标准的虚拟化IO设备模型的模型标识、一个线程的线程标识以及一个虚拟功能单元所虚拟成的物理转发端口的端口信息。在一些实施例中，该通道信息中的模型标识也可以替换成该标准的虚拟化IO设备模型中后端驱动程序的程序标识。
另外，调度器104还用于向每个线程103发送每个线程103所在VF通道的通道信息，以便每个线程103根据通道信息在对应VF通道的后端驱动程序与物理转发端口之间进行消息转发。下面对任一虚拟机102通过该VF通道与任一加速卡101进行通信的过程做如下介绍：
在虚拟机102中任一应用程序需要使用到加速卡101的情况下，该应用程序向虚拟机102配置的任一标准的虚拟化IO设备模型的前端驱动程序发送数据处理请求，前端驱动程序每接收到一个数据处理请求，将该数据处理请求加入到该虚拟化IO设备模型中后端驱动程序的第一请求队列，该第一请求队列用于存储应用程序的数据处理请求。对于计算机设备100中的任一线程103，线程103记录调度器104提供的至少一个VF通道的通道信息，对于任一VF的通道信息，线程103根据该通道信息中后端驱动程序的程序标识，从该后端驱动程序的第一请求队列读取数据处理请求，在该数据读取请求中添加该程序标识，以指示数据读取请求的来源。之后，线程103根据该通道信息中的物理转发端口的端口信息，将该数据处理请求转发到物理转发端口对应的虚拟功能单元的第二请求队列，加速卡101从该第二请求队列读取该数据处 理请求，根据为该虚拟功能分配的硬件通信单元，对该数据处理请求中的目标数据进行处理，得到数据处理响应，加速卡101将数据处理请求中的程序标识添加到数据处理响应后，将该数据处理响应加入到与该虚拟功能单元对应的第二响应请求队列，其中，加速卡101对该数据处理请求的处理过程，也可以理解为虚拟功能单元110对该数据处理请求的过程。对于计算机设备100中的任一线程103，线程103根据记录的任一VF通道的通道信息中的端口信息，从对应虚拟功能单元的第二响应队列读取数据处理响应，根据数据处理响应中的程序标识，向对应后端驱动程序的第一响应队列发送该数据处理请求，该后端驱动程序将第一响应队列中的数据处理请求发送到该后端驱动程序对应的前端驱动程序，前端驱动程序再将该数据处理响应发送给应用程序。当应用程序接收到任一数据处理请求的数据处理响应时，即该VF通道上的各个通信单元处理完成了该数据处理请求。
上述是以一个后端驱动程序共享至少一个物理转端口为例进行说明的，在另一些实施例中，至少一个后端驱动程序共享同一个物理转发端口，即将至少一个后端驱动程序共享同一个虚拟功能单元，以图1所示的计算机设备100为例，虚拟机102a和102b共享一个物理转发端口，从而无需将虚拟机102与固定单个虚拟功能单元110绑定，提高了虚拟功能单元110的复用率。
在一种可能的实现方式中，调度器104还用于通过执行本申请提出的虚拟机的调度方法，为虚拟机102分配虚拟功能单元110、线程103以及加速卡101中的至少一种通信单元，将虚拟机102调度到分配的通信单元，使得虚拟机102能够与分配的通信单元通信。
上述介绍的调度器104通过软件实现、硬件实现或者软硬件结合的方式实现。调度器104作为软件功能单元的一种举例，调度器104包括运行在计算实例上的代码。其中，计算实例包括虚拟机、容器中的至少一种。进一步地，上述计算实例可以是一台或者多台。例如，调度器104包括运行在多个虚拟机/容器上的代码。另外，用于运行该代码的多个虚拟机102/容器可能分布在相同的区域(region)中，也可能分布在不同的region中。进一步地，用于运行该代码的多个虚拟机/容器可能分布在相同的可用区(availability zone，AZ)中，也可能分布在不同的AZ中，每个AZ包括一个数据中心或多个地理位置相近的数据中心。其中，通常一个region可以包括多个AZ。
当采用运行在计算实例上的代码实现调度器104时，用于运行该代码的多个虚拟机/容器可以分布在同一个虚拟私有云(virtual private cloud，VPC)中，也可以分布在多个VPC中。其中，通常一个VPC设置在一个region内，同一region内两个VPC之间，以及不同region的VPC之间跨区通信需在每个VPC内设置通信网关，经通信网关实现VPC之间的互连。
调度器104作为硬件功能单元的一种举例，调度器104可能是利用专用集成电路(application-specific integrated circuit，ASIC)实现或可编程逻辑器件(programmable logic device，PLD)实现的设备等。其中，上述PLD可以是复杂程序逻辑器件(complex programmable logical device，CPLD)、现场可编程门阵列(field-programmable gate array，FPGA)、通用阵列逻辑(generic array logic，GAL)、数据处理单元(data processing unit，DPU)、片上系统(system on chip，SoC)或其任意组合实现。
接下来，基于上述介绍计算机设备，对本申请提供的虚拟机的调度方法作如下介绍：
图2是本申请实施例提供的一种虚拟机的调度方法的流程图，该方法应用于计算机设备，该计算机设备中配置有至少一个加速卡、多个虚拟机以及多个线程，该加速卡包括多个虚拟功能单元，虚拟机通过至少一个线程与至少一个虚拟功能单元通信，该方法由计算机设备内的调度器来执行，该方法包括如下步骤。
201、调度器获取该计算机设备的至少一种通信单元的负载量，该通信单元为虚拟功能单元、线程或加速卡，该通信单元的负载量与该多个虚拟机有关。
其中，该计算机设备至少具有虚拟功能单元、线程以及加速卡这3种类型的通信单元，该至少一种通信单元包括这3种通信单元中的至少一种，在该通信单元为虚拟功能单元的情况下，该至少一种通信单元的负载量包括该计算机设备中至少一个加速卡中各个虚拟功能单元的负载量。在该通信单元为该线程的情况下，该至少一种通信单元的负载量包括该多个线程的负载量，在该通信单元为加速卡的情况下，该至少一种通信单元的负载量包括该至少一个加速卡的负载量。
任一虚拟功能单元的负载量为目标时长中至少一个虚拟机为该虚拟功能单元提供的负载量之和，其中，该至少一个虚拟机为目标时长中与该虚拟功能单元通信的虚拟机，任一虚拟机为该虚拟功能单元提供的负载量等于该任一虚拟机与该虚拟功能单元之间的标准的虚拟化IO设备模型数量。例如，某一虚拟机通过2个标准的虚拟化IO设备模型与该虚拟功能单元通信，则该虚拟机为该虚拟功能单元提供的负载量为2。 该目标时长可根据具体实施场景进行设置，在此，本申请实施例对目标时长不做限定。
由于VF通道中线程在后端驱动程序与虚拟功能单元之间以零拷贝的方式转发应用程序的数据处理请求以及虚拟功能单元的数据处理请求，因此，不同长度的数据处理请求的在线程所消耗资源一致，基于此，任一后端驱动程序的负载量为单位时间内该后端驱动程序处理完成的数据处理请求的次数。该单位时间例如1秒，在单位时间为1秒的情况下，任一后端驱动程序的负载量的该后端驱动程序每秒的输入/输出操作数(input/output operations per second，IOPS)，当然，单位时间的时长也可能有其他的数值，在此，本申请实施例对单位时间的时长不再限定。
任一线程的负载量为目标时长中与该线程通信的后端驱动程序的负载量之和。
任一加速卡的负载量为目标时长中至少一个虚拟机为该加速卡提供的负载量之和，其中，该至少一个虚拟机为目标时长中与该加速卡中的虚拟功能单元通信的虚拟机。
任一虚拟机为该加速卡的虚拟功能单元提供的负载量等于该虚拟机对应的且与加速卡通信的至少一个后端驱动程序的负载量之和。若目标时长中该虚拟机通过一个后端驱动程序与该加速卡的虚拟功能单元通信，则该虚拟机为该加速卡的虚拟功能单元提供的负载量为该后端驱动程序的负载量，若目标时长中该虚拟机通过多个后端驱动程序与该加速卡的虚拟功能单元通信，则该虚拟机为该加速卡的虚拟功能单元提供的负载量为该多个后端驱动程序的负载量之和。
在一种可能的实现方式中，调度器中配置有下述7种调度策略中的至少一种调度策略，每种调度策略对应计算机设备的一种通信单元，以指示基于对应通信单元的负载量，为计算机设备中的部分虚拟机分配对应的通信单元，将这部分虚拟机调度至分配的通信单元，以使这部分虚拟机与分配的通信单元进行通信。基于此，调度器基于配置的至少一种调度策略，每间隔目标时长获取该至少一种调度策略对应通信单元的负载量。下面分别结合这7种调度策略，该过程做如下介绍：
调度策略1、跨虚拟功能单元调度虚拟机
其中，调度策略1对应的通信单元为虚拟功能单元，调度策略1指示基于该计算机设备的虚拟功能单元的负载量，为计算机设备中的部分虚拟机分配虚拟功能单元，将这部分虚拟机调度至分配的虚拟功能单元。在调度器中配置有采用调度策略1调度虚拟机的情况下，在执行本步骤201时，调度器每经过目标时长，统计该计算机设备内与每个虚拟功能单元的负载量，该过程在步骤301中进行详细介绍，在此不再赘述。由于每个虚拟功能单元对应一个物理转发端口，因此，跨虚拟功能单元调度虚拟机也即是跨物理转发端口调度虚拟机。
调度策略2、跨线程转发调度虚拟机
其中，调度策略2对应的通信单元为线程，调度策略2指示基于该计算机设备中线程的负载量，为计算机设备中的部分虚拟机分配线程，将这部分虚拟机调度至分配的线程。在调度器中配置有采用调度策略2调度虚拟机的情况下，在执行本步骤201时，调度器每经过目标时长，统计该计算机设备内每个线程的负载量。该过程在步骤501中进行详细介绍，在此不再赘述。
调度策略3、通过动态增加线程调度虚拟机
其中，调度策略3对应的通信单元为线程，调度策略3指示基于该计算机设备中线程的负载量，通过为计算机设备中的部分虚拟机增加线程，以实现为这部分虚拟功能单元分配线程，将这部分虚拟机调度至分配的线程。在调度器中配置有采用调度策略3调度虚拟机的情况下，在执行本步骤201时，调度器每经过目标时长，统计该计算机设备内每个线程的负载量，该过程在步骤501中进行详细介绍，在此不再赘述。
另外，在调度器中配置有采用调度策略3调度虚拟机的情况下，每经过目标时长，采用调度策略3为计算机设备中的部分虚拟机增加线程，经过多个目标时长后，也就实现了动态增加线程。
调度策略4、通过动态减少线程调度虚拟机
其中，调度策略4对应的通信单元为线程，调度策略4指示基于该计算机设备中线程的负载量，通过为计算机设备中的部分虚拟机减少线程，以实现为这部分虚拟功能单元分配线程。在调度器中配置有采用调度策略4调度虚拟机的情况下，在执行本步骤201时，调度器每经过目标时长，统计该计算机设备内每个线程的负载量，该过程在步骤501中进行详细介绍，在此不再赘述。
另外，在调度器中配置有采用调度策略4调度虚拟机的情况下，每经过目标时长，采用调度策略4为计算机设备中的部分虚拟机减少线程，经过多个目标时长后，也就实现了动态减少线程。
调度策略5、跨加速卡调度虚拟机
其中，调度策略5对应的通信单元为加速卡，调度策略5指示基于该计算机设备中加速卡的负载量，为计算机设备中的部分虚拟机分配加速卡，将这部分虚拟机调度至分配的加速卡。在调度器中配置有采用调度策略5调度虚拟机的情况下，在执行本步骤201时，调度器每经过目标时长，统计该计算机设备内每个加速卡的负载量，该过程在步骤1101中进行详细介绍，在此不再赘述。
调度策略6、通过动态增加加速卡调度虚拟机
其中，调度策略6对应的通信单元为加速卡，调度策略6指示基于该计算机设备中加速卡的负载量，通过为计算机设备中的部分虚拟机增加加速卡，以实现为这部分虚拟功能单元分配加速，将这部分虚拟机调度至分配的加速卡。在调度器中配置有采用调度策略6调度虚拟机的情况下，在执行本步骤201时，调度器每经过目标时长，统计该计算机设备内每个加速卡的负载量，该过程在步骤1101中进行详细介绍，在此不再赘述。
另外，在调度器中配置有采用调度策略6调度虚拟机的情况下，每经过目标时长，采用调度策略6为计算机设备中的部分虚拟机增加加速卡，经过多个目标时长后，也就实现了动态增加加速卡。
调度策略7、通过动态减少加速卡调度虚拟机
其中，调度策略7对应的通信单元为加速卡，调度策略7指示基于该计算机设备中加速卡的负载量，通过为计算机设备中的部分虚拟机减少加速卡，以实现为这部分虚拟功能单元分配加速卡。在调度器中配置有采用调度策略7调度虚拟机的情况下，在执行本步骤201时，调度器每经过目标时长，统计该计算机设备内每个加速卡的负载量，该过程在步骤1101中进行详细介绍，在此不再赘述。
另外，在调度器中配置有采用调度策略7调度虚拟机的情况下，每经过目标时长，采用调度策略7为计算机设备中的部分虚拟机减少加速卡，经过多个目标时长后，也就实现了动态减少加速卡。
202、调度器基于该至少一种通信单元的负载量，为该至少一个加速卡中的目标虚拟机分配目标通信单元，该目标通信单元为虚拟功能单元、线程或加速卡。
其中，目标虚拟机是本次待调度的虚拟机，目标通信单元是本次为该目标虚拟机分配的通信单元。
调度器基于不同的调度策略，调度目标虚拟机的方式不同，后续将结合附图3-16，对不同调度策略下本步骤202的执行过程做详细介绍，在此不再赘述。
203、调度器将该目标虚拟机调度到该目标通信单元，以使该目标虚拟机与该目标通信单元能够通信。
在一种可能的实现方式中，调度器基于该目标虚拟机以及目标通信单元，生成目标VF通道的目标通道信息，该目标VF通道用于连通该目标虚拟机目标通信单元，目标VF通道包括目标虚拟机对应的后端驱动程序、该目标线程以及目标物理转发端口，该目标通信单元为目标线程、目标物理转发端口对应的虚拟功能单元(即目标虚拟功能单元)或该目标虚拟功能单元所属的加速卡(即目标加速卡)。
调度器向目标VF通道中的目标线程发送目标通道信息，以便目标线程基于目标通道信息在目标虚拟功能单元与目标虚拟机之间建立目标VF通道，以将该目标虚拟机调度到该目标通信单元，使得目标虚拟机通过目标VF通道能够与目标通信单元通信。例如，目标线程基于该目标通道信息，对于目标VF通道，在该目标虚拟机对应的后端驱动程序以及该目标虚拟功能单元之间进行消息转发，从而使得该目标虚拟机能够与目标VF通道中的各部分通信，也能和该目标虚拟功能单元通信，在与该目标虚拟功能单元通信时，也就实现了与目标加速卡通信。
本申请实施例提供的方法，通过基于计算机设备的虚拟功能单元、线程以及加速卡中至少一种通信单元的负载量，为计算机设备中的目标虚拟机分配目标通信单元，将目标虚拟机调度到分配的目标通信单元，使得目标虚拟机与目标通信单元能够进行通信，由于能够基于至少一种通信单元的负载量为目标虚拟机分配目标通信单元，从而使得与目标虚拟机通信的虚拟功能单元并不固定，也就无需将目标虚拟机与固定的虚拟功能单元绑定，随着目标虚拟机在加速卡的不同通信单元之间进行调度，使得目标虚拟机能够与不同的虚拟功能单元灵活通信，从而提高了虚拟机与加速卡之间通信方式的灵活性。
图3是本申请实施例提供的一种基于调度策略1的虚拟机的调度方法流程图，该方法应用于计算机设备中配置有至少一个加速卡、多个虚拟机以及多个线程，该加速卡包括多个虚拟功能单元，虚拟机通过至少一个线程与至少一个虚拟功能单元通信，该方法由计算机设备内的调度器来执行，该方法包括如下步骤。
301、调度器获取计算机设备的至少一个加速卡中各个虚拟功能单元的负载量，该负载量与计算机设备中的该多个虚拟机有关。
其中，该至少一个加速卡中各个虚拟功能单元的负载量也即是计算机设备中虚拟功能单元这一种通信 单元的负载量。
在调度器中配置有采用调度策略1调度虚拟机的情况下，对于计算机设备中的每个虚拟功能单元，调度器每经过目标时长，统计目标时长中与该虚拟功能单元通信的后端驱动程序的数量，将该数量作为该虚拟功能单元的负载量。
302、调度器基于该至少一个加速卡中各个虚拟功能单元的负载量，确定第一虚拟功能单元以及第二虚拟功能单元，该第一虚拟功能单元为该至少一个加速卡中负载量最大的虚拟功能单元，该第二虚拟功能单元为该至少一个加速卡中负载量最小的虚拟功能单元。
其中，该第一虚拟功能单元和该第二虚拟功能单元分别为目标时长中该至少一个加速卡内的最大负载虚拟功能单元和最小负载虚拟功能单元，该第一虚拟功能单元与第二虚拟功能单元可能属于同一加速卡，也可能属于不同的加速卡。
例如，将该至少一个加速卡中负载量最大的虚拟功能单元确定为第一虚拟功能单元，将该至少一个加速卡中负载量最小的虚拟功能单元确定为第二虚拟功能单元。
303、若第一虚拟功能单元与第二虚拟功能单元之间的第一负载量差值大于或等于第一阈值，调度器为至少一个第一虚拟机中的目标虚拟机分配第二虚拟功能单元，该第一虚拟机为该多个虚拟机中与第一虚拟功能单元通信的虚拟机。
其中，第一负载量差值为第一虚拟功能单元的负载量与第二虚拟功能单元的负载量之间差值。第一阈值大于0，第一阈值可根据具体实施场景进行设置，在此，本申请实施例对第一阈值的取值不做限定。该至少一个第一虚拟机是与第一虚拟功能单元通信的所有虚拟机，该第二虚拟功能单元是本次为该目标虚拟机分配的目标虚拟功能单元。以图4所示的本申请实施例提供的一种基于调度策略1调度虚拟机的示意图为例，如图4所示的计算机设备中配置有加速卡400、虚拟机410-420以及线程1，在调度前，假设加速卡400中的虚拟功能单元401为第一虚拟功能单元，虚拟功能单元401通过线程1与虚拟机410-420，则虚拟机410-420为第一虚拟机。
在一种可能的实现方式中，调度器将第一虚拟功能单元的负载量与第二虚拟功能单元的负载量作差，得到第一负载量差值，若第一负载量差值大于或等于第一阈值，则第一虚拟功机以及第二虚拟功能单元满足调度条件，触发为该至少一个第一虚拟机中的部分虚拟机分配第二虚拟功能单元，以便后续将这部分虚拟机调度到第二虚拟功能单元，以减少第一虚拟功能单元的负载量。
在为多这部分虚拟机分配第二虚拟功能单元之前，调度器查询目标时长内第一虚拟功能单元对应的物理转发端口所在的第一VF通道，将每个第一VF通道所连接的虚拟机作为第一虚拟机，以确定出与该第一虚拟功能单元的至少一个第一虚拟机。其中，任一VF通道所连接的虚拟机为VF通道中的后端驱动程序对应的虚拟机。
下面对为多这部分虚拟机分配第二虚拟功能单元的方式作如下介绍：
在确定出至少一个第一虚拟机后，调度器从该至少一个第一虚拟机中筛选出目标虚拟机，调度器将该第二虚拟功能单元分配给该目标虚拟机。调度器通过下述方式1或2中的任一方式筛选目标虚拟机。
方式1、资源调度器基于第一负载量差值，确定第一个数，基于第一虚拟功能单元，确定该至少一个虚拟机对应的多个第一后端驱动程序，将该多个第一后端驱动程序中第一个数的第一后端驱动程序确定为目标后端驱动程序，该目标后端驱动程序所属的第一虚拟机为目标虚拟机。
其中，第一个数为待调度的目标后端驱动程序的个数，第一个数与1/2的第一负载量差值之间的差值小于或等于1。若1/2的第一负载量差值为整数，调度器将该整数作为第一个数，若1/2的第一负载量差值为不是整数，取比1/2的第一负载量差值的整数位大1或小1的数值作为第一个数，例如，若1/2的第一负载量差值为3.2，将2或4作为第一个数。
该多个第一后端驱动程序是该至少一个第一虚拟机与该第一虚拟机功能单元之间的后端驱动程序，每个第一虚拟机通过至少一个第一后端驱动程序与该第一虚拟机功能单元通信。以仍以图4为例，假设加速卡400中的虚拟功能单元402为第二虚拟功能单元，调度前，虚拟功能单元402不和任何虚拟机通信，虚拟功能单元402的负载量为0，虚拟功能单元401与虚拟功能单元402之间的第一负载量差值为2，假设第一阈值为2，则虚拟功能单元401与虚拟功能单元402之间的第一负载量差值大于或等于2，此时1/2的第一负载量差值为1，则调度器以1为第一个数，以虚拟功能单元402对应的后端驱动程序为目标后端驱动程序，以虚拟机420为待调度的目标虚拟机，将虚拟功能单元402分配给虚拟机420以及虚拟功能单元 402对应的后端驱动程序。
由于第一个数与1/2的第一负载量差值之间的差值小于或等于1，即使将第一个数的目标后端驱动程序分配给第二虚假功能单元，在将该目标后端驱动程序从第一虚拟功能单元调度到第二虚拟功能单元后，使得第二虚拟功能单元和第一虚拟功能单元的负载量之间的差值小于或等于1，使得调度后的第二虚拟功能单元和第一虚拟功能单元达到负载均衡。
方式2、资源调度器从该多个第一后端驱动程序中随机选择第二个数的第一后端驱动程序确定为目标后端驱动程序，其中，第二个数为预设个数，在此，本申请实施例对第二个数不做限定。
在确定出待调度的目标后端驱动程序后，对于任一目标后端驱动程序，以该目标后端驱动程序与第一虚拟功能单元之间的VF通道为该目标后端驱动程序的源VF通道，源VF通道的通道信息为源VF通道，以源VF通道中的线程为后端驱动程序的源线程，源VF通道中第一虚拟功能单元对应的物理转发端口为源物理转发端口，源物理转发端口的端口信息为源端口信息，以第二虚拟功能单元对应的物理转发端口为目标物理转发端口，目标物理转发端口的端口信息为目标端口信息，调度器查询该目标后端驱动程序的源通道信息，将查询到的源通道信息中的源端口信息替换为目标端口信息，得到目标通道信息，以将该第二虚拟功能单元分配该目标后端驱动程序所属的目标虚拟机，也即是将第二虚拟功能单元分配给该目标后端驱动程序所属的目标虚拟机。其中，目标通道信息所指示的VF也即是为本次待调度的目标虚拟机所建立的目标VF通道。
应当理解的是，步骤302至步骤303的所示的过程为步骤202的一种实现方式。
304、调度器将该目标虚拟机调度到该第二虚拟功能单元，以使该目标虚拟机与该第二虚拟功能单元能够通信。
对于任一目标后端驱动程序，在将第二虚拟功能单元分配给该目标后端驱动程序后，得到该目标后端驱动程序的目标通道信息，该调度器基于该目标通道信息中的线程标识，向该目标后端驱动程序所在的源线程发送通道信息更新请求，该通道信息更新请求指示将该目标后端驱动程序的源通道信息更新为该目标通道信息，该源线程接收到该通道信息更新请求后，基于该通道信息更新请求，将存储的该源通道信息更新为该目标通道信息，根据该目标通道信息，建立目标VF通道，以将目标后端驱动程序调度到第二虚拟功能单元，此时目标VF通道包括该目标后端驱动程序、该源线程以及目标物理转发端口。此时的源线程对于目标后端驱动程序所属的目标虚拟机而言，也即是目标线程。另外，源线程还删除目标后端驱动程序所在的源VF通道。
由于每个后端驱动程序仅属于一个虚拟机，因此，将目标后端驱动程序从第一虚拟功能单元调度到第二虚拟功能单元，也即是，将目标后端驱动程序所属的目标虚拟机从第一虚拟功能单元调度到第二虚拟功能单元。
仍以图4为例，以调度前，虚拟功能单元401和402分别对应的物理转发端口A和B为例，物理转发端口A和线程1分别为虚拟机420的源物理转发端口以及源线程，线程1删除物理转发端口A与虚拟机420之间的源VF通道403，建立了虚拟机402与物理转发端口B之间的目标VF通道404，从而将虚拟机420从虚拟功能单元401调度了虚拟功能单元420，实现了将虚拟机420从源虚拟功能单元(即虚拟功能单元401)到目的虚拟功能单元(即虚拟功能单元420)之间的跨虚拟功能单元的调度。
或者，调度器为该目标后端驱动程序建立目标线程，向目标线程发送给目标通道信息，此时该目标通道信息包括目标后端驱动程序的程序标识、目标线程的线程标识、第二虚拟功能单元对应的目标物理转发端口的端口信息，由目标线程基于该目标通道信息建立目标VF通道，以将目标后端驱动程序调度到第二虚拟功能单元，此时目标VF通道包括该目标后端驱动程序、该源线程以及目标物理转发端口。
目标VF通道建成后，该目标VF通道中的目标线程在目标后端驱动程序与第二虚拟功能单元之间进行消息转发，以便目标虚拟机通过目标VF通道与第二虚拟功能单元通信。
上述以将计算机设备中的最大负载虚拟功能单元上的部分后端驱动程序调度到最小负载虚拟功能单元为例进行介绍的，每经过一次目标时长，调度器执行一次步骤301至步骤304所示的调度过程，经过多次目标时长，调度器完成多次调度过程，使得计算机设备中各个虚拟功能单元的负载达到均衡。
在另一些实施例中，在每次调度过程中，调度器还可能将计算机设备中的次大负载虚拟功能单元上的部分虚拟机调度到次小负载虚拟功能单元，或者，还将计算机设备中的次次大负载虚拟功能单元上的部分虚拟机调度到次次小负载虚拟功能单元，这两种调度的调度方式可参考上述步骤302-303。这种情况下， 也即是依次调度过程可以调度多个虚拟功能单元上的虚拟机，以减少计算机设备中各个虚拟功能单元的负载达到均衡前的调度次数。
图3所述的方法实施例能够实现图2所示方法实施例的有益效果，且由于同一个加速卡中的虚拟功能单元共享整卡的硬件资源，因此，每个虚拟机功能单元处理的单个数据处理请求效率相差不多，但是与第一虚拟机功能单元通信的后端驱动程序的个数越多，每个后端驱动程序的数据处理请求等待处理的时长就会增加，而图3所示的方法实施例通过将与第一虚拟机功能单元通信的目标虚拟机调度到第二虚拟功能单元，以避免后续目标虚拟机的数据处理请求长时间在第一虚拟功能单元排队等待处理，提高了目标虚拟机的数据处理效率，降低了第一虚拟功能单元的负载量。
图5是本申请实施例提供的一种基于调度策略2的虚拟机的调度方法流程图，该方法应用于计算机设备，该计算机设备中配置有至少一个加速卡、多个虚拟机以及多个线程，该加速卡包括多个虚拟功能单元，虚拟机通过至少一个线程与至少一个虚拟功能单元通信，该方法由计算机设备内的调度器来执行，该方法包括如下步骤。
501、调度器获取计算机设备中该多个线程的负载量，该负载量与计算机设备中的该多个虚拟机有关。
其中，任一线程的负载量为目标时长中与该线程通信的后端驱动程序的负载量之和。
在调度器中配置有采用调度策略2调度虚拟机的情况下，调度器每经过目标时长，统计该多个线程中每个线程的负载量。
以统计任一线程的负载量为例，调度器查询该线程所在的至少一个VF通道，获取目标时长内该至少一个VF通道中后端驱动程序的负载量，将该至少一个VF通道中后端驱动程序的负载量之和作为该线程的负载量，该至少一个VF通道中的后端驱动程序也即是与该线程通信的后端驱动程序。
以获取目标时长中任一后端驱动程序的负载量为例，该调度器统计目标时长中从该后端驱动程序的第一响应队列出队至前端驱动程序的数据处理响应的总个数，基于该总个数、单位时间以及目标时长获取该后端驱动程序的负载量，其中，该负载量＝该总个数/(目标时长/单位时间)。
应当理解的是，本步骤501为步骤201的一种实现方式。
502、调度器基于该多个线程的负载量，确定第一线程以及第二线程，该第一线程为该多个线程中负载量最大的线程，该第二线程为该多个线程中负载量最小的线程。
其中，该第一线程即为目标时长中该计算机设备的该多个线程中的最大负载线程。该第二线程即为目标时长中计算机设备的该多个线程中的最小负载线程，该第二线程是为本次待调度的目标虚拟机分配的目标线程。
例如，将该多个线程中负载量最大的线程确定为第一线程，将该多个线程中负载量最小的线程确定为第二线程。
503、调度器为至少一个第二虚拟机中的目标虚拟机分配该第二线程，该第三虚拟功能单元为该至少一个加速卡中与该第二线程通信的虚拟功能单元，该第二虚拟机为该多个虚拟机中与该第一线程通信的虚拟机。
其中，该至少一个第二虚拟机是与该第一线程通信的所有虚拟机，以图6所示的本申请实施例提供的一种基于调度策略2调度虚拟机的示意图为例，如图6所示的计算机设备中配置有加速卡600、虚拟机610-630以及线程1-2，在调度前，假设线程1为第一线程，线程2为第二线程，线程1与虚拟机610和630通信，则虚拟机610和630均为第二虚拟机。
示例性地，调度器查询目标时长内第一线程所在多个第二VF通道，将每个第二VF通道所连接的虚拟机作为第二虚拟机，其中，该多个第二VF通道可能与多个第二虚拟机连接，也可能与一个第二虚拟机连接。在查询到该至少一个第二虚拟机后，触发为该至少一个第二虚拟机中的部分虚拟机分配第二线程，以便后续将这部分虚拟机调度到第二线程，以减少第一线程的负载量。
在一种可能的实现方式中，调度器将该多个第二VF通道中的后端驱动程序称为第二后端驱动程序，每个第二VF通道有一个第二后端驱动程序，则多个第二VF通道有多个第二后端驱动程序，该多个第二后端驱动程序也即是目标时长中与第一线程通信的后端驱动程序。调度器从该多个第二后端驱动程序中选择第三个数的第二后端驱动程序作为本次待调度的目标后端驱动程序，为目标后端驱动程序分配第二线程，其中，目标后端驱动程序所属的第二虚拟机也即是目标虚拟机，为目标后端驱动程序分配第二线程也即是为目标虚拟机分配第二线程。其中，第三个数为预设个数，在此，本申请实施例对第三个数不做限定。
在另一种可能的实现方式中，通过下述步骤5031-5032所示的过程，为至少一个第二虚拟机中的目标虚拟机分配该第二线程。
步骤5031、对于该至少一个第二虚拟机中的第一候选虚拟机，调度器基于该第一候选虚拟机为该第一线程提供的第一总负载量、该第一线程的负载量以及该第二线程的负载量，对第一线程的负载量以及第二线程的负载量进行预测，得到第一预测负载量以及第二预测负载量。
其中，第一候选虚拟机为至少一个第二虚拟机中目标虚拟机的候选项，该第一总负载量为各个第一候选虚拟机为第一线程提供的负载量之和，任一第一候选虚拟机为第一线程提供的负载量为该第一候选虚拟机与该第一线程之间的至少一个第二后端驱动程序的总负载量。该第一预测负载量为将第一候选虚拟机调度到该第二线程后该第一线程的负载量，该第二预测负载量为将第一候选虚拟机调度到该第二线程后该第二线程的负载量。
以与第一线程通信的第二后端驱动程序有m个为例，调度器按照负载量从小到大的顺序，对m个第二后端驱动程序的负载量进行排序，得到第一负载量序列，以第一负载量序列中前i个负载量所属的第二后端驱动程序所对应的第二虚拟机为第一候选虚拟机，对这前i个负载量进行求和，得到第一总负载量，其中，i为大于等于1且小于m的整数，m为大于1的整数。
调度器将该第一线程的负载量与第一总负载量之间的差值作为第一预测负载量，将该第二线程的负载量与第一总负载量之间的和值作为第二预测负载量，此时第一预测负载量指示将这前i个负载量所属的i个第二后端驱动程序调度到第二线程后第一线程的负载量，也可以理解为，将这前i个第二后端驱动程序调离第一线程后第一线程的负载量。此时第二预测负载量指示将这前i个第二后端驱动程序调度到第一线程后第二线程的负载量。由于每个后端驱动程序仅属于一个虚拟机，因此，将这i个第二后端驱动程序从第一线程调度到第二线程，也即是，将这i个第二后端驱动程序所属的第一候选虚拟机从第一线程调度到第二线程。
步骤5032、若第一预测负载量与第二预测负载量之间的差值的绝对值小于或等于第二阈值，调度器为该第一候选虚拟机分配该第二线程。
其中，第二阈值大于0，第二阈值可根据具体实施场景进行设置，在此，本申请实施例对第二阈值不做限定。
例如，在第一预测负载量与第二预测负载量之间的差值的绝对值小于或等于第二阈值的情况下，若第一总负载量为第一负载量序列中的前i个负载量之和，则调度器将第二线程分配给这前i个负载量所属的i个第二后端驱动程序，此时这i个第二后端驱动程序也即是本次待调度的目标后端驱动程序，i个第二后端驱动程序对应的第二虚拟机(即第一候选虚拟机)也即是本次待调度的目标虚拟机。后续再将这i个第二后端驱动程序调度到第二线程后，使得第一线程的负载量达到第一预测负载量，使得第二线程的负载量达到第二预测负载量，由于在第一预测负载量与第二预测负载量之间的差值的绝对值小于第二阈值，从而使得调度后的第一线程和第二线程达到负载均衡。
在第一预测负载量与第二预测负载量之间的差值的绝对值大于第二阈值的情况下，则调度器对第一负载量序列中的前i+1个负载量进行求和，得到新的第一总负载量，基于新的第一总负载量执行步骤5031-5032，直至找到多个负载量使得第一预测负载量与第二预测负载量之间的差值的绝对值小于或等于第二阈值为止，下面基于下述公式(1)，来进一步说明这种情况下。
公式(1)：|(第一线程的负载量–sum(i))–(sum(i)+第二线程的负载量)|≦第二阈值，其中，sum(i)为第一负载量序列中前i个负载量之和。
调度器基于该第一线程的负载量、该第二线程的负载量以及第一负载量序列，对上公式(1)进行i次判决，在第i次判决过程中，调度器以第一负载量序列中前i个负载量所属的第二后端驱动程序对应的第二虚拟机为第一候选虚拟机，将该第一线程的负载量、该第二线程的负载量以及这前i个负载量输入到公式(1)，若公式(1)不成立，则第i次判决过程结束，进入第i+1次判决过程，若公式(1)成立，则对公式(1)的判决结束，之后，调度器以这前i个负载量所属的第二后端驱动程序为目标后端驱动程序，以该第一候选虚拟机为目标虚拟机，将该第二线程分配给这i个后端驱动程序，以实现将该第二线程分配给目标虚拟机。
在从该多个第二后端驱动程序中确定出至少一个目标后端驱动程序后，对于任一目标后端驱动程序，调度器从与该第二线程通信的至少一个虚拟功能单元(即第三虚拟功能单元)中，选择至少一个目标虚拟 功能单元，基于该目标后端驱动程序、该第二线程以及至少一个目标虚拟功能单元，生成至少一个目标通道信息，以将第二线程分配给该目标后端驱动程序。其中，每个目标通道信息包括目标后端驱动程序的程序标识、该第二线程的线程标识以及一个目标虚拟功能单元所对应的目标物理转发端口的目标端口信息，此时第二线程也即是目标线程。
仍以图6为例，在调度前，假设线程1为第一线程，线程2为第二线程，线程1与加速卡600中的虚拟功能单元601和602通信，虚拟机610对应的后端驱动程序为线程1提供的负载量为2M IOPS，虚拟机630对应的后端驱动程序为线程1提供的负载量为1M IOPS，若预测到将虚拟机630对应的后端驱动程序调度到线程2后线程1和2达到负载均衡，则调度器将线程2所服务的虚拟功能单元603分配给虚拟机630对应的后端驱动程序。
应当理解的是，步骤502-503所示的过程为步骤202的一种实现方式。
504、调度器将该目标虚拟机调度到该第二线程，以使该目标虚拟机与该第二线程能够通信。
在将第二线程分配给目标虚拟机中的目标后端驱动程序后，得到该目标后端驱动程序的目标通道信息，该调度器基于该目标通道信息中的线程标识，向该目标线程(即第二线程)发送通道建立请求，该通道建立请求指示目标线程根据该目标通道信息建立目标VF通道，该目标线程接收到该通道建立请求后，根据通道信息存储请求携带的目标通道信息，建立目标VF通道，以将该目标后端驱动程序调度到第二线程，此时目标VF通道包括该目标后端驱动程序、目标线程以及目标物理转发端口。另外，该目标线程还存储该目标通道信息，以便后续根据该目标通道信息，目标线程在该目标后端驱动程序与目标虚拟功能单元之间进行消息转发，以便该目标后端驱动程序对应目标虚拟机通过该目标VF通道与该目标线程。
另外，该调度器还向该目标后端驱动程序的源线程(即第一线程)发送通道删除请求，该通道删除请求指示删除该目标后端驱动程序所在的源VF通道，源线程在接收到该通道删除请求后，删除该源VF通道以及该源VF通道的源通道信息，以避免后续源线程根据源通道信息继续在源VF通道上通信。
仍以图6为例，以线程1为源线程，线程2为目标线程，虚拟功能单元603和604中的任一虚拟功能单元为目标虚拟功能单元为例，再将虚拟机630对应的后端驱动程序的调度到线程2的情况下，线程1删除虚拟机630对应的后端驱动程序所在的源VF通道605，线程2根据目标通道信息建立了虚拟机630与虚拟功能单元603之间的目标VF通道606，从而将虚拟机630及其对应的后端驱动程序从线程1调度到线程2，实现了跨线程的虚拟机调度。
上述以将计算机设备中的最大负载线程上的部分虚拟机调度到最小负载线程为例进行介绍的，每经过一次目标时长，调度器执行一次步骤501-504所示的调度过程，经过多次目标时长，调度器完成多次调度过程，使得计算机设备中各个线程的负载达到均衡。
在另一些实施例中，在每次调度过程中，调度器还可能将计算机设备中的次大负载线程上的部分虚拟机调度到次小负载线程，或者，还将计算机设备中的次次大负载线程上的部分虚拟机调度到次次小负载线程，这两种调度的调度方式可参考上述步骤502-503。这种情况下，也即是依次调度过程可以调度多个线程上的虚拟机，以减少计算机设备中各个线程的负载达到均衡前的调度次数。
图5所述的方法实施例能够实现图2所示方法实施例的有益效果，另外，由于第一线程的负载量比较大，可能导致第二虚拟机的数据处理请求在第一线程等待转发，图5所示的方法实施例通过将至少一个第二虚拟机中的目标虚拟机调度到第二线程，以避免后续目标虚拟机的数据处理请求长时间在第一线程排队等待处理，提高了目标虚拟机的数据处理效率，降低了第一线程的负载量，提高了第一线程的处理效率，也能使得第二线程提供的资源能够被充分使用，避免第二线程的资源浪费。
图7是本申请实施例提供的一种基于调度策略3的虚拟机的调度方法流程图，该方法应用于计算机设备，该计算机设备中配置有至少一个加速卡、多个虚拟机以及多个线程，该加速卡包括多个虚拟功能单元，虚拟机通过至少一个线程与至少一个虚拟功能单元通信，该方法由计算机设备内的调度器来执行，该方法包括如下步骤。
701、调度器获取计算机设备中多个线程的负载量，该负载量与计算机设备中的该多个虚拟机有关。
其中，本步骤701与步骤501同理，在此，本申请实施例对本步骤701不再赘述。
702、调度器基于该多个线程的负载量，从该多个线程中，确定第三线程以及第四线程，第三线程的负载量大于或等于第三阈值，第四线程的负载量小于第三线程的负载量。
其中，该第三阈值大于0，第三阈值的取值可根据具体实施场景进行设置，在此，本申请实施例对第 三阈值不做限定。该多个线程中的第三线程有至少一个，该第四线程是为本次待调度的目标虚拟机分配的目标线程，第四线程有至少一个。
以线程有n个为例，按照负载量从小到大的顺序或从大到小的顺序，对该n个线程的负载量进行排序，得到第二负载量序列，将第二负载量序列中负载量大于第三阈值的各个线程作为第三线程。或者，若该多个线程中的第一线程的负载量大于第三阈值，则将第一线程作为第三线程。
待确定出第三线程后，第二负载量序列中除第三线程的负载量以外的剩余负载量均小于各个第三线程的负载量，则调度器从这些剩余负载量中选择至少一个目标负载量，将选择的至少一个目标负载量所属的线程作为第四线程。例如，从这些剩余负载量中选择负载量最小的第三个数的剩余负载量，以第三个数为2例，此时选择的目标负载量为n个线程的负载量中最小的2个负载量，相应地，此时的第四线程为n个线程中的第二线程。第三个数为预设个数，第三个数可根据具体实施场景进行设置，在此，本申请实施例对第三个数不再限定。在另一些实施例，调度器不设置第三个数，不通过第三个数选择第二线程，而是以多个线程中的负载量最小的线程为第四线程。
调度器最终确定出的第三线程可能有至少一个，第四线程也可能有至少一个，为了便于了解本申请实施例的调度方式，以一个第三线程以及一个第四线程为例进行如下介绍，在多个第三线程或多个第四线程的情况下，可参考一个第三线程以及一个第四线程时的调度方式。
703、调度器为至少一个第三虚拟机中的目标虚拟机分配该第四线程。
其中，该至少一个第三虚拟机是与该第三线程通信的所有虚拟机，以图8所示的本申请实施例提供的一种基于调度策略3调度虚拟机的示意图为例，如图8所示的计算机设备中配置有加速卡800、虚拟机810-820以及线程1，在调度前，假设线程1为第三线程，线程1与加速卡800中的虚拟功能单元801和802通信，则虚拟功能单元801和802均为第三虚拟机。
示例性地，调度器查询目标时长内第三线程所在的多个第三VF通道，将每个第三VF通道所连接的虚拟机作为第三虚拟机。其中，该多个第三VF通道可能与多个第三虚拟机连接，也可能与一个第三虚拟机连接。在查询到该至少一个第三虚拟机后，触发为该至少一个第三虚拟机中的部分虚拟机分配第四线程，以便后续将这部分虚拟机调度到第四线程，以减少第三线程的负载量。
在一种可能的实现方式中，调度器将该多个第三VF通道中的后端驱动程序称为第三后端驱动程序，每个第二VF通道有一个第三后端驱动程序，则多个第二VF通道有多个第三后端驱动程序，该多个第三后端驱动程序也即是目标时长中与第三线程通信的后端驱动程序。调度器从该多个第三后端驱动程序中选择第四个数的第三后端驱动程序作为本次待调度的目标后端驱动程序，为目标后端驱动程序分配第四线程，其中，目标后端驱动程序所属的第三虚拟机也即是目标虚拟机，为目标后端驱动程序分配第四线程也即是为目标虚拟机分配第四线程。其中，第四个数为预设个数，在此，本申请实施例对第四个数不做限定。
在另一种可能的实现方式中，通过下述步骤7031至步骤7032所示的过程，将第四虚拟功能单元分配给多个第二虚拟机中的至少一个第二虚拟机。
步骤7031、对于所述至少一个第三虚拟机中的第二候选虚拟机，调度器基于该第二候选虚拟机为该第三线程提供的第二总负载量、该第三线程的负载量以及该第四线程的负载量，分别对该第三线程的负载量以及该第四线程的负载量进行预测，得到第三预测负载量以及第四预测负载量。
其中，该第二总负载量为该至少一个第三虚拟机为第三线程提供的负载量之和，任一第三虚拟机为第三线程提供的负载量为该第三虚拟机与该第一线程之间的至少一个后端驱动程序的总负载量。该第三预测负载量为将该第二候选虚拟机调度到该第四虚拟功能单元后该第三线程的负载量，该第四预测负载量为将该第二候选虚拟机调度到该第四虚拟功能单元后该第四线程的负载量。
以与第三线程通信的第三后端驱动程序有p个为例，调度器按照负载量从小到大的顺序，对p个第三后端驱动程序的负载量进行排序，得到第三负载量序列，以第三负载量序列中前j个负载量所属的第三后端驱动程序所对应的第三虚拟机为第二候选虚拟机，对这前j个负载量进行求和，得到第二总负载量，其中，j为大于等于1且小于p的整数，p为大于1的整数。
调度器将该第三线程的负载量与第二总负载量之间的差值作为第三预测负载量，将第四线程的负载量与第二总负载量之间的和值作为第四预测负载量，此时第三预测负载量指示将这前j个负载量所属的j个第三后端驱动程序调度到该第四线程后第三线程的负载量，也可以理解为，将这j个第三后端驱动程序调离第三线程后第三线程的负载量。此时第二预测负载量指示将这j个第三后端驱动程序调度到该第四线程 后第四线程的负载量。由于每个后端驱动程序仅属于一个虚拟机，因此，将这j个第三后端驱动程序从第三线程调度到第四线程，也即是，将j个第三后端驱动程序所属的第二候选虚拟机从第三线程调度到第四线程。
步骤7032、若该第三预测负载量与该第四预测负载量之间的差值的绝对值小于或等于第四阈值，调度器为该第二候选虚拟机分配该第四线程。
其中，第四阈值大于0，第四阈值可根据具体实施场景进行设置，在此，本申请实施例对第四阈值不做限定。
例如，在第三预测负载量与第四预测负载量之间的差值的绝对值小于或等于第四阈值的情况下，若第二总负载量为第三负载量序列中的前j个负载量之和，则调度器将第四线程分配给这前j个负载量所属的j个第三后端驱动程序，此时这j个第三后端驱动程序也即是本次待调度的目标后端驱动程序，j个第三后端驱动程序对应的第三虚拟机(即第一候选虚拟机)也即是本次待调度的目标虚拟机。后续再将这j个第三后端驱动程序调度到第四线程后，使得第三线程的负载量达到第三预测负载量，使得第四线程的负载量达到第四预测负载量，由于在第三预测负载量与第四预测负载量之间的差值的绝对值小于第四阈值，从而使得调度后的第三线程和第四线程达到负载均衡。
在第三预测负载量与第四预测负载量之间的差值的绝对值大于第四阈值的情况下，则调度器对第三负载量序列中的前j+1个负载量进行求和，得到新的第二总负载量，基于新的第二总负载量执行步骤7031-7032，直至找到多个负载量使得第三预测负载量与第四预测负载量之间的差值的绝对值小于或等于第二阈值为止，下面基于下述公式(2)，来进一步说明这种情况下。
公式(2)：|(第三线程的负载量–sum(j))–(sum(j)+第四线程的负载量)|≦第四阈值，其中，sum(j)为第三负载量序列中前j个负载量之和。
调度器基于该第三线程的负载量、该第四线程的负载量以及第三负载量序列，对上述公式(2)进行j次判决，在第j次判决过程中，调度器以第三负载量序列中前j个负载量所属的第三后端驱动程序对应的第三虚拟机为第二候选虚拟机，将该第三线程的负载量、该第四线程的负载量以及这前j个负载量输入到公式(2)，若公式(2)不成立，则第j次判决过程结束，进入第j+1次判决过程，若公式(2)成立，则对公式(2)的判决结束，之后，调度器以这前j个负载量所属的第三后端驱动程序为目标后端驱动程序，以该第二候选虚拟机为目标虚拟机，将该第四线程分配给这j个第三后端驱动程序，以实现将该第四线程分配给目标虚拟机。
在从该多个第三后端驱动程序中确定出至少一个目标后端驱动程序后，对于任一目标后端驱动程序，调度器基于该目标后端驱动程序、该第四线程以及目标后端驱动程序的源虚拟功能单元，生成目标通道信息，以将第四线程分配给该目标后端驱动程序。其中，源虚拟功能单元为目标后端驱动程序通过第三线程所连接的虚拟功能单元，该目标通道信息包括目标后端驱动程序的程序标识、该第四线程的线程标识以及一个源虚拟功能单元所对应的源物理转发端口的源端口信息，此时第四线程也即是目标线程。
仍以图8为例，假设线程1为第三线程，线程2为第四线程，虚拟机810对应的后端驱动程序为线程1提供的负载量为2M IOPS、虚拟机820对应的后端驱动程序为线程1提供负载量为2M IOPS，若预测到将虚拟机820对应的后端驱动程序调度到线程2后线程1和2达到负载均衡，则调度器将线程2分配给虚拟机820及其对应的后端驱动程序。
应当理解的是，步骤702-703所示的过程为步骤202的一种实现方式。
704、调度器将该目标虚拟机调度到该第四线程，以使该目标虚拟机与该第四线程能够通信。
在将第二线程分配给目标虚拟机中的目标后端驱动程序后，得到该目标后端驱动程序的目标通道信息，该调度器基于该目标通道信息中的线程标识，向该目标线程(即第四线程)发送通道建立请求，该通道建立请求指示目标线程根据该目标通道信息建立目标VF通道，该目标线程接收到该通道建立请求后，根据通道信息存储请求携带的目标通道信息，建立目标VF通道，以将该目标后端驱动程序调度到第四线程，此时目标VF通道包括该目标后端驱动程序、目标线程以及源物理转发端口。该目标线程还存储该目标通道信息，以便后续根据该目标通道信息，目标线程在该目标后端驱动程序与源虚拟功能单元之间进行消息转发，以便该目标后端驱动程序对应的目标虚拟机通过该目标VF通道与该目标线程通信。
另外，该调度器还向该目标后端驱动程序的源线程(即第三线程)发送通道删除请求，该通道删除请求指示删除该目标后端驱动程序所在的源VF通道，源线程在接收到该通道删除请求后，删除该源VF通 道以及该源VF通道的源通道信息，以避免后续源线程根据源通道信息继续在源VF通道上通信。
仍以图8为例，假设线程1为源线程，线程2为目标线程，再将虚拟机820对应的后端驱动程序调度到线程2的情况下，线程1删除虚拟机820对应的后端驱动程序所在的源VF通道803，线程2根据目标通道信息建立了虚拟机820与虚拟功能单元802之间的目标VF通道804，从而将虚拟机820及其对应的后端驱动程序从线程1调度到线程2，对于线程1上的虚拟机810而言，线程2为新增的线程，即实现了通过增加线程调度虚拟机。
在另一种可能的实现方式中，在确定出第三线程后，调度器不再从已有的线程中确定第四线程，而是根据该第三线程连接的p个第三后端驱动程序的负载量，将p个第三后端驱动程序划分为多个后端驱动程序组，后端驱动程序组包括至少一个第三后端驱动程序，且各个后端驱动程序组的总负载量差值小于第四阈值，以确保每个后端驱动程序组的负载均衡，将多个后端驱动程序组中任一后端驱动程序组继续与第三线程连接，对于多个后端驱动程序组中除该任一后端驱动程序组以外各个剩余后端驱动程序组，调度器为该剩余后端驱动程序组创建一个目标线程，由该目标线程为该剩余后端驱动程序组建立目标VF通道，以便之后该目标线程根据该目标VF通道的目标通道信息，在该剩余后端驱动程序组和该剩余后端驱动程序的源虚拟功能单元之间进行消息转发。
图7所述的方法实施例能够实现图2所示方法实施例的有益效果，另外，由于第三线程的负载量比较大，可能导致第三虚拟机的数据处理请求在第三线程等待转发，图7所示的方法实施例通过将至少一个第三虚拟机中的目标虚拟机调度到第四线程，避免后续目标虚拟机的数据处理请求长时间在第三线程排队等待处理，提高了目标虚拟机的数据处理效率，降低了第三线程的负载量，提高了第三线程的处理效率，也能使得第二线程提供的资源能够被充分使用，避免第二线程的资源浪费。
图9是本申请实施例提供的一种基于调度策略4的虚拟机的调度方法流程图，该方法应用于计算机设备，该计算机设备中配置有至少一个加速卡、多个虚拟机以及多个线程，该加速卡包括多个虚拟功能单元，虚拟机通过至少一个线程与至少一个虚拟功能单元通信，该方法由计算机设备内的调度器来执行，该方法包括如下步骤。
901、调度器获取计算机设备中多个线程的负载量，该负载量与计算机设备中的该多个虚拟机有关。
其中，本步骤901与步骤501同理，在此，本申请实施例对本步骤901不再赘述。
902、调度器基于该多个线程的负载量，从该多个线程中，确定多个第五线程，该多个第五线程的负载量之和小于或等于第五阈值。
其中，多个第五线程为本次待合并的线程，该第五阈值大于0，第五阈值的取值可根据具体实施场景进行设置，在此，本申请实施例对第五阈值不做限定。
以线程有n个为例，按照负载量从小到大的顺序，对该n个线程的负载量进行排序，得到第二负载量序列，对第二负载量序列中的前t个负载量进行求和，若和值大于第五阈值，则将t减1继续后，再次执行对第二负载量序列中的前t个负载量进行求和的步骤，直到第二负载量序列中的前t-g个负载量的和值小于或等于第五阈值，则将前t-g个负载量所对应的各个线程作为第五线程，其中，t为大于0且小于n的整数，g为大于或等于0且小于或等于t-2的整数，n为大于2的整数。由于是直到第二负载量序列中的前t-g个负载量的和值小于或等于第五阈值，才将前t-g个负载量所对应的各个线程作为第五线程，之后再将多个第五线程合并成一个目标线程时，能够在保证目标线程性能的情况下将尽可能多的线程合并成一个目标线程。
或者是，调度器基于该多个线程的负载量，从确定多个线程中负载量最小的线程以及负载量次小的线程，若负载量最小的线程以及负载量次小的线程的总负载量小于或等于第五阈值，则将负载量最小的线程以及负载量次小的线程均确定为第五线程。
若该多个线程中不存在多个第五线程，则不再执行后续的步骤。
903、调度器为第四虚拟机分配该多个第五线程中的第六线程，该第四虚拟机为与该多个第五线程中的第七线程通信的虚拟机。
其中，第六线程为该多个第五线程中的任一线程，该第七线程为该多个第五线程中除该第六线程以外的线程，即多个第五线程包括一个第六线程以及至少一个第七线程。在本申请实施例中，第六线程是本次待调度的目标虚拟机分配的目标线程，与至少一个第七线程通信的各个第四虚拟机为本次待调度的目标虚拟机。
在一种可能的实现方式中，调度器从多个第五线程中选择任一线程作为第六线程，将该多个第五线程中除第六线程以外的各个线程作为第七线程，对于任一七线程，查询任一第七线程所在的第四VF通道，将第四VF通道所连接的虚拟机确定为第四虚拟机，对于任一第四虚拟机，调度器将该第四虚拟机分配给第六线程。
例如，调度器将该第四虚拟机对应的后端驱动程序为目标后端驱动程序，基于该目标后端驱动程序、该第六线程以及目标后端驱动程序的源虚拟功能单元，生成目标通道信息，以将第六线程分配给该目标后端驱动程序以及该第四虚拟机。此时，源虚拟功能单元为该目标后端驱动程序通过第七线程所连接的虚拟功能单元，该目标通道信息包括该目标后端驱动程序的程序标识、该第六线程的线程标识以及该源虚拟功能单元所对应的源物理转发端口的源端口信息，此时第六线程也即是目标线程。
以图10所示的本申请实施例提供的一种基于调度策略4调度虚拟机的示意图为例，如图10所示的计算机设备中配置有加速卡1000、虚拟机1010-1020以及线程1-2，其中，加速卡包括虚拟功能单元1001-1002，在调度前，假设线程1和线程2的负载量均为1K IOPS，若线程1和线程2的总负载量2K IOPS小于第五阈值，则线程1和2均为第五线程，调度器以线程1为目标线程，将与线程2通信的虚拟机1020(即第四虚拟机)分配给线程1。
应当理解的是，步骤902-903所示的过程为步骤202的一种实现方式。
904、调度器将该第四虚拟机调度到该第六线程，以使该第四虚拟机与该第六线程能够通信。
在得到该第四虚拟机的目标通道信息后，该调度器基于该目标通道信息中的线程标识，向该目标线程(即第六线程)发送通道建立请求，该通道建立请求指示目标线程根据该目标通道信息建立目标VF通道，该目标线程接收到该通道建立请求后，根据通道信息存储请求携带的目标通道信息，建立目标VF通道，以将该目标后端驱动程序调度到第六线程，此时目标VF通道包括该第四虚拟机对应的后端驱动程序(即目标后端驱动程序)、目标线程以及源物理转发端口。该目标线程还存储该目标通道信息，以便后续根据该目标通道信息，目标线程在该目标后端驱动程序与源虚拟功能单元之间进行消息转发，以便该目标后端驱动程序对应的第四虚拟机通过该目标VF通道与该目标线程通信。
另外，第七线程作为第四虚拟机的源线程，该调度器还删除第五线程中的各个第七线程，由于第六线程没有被删除，且将各个第七线程上的第四虚拟机调度第六线程，相当于将各个第七线程合并到了第六线程，减少了线程的数量，即实现了减少线程调度虚拟机。
以图10为例，假设线程1为第六线程，线程2为第七线程，调度器在将虚拟机1020从线程2调度到线程1后，调度器删除了线程2。
图9所述的方法实施例能够实现图2所示方法实施例的有益效果，另外，由于多个第五线程的负载量比较小，资源调度器将多个第五线程中的各个第七线程上的第四虚拟机都调度到多个第五线程中的第六线程，由第六线程负责与各个第四虚拟机通信，从而避免浪费线程资源。
图11是本申请实施例提供的一种基于调度策略5的虚拟机的调度方法流程图，该方法应用于计算机设备，该计算机设备中配置有多个加速卡、多个虚拟机以及多个线程，该加速卡包括多个虚拟功能单元，虚拟机通过至少一个线程与至少一个虚拟功能单元通信，该方法由计算机设备内的调度器来执行，该方法包括如下步骤。
1101、调度器获取计算机设备中多个加速卡的负载量，该负载量与计算机设备中的该多个虚拟机有关。
其中，任一加速卡的负载量为目标时长中至少一个虚拟机为该加速卡提供的负载量之和。
在调度器中配置有采用调度策略5调度虚拟机的情况下，调度器每经过目标时长，统计该多个加速卡中每个加速卡的负载量。
由于任一虚拟机为加速卡的虚拟功能单元提供的负载量等于该虚拟机对应的且与加速卡通信的至少一个后端驱动程序的负载量之和，获取任一加速卡的负载量的过程可以为：调度器查询目标时长中，该加速卡的每个虚拟功能单元对应的物理转发端口所在的VF通道，从查询到的VF通道中确定与该加速卡的虚拟功能单元通信的后端驱动程序，获取查询到的每个后端驱动程序的负载量，将查询到的每个后端驱动程序的负载量之和作为该加速卡的负载量。其中，获取后端驱动程序的负载量的过程在上文中有介绍，在此不再赘述。
应当理解的是，本步骤1101为步骤201的一种实现方式。
1102、调度器基于该多个加速卡的负载量，确定第一加速卡和第二加速卡，该第一加速卡为该多个加 速卡中负载量最大的加速卡，该第二加速卡为该多个加速卡中负载量最小的加速卡。
其中，该第一加速卡即为目标时长中该计算机设备中的最大负载加速卡。该第二线程即为目标时长中计算机设备中的最小负载加速卡，该第二加速卡是为本次待调度的目标虚拟机分配的目标加速卡。
例如，将该多个加速卡中负载量最大的加速卡确定为第一加速卡，将该多个加速卡中负载量最小的加速卡确定为第二加速卡。
1103、调度器为至少一个第五虚拟机中的目标虚拟机分配该第二加速卡，该第五虚拟机为该多个虚拟机中与该第一加速卡通信的虚拟机。
其中，该至少一个第五虚拟机是与该第一加速卡中的虚拟功能单元通信的所有虚拟机，以图12所示的本申请实施例提供的一种基于调度策略5调度虚拟机的示意图为例，如图12所示的计算机设备中配置有加速卡A-B、虚拟机1210-1230以及线程1，在调度前，假设加速卡A为第一加速卡，加速卡A为第二加速卡，加速卡A与虚拟机1210和1230通信，则虚拟机1210和1230均为第五虚拟机。
示例性地，调度器查询目标时长内与第一加速卡中的虚拟功能单元通信的多个第五VF通道，将每个第五VF通道所连接的虚拟机作为第五虚拟机，其中，该多个第五VF通道可能与多个第五虚拟机连接，也可能与一个第五虚拟机连接。在查询到该至少一个第五虚拟机后，触发为该至少一个第五虚拟机中的部分虚拟机分配第二加速卡，以便后续将这部分虚拟机调度到第二加速卡，以减少第一加速卡的负载量。
在一种可能的实现方式中，调度器将该多个第五VF通道中的后端驱动程序称为第四后端驱动程序，每个第五VF通道有一个第四后端驱动程序，则多个第五VF通道有多个第四后端驱动程序，该多个第四后端驱动程序也即是目标时长中与第一加速卡通信的后端驱动程序。调度器从该多个第四后端驱动程序中选择第五个数的第四后端驱动程序作为本次待调度的目标后端驱动程序，为目标后端驱动程序分配第二加速卡，其中，目标后端驱动程序所属的第五虚拟机也即是目标虚拟机，为目标后端驱动程序分配第二加速卡也即是为目标虚拟机分配第二加速卡。其中，第五个数为预设个数，在此，本申请实施例对第三个数不做限定。
在另一种可能的实现方式中，通过下述步骤1131-1132所示的过程，为至少一个第五虚拟机中的目标虚拟机分配该第二加速卡。
步骤1131、对于该至少一个第五虚拟机中的第三候选虚拟机，调度器基于该第三候选虚拟机为该第一加速卡提供的第三总负载量、该第一加速卡的负载量以及该第二加速卡的负载量，分别对该第一加速卡的负载量以及该第二加速卡的负载量进行预测，得到第五预测负载量以及第六预测负载量。
其中，第三候选虚拟机为至少一个第五虚拟机中目标虚拟机的候选项，该第三总负载量为各个第三候选虚拟机为第一加速卡提供的负载量之和，任一第三候选虚拟机为第一加速卡提供的负载量为该第三候选虚拟机与该第一加速卡之间的至少一个第四后端驱动程序的总负载量。该第五预测负载量为将该第三候选虚拟机调度到该第二加速卡后该第一加速卡的负载量，该第六预测负载量为将该第三候选虚拟机调度到该第二加速卡后该第二加速卡的负载量。
以与第一加速卡通信的第四后端驱动程序有w个为例，调度器按照负载量从小到大的顺序，对w个第四后端驱动程序的负载量进行排序，得到第四负载量序列，以第四负载量序列中前r个负载量所属的第四后端驱动程序所对应的第五虚拟机为第三候选虚拟机，对这前r个负载量进行求和，得到第三总负载量，其中，r为大于等于1且小于w的整数，w为大于1的整数。
调度器将该第一加速卡的负载量与第三总负载量之间的差值作为第五预测负载量，将该第二加速卡的负载量与第三总负载量之间的和值作为第六预测负载量，此时第五预测负载量指示将这前r个负载量所属的r个第四后端驱动程序调度到第二加速卡后第一加速卡的负载量，也可以理解为，将这前r个第四后端驱动程序调离第一加速卡后第一加速卡的负载量。此时第六预测负载量指示将这前r个第四后端驱动程序调度到第一加速卡后第二加速卡的负载量。由于每个后端驱动程序仅属于一个虚拟机，因此，将这r个第四后端驱动程序从第一加速卡调度到第二加速卡，也即是，将这r个第四后端驱动程序所属的第三候选虚拟机从第一加速卡调度到第二加速卡。
步骤1132、若该第五预测负载量与该第六预测负载量之间的差值的绝对值小于或等于第六阈值，调度器为该第三候选虚拟机分配该第二加速卡。
其中，第六阈值大于0，第六阈值可根据具体实施场景进行设置，在此，本申请实施例对第六阈值不做限定。
例如，在第四预测负载量与第六预测负载量之间的差值的绝对值小于或等于第六阈值的情况下，若第三总负载量为第四负载量序列中的前r个负载量之和，则调度器将第二加速卡分配给这前r个负载量所属的r个第四后端驱动程序，此时这r个第四后端驱动程序也即是本次待调度的目标后端驱动程序，r个第四后端驱动程序对应的第五虚拟机(即第一候选虚拟机)也即是本次待调度的目标虚拟机。后续再将这r个第四后端驱动程序调度到第二加速卡后，使得第一加速卡的负载量达到第四预测负载量，使得第二加速卡的负载量达到第六预测负载量，由于在第四预测负载量与第六预测负载量之间的差值的绝对值小于第六阈值，从而使得调度后的第一加速卡和第二加速卡达到负载均衡。
在第四预测负载量与第六预测负载量之间的差值的绝对值大于第六阈值的情况下，则调度器对第四负载量序列中的前r+1个负载量进行求和，得到新的第三总负载量，基于新的第三总负载量执行步骤1131-1132，直至找到多个负载量使得第四预测负载量与第六预测负载量之间的差值的绝对值小于或等于第六阈值为止，下面基于下述公式(3)，来进一步说明这种情况下。
公式(3)：|(第一加速卡的负载量–sum(r))–(sum(r)+第二加速卡的负载量)|≦第六阈值，其中，sum(r)为第四负载量序列中前r个负载量之和。
调度器基于该第一加速卡的负载量、该第二加速卡的负载量以及第四负载量序列，对上公式(3)进行r次判决，在第r次判决过程中，调度器以第四负载量序列中前r个负载量所属的第四后端驱动程序对应的第五虚拟机为第三候选虚拟机，将该第一加速卡的负载量、该第二加速卡的负载量以及这前r个负载量输入到公式(3)，若公式(3)不成立，则第r次判决过程结束，进入第r+1次判决过程，若公式(3)成立，则对公式(3)的判决结束，之后，调度器以这前r个负载量所属的第四后端驱动程序为目标后端驱动程序，以该第三候选虚拟机为目标虚拟机，将该第二加速卡分配给这r个后端驱动程序，以实现将该第二加速卡分配给目标虚拟机。
在从该多个第四后端驱动程序中确定出至少一个目标后端驱动程序后，对于任一目标后端驱动程序，调度器从与该第二加速卡的虚拟功能单元中，选择至少一个目标虚拟功能单元，对于任一目标虚拟功能单元，从与第一加速卡通信的线程中为该目标虚拟功能单元选择目标线程，或者，为该目标虚拟功能单元建立目标线程，基于该目标后端驱动程序、该目标线程以及该目标虚拟功能单元，生成目标通道信息，以将第二加速卡分配给该目标后端驱动程序。其中，目标通道信息包括目标后端驱动程序的程序标识、目标线程的线程标识以及该目标虚拟功能单元所对应的目标物理转发端口的目标端口信息。
仍以图12为例，在调度前，假设加速卡A为第一加速卡，加速卡B为第二加速卡，加速卡A中的虚拟功能单元A1-A2通过线程1分别与虚拟机1210和1230通信，虚拟机1210对应的后端驱动程序为线程1提供的负载量2M IOPS、虚拟机1230对应的后端驱动程序为线程1提供的负载量为1M IOPS，若预测到将虚拟机1230对应的后端驱动程序调度到加速卡B后加速卡A和B达到负载均衡，调度器以虚拟机1230为目标虚拟机，以虚拟机1230对应的后端驱动程序为目标后端驱动程序，从加速卡B的虚拟功能单元B1和B2中随机选择虚拟功能单元B1为目标虚拟功能单元，将虚拟功能单元B1分配给虚拟机1230对应的后端驱动程序，以实现将虚拟机1230分配给加速卡B。
应当理解的是，步骤1102-1103所示的过程为步骤202的一种实现方式。
1104、调度器将该目标虚拟机调度到该第二加速卡，以使该目标虚拟机与该第二加速卡能够通信。
在目标虚拟机对应的该目标后端驱动程序的目标通道信息后，该调度器基于该目标通道信息中的线程标识，向该目标线程发送通道建立请求，该目标线程接收到该通道建立请求后，根据通道信息存储请求携带的目标通道信息，建立目标VF通道，以将该目标后端驱动程序调度到第二加速卡，此时目标VF通道包括该目标后端驱动程序、目标线程以及目标物理转发端口。该目标线程还存储该目标通道信息，以便后续根据该目标通道信息，目标线程在该目标后端驱动程序与目标虚拟功能单元之间进行消息转发，以便该目标后端驱动程序对应目标虚拟机通过该目标VF通道与该目标线程。
另外，该调度器还向该目标后端驱动程序的源线程发送通道删除请求，该通道删除请求指示删除该目标后端驱动程序所在的源VF通道，源线程在接收到该通道删除请求后，删除该源VF通道以及该源VF通道的源通道信息，以避免后续源线程根据源通道信息继续在源VF通道上通信。
仍以图12为例，假设线程1为源线程和目标线程，再将虚拟机1230对应的后端驱动程序的调度到加速卡B的情况下，线程1删除虚拟机1230对应的后端驱动程序所在的源VF通道1201，根据目标通道信息建立了虚拟机1230与虚拟功能单元B1之间的目标VF通道1202，从而将虚拟机1230及其对应的后端 驱动程序从加速卡A调度到加速卡B，实现了跨加速卡的虚拟机调度。
图11所述的方法实施例能够实现图2所示方法实施例的有益效果，另外，由于第一加速的负载量比较大，可能导致第五虚拟机的数据处理请求在第一加速卡等待处理，图11所示的方法实施例通过将至少一个第五虚拟机中的目标虚拟机调度到第二加速卡，以避免后续目标虚拟机的数据处理请求长时间在第一加速卡排队等待处理，提高了目标虚拟机的数据处理效率，降低了第一加速卡的负载量，提高了第一加速卡的处理效率，也能使得第二加速卡提供的资源能够被充分使用，避免第二加速卡的资源浪费。
图13是本申请实施例提供的一种基于调度策略6的虚拟机的调度方法流程图，该方法应用于计算机设备，该计算机设备中配置有多个加速卡、多个虚拟机以及多个线程，该加速卡包括多个虚拟功能单元，虚拟机通过至少一个线程与至少一个虚拟功能单元通信，该方法由计算机设备内的调度器来执行，该方法包括如下步骤。
1301、调度器获取计算机设备中多个加速卡的负载量，该负载量与计算机设备中的该多个虚拟机有关。
其中，本步骤1301与步骤1101同理，在此，本申请实施例对本步骤1301不再赘述。
1302、调度器基于该多个加速卡的负载量，确定第一加速卡，该第一加速卡为所述多个加速卡中负载量最大的加速卡。
其中，确定第一加速卡的过程在步骤1102有相关介绍，在此，本申请实施例对本步骤1302不再赘述。
1303、若该第一加速卡的负载量大于或等于第七阈值，且该多个加速卡中存在空闲加速卡，调度器为至少一个第五虚拟机中的目标虚拟机分配空闲加速卡，该第五虚拟机为该多个虚拟机中与该第一加速卡通信的虚拟机。
其中，第七阈值大于0，第七阈值可根据具体实施场景进行设置，在此，本申请实施例对第七阈值不做限定。该空闲加速卡没有被分配给虚拟机使用的加速卡。该至少一个第三虚拟机是与该第三线程通信的所有虚拟机，以图14所示的本申请实施例提供的一种基于调度策略6调度虚拟机的示意图为例，如图14所示的计算机设备中配置有加速卡A-B、虚拟机1410-1430以及线程1，以加速卡A为QAT，以加速卡B为MLX为例，在调度前，假设加速卡A为第一加速卡，加速卡B没有连接任何虚拟机，则加速卡B为空闲加速卡，其中，加速卡A包括虚拟功能单元A1-A2，加速卡B包括虚拟功能单元B1-B2。
例如，调度器中记录有多个加速卡的状态，若该第一加速卡的负载量大于或等于第七阈值，调度器查询记录多个加速卡的状态，若任一加速卡的状态为使用中，则该加速卡不是空闲加速卡，若任一加速卡的状态为空闲中，则将该加速卡作为空闲加速卡。
再例如，从多个加速卡中查询为负载量为0的加速卡，若任一加速卡的负载量为0，则将该任一加速卡作为空闲加速卡。
若该第一加速卡的负载量大于或等于第七阈值，且多个加速卡中不存在加速卡，调度器发出加速卡增加请求，该加速卡增加请求指示添加空闲加速卡，该加速卡增加请求可以是文字消息也可以是语音消息，以提示用户添加空闲加速卡。
若该第一加速卡的负载量大于或等于第七阈值，且多个加速卡中存在空闲加速卡，则触发为该至少一个第五虚拟机中的部分虚拟机分配空闲加速卡，以便后续将这部分虚拟机调度到空闲加速卡，以减少第一加速卡的负载量。
在一种可能的实现方式中，调度器查询该至少一个第五虚拟机对应的多个第四后端驱动程序，将该多个第四后端驱动程序中一半的后端驱动程序作为目标驱动程序，或者，根据该多个第四后端驱动程序的负载量，将该多个第四后端驱动程序划分为第一驱动程序组和第二驱动程序组，第一驱动程序组和第二驱动程序组都包括至少一个第四后端驱动程序，且第一驱动程序组和第二驱动程序组的负载量差小于第九阈值，将第一驱动程序组或第一驱动程序组中的第四后端驱动程序作为目标驱动程序，以确保将该目标驱动程序调度到空闲加速卡后，空闲加速和第一加速卡达到负载均衡。
在从该多个第四后端驱动程序中确定出至少一个目标后端驱动程序后，对于任一目标后端驱动程序，调度器从与空闲加速卡的虚拟功能单元中，选择至少一个目标虚拟功能单元，对于任一目标虚拟功能单元，从与第一加速卡通信的线程中为该目标虚拟功能单元选择目标线程，或者，为该目标虚拟功能单元建立目标线程，基于该目标后端驱动程序、该目标线程以及目标虚拟功能单元，生成目标通道信息，以将该第二加速卡线程分配给该目标后端驱动程序。其中，该目标通道信息包括目标后端驱动程序的程序标识、该目标线程的线程标识以及该目标虚拟功能单元所对应的目标物理转发端口的目标端口信息。
应当理解的是，步骤1302-1303所示的过程为步骤202的一种实现方式。
1304、调度器将该目标虚拟机调度到该空闲加速卡，以使该目标虚拟机与该空闲加速卡能够通信。
其中，本步骤1304与步骤1104同理，在此，本申请实施例对本步骤1304不再赘述。
仍以图14为例，虚拟机1410对应的后端驱动程序为线程1提供的总负载量为2M IOPS，其中，1M IOPS的负载量通过VF通道1401提供给加速卡A，1M IOPS的负载量通过VF通道1402提供给加速卡A，以VF通道1402为源VF通道，VF通道1402连接的虚拟功能单元A2作为虚拟机1410对应的后端驱动程序的源虚拟功能单元，调度器以线程1为源线程和目标线程，将虚拟机1410对应的后端驱动程序从虚拟功能单元A2调度到加速卡B2中的虚拟功能单元B1，删除VF通道1402，建立虚拟1410与虚拟功能单元B1之间的VF通道1403，对于虚拟机1410而言，加速卡B为新增的加速卡，即实现了通过增加加速卡调度虚拟机。
图13所述的方法实施例能够实现图2所示方法实施例的有益效果，另外，由于第一加速的负载量比较大，可能导致第五虚拟机的数据处理请求在第一加速卡等待处理，图13所示的方法实施例通过将至少一个第五虚拟机中的目标虚拟机调度到空闲加速卡，以避免后续目标虚拟机的数据处理请求长时间在第一加速卡排队等待处理，提高了目标虚拟机的数据处理效率，降低了第一加速卡的负载量，提高了第一加速卡的处理效率，也能使得空闲加速卡提供的资源能够被充分使用，避免空闲加速卡的资源浪费。
图15是本申请实施例提供的一种基于调度策略7的虚拟机的调度方法流程图，该方法应用于计算机设备，该计算机设备中配置有至少一个加速卡、多个虚拟机以及多个线程，该加速卡包括多个虚拟功能单元，虚拟机通过至少一个线程与至少一个虚拟功能单元通信，该方法由计算机设备内的调度器来执行，该方法包括如下步骤。
1501、调度器获取计算机设备中多个加速卡的负载量，该负载量与计算机设备中的该多个虚拟机有关。
其中，本步骤1501与步骤1101同理，在此，本申请实施例对本步骤1501不再赘述。
1502、调度器基于多个加速卡的负载量，从该多个加速卡中，确定多个第三加速卡，该多个第三加速卡的负载量之和小于或等于第八阈值。
其中，该多个第三加速卡为本次待合并的线程，该第八阈值大于0，第八阈值的取值可根据具体实施场景进行设置，在此，本申请实施例对第八阈值不做限定。
以加速卡有s个为例，按照负载量从小到大的顺序，对该s个加速卡的负载量进行排序，得到第五负载量序列，对第五负载量序列中的前k个负载量进行求和，若和值大于第八阈值，则将k减1继续后，再次执行对第五负载量序列中的前k个负载量进行求和的步骤，直到第五负载量序列中的前k-h个负载量的和值小于或等于第八阈值，则将前k-h个负载量所对应的各个加速卡作为第三加速卡，其中，k为大于0且小于s的整数，h为大于或等于0且小于或等于k-2的整数，s为大于2的整数。由于是直到第五负载量序列中的前k-h个负载量的和值小于或等于第八阈值，才将前k-h个负载量所对应的各个加速卡作为第三加速卡，之后保留一个第三加速卡使用时，能够在保证第三加速卡性能的情况下将尽可能多的空出加速卡。
或者是，调度器基于该多个加速卡的负载量，从确定多个线程中负载量最小的加速卡以及负载量次小的加速卡，若负载量最小的加速卡以及负载量次小的加速卡的总负载量小于或等于第八阈值，则将负载量最小的加速卡以及负载量次小的加速卡均确定为第三加速卡。
若该多个加速卡中不存在多个第三加速卡，则不再执行后续的步骤。
1503、调度器为第六虚拟机分配该多个第三加速卡中的第四加速卡，该第六虚拟机为与该多个第三加速卡中的第五加速卡通信的虚拟机。
其中，第四加速卡为该多个第三加速卡中的任一加速卡，该第五加速卡为该多个第三加速卡中除该第四加速卡以外的加速卡，即多个第三加速卡包括一个第四加速卡以及至少一个第五加速卡。在本申请实施例中，第四加速卡是本次待调度的目标虚拟机分配的目标线程，与至少一个第五加速卡通信的各个第六虚拟机为本次待调度的目标虚拟机。
在一种可能的实现方式中，调度器从多个第三加速卡中选择任一加速卡作为第四加速卡，将该多个第三加速卡中除第四加速卡以外的各个加速卡作为第五加速卡，对于任一第五加速卡，查询任一第五加速卡的虚拟功能单元的物理转发接口所在的VF通道，将查询到VF通道所连接的虚拟机确定为第六虚拟机，对于任一第六虚拟机，调度器将该第六虚拟机分配给第四加速卡。
例如，调度器将该第六虚拟机对应的各个后端驱动程序为目标后端驱动程序，对于任一目标后端驱动 程序，调度器从与第四加速卡的虚拟功能单元中，选择至少一个目标虚拟功能单元，对于任一目标虚拟功能单元，从与第四加速卡通信的线程中为该目标虚拟功能单元选择目标线程，或者，为该目标虚拟功能单元建立目标线程。然后，调度器基于该目标后端驱动程序、该目标线程以及目标虚拟功能单元，生成目标通道信息，以将第四加速卡分配给该目标后端驱动程序以及该第六虚拟机。此时，该目标通道信息包括该目标后端驱动程序的程序标识、该目标线程的线程标识以及该目标虚拟功能单元所对应的目标物理转发端口的目标端口信息。
应当理解的是，步骤1502-1503所示的过程为步骤202的一种实现方式。
1504、调度器将该第六虚拟机调度到该第四加速卡，以使该第六虚拟机与该第四加速卡能够通信。
其中，本步骤1504与步骤1104同理，在此，本申请实施例对本步骤1504不再赘述。
以图16所示的本申请实施例提供的一种基于调度策略7调度虚拟机的示意图为例，如图16所示的计算机设备中配置有加速卡A-B、虚拟机1610-1630以及线程1，以加速卡A-B分别为QAT以及MLX为例，加速卡A包括虚拟功能单元A1-A2，加速卡B包括虚拟功能单元B1-B2，在调度前，虚拟机1610通过线程1为虚拟功能单元A1以及虚拟功能单元B1分别提供10K IOPS的负载量，调度器以线程1为源线程和目标线程，以虚拟功能单元1610为第六虚拟机，将虚拟机1610及其对应的后端驱动程序从虚拟功能单元B1调度到虚拟功能单元A2，调度后，对于虚拟机1610而言分配的加速卡减少了，从而实现通过减少加速卡调度虚拟机。
由于第五加速卡上的各个第六虚拟机均调度到第四加速卡，使得第五加速卡成为空闲加速卡。
图15所述的方法实施例能够实现图2所示方法实施例的有益效果，另外，由于多个第三加速卡的负载量比较小，资源调度器将多个第三加速卡中的各个第五加速卡上的第六虚拟机都调度到多个第三加速卡中的第四加速卡，由第四加速卡负责与各个第六虚拟机通信，从而避免占用过多的加速卡。
在相关技术中，虚拟机对应的一个后端驱动程序只能通过一个VF通道绑定一个虚拟功能单元，且一个虚拟功能单元也只能绑定一个后端驱动程序，一方面导致后端虚拟程序与虚拟功能单元之间的通信方式不灵活，另一方面导致虚拟功能单元的复用效率低。而基于上述图3-16所示的各个方法实施例可知，通过执行本申请提供的虚拟机的调度方法，将后端驱动程序在多个虚拟功能单元之间调度，使得后端虚拟程序能够与多个虚拟功能单元灵活通信，且还能够实现最大X个后端驱动程序共享同一虚拟功能单元(或物理转发端口)，以提高虚拟功能单元的复用率，另外，还使得加速卡所服务的后端驱动程序的数量从1*QVF数量提升X*QVF，其中，X数值由VF所分配到的内存资源决定，QVF为加速卡中虚拟功能单元的数量。
在另一些实施例中，每个加速卡中配置有会话池，该会话池用于存储与该加速卡通信的虚拟机的会话信息。其中，虚拟机的会话信息包括该虚拟机中应用程序建立的会话(session)的会话信息，该会话信息包括会话的会话标识(identity，ID)。
调度器还提供有会话信息缓存服务，示例性地，调度器配置有计算机设备中多个虚拟机的会话(session)信息库，该会话信息库用于存储该多个虚拟机的会话信息。例如，该会话信息库包括各个加速卡的副本会话池，每个副本会话池用于缓存对应加速卡会话池中的会话信息的副本。
对于计算机设备中的任一虚拟机，在该虚拟机中的应用程序创建会话(session)时，如果该会话对某一加速卡有使用需求，则应用程序通过该虚拟机对应的标准的半虚拟化IO设备模型，将该会话的会话信息缓存到调度器中的会话信息库(如会话信息库中该加速卡的副本会话池)，再由调度器将该会话信息库中的会话信息复制该加速卡中的会话池，以便后续应用程序在会话过程中所下发的数据处理请求达到该加速卡后，加速卡能够根据数据处理请求中的携带的会话ID，在会话池中查询到对应的会话信息，根据查询到的会话信息对数据处理请求执行相应地的处理操作。
仍以图12为例，调度器包括会话信息库1203，加速卡A包括会话池A3，加速卡B包括会话池B3，虚拟机1210的会话信息以及虚拟机1230的会话信息存储会话池A3中，且会话信息库1203中还存储有会话池A3和B3中各个会话信息的副本。再例如，图1中的调度器104包括会话信息库。
基于此，对于图11提供的方法实施例，在将目标虚拟机从第一加速卡调度到第二加速卡之后，若第一加速卡和第二加速卡的类型不同，调度器从该会话信息库中查询目标虚拟机的会话信息。例如，调度器从该会话信息库中第一加速卡的副本会话池中查询该目标虚拟机的会话信息。当查询到目标虚拟机的会话信息后，调度器将查询到的目标虚拟机的会话信息存储至第二加速卡中的会话池，以便后续目标虚拟机中应用程序的数据处理请求在下发到第二加速卡后，第二加速卡根据数据处理请求携带的会话ID，能够从自己 的会话池中查询到该应用程序的会话信息。
相应地，对于图13提供的方法实施例，在调度器将该目标虚拟机调度到该空闲加速卡后，若第一加速卡和空闲加速卡的类型不同，调度器从会话信息库中查询目标虚拟机的会话信息，将查询到的目标虚拟机的会话信息存储至空闲加速卡中的会话池，以便后续目标虚拟机中应用程序的数据处理请求在下发到空闲加速卡后，空闲加速卡根据数据处理请求携带的会话ID，能够从自己的会话池中查询到该应用程序的会话信息。
相应地，对于图15提供的方法实施例，在将该第六虚拟机调度到该第四加速卡后，若第四加速卡和第五加速卡的类型不同，调度器从会话信息库中查询第六虚拟机的会话信息，将查询到的第六虚拟机的会话信息存储至第四加速卡中的会话池，以便后续第六虚拟机中应用程序的数据处理请求在下发到第四加速卡后，第四加速卡根据数据处理请求携带的会话ID，能够从自己的会话池中查询到该应用程序的会话信息。
在另一些实施例中，在计算机设备中的虚拟机发生迁移时，调度器也能为目标计算机设备提供该虚拟机的会话信息。其中，虚拟机迁移需保证该虚拟机的租户对迁移过程无感知，因此又叫虚拟机在线迁移或热迁移。
图17所示的本申请实施例提供的一种虚拟机迁移过程的示意图为例，为例便于描述，将待迁移的虚拟机称为源虚拟机，源虚拟机所在的计算机设备称为源设备，源设备中的调度器称为源调度器，在源虚拟机发生迁移前，源虚拟机中应用程序在创建会话时，若该会话对加速卡有使用需求，应用程序向该源虚拟机对应的前端驱动程序发送该会话的会话信息，前端驱动程序一方面缓存该会话信息(如将该会话信息缓存到该虚拟机对应的内存页)，另一方面，将该会话信息复制一份发送给对应的后端驱动程序。该后端驱动程序接收到该会话信息后，将该会话信息存储在源调度器的会话信息库，由源调度器将该会话信息复制到该加速卡的会话池中。在源虚拟机发生热迁移时，源设备中的云管理平台通知另一计算机设备(即目的设备)的云管理平台客户端创建目的虚拟机，且目的虚拟机的规格与源虚拟机的规格相同，另外，还为目标虚拟机创建和源虚拟机相同的前端驱动程序和后端驱动程序。源设备中的云管理平台将源虚拟机对应的内存页数据发送到目的设备中目标虚拟机对应的内存空间，相应地，该源虚拟机的前端驱动程序缓存的会话信息也就发送到目标虚拟机对应的内存空间。但是，源调度器的会话信息库中源虚拟机的会话信息无法同步到目的设备，且源设备中源虚拟机对应加速卡的会话池中源虚拟机的会话信息也无法同步目的设备。
在迁移完成后，在目的虚拟机运行的过程中，目的虚拟机中的该应用程序在会话过程中下发的数据处理请求达到目的调度器(如目的调度器管理的线程)后，目的调度器会根据该数据处理请求携带的该会话的会话ID，在会话信息库中查询该会话的会话信息，而由于该目的调度器的会话信息库没有存储该应用程序的会话信息，则目的调度器在根据该会话ID查询会话信息时，发生会话信息缺失(miss)，触发目的调度器通过后端驱动程序向前端驱动程序发送会话信息获取请求，该会话信息获取请求指示获取该会话ID所指示的会话信息。前端驱动程序在获取到该会话信息获取请求后，基于该会话信息获取请求携带的会话ID，从缓存的会话信息中查询该会话ID所指示的会话信息，通过后端驱动程序向目的调度器发送查询到的会话信息。目的调度器将前端驱动程序返回的会话信息存储到自己的会话信息库以及与目标虚拟机通信的加速卡中的会话池，以便该加速卡基于该会话信息对数据处理请求进行相应地处理操作。另外，当目的调度器首次接收到该目的虚拟机中的该会话中的数据处理请求时，触发向前端驱动程序获取一次会话信息即可，无需多次获取。
通过目的调度器为加速卡从前端驱动程序获取会话信息，避免出现在热迁移时因无法将加速卡中的会话信息无法迁移到目的设备，而导致的迁移后会话信息丢失。
以上介绍了本申请实施例的方法，以下介绍本申请实施例的装置。应理解，以下介绍的装置具有上述方法中调度器的任意功能。上文结合图2至图17详细描述了根据本申请实施例的传输数据的方法。基于同一发明构思，下面将结合图18描述根据本申请实施例的虚拟机调度的装置。应理解，方法实施例所描述的技术特征同样适用于以下装置实施例。
参见图18，图18是本申请实施例提供的一种虚拟机的调度装置的结构示意图，图18所示的装置1800可以为前面各个实施例或图2-17中的调度器或调度器的部分，用于执行调度器所执行的方法，所述装置1800应用于计算机设备，所述计算机设备中配置有至少一个加速卡、多个虚拟机以及多个线程，所述加速卡包括多个虚拟功能单元，所述虚拟机通过至少一个线程与至少一个虚拟功能单元通信；装置1800包括：
获取模块1801，用于获取所述计算机设备的至少一种通信单元的负载量，所述通信单元为所述虚拟功能单元、所述线程或所述加速卡，所述通信单元的负载量与所述多个虚拟机有关；
分配模块1802，用于基于所述至少一种通信单元的负载量，为所述至少一个加速卡中的目标虚拟机分配目标通信单元，所述目标通信单元为所述虚拟功能单元、所述线程或所述加速卡；
调度模块1803，用于将所述目标虚拟机调度到所述目标通信单元，以使所述目标虚拟机与所述目标通信单元能够通信。
在一种可能的实现方式中，所述通信单元为所述虚拟功能单元，所述至少一种通信单元的负载量包括所述至少一个加速卡中各个虚拟功能单元的负载量，所述目标通信单元为所述虚拟功能单元；所述分配模块1802用于：
基于所述至少一个加速卡中各个虚拟功能单元的负载量，确定第一虚拟功能单元以及第二虚拟功能单元，所述第一虚拟功能单元为所述至少一个加速卡中负载量最大的虚拟功能单元，所述第二虚拟功能单元为所述至少一个加速卡中负载量最小的虚拟功能单元；
若所述第一虚拟功能单元与所述第二虚拟功能单元之间的第一负载量差值大于或等于第一阈值，为至少一个第一虚拟机中的目标虚拟机分配所述第二虚拟功能单元，所述第一虚拟机为所述多个虚拟机中与所述第一虚拟功能单元通信的虚拟机。
在一种可能的实现方式中，所述通信单元为所述线程，所述至少一种通信单元的负载量包括所述多个线程的负载量，所述目标通信单元为所述线程；所述分配模块1802包括：
确定子模块，用于基于所述多个线程的负载量，确定第一线程以及第二线程，所述第一线程为所述多个线程中负载量最大的线程，所述第二线程为所述多个线程中负载量最小的线程；
分配子模块，用于为至少一个第二虚拟机中的目标虚拟机分配所述第二线程，所述第二虚拟机为所述多个虚拟机中与所述第一线程通信的虚拟机。
在一种可能的实现方式中，所述分配子模块用于：
对于所述至少一个第二虚拟机中的第一候选虚拟机，基于所述第一候选虚拟机为所述第一线程提供的第一总负载量、所述第一线程的负载量以及所述第二线程的负载量，分别对所述第一线程的负载量以及所述第二线程的负载量进行预测，得到第一预测负载量以及第二预测负载量，所述第一预测负载量为将所述第一候选虚拟机调度到所述第二线程后所述第一线程的负载量，所述第二预测负载量为将所述第一候选虚拟机调度到所述第二线程后所述第二线程的负载量；
若所述第一预测负载量与所述第二预测负载量之间的差值的绝对值小于或等于第二阈值，为所述第一候选虚拟机分配所述第二线程。
在一种可能的实现方式中，所述通信单元为所述线程，所述至少一种资源的负载量包括所述多个线程的负载量，所述目标通信单元为所述线程；所述分配模块1802包括：
确定子模块，用于基于所述多个线程的负载量，从所述多个线程中，确定第三线程以及第四线程，所述第三线程的负载量大于或等于第三阈值，所述第四线程的负载量小于所述第三线程的负载量；
分配子模块，用于为至少一个第三虚拟机中的目标虚拟机分配所述第四线程，所述第三虚拟机为所述多个虚拟机中所述第三线程通信的虚拟机。
在一种可能的实现方式中，所述分配子模块用于：
对于所述至少一个第三虚拟机中的第二候选虚拟机，基于所述第二候选虚拟机为所述第三线程提供的第二总负载量、所述第三线程的负载量以及所述第四线程的负载量，分别对所述第三线程的负载量以及所述第四线程的负载量进行预测，得到第三预测负载量以及第四预测负载量，所述第三预测负载量为将所述第二候选虚拟机调度到所述第四线程后所述第三线程的负载量，所述第四预测负载量为将所述第二候选虚拟机调度到所述第四线程后所述第四线程的负载量；
若所述第三预测负载量与所述第四预测负载量之间的差值的绝对值小于或等于第四阈值，为所述第二候选虚拟机分配所述第四线程。
在一种可能的实现方式中，所述通信单元为所述线程，所述至少一种通信单元的负载量包括所述多个线程的负载量，所述目标通信单元为所述线程；所述分配模块1802用于：
基于所述多个线程的负载量，从所述多个线程中，确定多个第五线程，所述多个第五线程的负载量之和小于或等于第五阈值；
为第四虚拟机分配所述多个第五线程中的第六线程，所述第四虚拟机为与所述多个第五线程中的第七线程通信的虚拟机，所述第七线程为所述多个第五线程中除所述第六线程以外的线程。
在一种可能的实现方式中，所述通信单元为所述加速卡，所述至少一个加速卡包括多个加速卡，所述至少一种通信单元的负载量包括所述多个加速卡的负载量，所述目标通信单元为所述加速卡；所述分配模块1802：
确定子模块，用于基于所述多个加速卡的负载量，确定第一加速卡和第二加速卡，所述第一加速卡为所述多个加速卡中负载量最大的加速卡，所述第二加速卡为所述多个加速卡中负载量最小的加速卡；
分配子模块，用于为至少一个第五虚拟机中的目标虚拟机分配所述第二加速卡，所述第五虚拟机为所述多个虚拟机中与所述第一加速卡通信的虚拟机。
在一种可能的实现方式中，所述分配子模块用于：
对于所述至少一个第五虚拟机中的第三候选虚拟机，基于所述第三候选虚拟机为所述第一加速卡提供的第三总负载量、所述第一加速卡的负载量以及所述第二加速卡的负载量，分别对所述第一加速卡的负载量以及所述第二加速卡的负载量进行预测，得到第五预测负载量以及第六预测负载量，所述第五预测负载量为将所述第三候选虚拟机调度到所述第二加速卡后所述第一加速卡的负载量，所述第六预测负载量为将所述第三候选虚拟机调度到所述第二加速卡后所述第二加速卡的负载量；
若所述第五预测负载量与所述第六预测负载量之间的差值的绝对值小于或等于第六阈值，为所述第三候选虚拟机分配所述第二加速卡。
在一种可能的实现方式中，所述装置1800还包括：
查询模块，用于若所述第一加速卡和所述第二加速卡的类型不同，从所述多个虚拟机的会话信息库，查询所述目标虚拟机的会话信息，所述会话信息库用于存储所述多个虚拟机的会话信息；
存储模块，用于将所述目标虚拟机的会话信息存储至所述第二加速卡的会话池，所述会话池用于存储与所述第二加速卡通信的虚拟机的会话信息。
在一种可能的实现方式中，所述通信单元为所述加速卡，所述至少一个加速卡包括多个加速卡，所述至少一种通信单元的负载量包括所述多个加速卡的负载量，所述目标通信单元为所述加速卡；所述分配模块1802用于：
基于所述多个加速卡的负载量，确定第一加速卡，所述第一加速卡为所述多个加速卡中负载量最大的加速卡；
若所述第一加速卡的负载量大于或等于第七阈值，且所述多个加速卡中存在空闲加速卡，为至少一个第五虚拟机中的目标虚拟机分配所述空闲加速卡，所述第五虚拟机为所述多个虚拟机中与所述第一加速卡通信的虚拟机。
在一种可能的实现方式中，所述通信单元为所述加速卡，所述至少一个加速卡包括多个加速卡，所述至少一种通信单元的负载量包括所述多个加速卡的负载量，所述目标通信单元为所述加速卡；所述分配模块1802用于：
基于所述多个加速卡的负载量，从所述多个加速卡中，确定多个第三加速卡，所述多个第三加速卡的负载量之和小于或等于第八阈值；
为第六虚拟机分配所述多个第三加速卡中的第四加速卡，所述第六虚拟机为与所述多个第三加速卡中的第五加速卡通信的虚拟机，所述第五加速卡为所述多个第三加速卡中除所述第四加速卡以外的加速卡。
应理解，装置1800对应于上述方法实施例中的调度器，装置1800中的各模块和上述其他操作和/或功能分别为了实现方法实施例中的调度器所实施的各种步骤和方法，具体细节可参见上述方法实施例，为了简洁，在此不再赘述。
应理解，装置1800在调度虚拟机时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置1800的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的装置1800与上述方法实施例属于同一构思，其具体实现过程详见上述方法实施例，这里不再赘述。
图19是本申请实施例提供的一种芯片的结构示意图，图19是本申请提供的一种芯片的结构示意图，如图19所示，芯片1900包括处理器1901和接口电路1902，其中，接口电路1902，用于接收指令并传输至处理器1901。处理器1901例如可以装置1800的一种具体实现形式，可以用于执行上述虚拟机的调度方 法。处理器1901与存储器1903耦合，存储器1903用于存储程序代码，当该程序代码被处理器1901执行时，使得处理器1901、接口电路1902以及存储器1903所组成的芯片系统实现上述图2至图17中任一方法实施例中的方法的操作步骤。
可选地，该芯片系统中的处理器1901有至少一个，应理解，在本申请实施例中，处理器1901可以是CPU或其他通用处理器，处理器1901还可以是一个或多个用于实现本申请方案的集成电路，例如，数字信号处理器(digital signal processing，DSP)、ASIC、PLD、FPGA或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者是任何常规的处理器等。
可选地，该芯片系统中的存储器1903也可以为一个或多个。存储器1903可以与处理器1901集成在一起，也可以和处理器1901分离设置，本申请并不限定。示例性的，存储器1903可以与处理器1901集成在同一块芯片上，如图19所示，存储器1903也可以和处理器1901分别设置在不同的芯片上，本申请对存储器1903的类型以及存储器1903与处理器1901的设置方式不作具体限定。
其中，存储器1903可以包括只读存储器和随机存取存储器，并向处理器1901提供指令和数据。存储器1903还可以包括非易失性随机存取存储器。例如，存储器1903还可以存储设备类型的信息。存储器1903还可以是易失性存储器，或可包括易失性和非易失性存储器两者。
其中，非易失性存储器可以是只读存储器(read-only memory，ROM)、可编程只读存储器(programmable ROM，PROM)、可擦除可编程只读存储器(erasable PROM，EPROM)、电可擦除可编程只读存储器(electrically EPROM，EEPROM)或闪存。易失性存储器可以是随机存取存储器(random access memory，RAM)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的RAM可用，例如静态随机存取存储器(static RAM，SRAM)、动态随机存取存储器(DRAM)、同步动态随机存取存储器(synchronous DRAM，SDRAM)、双倍数据速率同步动态随机存取存储器(double data date SDRAM，DDR SDRAM)、增强型同步动态随机存取存储器(enhanced SDRAM，ESDRAM)、同步连接动态随机存取存储器(synchlink DRAM，SLDRAM)和直接内存总线随机存取存储器(direct rambus RAM，DR RAM)。
示例性的，该芯片系统可以是FPGA，可以是ASIC，还可以是SoC，还可以是CPU，还可以是网络处理器(network processor，NP)，还可以是数字信号处理电路(digital signal processor，DSP)，还可以是微控制器(micro controller unit，MCU)，还可以是PLD或其他集成芯片。
图20是本申请实施例提供的一种计算机设备的结构示意图。如图所示，计算机设备2000包括处理器2001、存储器2002、通信接口2003以及总线2004。其中，处理器2001、存储器2002、通信接口2003通过总线2004进行通信，也可以通过无线传输等其他手段实现通信。存储器2002用于存储指令，处理器2001用于执行该存储器2002存储的程序代码。处理器2001可以调用存储器2002中存储的程序代码执行上述虚拟机的调度方法(如上述的图2至图17)所提供的步骤。
示例性地，处理器2001可以包括一个或多个CPU。
示例性地，计算机设备2000可以包括多个处理器2001，这些处理器中的每一个可以是一个单核处理器(single-CPU)，也可以是一个多核处理器(multi-CPU)。这里的处理器可以指一个或多个设备、电路、和/或用于处理数据(如计算机程序指令)的处理核。
应理解，在本申请中，处理器2001和图19中的处理器1901的实现方式类似，存储器2002和图19中的存储器1903的实现方式类似，在此，本申请实施例对处理器2001和存储器2002的实现方式不做赘述。
通信接口2003使用任何收发器一类的装置，用于与其它设备或通信网络通信。通信接口2004包括有线通信接口，还可以包括无线通信接口。其中，有线通信接口例如可以为以太网接口。以太网接口可以是光接口，电接口或其组合。无线通信接口可以为无线局域网(wireless local area networks，WLAN)接口，蜂窝网络通信接口或其组合等。
总线2004用于在上述组件之间传送信息，总线2004除包括通信总线之外，还可以包括电源总线和状态信号总线等。但是为了清楚说明起见，在图中将各种总线都标为总线2004。其中，通信总线可以分为地址总线、数据总线、控制总线等。示例性地，通信总线可以是快捷外围部件互连标准(Peripheral Component Interconnect Express，PCIe)总线、扩展工业标准结构(extended industry standard architecture，EISA)总线、统一总线(unified bus，Ubus或UB)、计算机快速链接(compute express link，CXL)或缓存一致互联协议(cache coherent interconnect for accelerators，CCIX)等。
在一些实施例中，计算机设备还包括存储设备，存储设备可以是ROM或可存储静态信息和指令的其 它类型的静态存储设备，也可以是RAM或者可存储信息和指令的其它类型的动态存储设备，也可以是EEPROM、只读光盘(compact disc read-only memory，CD-ROM)或其它光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其它磁存储设备，或者是能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由处理器2001存取的任何其它介质，该存储设备包括至少一个存储器2002，但不限于此。存储设备可以是独立存在，并通过总线2004与处理器2001相连接。存储设备也可以和处理器2001集成在一起。
在一些实施例中，计算机设备2000还可以包括输出设备和输入设备2005。输出设备和处理器2001通信，可以以多种方式来显示信息。例如，输出设备可以是液晶显示器(liquid crystal display，LCD)、发光二级管(light emitting diode，LED)显示设备、阴极射线管(cathode ray tube，CRT)显示设备或投影仪(projector)等。输入设备2005和处理器2001通信，可以以多种方式接收用户的输入。例如，输入设备2005可以是加速卡、鼠标、键盘、触摸屏设备或传感设备等。
应理解，根据本申请用于实现虚拟机调度的计算机设备2000可对应于本申请实施例中的调度器所在的计算机设备，并可以对应于执行根据本申请实施例的虚拟机的调度方法中的相应主体，并且计算机设备2000中的各个模块的上述和其它操作和/或功能分别为了实现图2至图17中的各个方法的相应流程，为了简洁，在此不再赘述。
本申请还提供了一种计算机可读存储介质，例如包括程序代码的存储器，上述程序代码可由计算机设备(或芯片)中的处理器执行以完成上述实施例中虚拟机的调度方法。该计算机可读存储介质的实现方式可参考与图19中的存储器1903。
本申请还提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括程序代码，该程序代码存储在计算机可读存储介质中，计算机设备(或芯片)的处理器从计算机可读存储介质读取该程序代码，处理器执行该程序代码，使得计算机设备(或芯片)执行上述虚拟机的调度方法。
另外，本申请还提供一种装置，这个装置具体可以是芯片，组件或模块，该装置可包括相连的处理器和存储器；其中，存储器用于存储计算机执行指令，当装置运行时，处理器可执行存储器存储的计算机执行指令，以使芯片执行上述各方法实施例中虚拟机的调度方法。
其中，本申请提供的装置、设备、计算机可读存储介质、计算机程序产品或芯片均用于执行上文所提供的对应的方法，因此，其所能达到的有益效果可参考上文所提供的对应的方法中的有益效果，此处不再赘述。
上述实施例，可以全部或部分地通过软件、硬件、固件或其他任意组合来实现。当使用软件实现时，上述实施例可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载或执行所述计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以为通用计算机、专用计算机、计算机网络或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集合的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质(例如，软盘、硬盘、磁带)、光介质(例如，DVD)或者半导体介质。半导体介质可以是固态硬盘(solid state disk，SSD)。
以上所述，仅为本申请的具体实施方式。熟悉本技术领域的技术人员根据本申请提供的具体实施方式，可想到变化或替换，都应涵盖在本申请的保护范围之内。

Claims (15)

  1. 一种虚拟机的调度方法，其特征在于，所述方法应用于计算机设备，所述计算机设备中配置有至少一个加速卡、多个虚拟机以及多个线程，所述加速卡包括多个虚拟功能单元，所述虚拟机通过至少一个线程与至少一个虚拟功能单元通信；所述方法包括：
    获取所述计算机设备的至少一种通信单元的负载量，所述通信单元为所述虚拟功能单元、所述线程或所述加速卡，所述通信单元的负载量与所述多个虚拟机有关；
    基于所述至少一种通信单元的负载量，为所述至少一个加速卡中的目标虚拟机分配目标通信单元，所述目标通信单元为所述虚拟功能单元、所述线程或所述加速卡；
    将所述目标虚拟机调度到所述目标通信单元，以使所述目标虚拟机与所述目标通信单元能够通信。
  2. 根据权利要求1所述的方法，其特征在于，所述通信单元为所述虚拟功能单元，所述至少一种通信单元的负载量包括所述至少一个加速卡中各个虚拟功能单元的负载量，所述目标通信单元为所述虚拟功能单元；
    所述基于所述至少一种通信单元的负载量，为所述至少一个加速卡中的目标虚拟机分配目标通信单元包括：
    基于所述至少一个加速卡中各个虚拟功能单元的负载量，确定第一虚拟功能单元以及第二虚拟功能单元，所述第一虚拟功能单元为所述至少一个加速卡中负载量最大的虚拟功能单元，所述第二虚拟功能单元为所述至少一个加速卡中负载量最小的虚拟功能单元；
    若所述第一虚拟功能单元与所述第二虚拟功能单元之间的第一负载量差值大于或等于第一阈值，为至少一个第一虚拟机中的目标虚拟机分配所述第二虚拟功能单元，所述第一虚拟机为所述多个虚拟机中与所述第一虚拟功能单元通信的虚拟机。
  3. 根据权利要求1所述的方法，其特征在于，所述通信单元为所述线程，所述至少一种通信单元的负载量包括所述多个线程的负载量，所述目标通信单元为所述线程；
    所述基于所述至少一种通信单元的负载量，为所述至少一个加速卡中的目标虚拟机分配目标通信单元包括：
    基于所述多个线程的负载量，确定第一线程以及第二线程，所述第一线程为所述多个线程中负载量最大的线程，所述第二线程为所述多个线程中负载量最小的线程；
    为至少一个第二虚拟机中的目标虚拟机分配所述第二线程，所述第二虚拟机为所述多个虚拟机中与所述第一线程通信的虚拟机。
  4. 根据权利要求3所述的方法，其特征在于，所述为至少一个第二虚拟机中的目标虚拟机分配所述第二线程包括：
    对于所述至少一个第二虚拟机中的第一候选虚拟机，基于所述第一候选虚拟机为所述第一线程提供的第一总负载量、所述第一线程的负载量以及所述第二线程的负载量，分别对所述第一线程的负载量以及所述第二线程的负载量进行预测，得到第一预测负载量以及第二预测负载量，所述第一预测负载量为将所述第一候选虚拟机调度到所述第二线程后所述第一线程的负载量，所述第二预测负载量为将所述第一候选虚拟机调度到所述第二线程后所述第二线程的负载量；
    若所述第一预测负载量与所述第二预测负载量之间的差值的绝对值小于或等于第二阈值，为所述第一候选虚拟机分配所述第二线程。
  5. 根据权利要求1所述的方法，其特征在于，所述通信单元为所述线程，所述至少一种资源的负载量包括所述多个线程的负载量，所述目标通信单元为所述线程；
    所述基于所述至少一种通信单元的负载量，为所述至少一个加速卡中的目标虚拟机分配目标通信单元包括：
    基于所述多个线程的负载量，从所述多个线程中，确定第三线程以及第四线程，所述第三线程的负载量大于或等于第三阈值，所述第四线程的负载量小于所述第三线程的负载量；
    为至少一个第三虚拟机中的目标虚拟机分配所述第四线程，所述第三虚拟机为所述多个虚拟机中所述第三线程通信的虚拟机。
  6. 根据权利要求5所述的方法，其特征在于，所述为至少一个第三虚拟机中的目标虚拟机分配所述第四线程包括：
    对于所述至少一个第三虚拟机中的第二候选虚拟机，基于所述第二候选虚拟机为所述第三线程提供的第二总负载量、所述第三线程的负载量以及所述第四线程的负载量，分别对所述第三线程的负载量以及所述第四线程的负载量进行预测，得到第三预测负载量以及第四预测负载量，所述第三预测负载量为将所述第二候选虚拟机调度到所述第四线程后所述第三线程的负载量，所述第四预测负载量为将所述第二候选虚拟机调度到所述第四线程后所述第四线程的负载量；
    若所述第三预测负载量与所述第四预测负载量之间的差值的绝对值小于或等于第四阈值，为所述第二候选虚拟机分配所述第四线程。
  7. 根据权利要求1所述的方法，其特征在于，所述通信单元为所述线程，所述至少一种通信单元的负载量包括所述多个线程的负载量，所述目标通信单元为所述线程；
    所述基于所述至少一种通信单元的负载量，为所述至少一个加速卡中的目标虚拟机分配目标通信单元包括：
    基于所述多个线程的负载量，从所述多个线程中，确定多个第五线程，所述多个第五线程的负载量之和小于或等于第五阈值；
    为第四虚拟机分配所述多个第五线程中的第六线程，所述第四虚拟机为与所述多个第五线程中的第七线程通信的虚拟机，所述第七线程为所述多个第五线程中除所述第六线程以外的线程。
  8. 根据权利要求1所述的方法，其特征在于，所述通信单元为所述加速卡，所述至少一个加速卡包括多个加速卡，所述至少一种通信单元的负载量包括所述多个加速卡的负载量，所述目标通信单元为所述加速卡；
    所述基于所述至少一种通信单元的负载量，为所述至少一个加速卡中的目标虚拟机分配目标通信单元包括：
    基于所述多个加速卡的负载量，确定第一加速卡和第二加速卡，所述第一加速卡为所述多个加速卡中负载量最大的加速卡，所述第二加速卡为所述多个加速卡中负载量最小的加速卡；
    为至少一个第五虚拟机中的目标虚拟机分配所述第二加速卡，所述第五虚拟机为所述多个虚拟机中与所述第一加速卡通信的虚拟机。
  9. 根据权利要求8所述的方法，其特征在于，所述为至少一个第五虚拟机中的目标虚拟机分配所述第二加速卡包括：
    对于所述至少一个第五虚拟机中的第三候选虚拟机，基于所述第三候选虚拟机为所述第一加速卡提供的第三总负载量、所述第一加速卡的负载量以及所述第二加速卡的负载量，分别对所述第一加速卡的负载量以及所述第二加速卡的负载量进行预测，得到第五预测负载量以及第六预测负载量，所述第五预测负载量为将所述第三候选虚拟机调度到所述第二加速卡后所述第一加速卡的负载量，所述第六预测负载量为将所述第三候选虚拟机调度到所述第二加速卡后所述第二加速卡的负载量；
    若所述第五预测负载量与所述第六预测负载量之间的差值的绝对值小于或等于第六阈值，为所述第三候选虚拟机分配所述第二加速卡。
  10. 根据权利要求8或9所述的方法，其特征在于，所述为至少一个第五虚拟机中的目标虚拟机分配所述第二加速卡之后，所述方法还包括：
    若所述第一加速卡和所述第二加速卡的类型不同，从所述多个虚拟机的会话信息库，查询所述目标虚 拟机的会话信息，所述会话信息库用于存储所述多个虚拟机的会话信息；
    将所述目标虚拟机的会话信息存储至所述第二加速卡的会话池，所述会话池用于存储与所述第二加速卡通信的虚拟机的会话信息。
  11. 根据权利要求1所述的方法，其特征在于，所述通信单元为所述加速卡，所述至少一个加速卡包括多个加速卡，所述至少一种通信单元的负载量包括所述多个加速卡的负载量，所述目标通信单元为所述加速卡；
    所述基于所述至少一种通信单元的负载量，为所述至少一个加速卡中的目标虚拟机分配目标通信单元包括：
    基于所述多个加速卡的负载量，确定第一加速卡，所述第一加速卡为所述多个加速卡中负载量最大的加速卡；
    若所述第一加速卡的负载量大于或等于第七阈值，且所述多个加速卡中存在空闲加速卡，为至少一个第五虚拟机中的目标虚拟机分配所述空闲加速卡，所述第五虚拟机为所述多个虚拟机中与所述第一加速卡通信的虚拟机。
  12. 根据权利要求1所述的方法，其特征在于，所述通信单元为所述加速卡，所述至少一个加速卡包括多个加速卡，所述至少一种通信单元的负载量包括所述多个加速卡的负载量，所述目标通信单元为所述加速卡；
    所述基于所述至少一种通信单元的负载量，为所述至少一个加速卡中的目标虚拟机分配目标通信单元包括：
    基于所述多个加速卡的负载量，从所述多个加速卡中，确定多个第三加速卡，所述多个第三加速卡的负载量之和小于或等于第八阈值；
    为第六虚拟机分配所述多个第三加速卡中的第四加速卡，所述第六虚拟机为与所述多个第三加速卡中的第五加速卡通信的虚拟机，所述第五加速卡为所述多个第三加速卡中除所述第四加速卡以外的加速卡。
  13. 一种虚拟机的调度装置，其特征在于，所述装置应用于计算机设备，所述计算机设备中配置有至少一个加速卡、多个虚拟机以及多个线程，所述加速卡包括多个虚拟功能单元，所述虚拟机通过至少一个线程与至少一个虚拟功能单元通信；所述装置包括：
    获取模块，用于获取所述计算机设备的至少一种通信单元的负载量，所述通信单元为所述虚拟功能单元、所述线程或所述加速卡，所述通信单元的负载量与所述多个虚拟机有关；
    分配模块，用于基于所述至少一种通信单元的负载量，为所述至少一个加速卡中的目标虚拟机分配目标通信单元，所述目标通信单元为所述虚拟功能单元、所述线程或所述加速卡；
    调度模块，用于将所述目标虚拟机调度到所述目标通信单元，以使所述目标虚拟机与所述目标通信单元能够通信。
  14. 一种芯片，其特征在于，所述芯片包括处理器，所述处理器用于执行至少一条程序代码，使得所述芯片执行如权利要求1至权利要求12中任一项所述的方法。
  15. 一种计算机可读存储介质，其特征在于，所述存储介质中存储有至少一条程序代码，所述至少一条程序代码由芯片中的处理器读取以使所述芯片执行如权利要求1至权利要求12中任一项所述的方法。
PCT/CN2023/130566 2022-12-23 2023-11-08 虚拟机的调度方法、装置、芯片以及计算机可读存储介质 WO2024131368A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202211666451.XA CN118245163A (zh) 2022-12-23 2022-12-23 虚拟机的调度方法、装置、芯片以及计算机可读存储介质
CN202211666451.X 2022-12-23

Publications (1)

Publication Number Publication Date
WO2024131368A1 true WO2024131368A1 (zh) 2024-06-27

Family

ID=91555306

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2023/130566 WO2024131368A1 (zh) 2022-12-23 2023-11-08 虚拟机的调度方法、装置、芯片以及计算机可读存储介质

Country Status (2)

Country Link
CN (1) CN118245163A (zh)
WO (1) WO2024131368A1 (zh)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170235585A1 (en) * 2016-02-12 2017-08-17 At&T Intellectual Property I, L.P. Management of IoT Devices in a Virtualized Network
CN109558216A (zh) * 2018-12-11 2019-04-02 深圳先进技术研究院 一种基于在线迁移的单根i/o虚拟化优化方法及其系统
CN112367267A (zh) * 2020-09-30 2021-02-12 新华三大数据技术有限公司 一种虚拟机管理方法及装置
CN113032103A (zh) * 2021-04-14 2021-06-25 中南大学 基于高速网卡sr-iov功能的vf资源动态调度方法
CN114531405A (zh) * 2020-10-31 2022-05-24 华为技术有限公司 一种流表处理方法及相关设备

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170235585A1 (en) * 2016-02-12 2017-08-17 At&T Intellectual Property I, L.P. Management of IoT Devices in a Virtualized Network
CN109558216A (zh) * 2018-12-11 2019-04-02 深圳先进技术研究院 一种基于在线迁移的单根i/o虚拟化优化方法及其系统
CN112367267A (zh) * 2020-09-30 2021-02-12 新华三大数据技术有限公司 一种虚拟机管理方法及装置
CN114531405A (zh) * 2020-10-31 2022-05-24 华为技术有限公司 一种流表处理方法及相关设备
CN113032103A (zh) * 2021-04-14 2021-06-25 中南大学 基于高速网卡sr-iov功能的vf资源动态调度方法

Also Published As

Publication number Publication date
CN118245163A (zh) 2024-06-25

Similar Documents

Publication Publication Date Title
CN109375872B (zh) 数据访问请求的处理方法、装置和设备及存储介质
US10951515B2 (en) Leveraging multi-stream transport protocol capabilities for routing
US11159454B2 (en) Technologies for accelerating edge device workloads
US10701139B2 (en) Life cycle management method and apparatus
US9003409B2 (en) Common contiguous memory region optimized long distance virtual machine migration
WO2018035856A1 (zh) 实现硬件加速处理的方法、设备和系统
WO2018027586A1 (zh) 云计算系统中虚拟机访问物理服务器的方法、装置和系统
US9998532B2 (en) Computer-based, balanced provisioning and optimization of data transfer resources for products and services
JP3382953B2 (ja) 有限メモリコンピュータシステム上におけるクライアント管理フロー制御方法及び装置
US8725875B2 (en) Native cloud computing via network segmentation
US20200356402A1 (en) Method and apparatus for deploying virtualized network element device
CN107707622B (zh) 一种访问桌面云虚拟机的方法、装置及桌面云控制器
US20110078679A1 (en) Provisioning virtual machine placement
US11734172B2 (en) Data transmission method and apparatus using resources in a resource pool of a same NUMA node
US11099952B2 (en) Leveraging server side cache in failover scenario
WO2022111313A1 (zh) 一种请求处理方法及微服务系统
US10656966B1 (en) Deep-inspection weighted round robin of multiple virtualized resources
CN112600761A (zh) 一种资源分配的方法、装置及存储介质
US11985065B2 (en) Enabling isolated virtual network configuration options for network function accelerators
US20140289728A1 (en) Apparatus, system, method, and storage medium
Ashalatha et al. Dynamic load balancing methods for resource optimization in cloud computing environment
WO2024131368A1 (zh) 虚拟机的调度方法、装置、芯片以及计算机可读存储介质
US7669202B1 (en) Resource management
Thaha et al. Data location aware scheduling for virtual Hadoop cluster deployment on private cloud computing environment
US9176910B2 (en) Sending a next request to a resource before a completion interrupt for a previous request