A method and system for dynamic hot-plugging of host devices in a dual-stack virtualization environment

Abstract

This invention belongs to the field of cloud computing and virtualization technology, proposing a dynamic hot-plugging method and system for host devices in a dual-stack virtualization environment. Addressing the problems of difficulty in accurately specifying host devices, the inability to dynamically mount / unmount during runtime, and the lack of comprehensive control and consistency guarantees in existing dual-stack architectures, this invention deploys host device management plugins on each node to collect and maintain a transparent pool of host device resources. By defining a custom resource `HotPlugHostDevice` for hot-pluggable host devices, and carrying the target virtual machine identifier, target node identifier, and unique device identifier in the resource to initiate hot-add or hot-remove requests, the plugin locks the target device and temporarily registers it as an extended resource of the target node to establish a binding relationship. The control plane component updates the virtual machine instance object, writing device configuration in the spec and request and process status in the status. This solution achieves precise device-level scheduling, end-to-end automation, and traceable and recoverable hot-plugging.

Description

Technical Field

[0001] This invention belongs to the field of cloud computing and virtualization technology, and in particular relates to a method and system for dynamic hot-plugging of host devices in a dual-stack virtualization environment. Background Technology

[0002] With the development of cloud-native technologies, container orchestration platforms are gradually becoming the infrastructure for uniformly hosting various types of workloads. To maintain compatibility with traditional applications and achieve stronger isolation capabilities, the industry has introduced virtualization capabilities on top of Kubernetes (such as running QEMU-KVM virtual machines within Pod containers through components like KubeVirt), forming a dual-stack virtualization architecture that unifies the orchestration and management of containers and virtual machines. This architecture combines the agile scheduling advantages of containers with the isolation and compatibility advantages of virtual machines, and is gradually becoming an important direction for the evolution of cloud computing platforms.

[0003] In virtualization scenarios, to improve virtual machine I / O performance, it is often necessary to directly pass high-performance hardware devices from the host machine to the virtual machine for use, such as PCIe devices, GPUs, and dedicated accelerator cards. These devices can generate virtual functions based on SR-IOV or exist as physical functions, and secure pass-through is achieved through the VFIO and IOMMU isolation mechanism.

[0004] However, in a dual-stack virtualization environment, existing technologies have at least the following shortcomings:

[0005] Existing device selection mechanisms often use coarse-grained matching methods such as node tags, which makes it difficult to accurately locate a specific physical device on a certain node and cannot meet the needs of businesses with strict constraints on device ID / address.

[0006] Host devices often need to be statically requested by Pods during the creation / startup phase through resource declarations. The lifecycle of the device is strongly associated with the Pod, making it difficult to dynamically mount and unmount general-purpose host devices during virtual machine operation, which limits resource utilization and business elasticity.

[0007] In a dual-stack architecture, hot-plugging of devices requires the coordinated completion of three layers of links: node-side device preparation and isolation, container-side device injection, and virtual machine-side hot-plugging interface calls. It lacks a unified control logic and consistency guarantee mechanism that runs through the entire link, making the operation cumbersome and prone to errors. Summary of the Invention

[0008] In view of this, the present invention aims to provide a method and system for dynamic hot-plugging of host devices in a dual-stack virtualization environment, so as to at least solve one of the problems in the background art.

[0009] To achieve the above objectives, the technical solution of the present invention is implemented as follows:

[0010] Firstly, this solution discloses a method for dynamic hot-plugging of host devices in a dual-stack virtualization environment. The dual-stack virtualization environment includes a container orchestration cluster, Pods hosting virtual machines, and a management component for managing virtual machines. The management component includes a control plane component and a node-side component, comprising:

[0011] Run the host device management plugin on each node to collect and maintain the resource pool of transparent host devices;

[0012] Define and create a custom resource HotPlugHostDevice for a hot-plugg host device, which includes the target virtual machine identifier, the target node identifier, and the device's unique identifier, to request hot-add or hot-remove the device on a running virtual machine.

[0013] The host device management plugin responds to the HotPlugHostDevice by locking the target device from the resource pool and temporarily registering it as an extended resource of the target node, thus establishing a binding relationship between the target device and the target virtual machine.

[0014] The control plane component updates the virtual machine instance object corresponding to the target virtual machine according to the HotPlugHostDevice, writes the configuration of the device to be hot-plugged into its specifications, and writes the hot-plug request and process status into its status.

[0015] The node-side component performs device injection within the Pod based on the virtual machine instance object, and triggers the virtual machine running component within the Pod to perform hot-add or hot-remove of devices on the running virtual machine through the virtualization management interface;

[0016] The process status is updated upon completion or failure, wherein upon successful hot removal, the device access permissions of the Pod are revoked, the device node within the Pod is deleted, and the extended resources and the binding relationship are released.

[0017] Furthermore, at least one or more of the following are included: device ID, device type, PCI address, bus address, and unique identifier, and the device information is managed uniformly through custom resources.

[0018] Furthermore, the specification fields of the HotPlugHostDevice also include: hostname and / or host IP.

[0019] Furthermore, the device unique identifier is identification information corresponding to the host device type; when the host device type is a USB device, the device unique identifier includes the USB bus address; when the host device type is a PCIe device or a GPU device, the device unique identifier includes the PCI BDF address.

[0020] Furthermore, when the target device is temporarily registered as the extended resource, the resource name of the extended resource is determined by the host device type and the device unique identifier.

[0021] Furthermore, the binding relationship includes recording the correspondence between the target device and the target node and the target virtual machine, as well as the device allocation status, and storing the device allocation status in an external database and / or cluster storage.

[0022] Furthermore, the HotPlugHostDevice is created by a command-line tool that is used to request the creation of hot-add or hot-remove operations.

[0023] Furthermore, the dual-stack virtualization environment is an environment that runs QEMU-KVM virtual machines in Pod containers on Kubernetes through a virtualization management plugin; the control plane component includes virt-api, the node-side component includes virt-handler, the virtual machine runtime component includes virt-launcher, and the virtualization management interface includes the libvirt interface.

[0024] Furthermore, the virtual machine instance object includes: a status.hostDeviceRequests field for representing hot-plug requests, a spec.hostDevices field for describing the target host device configuration, and a status.hostDeviceStatus field for representing the hot-plug process and results.

[0025] Furthermore, when the node-side component completes device injection within the Pod, granting the Pod permission to access the target host device includes: setting device access control permissions for the Pod in cgroupfs to allow the Pod to access the device file corresponding to the target host device.

[0026] Furthermore, when the node-side component completes device injection within the Pod, the creation of the device node includes: entering the file system namespace of the Pod via chroot, and creating a character device node or block device node corresponding to the target host device within the Pod via mknod.

[0027] Furthermore, the virtual machine runtime component writing the target host device into the virtualization configuration includes: updating the target host device information to the XML configuration of the libvirt domain; the device hot-add or hot-remove operation includes calling the libvirt attach interface or detach interface to perform device hot-plugging on the running QEMU-KVM process.

[0028] Furthermore, the virtual machine runtime component identifies the hot-mounting or hot-unmounting behavior of the target host device by comparing the device data cached in the virtual machine domain with the host device configuration data in the virtual machine instance object, and triggers the corresponding attach or detach operation accordingly.

[0029] Furthermore, the process state includes at least one or more of the following states: Pending, AllocatingToVMI, AttachingToPod, LibvirtAdding, Ready, LibvirtRemoving, DetachingFromPod, ReleasingFromVMI, and Failed.

[0030] Secondly, this solution discloses a dynamic hot-swappable system for host devices in a dual-stack virtualization environment, wherein the dual-stack virtualization environment includes a container orchestration cluster and virtual machine instances running within Pod containers, characterized in that the system includes:

[0031] The host device management plugin is used to collect device information of host devices that can be used for transparent transmission on the node, build a host device resource pool, listen for HotPlugHostDevice resource events, and temporarily register the target host device as an extended resource into the resource capacity of the target node, while recording the device allocation status and binding relationship.

[0032] The control plane request processing module is used to update the virtual machine instance object corresponding to the target virtual machine according to the HotPlugHostDevice resource, so as to write the hot-plug request list and host device configuration, and drive the process state flow.

[0033] The node-side injection module is used to grant the Pod hosting the target virtual machine access permissions to the target host device after detecting a hot-plug request, create a device node within the Pod, and call the virtual machine runtime components within the Pod to complete the virtualization configuration update.

[0034] The Pod hot-plug execution module is used to hot-add or hot-remove execution devices on running virtual machines through the virtualization management interface based on changes in the host device configuration of the virtual machine instance object.

[0035] The status management module is used to maintain the hot-plug process status, completion status, and failure information in the status fields of virtual machine instance objects.

[0036] Furthermore, the host device management plugin includes: a device information acquisition unit, an extended resource registration unit, and a device allocation information storage unit; wherein the device allocation information storage unit is used to write the binding relationship between devices and nodes and virtual machines into an external database and / or cluster storage.

[0037] Furthermore, the node-side injection module includes a cgroup permission configuration unit and a device node creation unit; wherein the device node creation unit is used to create device nodes within the Pod using chroot and mknod.

[0038] Furthermore, the Pod-in-Hot-plug execution module includes: a domain XML update unit and a hot-plug interface call unit; wherein the hot-plug interface call unit is used to call libvirt's attach or detach interface to achieve hot-adding or hot-removing of devices.

[0039] Thirdly, this solution discloses an electronic device, including a processor and a memory, wherein the memory stores a computer program, and the computer program causes the electronic device to perform the method when the processor executes it.

[0040] Fourthly, this solution discloses a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method described in any of the above-mentioned embodiments.

[0041] Compared with existing technologies, the dynamic hot-plugging method and system for host devices in a dual-stack virtualization environment described in this invention have the following advantages:

[0042] (1) This invention designs a custom resource HotPlugHostDevice for hot-plugg host devices and carries the target node identifier, device type and device unique identifier / address information in the resource declaration, thereby achieving scheduling and binding from type-level fuzzy matching to device-level precise specification;

[0043] (2) The present invention temporarily registers the target device as an extended resource of the target node through the host device management plugin, and in conjunction with the device configuration field and hot-plug request field in the virtual machine instance object, the virtual machine can add / remove host devices on demand without shutting down, thereby improving resource reuse efficiency and business continuity.

[0044] (3) The node-side component of the present invention completes cgroup permission configuration and device node creation in Pod, the virtual machine running component in Pod completes libvirt domain XML update and attach / detach call, and the control plane component uniformly drives object update and process advancement, realizing full-link automated hot-plugging;

[0045] (4) The present invention maintains the hot-plug process status and failure information in the virtual machine instance object status field, and describes the stages such as Pending, AllocatingToVMI, AttachingToPod, LibvirtAdding / Removing, Ready, and Failed in a fine-grained manner, so that cross-component actions are traceable, rollbackable / recoverable, and improve reliability;

[0046] (5) The present invention can uniformly manage and support multiple host device types (such as USB, PCIe, GPU, etc.). The core mechanism is based on standardized device identification and resource model, does not depend on specific hardware manufacturers, has good compatibility with existing Kubernetes device management and virtualization technology stack, and is easy to quickly adapt to new devices. Attached Figure Description

[0047] The accompanying drawings, which form part of this invention, are used to provide a further understanding of the invention. The illustrative embodiments of the invention and their descriptions are used to explain the invention and do not constitute an undue limitation of the invention. In the drawings:

[0048] Figure 1 This is a schematic diagram illustrating the method described in an embodiment of the present invention;

[0049] Figure 2 This is a schematic diagram illustrating the dynamic registration and binding of host devices according to an embodiment of the present invention;

[0050] Figure 3 This is a schematic diagram of the hot-plugging process of the host device according to an embodiment of the present invention;

[0051] Figure 4 This is a schematic diagram of the state flow of the hot-plugging operation according to an embodiment of the present invention. Detailed Implementation

[0052] It should be noted that, unless otherwise specified, the embodiments and features described in the present invention can be combined with each other.

[0053] In the description of this invention, it should be understood that the terms "center," "longitudinal," "lateral," "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," and "outer," etc., indicating orientations or positional relationships based on the orientations or positional relationships shown in the accompanying drawings, are only for the convenience of describing the invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of the invention. Furthermore, the terms "first," "second," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined with "first," "second," etc., may explicitly or implicitly include one or more of that feature. In the description of this invention, unless otherwise stated, "a plurality of" means two or more.

[0054] In the description of this invention, it should be noted that, unless otherwise explicitly specified and limited, the terms "installation," "connection," and "linking" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art will understand the specific meaning of the above terms in this invention based on the specific circumstances.

[0055] The present invention will now be described in detail with reference to the accompanying drawings and embodiments.

[0056] like Figure 1As shown in the figure, this embodiment presents the overall process of performing dynamic hot-plugging of host devices on a running virtual machine in a dual-stack virtualization environment. First, the host device management plugin runs on each node to collect and maintain a resource pool of transparent host devices. Then, a custom resource, HotPlugHostDevice, is defined and created for hot-pluggable host devices. This resource carries the target virtual machine identifier, the target node identifier, and a unique device identifier, used to initiate hot-add or hot-remove requests for devices on running virtual machines. The host device management plugin responds to HotPlugHostDevice, locates and locks the target device from the resource pool, temporarily registers it as an extended resource of the target node, and establishes a binding relationship between the device and the target virtual machine. The control plane component updates the virtual machine instance object corresponding to the target virtual machine, writes the configuration of the device to be hot-plugged in the specification field, and writes the hot-plug request and process status in the status field. Based on the changes in the virtual machine instance object, the node-side component completes device injection within the Pod hosting the target virtual machine and triggers the virtual machine runtime component within the Pod to perform hot-add or hot-remove operations on the running virtual machine through the virtualization management interface. Upon successful hot-removal, the device access permissions of the Pod are revoked, the device node within the Pod is cleaned up, and the extended resources and binding relationships are released. Simultaneously, the process status is updated for tracking and recovery.

[0057] like Figure 2 As shown, this embodiment illustrates the collaborative relationship between the control plane and the node side around HotPlugHostDevice and the device-level resource modeling method. The control plane uses Kubernetes' kube-apiserver and etcd to store hot-plug-related resource objects, including HotPlugHostDevice, virtual machines, and virtual machine instance objects. The HostDeviceController listens for the creation / update of HotPlugHostDevice and schedules and advances the process. Each node deploys a HostDevicePlugin to discover and maintain a pool of transparent host device resources (e.g., GPUs, USBs, network cards) on the node, exposing the devices as "extended resources" to the node's schedulable resources. When initiating hot-plugging, the device type, unique device identifier / address information, target node, and target virtual machine fields recorded in HotPlugHostDevice are used to achieve "precise device-level specification." The HostDeviceController, in conjunction with the node-side plugin, completes device locking, temporary registration of extended resources, and binding with the target virtual machine, thus providing a consistent resource basis for subsequent Pod injection and virtual machine hot-plugging.

[0058] like Figure 3As shown in the illustration, this embodiment further illustrates the chain from initiating a hot-plug request to completing the device activation within the virtual machine. The requesting side can submit a hot-plug request to the kube-apiserver via command or interface, causing the relevant objects to be written to etcd; components such as virt-api, virt-controller, and HostDeviceController listen for object changes and drive execution. On the node side, virt-handler combines the hot-plug request in the virtual machine instance object with the device configuration to configure device access control permissions for the Pod hosting the target virtual machine (e.g., through cgroupfs device rules), and enters the Pod's file system namespace, creating a device node within the Pod that is consistent with the target host device; subsequently, the virtual machine runtime components within the Pod update the virtualization configuration according to the device configuration changes (e.g., updating the libvirt domain XML), and call the virtualization management interface to perform hot-add or hot-remove device operations on the running QEMU / KVM virtual machine, enabling the host-side device to be recognized and put into use or unloaded within the virtual machine.

[0059] like Figure 4 As shown in the figure, this embodiment illustrates the state machine and exception handling for the hot-plug process. A hot-plug request enters a pending state. When a hot-plug command is triggered, it sequentially enters the resource binding related state, the Pod injection state, and the virtualization interface hot-add state, until the device is ready. When a hot-plug command is triggered, the process enters the virtualization interface hot-removal state, and further completes Pod cleanup and unbinding release states. After successful resource release, it returns to the pending state. For abnormal scenarios such as resource conflicts / permission errors, Pod creation anomalies, and hot-plug / hot-plug timeouts, the state machine enters a failed state and retains failure information to support manual intervention, location, and recovery. This state machine is typically maintained in the state field of the virtual machine instance object to achieve traceability and recoverability of the three-layer collaboration process across nodes, Pods, and virtual machines.

[0060] In one embodiment, the present invention is applied to a dual-stack virtualization environment built on a container orchestration cluster. Cluster nodes are used to host Pods containing virtual machines. The virtual machines are started and run on QEMU KVM by a virtual machine runtime component within the Pod. The virtual machine management component includes at least a control plane component and a node-side component. The control plane component is used to handle hot-plug requests and update virtual machine instance objects. The node-side component is used to perform device injection on the node and Pod sides and cooperate with the virtual machine runtime component within the Pod to complete the virtual machine hot-plug operation.

[0061] To achieve unified management and precise allocation of host-side hardware devices, a host device management plugin is deployed on each node. The host device management plugin runs in DaemonSet mode and is used to discover and collect host device information that can be used for pass-through and form a resource pool. The host device information includes at least the device type, the device unique identifier, and the address information corresponding to the device type. The device type can be a USB device, a PCIe device, a GPU device, or a dedicated accelerator card, etc. The device unique identifier can be a USB bus address or a PCI BDF address, etc. The device status in the resource pool includes at least an idle state, an allocated state, and an unavailable state, thereby providing a basis for precise device-level location and availability judgment for subsequent hot-plugging.

[0062] Based on the above resource pool, this invention defines a custom resource HotPlugHostDevice for hot-pluggable host devices in the cluster. The resource declaration of HotPlugHostDevice is used to express a hot-plug request. The resource declaration includes the target virtual machine identifier, target node identifier, host device name, host device type, and device unique identifier or address information. It may also include host name or host address information to facilitate auditing, cross-node location, and troubleshooting. At the same time, the resource declaration includes the hot-plug operation type to indicate hot-add or hot-remove.

[0063] In this embodiment, the overall process of dynamic hot-plugging can be completed collaboratively by the host device management plugin, control plane component, node-side component, and virtual machine runtime component within the Pod.

[0064] When a hot-plug request for a running virtual machine is received, the requester creates a corresponding HotPlugHostDevice resource in the cluster and submits it to the cluster interface service. After the host device management plugin listens for the HotPlugHostDevice resource event, it locates the target device in the resource pool based on the target node identifier, host device type, and device unique identifier. It then performs consistency verification and occupancy control on the target device. After the verification passes, the target device is locked in the allocated state, and a binding relationship is established between the device and the target virtual machine. At the same time, the target device is temporarily registered as an extended resource of the target node, enabling the cluster resource model to perceive changes in device availability and provide a basis for subsequent processing.

[0065] After reading the HotPlugHostDevice resource, the control plane component updates the virtual machine instance object corresponding to the target virtual machine, writes the configuration of the device to be hot-plugged into the specification field of the virtual machine instance object and marks the device as supporting hot-plugging, and writes the hot-plug request into the status field of the virtual machine instance object and records the process status, thereby driving the node-side component to perform device injection and hot-plugging execution.

[0066] The node-side component continuously monitors changes to virtual machine instance objects. When a hot-plug request is detected, it configures device access control permissions for the Pod hosting the target virtual machine on the node side. These device access control permissions can be implemented by configuring device access rules in cgroupfs to allow the Pod to access the device file corresponding to the target host device. Subsequently, the node-side component enters the Pod's file system namespace and creates a device node within the Pod that is consistent with the target host device. The device node can be created as a character device node or a block device node using the mknod method. After completing the above injection, the node-side component triggers the virtual machine runtime component within the Pod to update the virtualization configuration and perform the virtual machine hot-plug operation.

[0067] The virtual machine runtime component within the Pod updates the XML configuration of the libvirt domain based on changes in the host device configuration of the virtual machine instance object and calls the virtualization management interface to perform hot-add or hot-remove devices on the running virtual machine. The virtual machine runtime component can identify hot-mount or hot-unmount behavior by comparing the device data in the domain cache with the device configuration data in the virtual machine instance object, and respectively call the libvirt attach interface or detach interface to implement hot-plug control of the running QEMU KVM process, thereby completing the dynamic mounting or unmounting of devices without interrupting the operation of the target virtual machine.

[0068] After hot-plugging is completed, the node-side components and control plane components write the hot-plugging result back to the status field of the virtual machine instance object, so that the device status enters the ready state; when hot removal is successful, the node-side components revoke the device access permissions of the Pod and clean up the device nodes in the Pod, and the host device management plugin removes the temporary registration and binding relationship of extended resources and restores the device status to the idle state, thereby realizing the closed-loop recycling and redistribution of devices.

[0069] To improve the consistency and recoverability of the three-layer collaboration process across nodes, Pods, and virtual machines, in a further embodiment, this invention maintains a host device hot-plug state machine in the state field of the virtual machine instance object. The state machine includes at least the following states: waiting to process, bound to the virtual machine instance object, injected into the Pod, hot-adding virtualization interface, ready, hot-removing virtualization interface, cleanup within the Pod, unbinding and release, and failure. After each step of the process is completed, the node-side component updates the state field and records the failure information, making the hot-plug process traceable, retryable, and able to be located and recovered in abnormal scenarios.

[0070] To avoid conflicts caused by concurrent allocation of the same device, the host device management plugin can use an external database or cluster storage to save device allocation records and implement mutual exclusion control for device locking and releasing based on an atomic update mechanism, thereby ensuring the uniqueness of device allocation. At the same time, the host device management plugin can also verify whether the device is in the correct driver binding state and meets the pass-through isolation conditions before locking the device. If necessary, it can switch the device to a pass-through driver such as VFIO and verify the IOMMU isolation conditions to improve pass-through security and success rate.

[0071] To ensure that the cleanup operation is completed, HotPlugHostDevice resources can be configured with termination control logic, which can still trigger device access permission revocation, device node cleanup, and extended resource unregistration and binding release when resources are deleted or operations fail, thereby reducing the risk of resource leakage.

[0072] In a more specific example, the target virtual machine runs in a Pod on node01. The business wants to dynamically pass-through a USB device with bus address 3-1.2 on node01 to this virtual machine. The requesting party creates a HotPlugHostDevice resource and writes information such as the target virtual machine identifier, target node identifier, host device name, host device type (USB), and device unique identifier (3-1.2) into the resource. The host device management plugin locates the USB device in the resource pool of node01, locks it, and temporarily registers it as an extended resource of node01, while recording the binding relationship between the device and the target virtual machine. The control plane component then updates the virtual machine instance object corresponding to the target virtual machine, writes the USB device configuration into the specification field, and writes the hot-add request and process status into the status field. Upon detecting the request, the node-side component configures the Pod containing the virtual machine with permissions to access the device file corresponding to the USB device. It then creates a device node within the Pod corresponding to the USB device. Subsequently, it calls the virtual machine runtime component within the Pod to update the libvirt domain XML and performs a hot-add operation via the virtualization management interface. This allows the USB device to be recognized and used within the virtual machine. After successful operation, the device status is updated to ready. If the USB device needs to be removed later, the requesting party creates a HotPlugHostDevice resource indicating hot removal or updates the corresponding hot removal request. The control plane component writes the hot removal request into the virtual machine instance object. The node-side component triggers the virtual machine runtime component within the Pod to perform a hot removal via the virtualization interface. Upon success, it cleans up the device node and access permissions within the Pod. The host device management plugin unbinds the device and releases the extended resource registration. Finally, the device returns to an idle state for reassignment.

[0073] In another extended example, when the host device type is a PCIe device or a GPU device, the PCI BDF address is used as the unique identifier of the device in the HotPlugHostDevice resource. Based on this, the host device management plugin can accurately locate the specific physical device on the target node and complete the locking and temporary registration of extended resources. The node-side components complete the Pod-side device injection and permission configuration according to the device type. The virtual machine running components in the Pod update the virtualization configuration and complete hot-add or hot-remove through the virtualization management interface, thereby realizing the general dynamic hot-plug management of multiple types of host devices under the same framework.

[0074] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for dynamic hot-plugging of host devices in a dual-stack virtualization environment, wherein the dual-stack virtualization environment includes a container orchestration cluster, Pods hosting virtual machines, and a management component for managing virtual machines, the management component including a control plane component and a node-side component, characterized in that, include: Run the host device management plugin on each node to collect and maintain the resource pool of transparent host devices; Define and create a custom resource HotPlugHostDevice for a hot-plugg host device, which includes the target virtual machine identifier, the target node identifier, and the device's unique identifier, to request hot-add or hot-remove the device on a running virtual machine. The host device management plugin responds to the HotPlugHostDevice by locking the target device from the resource pool and temporarily registering it as an extended resource of the target node, thus establishing a binding relationship between the target device and the target virtual machine. The control plane component updates the virtual machine instance object corresponding to the target virtual machine according to the HotPlugHostDevice, writes the configuration of the hot-swappable device into its specification, and writes the hot-swappable request and process status into its status. The node-side component performs device injection within the Pod based on the virtual machine instance object, and triggers the virtual machine running component within the Pod to perform hot-add or hot-remove of devices on the running virtual machine through the virtualization management interface; The process status is updated upon completion or failure, wherein upon successful hot removal, the device access permissions of the Pod are revoked, the device node within the Pod is deleted, and the extended resources and the binding relationship are released; The virtual machine instance object includes: a status.hostDeviceRequests field for representing hot-plug requests, a spec.hostDevices field for describing the target host device configuration, and a status.hostDeviceStatus field for representing the hot-plug process and results; When the node-side component completes device injection within the Pod, granting the Pod permission to access the target host device includes: setting device access control permissions for the Pod in cgroupfs to allow the Pod to access the device file corresponding to the target host device; When the node-side component completes device injection within the Pod, the creation of the device node includes: entering the file system namespace of the Pod through chroot, and creating a character device node or block device node corresponding to the target host device within the Pod through mknod; The virtual machine runtime component identifies the hot-mounting or hot-unmounting behavior of the target host device by comparing the device data cached in the virtual machine domain with the host device configuration data in the virtual machine instance object, and triggers the corresponding attach or detach operation accordingly.

2. The method according to claim 1, characterized in that, The dual-stack virtualization environment is an environment in which QEMU-KVM virtual machines are run in Pod containers on Kubernetes through a virtualization management plugin; the control plane component includes virt-api, the node-side component includes virt-handler, the virtual machine runtime component includes virt-launcher, and the virtualization management interface includes the libvirt interface.

3. The method according to claim 1, characterized in that, The virtual machine runtime component writes the target host device into the virtualization configuration, including updating the target host device information to the XML configuration of the libvirt domain; the device hot-add or hot-remove operation includes calling the libvirt attach interface or detach interface to perform device hot-plugging on the running QEMU-KVM process.

4. A dynamic hot-swappable system for host devices in a dual-stack virtualization environment, wherein the dual-stack virtualization environment includes a container orchestration cluster and virtual machine instances running within Pod containers, based on the method of claim 1, characterized in that... The system includes: The host device management plugin is used to collect device information of host devices that can be used for transparent transmission on the node, build a host device resource pool, listen for HotPlugHostDevice resource events, and temporarily register the target host device as an extended resource into the resource capacity of the target node, while recording the device allocation status and binding relationship. The control plane request processing module is used to update the virtual machine instance object corresponding to the target virtual machine according to the HotPlugHostDevice resource, so as to write the hot-plug request list and host device configuration, and drive the process state flow. The node-side injection module is used to grant the Pod hosting the target virtual machine access permissions to the target host device after detecting a hot-plug request, create a device node within the Pod, and call the virtual machine runtime components within the Pod to complete the virtualization configuration update. The Pod hot-plug execution module is used to hot-add or hot-remove execution devices on running virtual machines through the virtualization management interface based on changes in the host device configuration of the virtual machine instance object. The status management module is used to maintain the hot-plug process status, completion status, and failure information in the status fields of virtual machine instance objects.

Images