Method and system for flexibly transparently transmitting PCI devices for virtual machines based on OpenStack platform

Abstract

The present invention discloses a method and system for flexibly transparently transmitting PCI devices for virtual machines based on the OpenStack platform, belonging to the technical field of OpenStack cloud computing. The technical problem to be solved by the present invention is that the transmitted PCI devices cannot be added when the virtual machine is running, the transparent PCI devices cannot be uninstalled at run time, and the number of virtual machine type templates may be expanded. The technical scheme adopted is as follows: The method is specifically as follows: by modifying the API method, that is, adding two new API entrances, the dynamic mounting of PCI devices and the dynamic uninstallation of PCI devices are realized; by adding a new API method, the type of PCI device is configured; when calling the API interface, the user specifies the type of the mounted device. The system includes a mounting module, an uninstallation module, a configuration module and a designation module.

Description

Technical Field

[0001] The present invention relates to the technical field of OpenStack cloud computing, and in particular to a method and system for flexibly transparently transmitting PCI devices for virtual machines based on an OpenStack platform. Background Art

[0002] OpenStack originated from cloud computing and has been developing rapidly. IaaS (Infrastructure as a Service) is the most popular cloud service currently provided by cloud service providers, and OpenStack is its most typical representative. As a large-scale cloud operating system, OpenStack controls the three major resources of computing, networking, and storage, provides a web-based visual interface for administrators to control, and adopts an identity authentication mechanism to grant user permissions and resources. It has its standard infrastructure and service functions, but also has other components to provide other services to ensure the high availability of user applications. OpenStack has received extensive support from major leading manufacturers, has strong compatibility and applicability, and is very convenient and reliable to use. It meets the needs of users in scenarios such as high-performance computing, artificial intelligence, and graphics and image processing.

[0003] IOMMU is the abbreviation of Input / Output Memory Management Unit. Its function is to support the remapping of DMA of peripheral devices, that is, to convert the address accessed by peripheral devices into actual physical addresses through IOMMU devices, which actually converts the address of peripheral device DMA into a virtual address. This architecture enables peripheral devices to access the physical address of virtual machines through DMA while ensuring safety. PCI device transparent transmission uses the IOMMU function of the CPU and the capabilities of hardware devices to enable virtual machines to directly access peripheral devices, reducing the loss at the virtualization level and enabling virtual machines to access peripheral devices at a speed close to their highest speed. PCI device transparent transmission can also support online addition and removal of devices, giving virtual machines greater flexibility.

[0004] Currently, nova supports the transparent transmission of PCI devices by virtual machines, but nova does not support online mounting and unmounting of PCI devices on the host. There are several main problems:

[0005] ①. PCI device mounting can only be configured through the type template of the virtual machine when creating the virtual machine. Dynamic addition and deletion during operation is not supported.

[0006] ②. The number of mounted PCI devices is configured through the type template. The type and number of devices are fixed in the type template. When there are multiple types of devices in the system, there is a probability that the number of virtual machine type templates will expand.

[0007] There are problems such as transparent PCI devices cannot be added when the virtual machine is running, and transparent PCI devices cannot be uninstalled when running, which causes some inconvenience to users. Summary of the invention

[0008] The technical task of the present invention is to provide a method and system for flexibly transparently transmitting PCI devices for virtual machines based on the OpenStack platform, so as to solve the problem that transparently transmitted PCI devices cannot be added when the virtual machine is running, transparently transmitted PCI devices cannot be uninstalled at run time, and the number of virtual machine type templates may be expanded.

[0009] The technical task of the present invention is achieved in the following manner: a method for flexibly transparently transmitting PCI devices for virtual machines based on the OpenStack platform, the method is as follows:

[0010] By modifying the API, that is, adding two new API entries, dynamic mounting and dynamic unmounting of PCI devices are realized;

[0011] By adding a new API, the type of PCI device can be configured.

[0012] When calling the API interface, the user specifies the type of mounted device.

[0013] Preferably, the type of mounted device refers to a new data structure that defines a unique product identifier for the device, including a vendor ID and a product ID. When specifying the mounted device type, the alias of the device is defined. The alias is a user-visible device identifier. The alias should be unique, and the same device should have the same device identifier alias for different availability zones.

[0014] Preferably, the dynamic mounting of PCI devices is as follows:

[0015] When the server receives a user request, it verifies the legitimacy of the input parameters;

[0016] After the remote call is successful, the API side updates the task status of the virtual machine to mount the PCI device, and the API returns 204 to the client, indicating that the mount request has been received and the backend is processing it through the Conductor service component, Scheduler service component, and Compute service component.

[0017] Preferably, when the server receives a user request, it verifies the legitimacy of the input parameters as follows:

[0018] Verify device type: and determine whether verification is successful:

[0019] If the test fails, an exception code is returned to inform the client that the input parameter is invalid;

[0020] If the verification is successful, the mount request needs to be sent to the Conductor service component for further processing. The message sent to the Conductor service component via remote call includes the unique identifier of the virtual machine and the device type of the mounted device.

[0021] The contents of the verification device type include the following:

[0022] ①. Verify whether the current virtual machine ID exists and whether its status is normal;

[0023] ②. Verify whether the device ID passed in has been defined and exists.

[0024] Preferably, the Conductor service components are as follows:

[0025] After receiving the remote call, the Conductor service component parses the unique identifier of the backend product ID and supplier ID corresponding to the current given device type to confirm that the device type is legal;

[0026] Organize the virtual machine objects through the unique identifier of the virtual machine and locate the computing node where the virtual machine is currently located;

[0027] The product ID, supplier ID and computing node information are organized into a new virtual machine resource request object structure, and the current computing node is designated as the preferred node. The resource request is sent to the Scheduler service component in the form of a synchronous remote method call in the structure.

[0028] Preferably, the Scheduler service components are as follows:

[0029] After receiving a remote method call request, the Scheduler service component makes the following judgments:

[0030] Determine whether the node with the current priority principle can satisfy the resources, that is, whether the current node has a PCI device with a product ID and a shared ID:

[0031] If it exists, return the preferred node;

[0032] If it does not exist, determine whether the selected node can meet the requirements:

[0033] If the preferred node cannot meet the requirements, it is necessary to find the available computing node list in the current available computing node list and output the computing node candidate list. The nodes in the candidate list all meet the following requirements: sufficient CPU, memory and other available resources; the selected node in the candidate list is returned to the Conductor service component as the caller as the result of the synchronous remote call;

[0034] Determine whether the Scheduler service component can select a node that can be used:

[0035] If the Scheduler service component fails to select a usable node, it returns an empty list to the Conductor service component to inform it that no node that meets the conditions is available;

[0036] When the Conductor service receives the return result from the Scheduler service component, it should determine whether the return list is not empty:

[0037] If the returned list is empty, it indicates that no computing node is available. In this case, the task status of the virtual machine needs to be updated to failure, and a notification event needs to be sent to the message queue. The notification event contains the virtual machine ID, device type name, and failure reason information to facilitate the subsequent problem location.

[0038] If the returned candidate node list is not empty, determine whether the node where the virtual machine is currently located is in the returned list:

[0039] If it is indeed in this returned list, a request body including the virtual machine unique identifier, product ID and vendor ID is constructed and sent to the Compute service component;

[0040] If the current node is not in the candidate node list, it means that the current node cannot meet the resource requirements and the virtual machine needs to be scheduled to other nodes with sufficient resources through online migration to meet the requirements of further operations;

[0041] During the online migration process, the current online migration code of Nova is directly reused for processing. After executing the hot migration command, it is necessary to wait for the online migration to succeed before performing subsequent operations to determine whether the online migration is successful:

[0042] If the online migration fails, the current candidate list is traversed, and the next node is taken out to perform the migration operation. After all candidate lists are exhausted, the current mounted task status is set to failure, and a notification is issued, which is marked with the unique identifier of the virtual machine, the product ID and the vendor ID fields, and indicates that the reason for the failure is that the node cannot be migrated;

[0043] If the online migration is successful, it means that the node where the virtual machine is currently located meets the resource requirements required by the device type. The above-mentioned information is assembled into a structure and sent to the Compute service component in the form of an asynchronous call.

[0044] Preferably, the Compute service component works as follows:

[0045] After receiving the asynchronous remote call request, the Compute service component sends a notification to the message queue, indicating that the device mounting operation has started;

[0046] The Compute service component queries an available device from the PCI device table, modifies the unique identifier of the virtual machine of the available device to be consistent with the current request, and updates the PCI device table, which is stored in the database;

[0047] After the database is updated successfully, the PCI address of the available device is obtained, and the PCI address is mounted as a pass-through device to the virtual machine by calling the interface of the underlying virtualization platform. Note that for the mount to be successful, the IOMMU configuration on the computing node must be enabled, and IOMMU support must be provided only for pass-through devices.

[0048] After the device is mounted successfully, the task status is set to success, indicating that the virtual machine has successfully mounted the PCI device;

[0049] Send an event to the message queue to notify the event subscriber that the virtual machine has successfully mounted the PCI device. The event contains the unique identifier of the virtual machine, the physical address of the PCI device, the product ID of the device, and the vendor ID of the device.

[0050] When the customer queries the status of the virtual machine, he / she sees that the task of the virtual machine has been completed and the PCI device has been mounted, and then he / she can log in to the virtual machine to confirm the device.

[0051] As a preferred embodiment, the dynamic unloading of the PCI device is as follows:

[0052] Add a new API whose input parameters are the unique identifier of the virtual machine, the device type and the PCI address in the virtual machine. The unique identifier of the virtual machine, the device type and the PCI address in the virtual machine can be used to uniquely identify a PCI device that needs to be uninstalled.

[0053] On the API side, you need to verify whether the virtual machine identifier is legal, whether the virtual machine exists, and whether the PCI address is legal:

[0054] If the verification fails, an illegal request status code is returned to the client;

[0055] If the verification is normal, the request is passed to the Compute service component in the form of a synchronous remote method call;

[0056] After receiving the request, the Compute service component locates the PCI address of the transparently transmitted device on the corresponding computing node through the PCI address of the device passed in.

[0057] Get the vendor ID and product ID of the device stored in the device space of the device with the PCI address, and check whether the device type is consistent with the passed device type:

[0058] If the types are inconsistent, the task status is updated to failure, and a message is sent to notify the subscribed user;

[0059] If the types are consistent, the uninstall operation is performed;

[0060] During the uninstallation process, a request needs to be constructed based on the unique identifier of the virtual machine and the address that complies with the PCI, and sent to the underlying virtual machine software to perform the device uninstallation operation;

[0061] After the uninstallation is successful, the data table of the PCI device is updated, the current device is set to an available state, and the record of the unique identifier of the associated virtual machine is cleared;

[0062] Set the task status to successful and send a task success message to subscribed users.

[0063] A system for flexibly transparently transmitting PCI devices for virtual machines based on an OpenStack platform, the system comprising:

[0064] The mount module is used to realize the dynamic mount of PCI devices by modifying the API, that is, adding a new API entry; the mount module includes:

[0065] The verification submodule is used to verify the legitimacy of the input parameters after the server receives the user request;

[0066] The processing submodule is used to update the task status of the virtual machine to mount the PCI device on the API side after the remote call is successful. The API returns 204 to the client, indicating that the mount request has been received and the backend is processing it through the Conductor service component, Scheduler service component, and Compute service component.

[0067] Uninstall module, used to implement dynamic unloading of PCI devices by adding a new API;

[0068] Configuration module, used to configure the type of PCI device;

[0069] The specified module is used for users to specify the type of mounted device when calling the API interface.

[0070] A computer-readable storage medium, characterized in that the computer-readable storage medium stores computer-executable instructions, and when a processor executes the computer-executable instructions, the method of flexibly transparently transmitting PCI devices for virtual machines based on the OpenStack platform as described above is implemented.

[0071] The method and system for flexibly transparently transmitting PCI devices for virtual machines based on the OpenStack platform of the present invention have the following advantages:

[0072] (1) The present invention is easy to modify and reuses the current mature code architecture, which has the advantages of low intrusion and high code reuse rate, and is convenient for development and debugging;

[0073] (ii) The present invention adds an API to define the type of device, which reduces the dependence on the configuration file. The configuration of the device type and other features no longer needs to be performed by modifying the configuration file. On the one hand, it reduces the maintenance difficulties caused by modifying the configuration file. On the other hand, it also provides a simple method to dynamically modify the configuration items by saving the database, which reduces the difficulty of operation and maintenance.

[0074] (III) The present invention adds an API for mounting and unmounting PCI devices, so that users can dynamically add and unmount PCI direct devices during operation or shutdown, thereby improving the flexibility of interface use and reducing service downtime;

[0075] (IV) The present invention manages PCI devices by mounting and unmounting, which reduces the dependence on virtual machine flavors, avoids the problem of defining too many custom flavors in the environment, and facilitates the management of OpenStack clusters. BRIEF DESCRIPTION OF THE DRAWINGS

[0076] The present invention is further described below in conjunction with the accompanying drawings.

[0077] Attached Figure 1 A flowchart for checking the legitimacy of input;

[0078] Attached Figure 2 This is a flowchart of the process being processed by the backend through the Conductor service component, Scheduler service component, and Compute service component. DETAILED DESCRIPTION

[0079] The method and system for flexibly transparently transmitting PCI devices for virtual machines based on the OpenStack platform of the present invention are described in detail below with reference to the accompanying drawings and specific embodiments of the specification.

[0080] Embodiment 1:

[0081] The method of the present invention for flexibly transparently transmitting PCI devices for virtual machines based on the OpenStack platform is as follows:

[0082] S1. By modifying the API, that is, adding two new API entries, dynamic mounting and dynamic unmounting of PCI devices are realized;

[0083] S2. Implement the configuration of PCI device type by adding a new API.

[0084] S3. When calling the API interface, the user specifies the type of mounted device.

[0085] The type of mounted device in this embodiment refers to a new data structure, which defines the unique product identification of the device, including the vendor ID and the product ID. When specifying the mounted device type, the alias of the device is defined. The alias is a user-visible device identification. The alias should be unique, and the same device should have the same device identification alias for different availability zones.

[0086] In this embodiment, the dynamic mounting of the PCI device in step S1 is specifically as follows:

[0087] S101, when the server receives the user request, it verifies the legitimacy of the input parameter;

[0088] S102, after the remote call is successful, the API side updates the task status of the virtual machine to mount the PCI device, and the API returns 204 to the client, indicating that the mount request has been received and the backend is processing it through the Conductor service component, the Scheduler service component, and the Compute service component.

[0089] As attached Figure 1 As shown, in step S101 of this embodiment, when the server receives the user request, the legitimacy of the input parameter is checked as follows:

[0090] S10101. Verify device type: and determine whether verification is successful:

[0091] ①. If the test fails, execute step S10102;

[0092] ② If the verification is successful, execute step S10103;

[0093] S10102: Return an exception code to notify the client that the input parameter is illegal;

[0094] S10103. The mount request needs to be sent to the Conductor service component for further processing. The message sent to the Conductor service component via a remote call includes the unique identifier of the virtual machine and the device type of the mounted device.

[0095] In this embodiment, the content of the verification device type in step S10101 includes the following:

[0096] ①. Verify whether the current virtual machine ID exists and whether its status is normal;

[0097] ②. Verify whether the device ID passed in has been defined and exists.

[0098] As attached Figure 2 As shown, the backend in step S102 of this embodiment is being processed by the Conductor service component, the Scheduler service component, and the Compute service component as follows:

[0099] S10201. After receiving the remote call, the Conductor service component parses the unique identifier of the backend product ID and supplier ID corresponding to the currently given device type to confirm that the device type is legal;

[0100] S10202. Organize the virtual machine object by using the unique identifier of the virtual machine, and locate the computing node where the virtual machine is currently located;

[0101] S10203, organize the product ID, supplier ID and computing node information into a structure of a new virtual machine resource request object, designate the current computing node as a preferred node, and send the resource request in the structure to the Scheduler service component in the form of a synchronous remote method call;

[0102] S10204. After receiving the remote method call request, the Scheduler service component performs the following judgment:

[0103] (1) Determine whether the node with the current priority principle can satisfy the resources, that is, whether the current node has a PCI device with a product ID and a shared ID:

[0104] ①, if it exists, return the preferred node;

[0105] ② If it does not exist, go to step (2);

[0106] (2) Determine whether the selected node can meet the requirements:

[0107] ①. If the preferred node cannot meet the requirements, it is necessary to find the available computing node list in the current available computing node list and output the computing node candidate list. The nodes in the candidate list all meet the following requirements: sufficient CPU, memory and other available resources; the selected nodes in the candidate list are returned to the Conductor service component as the caller as the result of the synchronous remote call;

[0108] (3) Determine whether the Scheduler service component can select a node that can be used:

[0109] ① If the Scheduler service component fails to select a usable node, it returns an empty list to the Conductor service component to inform it that no node that meets the conditions is available;

[0110] (4) When the Conductor service receives the return result from the Scheduler service component, it should determine whether the return list is not empty:

[0111] ①. If the returned list is empty, it indicates that no computing node is available. In this case, the task status of the virtual machine needs to be updated to failure, and a notification event needs to be sent to the message queue. The notification event also includes the virtual machine ID, device type name, and failure reason information to facilitate the subsequent problem location.

[0112] ② If the returned candidate node list is not empty, execute step (5);

[0113] (5) Determine whether the node where the virtual machine is currently located is in the returned list:

[0114] ① If it is indeed in this returned list, a request body is constructed containing the unique identifier of the virtual machine, the product ID, and the vendor ID, and sent to the Compute service component;

[0115] ② If the current node is not in the candidate node list, it means that the current node cannot meet the resource requirements. It is necessary to schedule the virtual machine to other nodes with sufficient resources through online migration to meet the requirements of further operations;

[0116] (6) During the online migration process, the current online migration code of Nova is directly reused for processing. After executing the hot migration command, it is necessary to wait for the online migration to succeed before performing subsequent operations to determine whether the online migration is successful:

[0117] ① If the online migration fails, the current candidate list is traversed, and the next node is taken out to perform the migration operation. After all the candidate lists are exhausted, the current mounted task status is set to failure, and a notification is issued, which is marked with the unique identifier of the virtual machine, the product ID and the vendor ID field, and indicates that the reason for the failure is that the node cannot be migrated;

[0118] ② If the online migration is successful, it means that the node where the virtual machine is currently located meets the resource requirements required by the device type. The above-mentioned information is assembled into a structure and sent to the Compute service component in the form of an asynchronous call.

[0119] S10205. After receiving the asynchronous remote call request, the Compute service component sends a notification to the message queue, indicating that the device mounting operation has started.

[0120] S10206. The Compute service component searches for an available device from the PCI device table, modifies the unique identifier of the virtual machine of the available device to be consistent with the current request, and updates the PCI device table, which is stored in the database.

[0121] S10207. After the database is successfully updated, the PCI address of the available device is obtained, and the PCI address is mounted as a pass-through device to the virtual machine by calling the interface of the underlying virtualization platform. Note that for the mount to be successful, the IOMMU configuration on the computing node needs to be enabled, and IOMMU support is selected only for the pass-through device.

[0122] S10208. After the device is mounted successfully, the task status is set to success, indicating that the virtual machine has successfully mounted the PCI device; an event is sent to the message queue to notify the event subscriber that the virtual machine has successfully mounted the PCI device, and the event includes the unique identifier of the virtual machine, the physical address of the PCI device, the product ID of the device, and the vendor ID of the device;

[0123] S10209. When the customer inquires about the status of the virtual machine, he sees that the task of the virtual machine has been completed and the PCI device has been mounted, and then he can log in to the virtual machine to confirm the device.

[0124] In this embodiment, the dynamic unloading of the PCI device in step S1 is specifically as follows:

[0125] (i) Add a new API whose input parameters are the unique identifier of the virtual machine, the device type and the PCI address in the virtual machine; a PCI device to be uninstalled can be uniquely identified by the unique identifier of the virtual machine, the device type and the PCI address in the virtual machine;

[0126] (II) On the API side, it is necessary to verify whether the virtual machine identifier is legal, whether the virtual machine exists, and whether the PCI address is legal:

[0127] ①. If the verification fails, an illegal request status code is returned to the client;

[0128] ②. If the verification is normal, proceed to step (iii);

[0129] (3) passing the request to the Compute service component in the form of a synchronous remote method call;

[0130] (iv) After receiving the request, the Compute service component locates the PCI address of the transparently transmitted device on its corresponding computing node through the PCI address of the device passed in;

[0131] (V) Get the vendor ID and product ID of the device stored in the device space of the device with the PCI address, and check whether the device type is consistent with the passed device type:

[0132] ①. If the types are inconsistent, the status of the update task will be failed, and a message will be sent to notify the subscribed user;

[0133] ② If the types are the same, go to step (six);

[0134] (VI) Performing the uninstallation operation: constructing a request according to the unique identifier of the virtual machine that conforms to the PCI address, and sending it to the underlying virtual machine software to perform the device uninstallation operation;

[0135] (VII) After the uninstallation is successful, the data table of the PCI device is updated, the current device is set to an available state, and the record of the unique identifier of the associated virtual machine is cleared;

[0136] (8) Set the task status to successful and send a task success message to subscribed users.

[0137] Embodiment 2:

[0138] The system of the present invention is based on the OpenStack platform to flexibly transparently transmit PCI devices for virtual machines, and the system includes:

[0139] The mount module is used to realize the dynamic mount of PCI devices by modifying the API, that is, adding a new API entry; the mount module includes:

[0140] The verification submodule is used to verify the legitimacy of the input parameters after the server receives the user request;

[0141] The processing submodule is used to update the task status of the virtual machine to mount the PCI device on the API side after the remote call is successful. The API returns 204 to the client, indicating that the mount request has been received and the backend is processing it through the Conductor service component, Scheduler service component, and Compute service component.

[0142] Uninstall module, used to implement dynamic unloading of PCI devices by adding a new API;

[0143] Configuration module, used to configure the type of PCI device;

[0144] The specified module is used for users to specify the type of mounted device when calling the API interface.

[0145] Embodiment 3:

[0146] The embodiment of the present invention further provides a computer-readable storage medium, in which a plurality of instructions are stored, and the instructions are loaded by a processor, so that the processor executes the method of flexibly transparently transmitting PCI devices for virtual machines based on the OpenStack platform in any embodiment of the present invention. Specifically, a system or device equipped with a storage medium can be provided, on which a software program code that implements the functions of any of the above embodiments is stored, and a computer (or CPU or MPU) of the system or device reads and executes the program code stored in the storage medium.

[0147] In this case, the program code itself read from the storage medium can realize the function of any one of the above-mentioned embodiments, and thus the program code and the storage medium storing the program code constitute a part of the present invention.

[0148] The storage medium embodiments for providing the program code include a floppy disk, a hard disk, a magneto-optical disk, an optical disk (such as CD-ROM, CD-R, CD-RW, DVD-ROM, DVD-RAM, DVD-RW, DVD+RW), a magnetic tape, a non-volatile memory card, and a ROM. Alternatively, the program code can be downloaded from a server computer by a communication network.

[0149] In addition, it should be clear that the functions of any of the above embodiments can be implemented not only by executing the program code read by the computer, but also by enabling an operating system operating on the computer to complete part or all of the actual operations based on instructions from the program code.

[0150] In addition, it can be understood that the program code read from the storage medium is written to a memory provided in an expansion board inserted into the computer or written to a memory provided in an expansion unit connected to the computer, and then based on the instructions of the program code, a CPU installed on the expansion board or the expansion unit is enabled to perform part or all of the actual operations, thereby realizing the functions of any of the above-mentioned embodiments.

[0151] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or replace some or all of the technical features therein with equivalents. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for flexibly transparently transmitting PCI devices for virtual machines based on the OpenStack platform, characterized in that: The method is as follows: By modifying the API, that is, adding two new API entries, dynamic mounting and dynamic unmounting of PCI devices are realized; By adding a new API, the type of PCI device can be configured. When calling the API interface, the user specifies the type of mounted device; The dynamic mounting of PCI devices is as follows: When the server receives a user request, it verifies the legitimacy of the input parameters; the details are as follows: Verify device type: and determine whether verification is successful: If the test fails, an exception code is returned to inform the client that the input parameter is invalid; If the verification is successful, the mount request needs to be sent to the Conductor service component for further processing. The message sent to the Conductor service component via remote call includes the unique identifier of the virtual machine and the device type of the mounted device. The contents of the verification device type include the following: ①. Verify whether the current virtual machine ID exists and whether its status is normal; ②. Verify whether the device ID passed in has been defined and exists; After the remote call succeeds, the API side updates the task status of the virtual machine to mount the PCI device, and the API returns 204 to the client, indicating that the mount request has been received and the backend is processing it through the Conductor service component, Scheduler service component, and Compute service component; The Conductor service components are as follows: After receiving the remote call, the Conductor service component parses the unique identifier of the backend product ID and supplier ID corresponding to the current given device type to confirm that the device type is legal; Organize the virtual machine objects through the unique identifier of the virtual machine and locate the computing node where the virtual machine is currently located; Organize the product ID, supplier ID and computing node information into a new virtual machine resource request object structure, specify the current computing node as the preferred node, and send the resource request to the Scheduler service component in the form of a synchronous remote method call in the structure; The Scheduler service components are as follows: After receiving a remote method call request, the Scheduler service component makes the following judgments: Determine whether the currently provided preferred node can satisfy the resources, that is, whether the current node has a PCI device with a product ID and a vendor ID: If it exists, return the preferred node; If it does not exist, determine whether the preferred node can meet the requirements: If the preferred node cannot meet the requirements, it is necessary to find the available computing node list in the current available computing node list and output the computing node candidate list. The nodes in the candidate list all meet the following requirements: sufficient CPU, memory and other available resources; the nodes in the selected candidate list are returned to the Conductor service component as the caller as the result of the synchronous remote call; Determine whether the Scheduler service component can select a usable node: If the Scheduler service component fails to select a usable node, it returns an empty list to the Conductor service component to inform it that no node that meets the conditions is available; When the Conductor service component receives the return result from the Scheduler service component, it should determine whether the return list is not empty: If the returned list is empty, it indicates that no computing node is available. In this case, the task status of the virtual machine needs to be updated to failure, and a notification event is sent to the message queue; the notification event contains the virtual machine ID, device type name, and failure reason information; If the returned candidate node list is not empty, determine whether the node where the virtual machine is currently located is in the returned list: If it is indeed in this returned list, a request body including the virtual machine unique identifier, product ID and vendor ID is constructed and sent to the Compute service component; If the current node is not in the candidate node list, it means that the current node cannot meet the resource requirements and the virtual machine needs to be scheduled to other nodes with sufficient resources through online migration to meet the requirements of further operations; During the online migration process, the current online migration code of Nova is directly reused for processing. After executing the hot migration command, it is necessary to wait for the online migration to succeed before performing subsequent operations to determine whether the online migration is successful: If the online migration fails, the current candidate list is traversed, and the next node is taken out to perform the migration operation. After all candidate lists are exhausted, the current mounted task status is set to failure, and a notification is issued, indicating the unique identifier of the virtual machine, the product ID and the vendor ID fields, and indicating that the reason for the failure is that the node cannot be migrated; If the online migration is successful, it means that the node where the virtual machine is currently located meets the resource requirements required by the device type. The above information is assembled into a structure and sent to the Compute service component in the form of an asynchronous call; The working process of the Compute service component is as follows: After receiving the asynchronous remote call request, the Compute service component will send a notification to the message queue, indicating that the device mounting operation has started; The Compute service component queries an available device from the PCI device table, modifies the unique identifier of the virtual machine of the available device to be consistent with the current request, and updates the PCI device table, which is stored in the database; After the database is updated successfully, the PCI address of the available device is obtained, and the PCI address is mounted as a pass-through device to the virtual machine by calling the interface of the underlying virtualization platform. Note that for the mount to be successful, the IOMMU configuration on the computing node must be enabled, and IOMMU support must be provided only for pass-through devices. After the device is mounted successfully, the task status is set to success, indicating that the virtual machine has successfully mounted the PCI device; Send an event to the message queue to notify the event subscriber that the virtual machine has successfully mounted the PCI device. The event contains the unique identifier of the virtual machine, the physical address of the PCI device, the product ID of the device, and the vendor ID of the device. When the customer inquires about the status of the virtual machine, he / she will see that the task of the virtual machine has been completed and the PCI device has been mounted. Then he / she can log in to the virtual machine to confirm the device. The dynamic unloading of PCI devices is as follows: Add a new API whose input parameters are the unique identifier of the virtual machine, the device type and the PCI address in the virtual machine. The unique identifier of the virtual machine, the device type and the PCI address in the virtual machine can be used to uniquely identify a PCI device that needs to be uninstalled. On the API side, you need to verify whether the virtual machine identifier is legal, whether the virtual machine exists, and whether the PCI address is legal: If the verification fails, an illegal request status code is returned to the client; If the verification is normal, the request is passed to the Compute service component in the form of a synchronous remote method call; After receiving the request, the Compute service component locates the PCI address of the transparently transmitted device on the corresponding computing node through the PCI address of the device passed in. Get the vendor ID and product ID of the device stored in the device space of the device with the PCI address, and check whether the device type is consistent with the passed device type: If the types are inconsistent, the task status is updated to failure, and a message is sent to notify the subscribed user; If the types are consistent, the uninstall operation is performed; During the uninstallation process, a request needs to be constructed based on the unique identifier of the virtual machine and the address that complies with the PCI, and sent to the underlying virtual machine software to perform the device uninstallation operation; After the uninstallation is successful, the data table of the PCI device is updated, the current device is set to an available state, and the record of the unique identifier of the associated virtual machine is cleared; Set the task status to successful and send a task success message to subscribed users.

2. The method for flexibly transparently transmitting PCI devices for virtual machines based on the OpenStack platform according to claim 1, characterized in that: The type of mounted device refers to a new data structure that defines the unique product identifier of the device, including the vendor ID and product ID. When specifying the mounted device type, the alias of the device is defined. The alias is a user-visible device identifier. The alias should be unique, and the same device should have the same device identifier alias for different availability zones.

3. A system for flexibly transparently transmitting PCI devices for virtual machines based on the OpenStack platform, characterized in that: The system is used to implement the method for flexibly transparently transmitting PCI devices for virtual machines based on the OpenStack platform as described in claim 1 or 2; the system includes: The mounting module is used to realize the dynamic mounting of PCI devices by modifying the API, that is, adding a new API entry; The mount modules include: The verification submodule is used to verify the legitimacy of the input parameters after the server receives the user request; The processing submodule is used to update the task status of the virtual machine to mount the PCI device on the API side after the remote call is successful. The API returns 204 to the client, indicating that the mount request has been received and the backend is processing it through the Conductor service component, Scheduler service component, and Compute service component. Uninstall module, used to implement dynamic unloading of PCI devices by adding a new API; Configuration module, used to configure the type of PCI device; The specified module is used for users to specify the type of mounted device when calling the API interface.

4. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer-executable instructions. When the processor executes the computer-executable instructions, the method for flexibly transparently transmitting PCI devices for virtual machines based on the OpenStack platform as claimed in claim 1 or 2 is implemented.

Images