A method for implementing qcow format in logical volume management module

Abstract

The present invention relates to the field of virtual machine storage, and specifically provides a method for implementing the qcow format in a logical volume management module. The physical volume added to the logical volume group is allocated into multiple storage blocks according to a preset size to form a storage block warehouse; according to the storage size required by the newly created virtual machine, the logical volume group is applied for a logical volume, and the logical volume group obtains a number of storage blocks of the corresponding storage size from the storage block warehouse, initializes the logical volume implemented in the qcow2 format, and returns it to the user; when data needs to be written to the logical volume, a new storage block is applied to the storage block warehouse, and the corresponding qcow2 format information is updated, and data is started to be written to the new storage block; when data needs to be read from the logical volume, the storage block storing the data to be read is found according to the qcow2 format information, and data is started to be read from the storage block. While ensuring that the back-end storage of the virtio device is implemented in the kernel state, the advantages of physical memory allocation in the qcow2 format are also combined.

Description

Technical Field

[0001] The present invention relates to the technical field of virtual machine storage, and specifically provides a method for implementing a qcow format in a logical volume management module. Background Art

[0002] In the traditional solution, the storage backend of virtio is implemented in the user layer of the Host OS. In this case, when the user-mode qemu process needs to interact with the kernel-mode storage device, it is necessary to frequently switch between the user mode and the kernel mode. This switching not only adds extra workload, but may also lead to a decrease in IO performance. The vhost solution moves the storage backend of virtio to the kernel layer (kernel) of the Host OS for implementation. In this way, when the qemu process needs to interact with the storage device, it can communicate directly through the kernel-mode vhost module, avoiding frequent user-mode and kernel-mode switching. This improvement reduces the number of system calls and the workload of context switching, thereby improving IO performance. Overall, the vhost solution is significant in improving the performance of the virtio storage backend, especially in high-load and high-concurrency scenarios.

[0003] However, because the vhost solution is implemented at the kernel layer, and the qcow2 format virtual disk file is at the file system layer, the parsing and packaging of the qcow2 file is in the qemu code. qemu itself is a user-mode program, and only implements the qcow2 format support for virtual disk files when storing in the backend, that is, the qcow2 format virtual disk file is implemented inside qemu, that is, in the user layer. The qcow2 format uses the Copy-On-Write mechanism. When data is not stored, it does not need to allocate disk space. It only allocates disk space when data is written. In this way, the area where data has not been written will not actually occupy disk space temporarily, and the unused disk space can be released for other processes that need it, avoiding the situation of tight disk space. When the vhost solution moves the storage backend implementation of virtio from the user layer to the kernel layer, the qcow2 format disk file cannot be used as the storage backend.

[0004] Figure 1 Schematic diagram of the use scenario of user-mode backend storage and kernel-mode backend storage in the background technology of the present invention, such as Figure 1As shown in the figure, in the user-mode backend storage solution (virtio-scsi), the IO request in the client needs to go through 6 layers (client OS->user-mode backend storage module->Qcow2 format virtual disk file->XFS file system module->logical volume->block device driver module), while in the kernel-mode backend storage solution (vhost-scsi), the IO request in the client only needs to go through 4 layers (client OS->kernel-mode backend storage module->logical volume->block device driver module). It is obvious that the kernel-mode storage solution passes through fewer software stacks during the IO request process. After actual measurement and research, it was found that when the amount of data in each IO request is less than 4K, the time consumed by the software stack during a single IO request is almost the same as the time consumed by the hardware data to the disk, each accounting for 50%. In this case, if the IO request passes through fewer software stack layers, the IO request will take less time and be faster.

[0005] It seems that kernel-level backend storage (vhost-scsi) is a powerful tool for improving IO speed. However, due to the lack of support for the Copy-On-Write mechanism in the qcow2 format, the kernel-level backend storage cannot continue to enjoy the benefits of the qcow2 format in the vhost solution. Summary of the invention

[0006] In order to overcome the above defects, the present invention is proposed to solve the problem in the prior art that the advantages of both the vhost technology and the qcow2 format cannot be combined in virtual machine storage.

[0007] The present invention provides a method for implementing the qcow format in a logical volume management module. In the vhost technical solution, the following steps are performed on the logical volume management module:

[0008] Allocate the physical volume added to the logical volume group into multiple storage blocks according to the preset size to form a storage block warehouse;

[0009] According to the storage size required by the newly created virtual machine, apply for a logical volume from the logical volume group. The logical volume group obtains several storage blocks of the corresponding storage size from the storage block warehouse, initializes them into a logical volume implemented in the qcow2 format, and returns them to the user.

[0010] When data needs to be written to the logical volume, a new storage block is requested from the storage block warehouse, and the corresponding qcow2 format information is updated to start writing data to the new storage block;

[0011] When data needs to be read from the logical volume, the storage block storing the data to be read is found according to the qcow2 format information, and the data is read from the storage block.

[0012] Furthermore, the preset size is 65536 bytes.

[0013] Furthermore, when the number of storage blocks in the storage block warehouse is lower than a preset value, other physical volumes are obtained, allocated as multiple storage blocks according to a preset size, and added to the storage block warehouse.

[0014] Furthermore, when a physical volume is withdrawn or replaced, the storage block warehouse selects the storage blocks allocated on the physical volume, copies the contents on the storage blocks to other free storage blocks, and makes associations.

[0015] Working principle and beneficial effects of the present invention:

[0016] In the technical solution of the present invention, the physical volume is divided into many storage blocks, which are centrally managed as storage block warehouses in LVM. When new data needs to be written to the logical volume, the logical volume in qcow2 format applies for new storage blocks from the logical volume group to store the data, so that the logical volume can only logically divide the storage space of the corresponding size when the initial new application size is created, and there is no need to allocate real storage blocks. The number of storage blocks actually allocated to the logical volume is allocated according to the space required for the data written to it. In the vhost technical solution, the above-mentioned improvement is made to the logical volume management module LVM, which not only ensures the implementation of virtio device backend storage in kernel state, but also has the advantage of allocating qcow2 format storage space only when it is needed. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] The disclosure of the present invention will become more easily understood with reference to the accompanying drawings. It is easy for those skilled in the art to understand that these drawings are only for illustrative purposes and are not intended to limit the scope of protection of the present invention. In addition, similar numbers in the figures are used to represent similar components, among which:

[0018] Figure 1 It is a schematic diagram of the use scenario of user-mode backend storage and kernel-mode backend storage in the background technology of the present invention;

[0019] Figure 2 It is a structural diagram of the logical volume management module in the present invention;

[0020] Figure 3 It is a schematic diagram of qcow2 format information in the present invention. DETAILED DESCRIPTION

[0021] Some embodiments of the present invention are described below with reference to the accompanying drawings. It should be understood by those skilled in the art that these embodiments are only used to explain the technical principles of the present invention and are not intended to limit the protection scope of the present invention.

[0022] At present, the common LVM is fixedly divided into logical volume storage. If 100G is divided at the beginning, 100G of storage space will be actually allocated. In fact, most of this 100G is unused and cannot be allocated to others, which will cause a waste of resources. In order to enjoy the efficient IO performance brought by the kernel-mode backend storage, and also use the Copy-On-Write mechanism in the qcow2 format to make the disk space redundant, then is it possible to implement the QCOW2 format to allocate block device storage space at the logical volume LVM module layer?

[0023] In the present invention, by analyzing the overall IO process of vhost-scsi, the storage is divided in the qcow2 format at the logical volume layer (LVM module), so that both the efficient IO of the kernel-state backend storage (vhost-scsi) and the flexible storage space brought by the qcow2 format image can be enjoyed.

[0024] Figure 2 Schematic diagram of the structure of the logical volume management module in the present invention. Figure 2 As shown, based on the vhost technical solution, a method for implementing the qcow format in a logical volume management module in this embodiment mainly includes the following steps performed on the logical volume management module.

[0025] 1. Divide storage blocks

[0026] The physical volume pv (PhysicalVolume) added to the logical volume group vg (volume group) is allocated into multiple storage block clusters according to the preset size, forming a large storage block warehouse (cluster depot).

[0027] In this embodiment, the concept of cluster in the qcow2 format is adopted, and the size of the cluster can be configured to 2^n bytes, and the default is 65536 bytes (2^16). This size is relatively balanced in all aspects, which is beneficial to the query speed and will not cause a sudden increase in metadata. That is to say, in one embodiment, the preset size can be configured to 65536 bytes.

[0028] 2. Create storage media for the virtual machine

[0029] First, apply for a logical volume from the logical volume group based on the storage size required for the newly created virtual machine.

[0030] In this embodiment, when a user needs a 120G logical volume, it will send the request to the logical volume group (corresponding to Figure 2The part where the logical volume points to the volume group. The applied logical volume is used for the newly created virtual machine. The logical volume group is responsible for allocating it when the virtual machine storage backend needs a new cluster.

[0031] Second, the logical volume group obtains several storage blocks of the corresponding storage size from the storage block warehouse, initializes them into logical volumes implemented in the qcow2 format, and returns them to the user.

[0032] The logical volume group takes several storage blocks (cluster) from the storage block warehouse (cluster depot) and initializes it to store a logical volume implemented in qcow2 format with a logical size of 120G (corresponding to Figure 2 At this time, the 120G logical volume (lv) can be returned to the user.

[0033] The storage logical size here refers to how many GB of data storage the newly created virtual machine will achieve. However, it does not necessarily allocate all the real storage of each byte from the backend storage medium immediately. Only when the virtual machine executes a "write / write" request on a certain storage block, the real storage of the corresponding storage block size is actually allocated from the backend storage medium to store the data. In the part of the returned logical volume that has not yet been written to, the default data is all binary 0.

[0034] This effect is achieved by initializing the logical volume to the qcow2 format. The qcow2 format means that the part that has not been written is assumed to be a binary value of 0, and there is no need to actually allocate disk space for it. Until this location receives the first write operation request, storage space will be allocated for it. This is the basic principle of qcow2 format storage, which occupies less disk space.

[0035] And associate the (cluster) block containing qcow2 format information with this logical volume (lv). S1 only allocates cluster blocks according to cluster_size, which is only the most basic storage unit in the qcow2 format and does not completely contain the qcow2 format information of a virtual disk. The newly divided logical volume is used as a virtual disk for the virtual machine. The actual cluster block allocated corresponds to the starting position of the virtual disk. A mapping relationship table is required for query, because this cluster block is used to map and store virtual disks, but the mapping relationship needs to be stored somewhere else (meta information or data metadata is stored somewhere else)

[0036] Among them, the (cluster) block containing qcow2 format information is created when the logical volume is first applied to the logical volume group. Specifically, it refers to the qcow2 format header information, which records the starting position information of each allocated storage block corresponding to the virtual disk (usually called meta information or metadata). The actual allocated storage space corresponds to the logical position of the virtual machine disk and needs to be recorded in the qcow2 format. Generally, the first storage space actually allocated is used to store qcow2 metadata. There are also metadata in other locations, but the location of other metadata is also recorded according to certain qcow2 format specifications and must be calculated from the content recorded in the qcow2 header information.

[0037] Figure 3 is a schematic diagram of the qcow2 format information in the present invention, such as Figure 3 As shown, the L1 Table contains a series of L2Table location information, and the L2 Table contains a series of Data culster location information.

[0038] In one implementation, since the addressing disk starts at position 0, the location information of the first Datacluster needs to be found. Therefore, the L1Table needs to be found through the location of the L1 table in the qcow2 header table. The L1 Table stores a series of L2 Table locations. To find the disk position 0, the first L2 Table in the L1 Table must be found, and then the location of the first data cluster is found in the corresponding L2 Table based on the location. The location of the first data cluster is found, and the space of cluster_size (i.e., the preset size in step S1) after it is the storage space of the first storage block.

[0039] 3. Write data to the logical volume

[0040] When data needs to be written to the logical volume, a new storage block is requested from the storage block warehouse, the corresponding qcow2 format information is updated, and data is started to be written to the new storage block.

[0041] In this embodiment, when the user starts to write data to the 120G logical volume returned by step S2, the logical volume will find a suitable storage location in the storage block containing the qcow2 format information and start writing data into it. If it is found that the storage location to be written has not been allocated a real storage block, the logical volume needs to send a message to the storage block warehouse to apply for occupying a new storage block, and update the corresponding qcow2 format information, establish an association with the logical volume, and then start writing data to the new storage block. After the new storage block (cluster) is allocated to the storage in qcow2 format (referring to the logical volume above in this embodiment), the contents of the L1 Table and L2 Table in the qcow2 format need to be updated. Through the corresponding relationship of the virtual disk space, the disk space location of the new storage block needs to be filled in the L2 Table. If the L2 table does not exist here, it is also necessary to apply for the storage space of the L2 table itself first, and then count the location of the new storage block into the L2 table.

[0042] 4. Read data from the logical volume

[0043] When data needs to be read from the logical volume, the storage block storing the data to be read is found according to the qcow2 format information, and the data is read from the storage block.

[0044] In this embodiment, when the user starts to read data from the 120G logical volume (lv), the logical volume will go to the storage block containing the qcow2 format information, find the storage block of the data to be read according to the qcow2 format information, and start reading data from the storage block.

[0045] If it is found that the storage location to be written has not been allocated a real storage block (cluster), the understanding of the virtual disk is that this area is all 0, which can be read, but the read output is all 0. Before the write operation occurs to this virtual disk storage location, it is not necessary to pre-allocate a real cluster for it according to the qcow2 format. Unallocated is just a compression algorithm to take up less space.

[0046] 5. If the cluster depot finds that there are not many storage blocks in stock, you can add other physical volumes, split the encoding into multiple new storage blocks and add them to the cluster depot.

[0047] 6. If a physical volume needs to be withdrawn or replaced later, the cluster depot will select the storage blocks allocated to the physical volume, copy the contents of these storage blocks to other free storage blocks, and make associations. This makes it easy to dynamically replace physical storage.

[0048] Through the above steps, the physical volume is divided into many storage blocks, which are centrally managed as storage block warehouses in LVM. When new data needs to be written to the logical volume, the qcow2 format logical volume applies for a new storage block from the logical volume group to store the data. In this way, when the logical volume is initially created and applied for size, it can only logically divide the memory of the corresponding size without allocating real storage blocks. The number of storage blocks actually allocated to the logical volume is allocated according to the space required for the data written to it. In the vhost technical solution, the above improvements are made to the logical volume management module LVM, which not only ensures the implementation of virtio device backend storage in kernel state, but also has the advantages of qcow2 format physical memory allocation.

[0049] It should be pointed out that although the various steps in the above embodiments are described in a specific order, those skilled in the art can understand that in order to achieve the effects of the present invention, different steps do not have to be performed in such an order, and they can be performed simultaneously (in parallel) or in other orders. These changes are within the scope of protection of the present invention.

[0050] Here are some terms involved in the present invention.

[0051] QCOW: The full name is Qemu Copy-On-Write, which is a disk format mainly used for qemu virtual machines. This format optimizes performance by delaying the allocation of space and adopts a copy-on-write mechanism. This means that only when a data block is referenced multiple times and attempted to be written will the data block be copied, and the modifications will be applied to the copied data block to keep the data of other instances unchanged. The qcow format has developed to the third version, but usually only the two extensions qcow and qcow2 are used. The official format is currently qcow2. Among them, qcow2 is a particularly commonly used image file format in QEMU virtual machines, and the qcow2 format is also used as an example in this embodiment.

[0052] Cluster: It is a concept in the qcow2 format. The default size is 2^16=65536 bytes (configurable to 2^n).

[0053] Qemu: Qemu stands for Quick Emulator. It is a powerful open source virtual machine manager. It can support hardware virtualization by combining with the KVM module in the Linux kernel. Currently, Qemu+KVM is commonly used to provide virtualization services on the Linux platform.

[0054] KVM: Kernel-based Virtual Machine, is an open source system virtualization module. Its core is to add a virtualization module to the Linux operating system. Through this module, the operating system can directly run multiple virtual machines, namely virtual clients (VM - Virtual Machine)

[0055] GuestOS: In virtualization, a computer can run multiple operating systems at the same time. Each operating system is called a Guest OS, that is, the operating system on the virtual machine.

[0056] HostOS: In a virtual machine, Host OS corresponds to Guest OS. The former refers to the operating system installed on the physical machine, while the latter refers to the operating system installed in the virtual machine. For example, if we install Ubuntu on a physical computer and then create a virtual machine on this system with OpenEuler installed, Ubuntu is the Host OS.

[0057] vHost: vhost is a technology that provides backend storage for virtio devices in the kernel. The main purpose of vhost is to improve the IO performance of virtio devices in a virtual environment and avoid the need for a large number of state switches and system calls when implementing backend storage in user mode. vhost defines a message-based protocol through which the virtio backend can forward the data plane configuration information of the virtio device to another component, which then completes the data plane function. In this way, vhost separates the control plane and data plane of the virtio backend into two components, improving performance. vhost shares file descriptors with kvm in a kvm scenario, and notifies each other of events through these file descriptors without the involvement of qemu. vhost is a backend storage implementation for virtio, mainly used to improve the IO performance of virtual machines.

[0058] LVM: Logical Volume Manager (Logical Volume Management) is a mechanism for managing disk partitions in Linux. It is essentially a virtual device driver, a new abstraction layer added between block devices and physical devices in the kernel. It can combine several disks pv (physical volumes, PhysicalVolume) to form a storage pool or logical volume group vg (VolumeGroup). LVM can divide logical volumes lv (LogicalVolume) of different sizes from the volume group each time to create a new logical storage device as the backend storage medium for the virtual machine. The underlying original disk is no longer directly controlled by the kernel, but by the LVM layer.

[0059] So far, the technical solutions of the present invention have been described in conjunction with the preferred embodiments shown in the accompanying drawings. However, it is easy for those skilled in the art to understand that the protection scope of the present invention is obviously not limited to these specific embodiments. Without departing from the principle of the present invention, those skilled in the art can make equivalent changes or substitutions to the relevant technical features, and the technical solutions after these changes or substitutions will fall within the protection scope of the present invention.

Claims

1. A method for implementing the qcow format in a logical volume management module, characterized in that: In the vhost technical solution, the following steps are performed on the logical volume management module: Allocate the physical volume added to the logical volume group into multiple storage blocks according to the preset size to form a storage block warehouse; According to the storage size required by the newly created virtual machine, apply for a logical volume from the logical volume group. The logical volume group obtains several storage blocks of the corresponding storage size from the storage block warehouse, initializes them as logical volumes implemented in the qcow2 format, and returns them to the user. When applying for a logical volume from the logical volume group for the first time, a storage block containing qcow2 format information is created, and the storage block containing qcow2 format information is associated with the logical volume. When data needs to be written to the logical volume, a new storage block is requested from the storage block warehouse, and the corresponding qcow2 format information is updated to start writing data to the new storage block; When data needs to be read from the logical volume, the storage block storing the data to be read is found according to the qcow2 format information, and the data is read from the storage block.

2. A method for implementing the qcow format in a logical volume management module according to claim 1, characterized in that: The preset size is 65536 bytes.

3. A method for implementing the qcow format in a logical volume management module according to claim 1, characterized in that: When the number of storage blocks in the storage block warehouse is lower than the preset value, other physical volumes are obtained, allocated as multiple storage blocks according to the preset size and added to the storage block warehouse.

4. A method for implementing the qcow format in a logical volume management module according to claim 1, characterized in that: When a physical volume is withdrawn or replaced, the storage block warehouse selects the storage blocks allocated on the physical volume, copies the contents of the storage blocks to other free storage blocks, and makes associations.

Images