Dynamic management method and system for virtual machine filter and storage medium

Abstract

The invention relates to a virtual machine filter dynamic management method and system and a storage medium. The method comprises a filter management component configuration step, a loading command definition step, a filter compiling step, a filter first judgment step, a new filter loading step, a filter sequence adjustment step and an I / O request processing step. The system comprises a filter management component configuration module, a loading command definition module, a filter compiling module, a filter first judgment module, a new filter loading module, a filter sequence adjustment module and an I / O request processing module. According to the method, the filter management component is newly added in the QEMU, the dynamic link library file of the filter is dynamically loaded and the operation sequence of the filter is adjusted according to the priority when the virtual machine runs, and the technical defects that the function extension of the filter is difficult, the deployment process is complex, and the execution sequence is solidified are effectively overcome.

Description

Technical Field

[0001] This invention belongs to the field of virtualization technology and relates to a method, system and storage medium for dynamic management of virtual machine filters. Background Technology

[0002] In virtualized environments, I / O operations are a critical factor affecting overall system performance and security, making their management and control particularly important. To meet diverse data processing needs, virtual machines can dynamically insert programmable modules with specific functions into the I / O path by loading filters. This enables processing operations such as data encryption, integrity verification, cache optimization, or access control during data read and write operations. These filters need to possess high execution performance and flexible configuration capabilities to adapt to the storage management requirements of different application scenarios.

[0003] QEMU (Quick Emulator), as an open-source virtualization software, allows its block device layer to form a block device chain by loading filter drivers, thereby enabling diverse processing of virtual machine I / O data. Currently, QEMU supports filter functions such as traffic limiting, encryption, and replication. However, its supported filter types are limited, and its functional expansion is inflexible. Especially when introducing advanced filter functions such as third-party developed continuous data protection and block-layer agentless antivirus, developers must integrate their self-developed filter code into the QEMU source code tree and recompile to generate QEMU binaries. At the same time, users need to stop the virtual machine from running and recompile the QEMU emulator. This static compilation and integration of filter functions not only requires interruption of production environment services but also introduces the risk of compilation and deployment failures to users.

[0004] Furthermore, QEMU supports building filter chains at the block device layer by loading multiple filters to meet diverse I / O data management needs. However, the execution order of these filters is statically determined when QEMU starts up and cannot be dynamically adjusted during virtual machine operation. If it is necessary to flexibly adjust the execution order of filters based on changes in system load or security policies during actual business operations, the only way to change the filter order is to shut down the virtual machine, modify the QEMU configuration, and restart it. Such operations are not only cumbersome but also cause service interruptions, severely impacting the continuity of business operations and system availability.

[0005] Therefore, the management of QEMU block device filter chains is highly static and rigid, making dynamic and uninterrupted configuration changes impossible during virtual machine runtime. This severely limits the convenient expansion and on-demand scheduling of advanced filtering functions, and introduces unnecessary complexity and service interruption risks to production environment operations and maintenance. Currently, the industry lacks an effective dynamic management solution to address this core pain point.

[0006] In summary, finding a method for managing virtual machine filters that is easy to extend, simple to deploy and maintain, and allows for adjustable execution order is a problem that urgently needs to be solved. Summary of the Invention

[0007] To address the technical problems described in the background section, this invention provides a method, system, and storage medium for dynamic management of virtual machine filters. The technical solution is as follows: The first aspect provides a method for dynamic management of virtual machine filters, including the following steps: The steps to configure the filter management component are as follows: add a filter management component to the QEMU source code, configure it, and compile it into the QEMU binary file; The loading command definition steps define the filter loading command in the QEMU QAPI standardized interface. The loading command includes the absolute path parameter of the dynamic link library file. The filter compilation step compiles the filters that need to be loaded into dynamic link library files; The first step in the filter judgment process is to determine whether the filter to be loaded has already been loaded in the virtual machine. If it has not been loaded, the new filter loading step is executed first, followed by the filter order initial adjustment step; if it has been loaded, the filter order initial adjustment step is executed directly. The new filter loading step involves setting the priority of the new filter and loading the dynamic link library file into the filter management component using a loading command. The initial filter order adjustment step involves the filter management component adjusting the filter execution order based on filter priority. In the I / O request processing steps, when an I / O request is issued, the filter management component calls the filter callback functions in sequence to process the I / O request and sends the processing result to the backend block device.

[0008] Secondly, a dynamic management system for virtual machine filters is also provided, the system comprising: The filter management component configuration module is used to add filter management components to the QEMU source code, configure them, and compile them into the QEMU binary file. The loading command definition module is used to define the loading commands for filters in the QEMU QAPI standardized interface. The loading commands include the absolute path parameter of the dynamic link library file. The filter compilation module is used to compile the filters that need to be loaded into dynamic link library files; The first filter judgment module is used to determine whether the filter to be loaded has already been loaded in the virtual machine. If it has not been loaded, the new filter loading module is run first, and then the filter order initial adjustment module is run; if it has been loaded, the filter order initial adjustment module is run directly. The new filter loading module is used to set the priority of new filters and load dynamic link library files into the filter management component via loading commands; The filter order initial adjustment module is used by the filter management component to adjust the filter running order according to the filter priority; The I / O request processing module is used to process I / O requests by sequentially calling the filter callback functions of the filter when an I / O request is issued, and then sending the processing results to the backend block device.

[0009] Thirdly, a computer-readable storage medium is provided on which a computer program is stored, which is executed by a processor to implement the virtual machine filter dynamic management method described above.

[0010] The beneficial effects of this invention are: This invention provides an efficient, secure, and flexible method for dynamic management of virtual machine filters. By adding a filter management component to QEMU, this component dynamically loads the dynamic link library files of the filters during virtual machine runtime. Based on the priority parameters passed when loading the dynamic link library files, the running order of the filters can be dynamically adjusted, effectively solving the technical defects of the prior art, such as difficulty in expanding filter functions, complex deployment process, and fixed running order. Attached Figure Description

[0011] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 This is a schematic diagram of the dynamic management method for virtual machine filters in Embodiment 1 of the present invention.

[0013] Figure 2 This is a schematic diagram of the TAILQ doubly linked list structure in Embodiment 1 of the present invention.

[0014] Figure 3 This is a structural diagram of the filter management component in Embodiment 1 of the present invention.

[0015] Figure 4 This is a schematic diagram of the dynamic management method for virtual machine filters in Embodiment 2 of the present invention.

[0016] Figure 5 This is a schematic diagram of the dynamic management method for virtual machine filters in Embodiment 3 of the present invention.

[0017] Figure 6This is a schematic diagram of the virtual machine filter dynamic management system structure in Embodiment 4 of the present invention.

[0018] Figure 7 This is a schematic diagram of the loading command definition module structure in Embodiment 4 of the present invention.

[0019] Figure 8 This is a schematic diagram of the new filter loading module structure in Embodiment 4 of the present invention.

[0020] Figure 9 This is a schematic diagram of the filter sequence initial adjustment module structure in Embodiment 4 of the present invention.

[0021] The attached diagram lists the components represented by each number as follows: The filter management component configuration module; 4002, Load command definition module; 4003, Filter compilation module; 4004, Filter first judgment module; 4005, Version verification module; 4006, New filter loading module; 4007, Filter order initial adjustment module; 4008, I / O request processing module; 4009, Unload command definition module; 4010, Filter second judgment module; 4011, Filter unloading module; 4012, Filter order readjustment module; 40021, Add command unit; 40022, Configuration parameter unit; 40061, File descriptor acquisition unit; 40062, Function descriptor acquisition unit; 40063, Filter node creation unit; 40071, Filter organization unit; 40072, Filter adjustment unit. Detailed Implementation

[0022] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0023] Example 1 The management of QEMU block device filter chains is highly static and rigid, making dynamic, non-disruptive configuration changes impossible during virtual machine runtime. This severely limits the convenient expansion and on-demand scheduling of advanced filtering functions, and introduces unnecessary complexity and service interruption risks to production environment operations and maintenance. Currently, the industry lacks an effective dynamic virtual machine management solution to address this core pain point.

[0024] To address the above problems, embodiments of the present invention provide a method for dynamic management of virtual machine filters. Figure 1 This is a flowchart illustrating a method for dynamic management of virtual machine filters provided in an embodiment of the present invention, such as... Figure 1 As shown, this method includes: Step S101: Add a filter management component to the QEMU source code, configure it, and compile it into the QEMU binary file.

[0025] It is understandable that the QEMU binary file refers to the core execution carrier of the QEMU virtualization platform, that is, the final executable program it generates. Under the existing technical framework, any enhancement or modification to the core functionality of QEMU requires integrating the new or modified source code into the QEMU source tree and generating a QEMU binary executable file containing the new functionality through the standard development process of reconfiguring and recompiling. The operation of adding a filter management component and compiling it into the QEMU binary file in step S101 of this embodiment follows this standard process and is a necessary technical means to achieve core functionality extension.

[0026] It is worth noting that the newly added filter management component in this embodiment is integrated and deployed in the Block Device Layer of the QEMU architecture. This component plays a core hub role in the block device I / O processing path. Specifically, when I / O requests generated by upper-layer virtual devices are sent to the block device layer for processing, this I / O data is processed by the filter management component before reaching the backend block devices (such as image files or physical devices).

[0027] Step S102: Define the filter loading command in the QEMU QAPI standardized interface. The loading command includes the absolute path parameter of the dynamic link library file.

[0028] Understandably, the QAPI (QEMU Application Programming Interface) standardized interface defines a series of structured, type-safe virtual machine operation commands and responses provided by QEMU. These specifications are implemented through QMP (QEMU Machine Protocol) and use the JSON-RPC protocol to enable virtual machine management tools to interact with virtual machines.

[0029] It's also understandable that the absolute path parameter defined in the load command requires the caller to provide a complete and explicit path identifier for the dynamic link library file corresponding to the target filter implementation within the host file system. The absolute path eliminates the ambiguity that relative paths can cause, precisely locating the unique target library file on the host machine and avoiding the risk of loading failure due to changes in the working directory or differences in path resolution rules. Furthermore, this parameter is not coupled to QEMU's own installation path or predefined directory structure, allowing administrators to freely deploy filter libraries in any authorized location within the host file system (e.g., a separate secure storage area or a specific project directory), greatly improving the flexibility of deployment strategies. When performing a load operation, the filter management component will strictly adhere to this absolute path parameter to access and load the specified library file.

[0030] Preferably, step S102 further includes: Step S1021: Add filter loading command code to the block device core json file in the QEMU QAPI standardized interface; Step S1022: Configure the parameters of the loading command, including: filter name and filter priority.

[0031] It is worth noting that this embodiment adds a dedicated block device filter loading command (named `filter-load` in this embodiment) to the standardized interface of the QAPI specification. This command is provided externally through the QMP interface. Virtual machine management tools can trigger the dynamic loading operation of the filter by establishing a QMP connection to the target QEMU process and sending a JSON-RPC request conforming to the `filter-load` command specification. This command definition strictly follows the QAPI type system standard, performs strong type validation on input parameters (such as filter name and filter priority), and defines standardized success responses and possible error codes and error message formats. By abstracting and standardizing the filter loading operation into a QMP command, this embodiment provides a core, standardized remote procedure call (RPC) mechanism for achieving secure, controllable, and tool-independent runtime filter management, significantly improving the interoperability, reliability, and integration convenience of management operations. For ease of understanding, an operational example is provided here: Adding the option `-qmp stdio` to the normal QEMU startup command parameters enables QMP's local standard input / output mode. After the virtual machine starts normally, sending the `qmp` command `{"execute": "qmp_capabilities"}` will return a result `{"return": {}}`, indicating that the virtual machine has entered command mode. To load a filter, compile the filter into a shared library file `test_filter.so` and execute the command `{"execute": "filter-load","arguments":{"filter-path": " / home / path / qemu / block / filter / test_filter.so","filter-name":"test_filter","order": "1"}}`, where `filter-name` is the filter name and `order` is the filter priority. This command allows for flexible loading of filters into QEMU without recompiling or shutting down the system.

[0032] Step S103: Compile the filters that need to be loaded into dynamic link library files.

[0033] Understandably, the QEMU virtualization platform is primarily deployed and runs in a Linux operating system environment. In typical implementation scenarios, this dynamic link library needs to be compiled into a shared library file (SharedObject) that conforms to the Linux Dynamic Linking Standard (ELF), with the file name extension .so.

[0034] Step S104: Determine whether the filter to be loaded has been loaded in the virtual machine. If it has not been loaded, execute step S105 first, and then execute step S106; if it has been loaded, execute step S106 directly.

[0035] It is worth noting that during the virtual machine's operation, multiple filters are loaded or adjusted. The core of this step is to achieve dynamic and state-aware management of filters during virtual machine operation. Precise state detection effectively prevents the same filter instance from being loaded into memory multiple times. Repeated loading not only causes unnecessary consumption of host system memory resources, but may also lead to chaotic internal state of the filter or unexpected superimposed processing effects, affecting the correctness of data processing.

[0036] Step S105: Set the priority of the new filter and load the dynamic link library file into the filter management component by loading the command.

[0037] Preferably, while performing steps S1021 and S1022, step S105 further includes: Step S1051: Use the dlopen function to load the dynamic link library file according to the absolute path in the loading command to obtain the file descriptor; Step S1052: Use the dlsym function to obtain the function descriptor in the dynamic link library file based on the file descriptor; In step S1053, the filter management component creates a filter node based on the function descriptor, filter name, and filter priority, and adds the node to the filter management component.

[0038] It is worth noting that dynamic link library files, as the standard format for carrying dynamically loadable code under the Linux system, enable the newly added filter management component in this embodiment to utilize the Linux operating system's dynamic linker interfaces such as dlopen and dlsym. During QEMU process runtime, the defined filter functions are safely loaded and linked using the absolute paths provided by the loading commands. This compilation method ensures binary compatibility between the filter function module and the host Linux environment and the QEMU process.

[0039] Step S106: The filter management component adjusts the filter running order according to the filter priority.

[0040] Preferably, step S106 further includes: Step S1061: The filter management component uses a TAILQ doubly linked list structure to organize filter nodes. The nodes of this doubly linked list are used to store the loaded filters and their corresponding priority information. In step S1062, the filter management component traverses the linked list nodes according to the filter priority, compares the filter priority represented by each node, and then reorganizes the filter nodes in the linked list according to the priority result of the comparison.

[0041] It's also understandable that TAILQ (tail queue) is an efficient doubly linked list, with a structure like... Figure 2As shown, this structure consists of a head list and multiple nodes. The head list is located at the beginning of the entire TAILQ structure. The head pointer (`first`) and tail pointer (`last`) point to the first node (`1`) and the last node (`n`) of the list, respectively. Each node has a value (`value`), a predecessor pointer (`prev`), and a successor pointer (`next`). For example, node 1 has a value (`1`), a predecessor pointer (`1`), and a successor pointer (`1`); node 2 has a value (`2`), a predecessor pointer (`2`), and a successor pointer (`2`); node 3 has a value (`3`), a predecessor pointer (`3`), and a successor pointer (`3`); and so on, up to node n, which has a value (`n`), a predecessor pointer (`n`), and a successor pointer (`n`). Simultaneously, the predecessor pointer (`1`) of node 1 and the successor pointer (`n`) of node n point to null addresses. Starting from the head list, nodes 1, 2, 3, and n are sequentially connected, forming a complete doubly linked list. Compared to ordinary singly linked lists or ordinary doubly linked lists without a head, TAILQ natively supports efficient bidirectional traversal and maintains direct pointers at both the head and tail of nodes. This design allows TAILQ to achieve constant time complexity O(1) when performing insertion and deletion operations at the head / tail of nodes, and also requires only O(1) time to insert / delete nodes before or after any known node. These characteristics are particularly suitable for scenarios in this embodiment that require frequent dynamic insertion, deletion, and reordering of nodes.

[0042] It is worth noting that this embodiment introduces a TAILQ structure into the filter management component and performs linked list reorganization based on priority. Its core purpose is to achieve real-time, lossless, and efficient dynamic adjustment of the filter chain execution order during virtual machine runtime. By managing each filter node (including its priority attribute) as a TAILQ node, the component can efficiently traverse the linked list, compare node priority values, and, through efficient node removal and insertion operations, immediately reposition nodes to the correct position in the linked list corresponding to their priority. This mechanism allows administrators to flexibly and dynamically optimize the I / O processing pipeline according to real-time load or policy requirements, greatly improving the system's adaptability and availability.

[0043] In step S107, when an I / O request is issued, the filter management component calls the filter callback function in sequence to process the I / O request and sends the processing result to the backend block device.

[0044] It's worth noting that when an I / O request from a virtual device arrives at the block device layer, the filter management component, according to the order of the filter nodes it maintains, sequentially calls the callback functions registered by each node. Each filter performs its specific processing on the I / O data (such as encryption, rate limiting, etc.) in sequence, and the processing results are passed down level by level by the management component. Finally, the I / O request processed by all filters is sent to the backend block device, completing the entire I / O processing flow and ensuring the sequential and reliable execution of filter functions.

[0045] To more clearly illustrate the implementation and organizational structure of the method in this embodiment, the following is combined with... Figure 3 To elaborate in detail. For example Figure 3 As shown, the filter management component is responsible for managing and controlling operations such as filter loading and order adjustment. This includes the filter chain to be managed and the loading command. The filter chain consists of a series of sequentially arranged filter nodes, including filter 1, filter 2, filter 3 to filter n. Each filter node represents a loaded filter instance, and its function and processing logic are defined by the corresponding dynamic link library file. When a new filter needs to be loaded, such as dynamic link library file 3 and filter 3 as shown in the dashed box in the figure, the filter management component receives the externally issued filter loading command, loads dynamic link library file 3 from the specified path, and inserts its corresponding filter 3 into the specified position in the filter chain. When an I / O request arrives, the filter management component will call the callback functions of each filter in the order of the filter chain to process the data, and finally pass the processing result to the backend block device to complete the actual data read / write operation. Through this architecture design, the loading and execution order adjustment of filters can be completed in real time during virtual machine runtime, effectively improving the convenience of functional expansion.

[0046] This embodiment provides an efficient, secure, and convenient method for dynamic management of virtual machine filters. By adding a filter management component to QEMU, this component dynamically loads the dynamic link library files of the filters during virtual machine runtime. Based on the priority parameters passed when loading the dynamic link library files, the running order of the filters can be dynamically adjusted, effectively solving the technical defects of the prior art, such as difficulty in expanding filter functions, complex deployment process, and fixed running order.

[0047] Example 2 like Figure 4 As shown, a method for dynamic management of virtual machine filters is provided, which includes the following steps: Step S201: Add a filter management component to the QEMU source code, configure it, and compile it into the QEMU binary file; Step S202: Define the filter loading command in the QAPI standardized interface of QEMU. The loading command includes the absolute path parameter of the dynamic link library file. Step S203: Compile the filters that need to be loaded into dynamic link library files; Step S204: Determine whether the filter to be loaded has been loaded in the virtual machine. If it has not been loaded, execute step S205 first, and then execute steps S206 and S207 in sequence; if it has been loaded, execute step S207 directly. In step S205, the filter management component verifies whether the version information declared in the dynamic link library file is compatible with the current QEMU version. If it is compatible, proceed to step S206; if it is incompatible, refuse to load and return an error message. Step S206: Set the priority of the new filter and load the dynamic link library file into the filter management component by loading the command; Step S207: The filter management component adjusts the filter running order according to the filter priority; In step S208, when an I / O request is issued, the filter management component calls the filter callback function in sequence to process the I / O request and sends the processing result to the backend block device.

[0048] It's worth noting that different versions of QEMU may provide different function interfaces. Directly loading unverified dynamic link library files can lead to interface call mismatches, function pointer errors, or even QEMU process crashes. Therefore, verifying the compatibility of the version information declared in the dynamic link library with the current QEMU version before loading the filter is a crucial step to ensure system stability and functional correctness. Specifically, before the filter management component calls the dlopen interface to load the dynamic link library, it first reads and parses the predefined version information field in the library and compares it with the interface version declared by the current QEMU runtime environment to determine whether the filter is compatible with the current QEMU version.

[0049] Unlike the above embodiments, this embodiment adds filter version verification before loading new filters, which effectively avoids compatibility issues caused by differences in function interfaces between different versions of QEMU, and prevents the QEMU process from crashing due to calling mismatched function signatures or accessing illegal memory addresses.

[0050] Example 3 like Figure 5 As shown, a method for dynamic management of virtual machine filters is provided, the method comprising: Step S301: Add a filter management component to the QEMU source code, configure it, and compile it into the QEMU binary file; Step S302: Define the filter loading command in the QAPI standardized interface of QEMU. The loading command includes the absolute path parameter of the dynamic link library file. Step S303: Compile the filters that need to be loaded into a dynamic link library file; Step S304: Determine whether the filter to be loaded has been loaded in the virtual machine. If it has not been loaded, execute step S305 first, and then execute step S306; if it has been loaded, execute step S306 directly. Step S305: Set the priority of the new filter and load the dynamic link library file into the filter management component by loading the command; Step S306: The filter management component adjusts the filter running order according to the filter priority; Step S307: When an I / O request is issued, the filter management component calls the callback function of the filter in sequence to process the I / O request and sends the processing result to the backend block device. Step S308: Define the filter unload command in the QAPI standardized interface of QEMU; Step S309: When the virtual machine is running, execute the uninstall command and determine whether the filter to be uninstalled has been loaded. If it has not been loaded, no operation is performed; if it has been loaded, execute step S310. Step S310: When the filter is in a non-running state, the filter management component removes and cleans up the filter to be uninstalled; Step S311: After the unloading is completed, the filter management component readjusts the running order of the remaining filters.

[0051] It's worth noting that the QEMU QAPI standardized interface defines the filter uninstallation command, and the parameters of the uninstallation command include the filter name. The filter name is unique throughout the entire virtual machine runtime. When the virtual machine executes the uninstallation command, it uses the filter name to determine whether the filter has been loaded.

[0052] It's also worth noting that when a virtual machine is running, stopping a filter in the filter chain typically requires shutting down the virtual machine and restarting QEMU, leading to service interruption and impacting system availability. In this embodiment, before unloading, the system checks whether the target filter is processing I / O requests to avoid forced unloading during data processing, which could result in data loss or pointer errors. After unloading, the filter management component automatically adjusts the running order of the remaining filters to prevent logical errors or functional failures due to missing filters.

[0053] Unlike the above embodiments, this embodiment adds a filter uninstallation process, which can uninstall unnecessary filters based on the virtual machine's running status, reducing the system burden and greatly improving the flexibility and controllability of QEMU's filter management.

[0054] Example 4 This embodiment provides a dynamic management system for virtual machine filters, such as... Figure 6 As shown, the system includes: The filter management component configuration module 4001 is used to add a filter management component to the QEMU source code, configure it, and compile it into the QEMU binary file. Load command definition module 4002 is used to define the loading commands for filters in the QAPI standardized interface of QEMU. The loading commands include the absolute path parameter of the dynamic link library file. The filter compilation module 4003 is used to compile the filters that need to be loaded into dynamic link library files; The first filter judgment module 4004 is used to determine whether the filter to be loaded has been loaded in the virtual machine. If it has not been loaded, the version verification module 4005 is run first, and then the new filter loading module 4006 and the filter order initial adjustment module 4007 are run in sequence. If it has been loaded, the filter order initial adjustment module 4007 is run directly. Version verification module 4005 is used by the filter management component to verify whether the version information declared in the dynamic link library file is compatible with the current QEMU version. If it is compatible, the new filter loading module 4006 will continue to run; if it is incompatible, loading will be refused and an error message will be returned. The new filter loading module 4006 is used to set the priority of new filters and load dynamic link library files into the filter management component via loading commands; The filter order initial adjustment module 4007 is used by the filter management component to adjust the filter running order according to the filter priority; The I / O request processing module 4008 is used to process I / O requests by sequentially calling the callback functions of the filters when an I / O request is issued, and then sending the processing results to the backend block device. Unload command definition module 4009 is used to define the unload command for the filter in the QAPI standardized interface of QEMU; The second filter judgment module 4010 is used to execute the uninstallation command and determine whether the filter to be uninstalled has been loaded when the virtual machine is running. If it has not been loaded, no operation is performed; if it has been loaded, the filter uninstallation module 4011 is run. The filter unloading module 4011 is used by the filter management component to remove and clean up the filter to be unloaded when the filter is not running. The filter order reordering module 4012 is used to reorder the running order of the remaining filters after unloading is complete.

[0055] Preferred, such as Figure 7 As shown, the loading command definition module 4002 also includes: Add command unit 40021 to add a filter to the block device core json file in the QEMU QAPI standardized interface to load command code; Configuration parameter unit 40022 is used to configure the parameters of the loading command, including: filter name and filter priority; At the same time, such as Figure 8 As shown, the new filter loading module 4006 further includes: The file descriptor acquisition unit 40061 is used to load the dynamic link library file using the dlopen function based on the absolute path in the loading command to obtain the file descriptor. Function descriptor acquisition unit 40062 is used to obtain function descriptors in dynamic link library files based on file descriptors using the dlsym function; The filter node creation unit 40063 is used by the filter management component to create filter nodes based on function descriptors, filter names, and filter priorities, and add the nodes to the filter management component.

[0056] Preferred, such as Figure 9 As shown, the filter sequence initial adjustment module 4007 also includes: The filter organization unit 40071 is used to organize filter nodes in the filter management component using a TAILQ doubly linked list structure. The nodes of this doubly linked list are used to store the loaded filters and their corresponding priority information. The filter adjustment unit 40072 is used by the filter management component to traverse the linked list nodes according to the filter priority, compare the filter priority represented by each node, and then reorganize the filter nodes in the linked list according to the priority result of the comparison.

[0057] This embodiment supports multiple dynamic filter management methods. During virtual machine runtime, new filters can be loaded, existing filters can be unloaded, and the filter running order can be adjusted to meet different business needs. In addition, version verification during loading ensures filter compatibility and greatly improves system availability and stability.

[0058] Example 5 In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which is executed by a processor to implement the virtual machine filter dynamic management method as described in any one of embodiments 1 to 3.

[0059] The computer storage medium of this invention can be any combination of one or more computer-readable media. The computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. Computer-readable storage media include, but are not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatuses, or devices, or any combination thereof. More specific examples (a non-exhaustive list) of computer-readable storage media include: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this document, a computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0060] This invention can be written in one or more programming languages ​​or a combination thereof to perform computer program code for carrying out the operations of this invention. The programming languages ​​include object-oriented programming languages—such as Java, Smalltalk, C++, Ruby, and Go—and also conventional procedural programming languages—such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0061] The embodiments described above are merely illustrative of several implementations of the present invention, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of the present invention. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the present invention, and these modifications and improvements all fall within the scope of protection of the present invention. Therefore, the scope of protection of this patent should be determined by the appended claims.

Claims

1. A method for dynamic management of virtual machine filters, characterized in that, The method includes the following steps: The steps to configure the filter management component are as follows: add a filter management component to the QEMU source code, configure it, and compile it into the QEMU binary file; The loading command definition steps define the filter loading command in the QEMU QAPI standardized interface. The loading command includes the absolute path parameter of the dynamic link library file. The filter compilation step compiles the filters that need to be loaded into dynamic link library files; The first step in the filter judgment process is to determine whether the filter to be loaded has already been loaded in the virtual machine. If it has not been loaded, the new filter loading step is executed first, followed by the filter order initial adjustment step; if it has been loaded, the filter order initial adjustment step is executed directly. The new filter loading step involves setting the priority of the new filter and loading the dynamic link library file into the filter management component using a loading command. The initial filter order adjustment step involves the filter management component adjusting the filter execution order based on filter priority. In the I / O request processing steps, when an I / O request is issued, the filter management component calls the filter callback functions in sequence to process the I / O request and sends the processing result to the backend block device.

2. The method for dynamic management of virtual machine filters according to claim 1, characterized in that, The loading command definition step also includes: Add the filter loading command code to the block device core JSON file in the QEMU QAPI standardized interface; Configure the parameters for the loading command, including: filter name and filter priority; Meanwhile, the new filter loading step also includes: The file descriptor is obtained by using the dlopen function to load the dynamic link library file based on the absolute path in the load command; Use the dlsym function to obtain the function descriptor in the dynamic link library file based on the file descriptor; The filter management component creates filter nodes based on function descriptors, filter names, and filter priorities, and adds the nodes to the filter management component.

3. The method for dynamic management of virtual machine filters according to claim 1, characterized in that, The initial adjustment step for the filter sequence also includes: The filter management component uses a TAILQ doubly linked list structure to organize filter nodes. The nodes of this doubly linked list are used to store the loaded filters and their corresponding priority information. The filter management component traverses the linked list nodes according to the filter priority, compares the priority of the filters represented by each node, and then reorganizes the filter nodes in the linked list according to the priority comparison results.

4. The method for dynamic management of virtual machine filters according to claim 1, characterized in that, The first determination step of the filter also includes: Determine if the filter to be loaded has already been loaded in the virtual machine. If not, first execute the version verification step, then execute the new filter loading step and the filter order initial adjustment step in sequence; if it has already been loaded, directly execute the filter order initial adjustment step. The version verification step specifically includes: The filter management component verifies whether the version information declared in the dynamic link library file is compatible with the current QEMU version. If compatible, it proceeds to the next step; if incompatible, it refuses to load and returns an error message.

5. The method for dynamic management of virtual machine filters according to claim 1, characterized in that, Following the I / O request processing step, the following is also included: The uninstallation command definition steps define the filter uninstallation command in the QEMU QAPI standardized interface; The second step of the filter judgment is as follows: when the virtual machine is running, the uninstallation command is executed and it is determined whether the filter to be uninstalled has been loaded. If it has not been loaded, no operation is performed; if it has been loaded, the filter uninstallation step is executed. The filter uninstallation process involves the filter management component removing and cleaning up the filter to be uninstalled when it is not in a running state. The filter order readjustment process involves the filter management component readjusting the running order of the remaining filters after uninstallation is complete.

6. A dynamic management system for virtual machine filters, characterized in that, The system includes: The filter management component configuration module is used to add filter management components to the QEMU source code, configure them, and compile them into the QEMU binary file. The loading command definition module is used to define the loading commands for filters in the QEMU QAPI standardized interface. The loading commands include the absolute path parameter of the dynamic link library file. The filter compilation module is used to compile the filters that need to be loaded into dynamic link library files; The first filter judgment module is used to determine whether the filter to be loaded has already been loaded in the virtual machine. If it has not been loaded, the new filter loading module is run first, and then the filter order initial adjustment module is run; if it has been loaded, the filter order initial adjustment module is run directly. The new filter loading module is used to set the priority of new filters and load dynamic link library files into the filter management component via loading commands; The filter order initial adjustment module is used by the filter management component to adjust the filter running order according to the filter priority; The I / O request processing module is used to process I / O requests by sequentially calling the filter callback functions of the filter when an I / O request is issued, and then sending the processing results to the backend block device.

7. The virtual machine filter dynamic management system according to claim 6, characterized in that, The loading command definition module also includes: Add a command unit to add a filter to the block device core json file in the QEMU QAPI standardized interface to load command code; The configuration parameter unit is used to configure the parameters of the loading command, including: filter name and filter priority; Meanwhile, the new filter loading module also includes: The file descriptor acquisition unit is used to load the dynamic link library file using the dlopen function based on the absolute path in the load command and obtain the file descriptor. The function descriptor acquisition unit is used to retrieve function descriptors in dynamic link library files based on file descriptors using the dlsym function. The node creation unit is used by the filter management component to create filter nodes based on function descriptors, filter names, and filter priorities, and then add the nodes to the filter management component.

8. The virtual machine filter dynamic management system according to claim 6, characterized in that, The filter sequence initial adjustment module further includes: The filter organization unit uses a TAILQ doubly linked list structure to organize filter nodes in the filter management component. The nodes of this doubly linked list are used to store the loaded filters and their corresponding priority information. The filter adjustment unit is used by the filter management component to traverse the linked list nodes according to the filter priority, compare the filter priority represented by each node, and then reorganize the filter nodes in the linked list according to the priority result of the comparison.

9. The virtual machine filter dynamic management system according to claim 6, characterized in that, Following the I / O request processing module, the following is also included: The uninstallation command definition module is used to define the uninstallation commands for filters in the QEMU QAPI standardized interface; The second filter judgment module is used to execute the uninstallation command and determine whether the filter to be uninstalled has been loaded when the virtual machine is running. If it has not been loaded, no operation is performed; if it has been loaded, the filter uninstallation module is run. The filter unloading module is used by the filter management component to remove and clean up filters that are to be unloaded when the filter is not running. The filter order reordering module is used by the filter management component to reorder the running order of the remaining filters after unloading is complete.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, The program is executed by the processor to implement a method for dynamic management of virtual machine filters as described in any one of claims 1 to 5.

Images