A virtual machine filter dynamic management method, system and storage medium

Abstract

The present application relates to a kind of virtual machine filter dynamic management method, system and storage medium.The method includes: filter management component configuration step, load command definition step, filter compilation step, filter first judgment step, new filter loading step, filter sequence adjustment step, I / O request processing step.The system includes: filter management component configuration module, load command definition module, filter compilation module, filter first judgment module, new filter loading module, filter sequence adjustment module, I / O request processing module.The present application is by adding filter management component in QEMU, the dynamic link library file of this component realizes that virtual machine runs dynamically loads filter and adjusts filter operation sequence according to priority, effectively solve the technical defects such as filter function extension difficulty, deployment process complex and execution sequence solidification.

Description

TECHNICAL FIELD

[0001] The present application belongs to the technical field of virtualization, and relates to a virtual machine filter dynamic management method, system and storage medium. BACKGROUND

[0002] In a virtualization environment, I / O operations are a key link affecting the overall system performance and security, and their management and control are particularly critical. To meet diverse data processing needs, a virtual machine can dynamically insert a programmable module with specific functions into an I / O path by loading a filter, thereby implementing processing operations such as data encryption, integrity verification, cache optimization, or access control during data reading and writing. The above filter needs to have efficient execution performance and flexible configuration capability to adapt to storage management needs in different application scenarios.

[0003] QEMU (Quick Emulator) is an open-source virtualization software, and its block device layer can form a block device chain by loading filter drivers to achieve diversified processing of virtual machine I / O data. Currently, QEMU can support filter functions such as traffic limiting, encryption, and replication, but the types of filters it supports are limited and the function extension is not flexible. In particular, when advanced filter functions such as continuous data protection and block layer agentless antivirus developed by third parties need to be introduced, developers must integrate their own filter code into the QEMU source tree and recompile the QEMU binary file. At the same time, users need to stop the operation of the virtual machine and recompile the QEMU emulator. This static compilation and integration of filter functions not only interrupts the production environment service, but also brings the risk of failed compilation and deployment to users.

[0004] In addition, QEMU supports the construction of a filter chain at the block device layer by loading multiple filters to meet the diverse needs of I / O data management, but the running order of these filters is statically determined at the time of QEMU startup and cannot be dynamically adjusted during the operation of the virtual machine. If the running order of the filters needs to be flexibly adjusted according to changes in system load or security policies during actual business operation, the only way to change the filter order is to shut down the virtual machine, modify the QEMU configuration, and restart. Such operations not only have a cumbersome process, but also cause service interruption, seriously affecting the continuity of business operation and the availability of the system.

[0005] Therefore, the management of the QEMU block device filter chain is highly static and rigid, and cannot be dynamically and uninterruptedly configured during the operation of the virtual machine. This greatly limits the convenient expansion and on-demand scheduling of advanced filtering functions, and brings unnecessary complexity and service interruption risks to the operation and maintenance of the production environment. The industry currently lacks effective dynamic management solutions for this core pain point.

[0006] To sum up, how to manage the virtual machine filter by using a method which is convenient for function expansion, simple for deployment and maintenance, and has adjustable running order is an urgent problem to be solved. SUMMARY

[0007] In order to solve the technical problems in the above background art, the present application provides a virtual machine filter dynamic management method, system and storage medium, and the technical solution is as follows:

[0008] In a first aspect, a virtual machine filter dynamic management method is provided, comprising the steps of:

[0009] The filter management component configuration step adds a filter management component in the QEMU source code, and configures and compiles it into the QEMU binary file;

[0010] The loading command definition step defines the loading command of the filter in the QAPI standardized interface of QEMU, and the loading command includes the absolute path parameter of the dynamic link library file;

[0011] The filter compiling step compiles the filter to be loaded into a dynamic link library file;

[0012] The filter first judgment step judges whether the filter to be loaded has been loaded in the virtual machine, if not, the new filter loading step is executed first, and then the filter order initial adjustment step is executed; if yes, the filter order initial adjustment step is directly executed;

[0013] The new filter loading step sets the priority of the new filter through the loading command and loads the dynamic link library file into the filter management component;

[0014] The filter order initial adjustment step adjusts the running order of the filter according to the priority of the filter by the filter management component;

[0015] The I / O request processing step, when there is an I / O request, the filter management component calls the callback function of the filter in sequence to process the I / O request and issues the processing result to the back-end block device.

[0016] In a second aspect, a virtual machine filter dynamic management system is also provided, and the system comprises:

[0017] The filter management component configuration module is used to add a filter management component in the QEMU source code, and configure and compile it into the QEMU binary file;

[0018] The loading command definition module is used to define the loading command of the filter in the QAPI standardized interface of QEMU, and the loading command includes the absolute path parameter of the dynamic link library file;

[0019] a filter compiling module, configured to compile the filter to be loaded into a dynamic link library file;

[0020] a filter first judging module, configured to judge whether the filter to be loaded has been loaded in the virtual machine, if not, run the new filter loading module first, and then run the filter sequence initial adjustment module, if yes, run the filter sequence initial adjustment module directly;

[0021] a new filter loading module, configured to set the priority of the new filter through a loading command and load the dynamic link library file into the filter management component;

[0022] a filter sequence initial adjustment module, configured to adjust the filter running sequence according to the priority of the filter by the filter management component;

[0023] an I / O request processing module, configured to, when there is an I / O request to be issued, the filter management component calls the callback function of the filter in sequence to process the I / O request and issues the processing result to the back-end block device.

[0024] In a third aspect, a computer readable storage medium is provided, and the computer readable storage medium stores a computer program, and the computer program is executed by a processor to implement the virtual machine filter dynamic management method.

[0025] The beneficial effects of the present application are as follows:

[0026] The present application provides a high-efficiency, safe and flexible virtual machine filter dynamic management method, by adding a filter management component in QEMU, the component dynamically loads the dynamic link library file of the filter when the virtual machine is running, according to the priority parameter transmitted when the dynamic link library file is loaded, the running sequence of the filter can be dynamically adjusted, effectively solving the technical defects of the prior art, such as difficult filter function expansion, complex deployment process and fixed running sequence. BRIEF DESCRIPTION OF DRAWINGS

[0027] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed in the embodiment description will be briefly introduced as follows, and obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor.

[0028] Figure 1 The figure is a virtual machine filter dynamic management method flowchart in the embodiment 1 of the present application.

[0029] Figure 2 The figure is a TAILQ bidirectional linked list structure in the embodiment 1 of the present application.

[0030] Figure 3 Filter management component structure diagram in embodiment 1 of the present application.

[0031] Figure 4 Virtual machine filter dynamic management method flow chart in embodiment 2 of the present application.

[0032] Figure 5 Virtual machine filter dynamic management method flow chart in embodiment 3 of the present application.

[0033] Figure 6 Virtual machine filter dynamic management system structure diagram in embodiment 4 of the present application.

[0034] Figure 7 Load command definition module structure diagram in embodiment 4 of the present application.

[0035] Figure 8 New filter load module structure diagram in embodiment 4 of the present application.

[0036] Figure 9 Filter order initial adjustment module structure diagram in embodiment 4 of the present application.

[0037] In the drawings, the components represented by each reference numeral are listed as follows:

[0038] Filter management component configuration module; 4002, load command definition module; 4003, filter compiling module; 4004, filter first judging module; 4005, version checking module; 4006, new filter load module; 4007, filter order initial adjustment module; 4008, I / O request processing module; 4009, unload command definition module; 4010, filter second judging module; 4011, filter unload module; 4012, filter order re-adjustment 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 DESCRIPTION

[0039] In order to make the objectives, technical solutions and advantages of the present application clearer, further detailed description will be given to the present application in combination with the drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application, and are not used to limit the present application.

[0040] Embodiment 1

[0041] The management of the QEMU block device filter chain is highly static and rigid, and cannot be dynamically and interrupt-free configured during the runtime of the virtual machine. This greatly limits the convenient expansion and on-demand scheduling of advanced filtering functions, and brings unnecessary complexity and service interruption risks to the operation and maintenance of production environments. The industry currently lacks effective dynamic management solutions for virtual machines to address this core pain point.

[0042] To solve the above problems, the embodiment of the present application provides a virtual machine filter dynamic management method, Figure 1 The virtual machine filter dynamic management method provided by the embodiment of the present application is shown in the flowchart Figure 1 The method comprises the following steps:

[0043] Step S101, a filter management component is added in the QEMU source code, and the filter management component is configured and compiled into the QEMU binary file.

[0044] It can be understood that the QEMU binary file refers to the core execution carrier of the QEMU virtualization platform, that is, the finally generated executable program. Under the prior art framework, any enhancement or modification of the core function of QEMU needs to integrate the added or modified source code into the QEMU source code tree, and generate a QEMU binary executable file containing new functions through the standard development process of reconfiguration (configure) and recompilation (make). The operation of adding the filter management component and compiling it into the QEMU binary file in step S101 of the embodiment follows this standard process and is a necessary technical means to realize the extension of the core function.

[0045] It is worth noting that the filter management component added in the embodiment is integrated and deployed in the block device layer of the QEMU architecture. The component plays a core hub role in the block device I / O processing path. Specifically, when the I / O request generated by the upper virtual device (Virtual Device) is issued to the block device layer for processing, the I / O data will be processed by the filter management component before reaching the backend block device (such as an image file or a physical device).

[0046] Step S102, a filter loading command is defined in the QAPI standardized interface of QEMU, and the loading command includes an absolute path parameter of a dynamic link library file.

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

[0048] It can also be understood that the absolute path parameter defined in the load command requires the caller to provide the complete and explicit path identification of the dynamic link library file corresponding to the target filter implementation in the host file system. The absolute path eliminates the ambiguity that may be caused by the relative path, accurately locates the unique target library file on the host, and avoids the risk of loading failure caused by changes in the working directory or differences in path resolution rules. In addition, this parameter is not coupled with the installation path or predefined directory structure of QEMU itself, allowing administrators to freely deploy filter libraries in any authorized location on the host file system (for example, a separate secure storage area or a specific project directory), greatly improving the flexibility of the deployment strategy. The filter management component will strictly access and load the specified library file according to this absolute path parameter when performing the load operation.

[0049] Preferably, the step S102 further comprises:

[0050] Step S1021, adding filter load command code in the block device core json file in the QAPI standardized interface of QEMU;

[0051] Step S1022, configuring parameters of the load command, wherein the parameters include: filter name and filter priority.

[0052] It is worth mentioning that the embodiment adds a dedicated block device filter loading command (named filter-load in the embodiment) in the standardized interface in the QAPI specification, which is provided to the outside through the QMP interface. The virtual machine management tool can trigger the dynamic loading operation of the filter by establishing a QMP connection to the target QEMU process, sending a JSON-RPC request conforming to the filter-load command specification. The command definition strictly follows the type system standard of QAPI, performs strong type checking on the input parameters (such as filter name and filter priority), and defines a standardized success response and possible error code and error information format. By abstracting and standardizing the filter loading operation as a QMP command, the embodiment provides a core and standardized remote procedure call (RPC) mechanism for implementing safe, controllable, and tool-independent runtime filter management, greatly improving the interoperability, reliability, and integration convenience of the management operation. For ease of understanding, an operation example is provided as follows:

[0053] An option -qmp stdio is added to the normal start command parameter of QEMU to enable the local standard input and output mode of QMP. After the virtual machine is normally started, the qmp instruction "execute": "qmp_capabilities" is sent, and the return result "{return": {}}" is returned. At this time, the virtual machine enters the command mode. If the filter needs to be loaded, the filter is compiled into a test_filter.so shared library file, and the command "{execute": "filter-load","arguments":{"filter-path": " / home / path / qemu / block / filter / test_filter.so","filter-name":"test_filter","order": "1"}" is executed. The filter-name is the filter name, and the order is the filter priority. Through the command, the filter can be flexibly loaded into QEMU without recompiling QEMU and stopping.

[0054] In step S103, the filter to be loaded is compiled into a dynamic link library file.

[0055] It can be understood that the QEMU virtualization platform is mainly deployed and run in the Linux operating system environment, and in a typical implementation scenario, the dynamic link library needs to be compiled into a shared library file (SharedObject) conforming to the Linux dynamic link standard (ELF), and the file name extension standard is.so.

[0056] Step S104, judging whether the filter to be loaded has been loaded in the virtual machine, if not, executing step S105 first, and then executing step S106; if yes, executing step S106 directly.

[0057] It is worth mentioning that during the running of the virtual machine, the loading or adjustment of multiple filters are involved, and the core of this step is to realize the dynamic and state-aware management of the filters during the running of the virtual machine. The accurate state detection effectively prevents the same filter instance from being loaded into the memory multiple times. The repeated loading not only causes the unnecessary consumption of the memory resources of the host system, but also can lead to the confusion of the internal state of the filter or the unexpected superimposed processing effect, thereby affecting the correctness of data processing.

[0058] Step S105, setting the priority of the new filter and loading the dynamic link library file into the filter management component through a loading command.

[0059] Preferably, while executing step S1021 and step S1022, the step S105 further comprises:

[0060] Step S1051, loading the dynamic link library file to obtain a file descriptor according to the absolute path in the loading command using the dlopen function;

[0061] Step S1052, obtaining a function descriptor in the dynamic link library file according to the file descriptor using the dlsym function;

[0062] Step S1053, the filter management component creates a node of the filter according to the function descriptor, the filter name and the filter priority, and adds the node to the filter management component.

[0063] It is worth mentioning that the dynamic link library file is a standard format for carrying dynamically loadable codes under the Linux system, so that the newly added filter management component in this embodiment can use the interfaces of the dynamic linker dlopen, dlsym, etc. of the Linux operating system to safely load and link the filter function implementation defined therein using the absolute path provided by the loading command during the running of the QEMU process. This compilation mode ensures the binary compatibility of the filter function module with the host Linux environment and the QEMU process.

[0064] Step S106, the filter management component adjusts the running order of the filters according to the priority of the filters.

[0065] Preferably, the step S106 further comprises:

[0066] Step S1061, the filter management component organizes the filter nodes with a TAILQ double-linked list structure, and the nodes of the double-linked list are used to store the loaded filters and their corresponding priority information;

[0067] Step S1062, the filter management component traverses the list nodes according to the priorities of the filters, compares the priorities of the filters represented by the nodes, and reorganizes the filter nodes in the list according to the comparison results.

[0068] It can also be understood that TAILQ (Tail Queue) is a high-efficiency double-linked list, and its structure is as shown in Figure 2 The structure is composed of a list head and a plurality of list nodes, the list head is located at the starting position of the entire TAILQ structure, the internal first head pointer and the last tail pointer point to the first node 1 and the last node n of the list respectively, each node has its corresponding value value, predecessor pointer prev and successor pointer next, for example, node 1 has corresponding value 1, predecessor pointer 1 and successor pointer 1; node 2 has corresponding value 2, predecessor pointer 2 and successor pointer 2; node 3 has corresponding value 3, predecessor pointer 3 and successor pointer 3; and node n has corresponding value n, predecessor pointer n and successor pointer n. At the same time, the predecessor pointer 1 of node 1 and the successor pointer n of node n point to the null address, and from the list head, node 1, node 2, node 3 and node n are connected in turn, and these nodes are arranged in order, thereby forming a complete double-linked list. Compared with the ordinary single-linked list or the ordinary double-linked list without the list head, TAILQ naturally supports high-efficiency double traversal, and direct pointers are maintained at the head and tail of the node, and this design makes TAILQ achieve constant time complexity O(1) when performing head / tail insertion and deletion operations, and only needs O(1) when inserting / deleting nodes before / after any known node. These characteristics are particularly suitable for the scene in which dynamic insertion, deletion and sequential rearrangement of nodes are frequently required in the embodiment.

[0069] It is worth noting that the embodiment introduces the TAILQ structure in the filter management component and reorganizes the list based on the priority, and the core purpose is to realize real-time, lossless and efficient dynamic adjustment of the running order of the filter chain of the virtual machine. By managing each filter node (including its priority attribute) as a node of TAILQ, the component can efficiently traverse the list, compare the priority values of the nodes, and reposition the nodes to the correct positions in the list according to the priority corresponding to the priority according to the new priority set by the administrator through the QMP command. This mechanism enables the administrator to flexibly and dynamically optimize the I / O processing pipeline according to real-time load or policy requirements, greatly improving the adaptability and usability of the system.

[0070] Step S107, when there is an I / O request, the filter management component sequentially calls the callback function of the filter to process the I / O request and issues the processing result to the backend block device.

[0071] It is worth noting that when the I / O request generated by the virtual device reaches the block device layer, the filter management component sequentially calls the callback function registered by each node according to the filter node order it maintains, and each filter sequentially processes the I / O data according to its specific processing (such as encryption, flow limiting, etc.), and the processing result is passed by the management component level by level. Finally, the I / O request processed by all filters is issued to the backend block device, completing the entire I / O processing flow and ensuring the sequential and reliable execution of the filter function.

[0072] In order to more clearly illustrate the implementation and organization structure of the method of the embodiment, the following will be described in detail in combination with Figure 3 As shown in Figure 3 , the filter management component is responsible for managing and controlling the loading and order adjustment of the filters, and contains the filter chain and loading command that need to be managed. The filter chain is composed 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 the dynamic link library file 3 and the filter 3 shown by the dashed box in the figure, the filter management component loads the dynamic link library file 3 from the specified path by receiving the externally issued filter loading command, and inserts the corresponding filter 3 into the specified position in the filter chain. When an I / O request arrives, the filter management component will sequentially call the callback function of each filter to process the data according to the order in the filter chain, and finally pass the processing result to the backend block device to complete the actual data read / write operation. Through the above architecture design, the loading and running order adjustment of the filter can be completed in real time during the running of the virtual machine, which can effectively improve the convenience of functional expansion.

[0073] The embodiment provides a kind of efficient, safe and convenient virtual machine filter dynamic management method, by adding filter management component in QEMU, this component loads the dynamic link library file of filter dynamically when virtual machine runs, according to the priority parameter passed in when loading dynamic link library file, can dynamically adjust the running order of filter, effectively solve the technical defects, such as filter function expansion difficulty, deployment process complex and running order solidification in prior art.

[0074] Embodiment 2

[0075] As shown in Figure 4 , a virtual machine filter dynamic management method is provided, which comprises the following steps:

[0076] Step S201, a filter management component is added in the QEMU source code, and is configured and compiled into the QEMU binary file;

[0077] Step S202, a filter loading command is defined in the QAPI standardized interface of QEMU, and the loading command includes an absolute path parameter of a dynamic link library file;

[0078] Step S203, a filter to be loaded is compiled into a dynamic link library file;

[0079] Step S204, it is judged whether the filter to be loaded has been loaded in the virtual machine, if not, step S205 is executed first, and then steps S206 and S207 are executed in sequence; if yes, step S207 is directly executed;

[0080] Step S205, the filter management component checks whether the version information declared in the dynamic link library file is compatible with the current QEMU version, if yes, step S206 is continued to execute; if not, the loading is rejected and an error information is returned;

[0081] Step S206, the new filter priority is set through the loading command, and the dynamic link library file is loaded into the filter management component;

[0082] Step S207, the filter management component adjusts the filter running order according to the filter priority;

[0083] Step S208, when an I / O request is issued, the filter management component sequentially calls the callback function of the filter to process the I / O request and issues the processing result to the back-end block device.

[0084] It is worth mentioning that the function interfaces provided by different versions of QEMU may be different, if the dynamic link library file without version checking is directly loaded, it may cause interface calling mismatch, function pointer error or even QEMU process crash. Therefore, the compatibility check of the version information declared in the dynamic link library and the current QEMU version before loading the filter is a key step to ensure the system stability and function correctness. Specifically, before the filter management component calls the dlopen interface to load the dynamic link library, the pre-defined version information field in the library is first read and parsed, and is compared with the interface version declared in the current QEMU running environment, to judge whether the filter is adapted to the current QEMU version.

[0085] Different from the above embodiment, the embodiment adds filter version checking before loading a new filter, effectively avoiding compatibility problems caused by function interface differences between different versions of QEMU, and preventing QEMU process crashes caused by calling mismatched function signatures or accessing illegal memory addresses.

[0086] Embodiment 3

[0087] As shown in Figure 5 A virtual machine filter dynamic management method is provided, and the method comprises the following steps:

[0088] Step S301, a filter management component is added in QEMU source code, and the filter management component is configured and compiled into a QEMU binary file;

[0089] Step S302, a filter loading command is defined in a QAPI standardized interface of QEMU, and the loading command comprises an absolute path parameter of a dynamic link library file;

[0090] Step S303, a filter to be loaded is compiled into a dynamic link library file;

[0091] Step S304, it is judged whether the filter to be loaded has been loaded in a virtual machine, if not, step S305 is performed, and then step S306 is performed; if yes, step S306 is directly performed;

[0092] Step S305, a new filter priority is set by the loading command, and the dynamic link library file is loaded into the filter management component;

[0093] Step S306, the filter management component adjusts a filter running order according to the filter priority;

[0094] Step S307, when an I / O request is issued, the filter management component sequentially calls a callback function of the filter to process the I / O request and issues a processing result to a back-end block device;

[0095] Step S308, a filter unloading command is defined in the QAPI standardized interface of QEMU;

[0096] Step S309, when a virtual machine is running, the unloading command is executed, and it is judged whether a filter to be unloaded has been loaded, if not, no operation is performed; if yes, step S310 is performed;

[0097] Step S310, when the filter is in a non-running state, the filter management component removes the filter to be unloaded and cleans up;

[0098] Step S311, after the unloading is completed, the filter management component re-adjusts a running order of remaining filters.

[0099] It is worth mentioning that the unloading command of the filter is defined in the QAPI standardized interface of QEMU, and the parameter of the unloading command includes the filter name. The filter name is unique during the entire running process of the virtual machine, and when the virtual machine executes the unloading command, it is judged whether the filter is loaded according to the filter name.

[0100] It is also worth mentioning that when the virtual machine is running, if it is necessary to stop a filter in the filter chain, the traditional method can usually only be realized by shutting down the virtual machine and restarting QEMU, which causes business interruption and affects system availability. Before unloading, the system of the embodiment judges whether the target filter is processing an I / O request, so as to avoid data loss or pointer exception caused by forced unloading during data processing; after unloading, the filter management component also automatically adjusts the running order of the remaining filters to prevent logical disorder or function failure caused by missing filters.

[0101] Unlike the above embodiment, the embodiment adds a filter unloading process, which can unload filters that do not need to be executed according to the running state of the virtual machine, thereby reducing the system burden and greatly improving the flexibility and controllability of QEMU in managing filters.

[0102] Embodiment 4

[0103] The embodiment provides a virtual machine filter dynamic management system, as shown in Figure 6 The system comprises:

[0104] The filter management component configuration module 4001 is configured to add a filter management component in the QEMU source code, and configure and compile the filter management component into the QEMU binary file;

[0105] The loading command definition module 4002 is configured to define a loading command of the filter in the QAPI standardized interface of QEMU, and the loading command includes an absolute path parameter of a dynamic link library file;

[0106] The filter compiling module 4003 is configured to compile the filter to be loaded into a dynamic link library file;

[0107] The filter first judging module 4004 is configured to judge whether the filter to be loaded has been loaded in the virtual machine, if not, first run the version checking module 4005, and then run the new filter loading module 4006 and the filter order initial adjustment module 4007 in sequence; if yes, directly run the filter order initial adjustment module 4007;

[0108] The version checking module 4005 is configured to check whether the version information declared in the dynamic link library file is compatible with the current QEMU version by the filter management component, if compatible, the new filter loading module 4006 is continued to run, if incompatible, the loading is rejected and error information is returned;

[0109] The new filter loading module 4006 is configured to set the priority of the new filter by a loading command and load the dynamic link library file into the filter management component;

[0110] The filter sequence initial adjustment module 4007 is configured to adjust the filter running sequence according to the priority of the filter by the filter management component;

[0111] The I / O request processing module 4008 is configured to call the callback function of the filter in sequence to process the I / O request and issue the processing result to the back-end block device when there is an I / O request issued by the filter management component;

[0112] The uninstall command defining module 4009 is configured to define the uninstall command of the filter in the QAPI standardized interface of QEMU;

[0113] The filter second judging module 4010 is configured to execute the uninstall command and judge whether the filter to be uninstalled has been loaded when the virtual machine is running, if not loaded, no operation is performed, if loaded, the filter uninstalling module 4011 is run;

[0114] The filter uninstalling module 4011 is configured to remove and clean the filter to be uninstalled by the filter management component when the filter is in a non-running state;

[0115] The filter sequence re-adjustment module 4012 is configured to re-adjust the running sequence of the remaining filters by the filter management component after the uninstallation is completed.

[0116] Preferably, as shown in the loading command defining module 4002, further comprising: Figure 7 The adding command unit 40021 is configured to add the filter loading command code in the block device core json file in the QAPI standardized interface of QEMU;

[0117] The configuration parameter unit 40022 is configured to configure the parameters of the loading command, wherein the parameters include the filter name and the filter priority;

[0118] Meanwhile, as shown in the new filter loading module 4006, further comprising:

[0119] Figure 8

[0120] ​​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.

[0121] Function descriptor acquisition unit 40062 is used to obtain function descriptors in dynamic link library files based on file descriptors using the dlsym function;

[0122] 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.

[0123] Preferred, such as Figure 9 As shown, the filter sequence initial adjustment module 4007 also includes:

[0124] 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.

[0125] 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.

[0126] 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.

[0127] Example 5

[0128] 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.

[0129] The computer storage medium of the embodiments of the present application can adopt 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. The computer readable storage medium includes, but is not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or apparatus, or any combination thereof. More specific examples (non-exhaustive list) of the computer readable storage medium include: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In this document, the computer readable storage medium can be any tangible medium that contains or stores a program that can be used by or in connection with an instruction execution system, device or apparatus.

[0130] The present application can be written in one or more programming languages or combinations of languages including object-oriented languages such as Java, Smalltalk, C++, Ruby, Go, and conventional procedural programming languages such as the "C" language or similar programming languages. The program code can execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection can be made to an external computer (for example, through the Internet using an Internet Service Provider).

[0131] The above-described embodiments only express several embodiments of the present application, which are described in a more specific and detailed manner, but should not be understood as limiting the scope of the patent of the present application. It should be noted that for those skilled in the art, several modifications and improvements can be made without departing from the concept of the present application, which are all within the scope of protection of the present application. Therefore, the scope of protection of the patent of the present application should be subject to the appended claims.

Claims

1. A method for dynamic management of virtual machine filters, characterized in that, The method comprises the steps of: Filter management component configuration step, adding a filter management component in QEMU source code and configuring and compiling it into QEMU binary file; Load command definition step, defining the load command of the filter in the QAPI standardized interface of QEMU, the load command including the absolute path parameter of the dynamic link library file; Filter compiling step, compiling the filter to be loaded into a dynamic link library file; Filter first judgment step, judging whether the filter to be loaded has been loaded in the virtual machine, if not, executing the new filter loading step first, and then executing the filter order initial adjustment step; if yes, directly executing the filter order initial adjustment step; New filter loading step, setting the priority of the new filter through the load command and loading the dynamic link library file into the filter management component; Filter order initial adjustment step, the filter management component adjusting the filter running order according to the priority of the filter; I / O request processing step, when there is an I / O request, the filter management component calling the callback function of the filter in sequence to process the I / O request and delivering the processing result to the back-end block device; The load command definition step further comprises: adding the filter load command code in the block device core json file in the QAPI standardized interface of QEMU; configuring the parameters of the load command, wherein the parameters include the filter name and the filter priority; Meanwhile, the new filter loading step further comprises: loading the dynamic link library file according to the absolute path in the load command to obtain the file descriptor by using the dlopen function; obtaining the function descriptor in the dynamic link library file by using the dlsym function according to the file descriptor; the filter management component creating the node of the filter according to the function descriptor, the filter name and the filter priority, and adding the node into the filter management component.

2. The method of claim 1, wherein, The filter order initial adjustment step further comprises: the filter management component organizing the filter nodes in a TAILQ bidirectional linked list structure, and the nodes of the bidirectional linked list are used for storing the loaded filters and the corresponding priority information of the filters; the filter management component traversing the linked list nodes according to the priority of the filters, comparing the priority of the filters represented by the nodes, and reorganizing the filter nodes in the linked list according to the comparison result.

3. The method of claim 1, wherein, In the filter first judgment step, further comprising: judging whether the filter to be loaded has been loaded in the virtual machine, if not, executing the version checking step first, and then executing the new filter loading step and the filter order initial adjustment step in sequence; if yes, directly executing the filter order initial adjustment step; The version checking step specifically comprises: the filter management component checking whether the version information declared in the dynamic link library file is compatible with the current QEMU version, if yes, executing the next step; if not, refusing to load and returning an error message.

4. The method of claim 1, wherein, After the I / O request processing step, further comprising: uninstall command definition step, defining the uninstall command of the filter in the QAPI standardized interface of QEMU; The filter second judging step is to execute the uninstall command and judge whether the filter to be uninstalled has been loaded when the virtual machine is running, if not, no operation is performed, and if yes, the filter uninstalling step is executed; The filter uninstalling step is to remove the filter to be uninstalled and clean up when the filter is in a non-running state by the filter management component; The filter sequence readjusting step is to readjust the running sequence of the remaining filters by the filter management component after the uninstalling is completed.

5. A virtual machine filter dynamic management system, characterized by, The system comprises: The filter management component configuration module is used to add the filter management component in the QEMU source code and configure and compile it into the QEMU binary file; The loading command definition module is used to define the loading command of the filter in the QAPI standardized interface of the QEMU, and the loading command comprises an absolute path parameter of the dynamic link library file; The filter compiling module is used to compile the filter to be loaded into the dynamic link library file; The filter first judging module is used to judge whether the filter to be loaded has been loaded in the virtual machine, if not, the new filter loading module is run first, and then the filter sequence initial adjusting module is run, and if yes, the filter sequence initial adjusting module is directly run; The new filter loading module is used to set the priority of the new filter by the loading command and load the dynamic link library file into the filter management component; The filter sequence initial adjusting module is used to adjust the filter running sequence by the filter management component according to the priority of the filter; The I / O request processing module is used to call the callback function of the filter in sequence by the filter management component to process the I / O request and issue the processing result to the back-end block device when the I / O request is issued; The loading command definition module further comprises: The adding command unit is used to add the filter loading command code in the block device core json file in the QAPI standardized interface of the QEMU; The configuration parameter unit is used to configure the parameters of the loading command, wherein the parameters comprise the filter name and the filter priority; Meanwhile, the new filter loading module further comprises: The file descriptor obtaining unit is used to load the dynamic link library file by the dlopen function according to the absolute path in the loading command to obtain the file descriptor; The function descriptor obtaining unit is used to obtain the function descriptor in the dynamic link library file by the dlsym function according to the file descriptor; The node creating unit is used to create the node of the filter by the filter management component according to the function descriptor, the filter name and the filter priority, and add the node into the filter management component.

6. The system of claim 5, wherein, The filter sequence initial adjusting module further comprises: The filter organizing unit is used to organize the filter node by the filter management component in the TAILQ bidirectional link list structure, and the node of the bidirectional link list is used to store the loaded filter and the corresponding priority information of the filter; The filter adjusting unit is used to traverse the link list node by the filter management component according to the priority of the filter, compare the priority of the filter represented by each node, and reorganize the filter node in the link list according to the priority result after the comparison.

7. The system of claim 5, wherein the virtual machine filter dynamic management system further comprises: After the I / O request processing module, further comprises: The unloading command definition module is configured to define the unloading command of the filter in a QEMU QAPI standardized interface. The filter second judgment module is configured to execute the unloading command when the virtual machine is running, and judge whether the filter to be unloaded has been loaded. If not, no operation is performed. If yes, the filter unloading module is run. The filter unloading module is configured to remove and clean the filter to be unloaded by the filter management component when the filter is in a non-running state. The filter sequence readjustment module is configured to readjust the running sequence of the remaining filters by the filter management component after the unloading is completed.

8. A computer-readable storage medium having stored thereon a computer program, characterized in that, The program is executed by the processor to implement the virtual machine filter dynamic management method according to any one of claims 1 to 4.

Images