A method for improving read-write performance of a virtual machine image file

Abstract

The application provides a method for improving the read-write performance of a virtual machine image file, and belongs to the technical field of virtual machines, and comprises the following steps: S1: kernel module loading and initialization, loading a loadable kernel module QCOW2 driver for realizing QCOW2 analysis function; S2: QCOW2 image file metadata analysis, opening a specified QCOW2 image file, and analyzing the header structure and metadata of the QCOW2 image file; S3: device mapping framework device creation, creating a new virtual block device through a device mapping framework interface and associating the new virtual block device with the QCOW2 image file analyzed in step S2; and S4: input / output request processing. The method of the application avoids the context switching between the user state and the kernel state and the network block device protocol overhead.

Description

Technical Field

[0001] This invention relates to virtual machine image file reading and writing, and more particularly to a method for improving the performance of virtual machine image file reading and writing, belonging to the field of virtual machine technology. Background Technology

[0002] Virtualization technology has been widely used in data centers and cloud computing environments to improve resource flexibility and utilization. In virtualization environments, QCOW2, as a storage format for virtual machine disk images, supports sparse files, compressibility, and snapshots, and is widely used in QEMU virtual machine system images.

[0003] Currently, the mainstream technology for accessing QCOW2 image content within the host operating system relies on the collaborative work of user-space processes and kernel modules. Specifically, it commonly employs the qemu-nbd (Network Block Device) tool provided by the QEMU project. Figure 1 As shown, this scheme opens and parses the QCOW2 image file through a daemon process (qemu-nbd) running in user space. Then, it uses the Network Block Device (NBD) protocol to export the image content via a virtual network socket pair. Finally, the NBD client module in the kernel maps it to a standard block device (such as / dev / nbd0) for system use.

[0004] Although the architecture implements basic functionality, its inherent design patterns lead to several serious flaws and shortcomings: 1) Significant performance bottlenecks, including high input / output latency and low throughput. Every input / output request must go through the complete path of "kernel mode → user mode → kernel mode". This process involves multiple expensive context switches, and the processor cycle overhead directly leads to a significant increase in the response time (latency) of input / output operations, making it difficult to meet the needs of latency-sensitive application scenarios (such as high-performance databases and real-time systems).

[0005] The NBD protocol itself is designed for use in real network environments. When it is used for internal local communication, the encapsulation, decapsulation, and verification processes of the protocol introduce unnecessary computational overhead, consuming valuable processor resources and thus limiting the overall input / output throughput.

[0006] When transferring data between user-space processes and kernel space, memory copying is typically required, rather than zero-copy transfer. This multiple data copying not only consumes memory bandwidth but also further increases input / output latency.

[0007] 2) Low system resource utilization and poor scalability As a standalone user-space process, qemu-nbd itself requires a significant amount of memory and processor resources. When multiple virtual machines or containers need to run simultaneously on the host machine, i.e., when multiple QCOW2 images need to be mapped, multiple qemu-nbd process instances must be started, resulting in a large consumption of system resources (especially process descriptors, memory, and processor time slices), severely limiting scalability.

[0008] The user-space qemu-nbd process and the kernel page cache each maintain potentially overlapping data caches, resulting in a waste of memory resources and an inability to achieve unified and efficient memory usage.

[0009] 3) Weak integration with the kernel storage stack, unable to utilize advanced kernel features. Because it relies on user-space processes, its stability, monitoring, and management are more complex. Abnormal process termination can cause block devices to suddenly become unavailable, and performance monitoring and debugging require attention to both user processes and kernel modules, resulting in high operational complexity.

[0010] 4) Limited functionality support and low efficiency in implementing advanced features. Although the QCOW2 format itself supports advanced features such as snapshots, copy-on-write, and compression, in the qemu-nbd architecture, the processing of these features is entirely performed in user space. This approach is inefficient, especially in scenarios requiring frequent metadata operations, such as snapshot chain queries and real-time compression, where the performance penalty is particularly noticeable.

[0011] In summary, the architecture of current mainstream technologies (taking qemu-nbd as an example) can be described as a hybrid model of "user space resolution + kernel network block device relay". Its core is to use the NBD protocol as a bridge to split the block device emulation task, which should have been completed directly by the kernel, into a collaborative process between user space and kernel space. This architecture achieved rapid functional implementation in the early stages of technological development, but with the rapid increase in storage performance, density, and efficiency requirements in the era of cloud computing and big data, its architectural bottlenecks and shortcomings have become increasingly prominent, and it can no longer meet the needs of modern data centers for high-performance virtualized storage.

[0012] In view of the above situation, it is imperative to implement a technical solution that can directly and efficiently parse and provide QCOW2 image access capabilities at the kernel level to overcome the inherent defects of existing user-space solutions. Summary of the Invention

[0013] To address the aforementioned problems, this invention provides a method for improving the read and write performance of virtual machine image files, thereby enhancing I / O performance and reducing resource consumption.

[0014] To achieve the above objectives, the technical solution of the present invention is as follows: a method for improving the read and write performance of virtual machine image files, comprising the following steps: S1: Kernel module loading and initialization Load the loadable kernel module QCOW2 driver that implements QCOW2 resolution functionality. The QCOW2 driver registers a custom target device type with the Linux kernel's device mapping framework. S2:QCOW2 image file metadata parsing In response to the command to create a device mapping framework device, the QCOW2 driver opens the specified QCOW2 image file and parses the header structure and metadata of the QCOW2 image file, including parsing the cluster size and virtual disk size; S3: Device Mapping Framework Device Creation Based on the parsed virtual disk size, a new virtual block device is created through the device mapping framework interface, which is associated with the QCOW2 image file parsed in step S2; S4: Input / Output Request Processing When an application or file system initiates an I / O request to the virtual block device, the device mapping framework routes the request to the processing function registered by the QCOW2 driver for processing.

[0015] Furthermore, the target device type mentioned in step S1 is a virtual block device.

[0016] Furthermore, the metadata mentioned in step S2 includes at least the cluster size and first-level table information.

[0017] Furthermore, step S2 involves parsing the header structure and metadata of the QCOW2 image file, including the following: Read and verify the QCOW2 magic number and version number; Analyze cluster size and virtual disk size; Load the offset and size of the first-level table, and read the contents of the first-level table into kernel memory; Initialize the L2 table caching mechanism.

[0018] Furthermore, the processing function in step S4 performs the following operations: S4.1: Request parsing: Extract the logical block address and length of the I / O request.

[0019] S4.2: Address Translation: Using the parsed QCOW2 image file metadata and the loaded QCOW2 metadata, the requested logical block address is translated into a physical offset within the QCOW2 image file; S4.3: Request execution: For read requests: Based on the converted physical offset, data is read directly from the QCOW2 image file and returned to the upper-layer requester through the device mapping framework.

[0020] For write requests: Based on QCOW2's copy-on-write semantics, allocate a new data cluster if necessary, update the corresponding L2 table entries, and then write the data to the newly allocated cluster.

[0021] Furthermore, the address translation in step S4.2 includes the following steps: Calculate the corresponding cluster index based on the logical block address; Use the cluster index to look up the first-level table and obtain the offset of the second-level table; The secondary table is loaded according to the offset of the secondary table, and the physical address of the data cluster is found. The final physical offset is obtained by combining the offset within the cluster.

[0022] Furthermore, the processing of write requests in step S4.3 follows copy-on-write semantics, including the following: Determine whether the target data cluster is a shared cluster; If it is a shared cluster, then a new data cluster will be allocated; Update the corresponding second-level table entry to point to the newly allocated data cluster.

[0023] The QCOW2 driver also implements the following functions: Snapshot management: Supports the creation and rollback to snapshots by maintaining different metadata views; Cache management: Implement L2 table and data cluster caching mechanisms in the kernel to reduce the number of times metadata accesses to the image file are performed; Compression / Encryption: Integrated kernel compression / decryption algorithms that support transparent processing of compression or encryption clusters.

[0024] The beneficial effects of the method for improving virtual machine image file read / write performance according to the present invention are as follows: Compared with existing technologies, this invention loads a dedicated driver module in kernel space to directly parse the metadata of the QCOW2 image file and uses a device mapping framework to create virtual block devices. When processing I / O requests, the QCOW2 driver converts the logical block address into a physical offset within the QCOW2 file and directly performs file operations, avoiding context switching between user mode and kernel mode and the overhead of network block device protocols.

[0025] This invention significantly improves I / O performance, reduces resource consumption, and achieves deep integration with the kernel storage stack, effectively solving the performance bottleneck problem of existing user space solutions. Attached Figure Description

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

[0027] Figure 1 It is the existing technology based on the QCOW2 image file usage process architecture of qemu-nbd; Figure 2 This is a system architecture block diagram of the method of the present invention; Figure 3 This is a sequence diagram of the I / O request processing of the present invention; Figure 4 This is a flowchart of the QCOW2 address translation process of the present invention; Figure 5 This is a schematic diagram of the address translation steps of the present invention; Figure 6 This is a schematic diagram of the write request step in an embodiment of the present invention. Detailed Implementation

[0028] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Many specific details are set forth in the following description to provide a thorough understanding of the present invention. However, the present invention may also be implemented in other ways different from those described herein. Those skilled in the art can make similar extensions without departing from the spirit of the present invention. Therefore, the present invention is not limited to the specific embodiments disclosed below.

[0029] Definitions of abbreviations and key terms: Virtual disk files: Virtual disk files are a storage method that uses files to simulate hard disk devices for use by virtual machines. From the host machine's perspective, the virtual machine's disk is just a file, and from the guest machine's perspective, it is no different from a regular hard disk.

[0030] QCOW2 format: Short for QEMU copy-on-write format, this is a virtual disk image format where the QEMU virtual machine dynamically grows the virtual disk image only when a "write" operation occurs. Compared to the native image format (RAW), its biggest feature is that it only allocates space when data is needed, thus saving disk space on the host machine. The QCOW2 image format is composed of multiple fixed-size units called clusters. Both actual user data (guest data) and image metadata are stored within a single cluster unit.

[0031] QEMU, short for Quick Emulator, is a powerful, open-source virtual machine manager. Combined with the KVM module in the Linux kernel, it enables hardware virtualization support. Currently, Linux platforms typically use QEMU+KVM to provide virtualization services: KVM handles CPU and memory virtualization, while QEMU handles device emulation, including emulating BIOS, PCI / PCIe buses, disks, network cards, graphics cards, sound cards, keyboards, mice, etc.

[0032] Device Mapper (DM): A framework mechanism for mapping logical devices to physical devices, providing a highly modular kernel architecture for implementing device drivers used for storage resource management. It consists of two parts: the kernel-space device mapper driver, the user-space device mapper library, and the dmsetup tool it provides.

[0033] NBD (Network Block Device): A network block device that is accessed via a network, or a device image.

[0034] QEMU-NBD: Generally refers to the implementation using Linux's NBD (Network Block Device) and QEMU's QEMU-NBD as the backend server.

[0035] Host machine: The host machine is a dedicated physical server with a virtualization environment deployed. One server can virtualize multiple virtual machines for users to use, and virtualization technology is used to realize the sharing of server hardware among multiple virtual machines.

[0036] This invention provides a method for improving the read / write performance of virtual machine image files. The basic idea is to implement an architectural innovation, abandoning the path of relaying through user-space processes and the NBD protocol, and instead directly embedding the QCOW2 format parsing capability into the operating system kernel. By developing a dedicated target driver for the device mapping framework in the Linux kernel, the conversion from logical block addresses to QCOW2 file physical offsets and input / output scheduling can be directly completed within kernel space.

[0037] This invention enables QCOW2 image files to be presented to upper-layer systems as a standard, pure kernel-level block device, thereby completely eliminating the boundary overhead between user space and kernel space, data copying, and redundant protocol processing. It achieves deep and seamless integration with the kernel storage stack, ultimately achieving high performance, low overhead, and strong integration.

[0038] Example 1

[0039] Combination Figures 2-4 This invention introduces a method for improving the read and write performance of virtual machine image files. The system framework on which this method is implemented is as follows: Figure 2 As shown, it includes the user-level dm management tool dmsetup and application, as well as the kernel-level device mapping framework device mapper, QCOW2 driver, QCOW2 image file, VFS virtual file system, page cache / bio, and physical disk; the method of this invention includes the following key points: 1) Using the device mapping framework device mapper, QCOW2 image files are mapped to block devices, which can be used by upper-layer applications without any modifications.

[0040] 2) Shorten the file I / O path. Existing technologies use user-space tools such as qemu-nbd to process QCOW2 image files, and the path includes "application -> kernel block device -> network protocol -> user process -> file system -> hard disk". However, the path of this invention is "application -> kernel block device -> (dm-qcow2 driver + file system) -> hard disk", which shrinks the complex I / O process to the kernel space and eliminates the switching between user mode and kernel mode and protocol overhead.

[0041] 3) Efficient address translation: This invention realizes the precise process of converting "virtual disk sector number" into "QCOW2 file offset". By introducing a high-performance caching mechanism, the frequently accessed L2 table is cached in kernel memory, avoiding reading the image file for every I / O, which greatly reduces metadata access latency.

[0042] in, Figure 2 DM is a mapping framework in the kernel that allows the creation of virtual block devices, typically located in the ` / dev / mapper / ` directory, such as ` / dev / mapper / my-volumne`. A corresponding device node also exists in ` / dev / dm-X`. Its main workflow is as follows: (1) When user space initiates an I / O request to a DM target device (such as / dev / mapper / my-volume), the request is first intercepted by the DM layer; (2) DM queries its internal mapping table based on the requested sector number and finds the corresponding mapping entry; (3) Based on the mapping type specified in the entry, DM will call the corresponding target driver to handle this I / O request; (4) The target driver executes its specific logic (such as redirecting sectors, encrypting data, writing to multiple devices, etc.) and sends the final sub-I / O request to one or more actual back-end physical devices.

[0043] Figure 2 dmsetup is a set of tools in dm used to create and manage virtual block devices.

[0044] Figure 2 The term "index update" refers to the fact that the relevant I / O operations on the virtual block device will ultimately be completed by the address translation mechanism in this invention for reading and writing the qcow2 virtual image file.

[0045] Figure 3 In Linux, the block device layer, also known as the block I / O layer, is a subsystem within the Linux kernel responsible for managing block devices (such as hard drives, SSDs, NVMe drives, and USB storage devices). Its main task is to provide a unified, abstract, and efficient interface for upper layers (file systems, virtual memory systems, etc.) to access these storage devices, while handling all the complex details related to block devices, such as I / O scheduling, request merging, performance optimization, and device management.

[0046] Figure 3 The "map" in this context refers to the mapping mechanism of DM.

[0047] Figure 3 The qcow2 mapping is the core of the entire invention, that is, the module implemented in the kernel, which includes mapping the qcow2 virtual machine image file into a virtual block device via dm and address translation.

[0048] Example 2

[0049] Based on Example 1, further combining Figures 2-6 The method of the present invention will be described in detail, and the method includes the following steps: S1: Kernel module loading and initialization Load the loadable kernel module that implements QCOW2 parsing functionality - the QCOW2 driver. This module registers a custom target device type - a virtual block device - with the Linux kernel's device mapping framework (this virtual block device is a driver device based on the device mapping framework that is used to map and parse qcow2 virtual disk image files).

[0050] S2:QCOW2 image file metadata parsing In response to the command to create a device mapping framework device, the kernel module (QCOW2 driver) opens the specified QCOW2 image file and parses its header structure and metadata (the metadata includes at least the cluster size and first-level table information), including but not limited to: Read and verify the QCOW2 magic number and version number; Analyze cluster size and virtual disk size; Load the offset and size of the L1 table, and read the contents of the L1 table into kernel memory; Initialize the L2 table caching mechanism.

[0051] The cluster size is not fixed; it is specified when the qcow2 image file is created, and is generally 64K by default, which cannot be changed after creation. Since a sector is typically 512 bytes, a cluster contains 64K bytes. 1024 / 512=128 sectors.

[0052] S3: Device Mapping Framework Device Creation Based on the parsed virtual disk size, a new virtual block device is created through the device mapping framework interface (this virtual block device is based on the driver device created in step S1 and the block storage device parsed and mapped in step S2), and this device is associated with the QCOW2 image file parsed in step S2.

[0053] S4: Input / Output Request Processing When an application or file system initiates an I / O request to the virtual block device (i.e., the new virtual block device created in step S3), the device mapping framework routes the request to the processing function registered by the kernel module. This processing function performs the following operations: S4.1: Request parsing: Extract the logical block address and length of the I / O request.

[0054] S4.2: Address Translation: Using the parsed QCOW2 image file metadata and the loaded QCOW2 metadata (L1 table, L2 table), the requested logical block address is translated into a physical offset within the QCOW2 image file. This process includes: Calculate the corresponding cluster index based on the logical block address; Use the cluster index to look up the first-level table and obtain the offset of the second-level table; The secondary table is loaded according to the offset of the secondary table, and the physical address of the data cluster is found. The final physical offset is obtained by combining the offset within the cluster.

[0055] The above process combined Figure 4 and Figure 5 Examples are given below: The user needs to read sector number 30000, and the cluster size is 64 KB (65536 bytes); Step 1: Calculate the virtual offset: Virtual offset = 30000 512 = 15,360,000 bytes; Step 2: Calculate the cluster index (find which "page"): Cluster index = 15,360,000 / 65,536 = 234 (division, rounding); Step 3: Calculate the intra-cluster offset (find its location within the "page"): Intra-cluster offset = 15,360,000 % 65,536 = 24,576 (modulo / remainder); In this step, the % sign is the calculation symbol, which ensures that the final result will not overflow, and is an algorithm to prevent overflow; Interpretation of the results: The data is located in cluster number 234; within this cluster, starting from the beginning of the cluster, 24,576 bytes further on is the starting point of the data we want to read / write.

[0056] Ultimately, the QCOW2 driver found the starting address of the physical cluster corresponding to logical cluster number 234 through the L1 / L2 tables.

[0057] Assuming this physical address is at byte 0x12340000 in the QCOW2 file, then the precise physical address to be accessed is: Final physical address = Physical cluster start address + Cluster offset; Final physical address = 0x12340000 + 0x6000 (24,576 in hexadecimal) = 0x12346000.

[0058] S4.3: Request execution: For read requests: Based on the converted physical offset, data is read directly from the QCOW2 image file and returned to the upper-layer requester through the device mapping framework.

[0059] For write requests: Based on QCOW2's copy-on-write semantics, allocate a new data cluster if necessary, update the corresponding L2 table entries, and then write the data to the newly allocated cluster.

[0060] The processing of write requests follows copy-on-write semantics, including: Determine whether the target data cluster is a shared cluster; If it is a shared cluster, then a new data cluster will be allocated; Update the corresponding second-level table entry to point to the newly allocated data cluster.

[0061] Combination Figure 6 As shown, "shared clusters" typically appear in a snapshot chain. A data cluster is shared if it is referenced by multiple snapshots (including the currently active image). The purpose of COW is to prevent the data in the original snapshot from being destroyed when modifying such shared clusters.

[0062] The physical address of the target data cluster is obtained by querying the L1 / L2 table, which is the transformation calculation process described above.

[0063] In the QCOW2 format, whether a cluster is shared by multiple snapshots can be determined by its reference count.

[0064] The updated data cluster allocates a new, private data cluster to currently active QCOW2 image file users. If it is not a shared cluster, it means that this data cluster belongs exclusively to the current user, there is no snapshot that depends on it, and it is directly overwritten.

[0065] S5: Advanced Feature Support The kernel module also implements kernel-level support for the following advanced QCOW2 features: Snapshot management: Supports the creation and rollback to snapshots by maintaining different metadata views.

[0066] Cache management: Implement a caching mechanism for L2 tables and data clusters in the kernel to reduce the number of times metadata accesses to the image file are required.

[0067] Compression / Encryption: Integrated kernel compression / decryption algorithms that support transparent processing of compression or encryption clusters.

[0068] Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.

Claims

1. A method for improving the read and write performance of virtual machine image files, characterized in that, Includes the following steps: S1: Kernel module loading and initialization Load the loadable kernel module QCOW2 driver that implements QCOW2 resolution functionality. The QCOW2 driver registers a custom target device type with the Linux kernel's device mapping framework. S2:QCOW2 image file metadata parsing In response to the command to create a device mapping framework device, the QCOW2 driver opens the specified QCOW2 image file and parses the header structure and metadata of the QCOW2 image file, including parsing the cluster size and virtual disk size; S3: Device Mapping Framework Device Creation Based on the parsed virtual disk size, a new virtual block device is created through the device mapping framework interface, which is associated with the QCOW2 image file parsed in step S2; S4: Input / Output Request Processing When an application or file system initiates an I / O request to the virtual block device, the device mapping framework routes the request to the processing function registered by the QCOW2 driver for processing.

2. The method according to claim 1, characterized in that, The target device type mentioned in step S1 is a virtual block device.

3. The method according to claim 1, characterized in that, The metadata mentioned in step S2 includes at least the cluster size and first-level table information.

4. The method according to claim 3, characterized in that, Step S2 involves parsing the header structure and metadata of the QCOW2 image file, including the following: Read and verify the QCOW2 magic number and version number; Analyze cluster size and virtual disk size; Load the offset and size of the first-level table, and read the contents of the first-level table into kernel memory; Initialize the L2 table caching mechanism.

5. The method according to claim 1, characterized in that, In step S4, the processing function performs the following operations: S4.1: Request parsing: Extract the logical block address and length of the I / O request; S4.2: Address Translation: Using the parsed QCOW2 image file metadata and the loaded QCOW2 metadata, the requested logical block address is translated into a physical offset within the QCOW2 image file; S4.3: Request execution: For read requests: Based on the converted physical offset, data is read directly from the QCOW2 image file and returned to the upper-layer requester through the device mapping framework; For write requests: Based on QCOW2's copy-on-write semantics, allocate a new data cluster if necessary, update the corresponding L2 table entries, and then write the data to the newly allocated cluster.

6. The method according to claim 5, characterized in that, The address translation in step S4.2 includes the following steps: Calculate the corresponding cluster index based on the logical block address; Use the cluster index to look up the first-level table and obtain the offset of the second-level table; The secondary table is loaded according to the offset of the secondary table, and the physical address of the data cluster is found. The final physical offset is obtained by combining the offset within the cluster.

7. The method according to claim 5, characterized in that, The processing of write requests in step S4.3 follows copy-on-write semantics, including the following: Determine whether the target data cluster is a shared cluster; If it is a shared cluster, then a new data cluster will be allocated; Update the corresponding second-level table entry to point to the newly allocated data cluster.

8. The method according to claim 1, characterized in that, The QCOW2 driver also implements the following functions: Snapshot management: Supports the creation and rollback to snapshots by maintaining different metadata views; Cache management: Implement L2 table and data cluster caching mechanisms in the kernel to reduce the number of times metadata accesses to the image file are performed; Compression / Encryption: Integrated kernel compression / decryption algorithms that support transparent processing of compression or encryption clusters.

Images