A method and device for sharing QCOW2 disks between QEMU virtual machines

Abstract

The present application discloses a method and device for sharing a QCOW2 disk between QEMU virtual machines, including: for a QCOW2 disk, pre-extending a bitmap based on the QCOW2 (QEMU copy on write) file header to record the operating status of all data blocks in the disk using the extended bitmap; when any QEMU virtual machine needs to write data to any data block of the QCOW2 disk, querying the operating status of any data block through the extended bitmap; when the operating status of any data block is idle, or when it is converted to idle, allowing any QEMU virtual machine to write data. The embodiment of the present application realizes the concurrent operation of multiple cloud servers on a cloud hard disk without relying on other systems by modifying QEMU and expanding the QCOW2 disk.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a method and device for sharing a QCOW2 disk between QEMU virtual machines. Background Art

[0002] Shared cloud hard drives support concurrent read and write access to a storage device block by multiple cloud servers. They feature multiple mount points, high concurrency, high performance, and high reliability, making them suitable for key enterprise application scenarios that require cluster support and high availability.

[0003] To use a shared cloud drive, you must set up a shared file system or a similar clustered file system (such as CFS). Mounting a cloud drive to multiple cloud servers without a shared or clustered file system presents two problems: First, data sharing and synchronization are impossible, and second, if multiple cloud servers simultaneously read and write the same data block on the cloud drive, there is a significant risk of data overwriting.

[0004] Cluster file systems are divided into serial access and parallel access according to the file access method. NFS is a commonly used serial access file system that controls the concurrent access of cloud servers to files on cloud hard disks by supporting native Unix file locks. Figure 1 As shown in the figure, NFS connects storage to cloud servers through standard networks without the need for special hardware.

[0005] HDFS shared file system architecture Figure 2 As shown in Figure 2, parallel access file systems, such as GFS and HDFS, require more resources to deploy complex cluster file systems, and special clients need to be installed on the cloud server.

[0006] When cloud servers share cloud hard disks through the NFS file system, an additional file system layer is added between the user process and the disk. This reduces read and write efficiency compared to direct disk file operations. Parallel access is not supported and can only be converted into low-performance and low-efficiency serial access through file locks.

[0007] When cloud servers share cloud hard disks through cluster file systems similar to HDFS, the problem of inability to access in parallel is solved. However, in addition to installing a dedicated client on the cloud server, a cluster must also be deployed on the storage server, which increases the deployment difficulty and consumes more resources. Summary of the Invention

[0008] The embodiments of the present application provide a method and device for sharing QCOW2 disks between QEMU virtual machines, which are used to modify QEMU and expand QCOW2 disks, and realize concurrent operation of multiple cloud servers on a cloud hard disk without relying on other systems.

[0009] This embodiment of the present application provides a method for sharing a QCOW2 disk between QEMU virtual machines, including:

[0010] For QCOW2 disks, the bitmap is pre-extended based on the QCOW2 (QEMU copy on write) file header to record the operation status of all data blocks in the disk using the extended bitmap;

[0011] When any QEMU virtual machine needs to write data to any data block of the QCOW2 disk, query the operation status of any data block through the extended bitmap;

[0012] When the operation state of any one of the data blocks is an idle state, or is converted to an idle state, any one of the QEMU virtual machines is allowed to write data.

[0013] Optionally, recording the operation status of all data blocks in the disk using an extended bitmap is achieved through the OP Bitmap field, and the OP Bitmap field also describes the size of each data block, the start address and the end address of the data block.

[0014] Optionally, it also includes: when the corresponding virtual machine process on the host has an IO write operation, sending a preset request to QEMU, so that the QEMU reads the OP Bitmap from the QCOW2 disk to return the operation status of the data block that needs to be operated.

[0015] The present application also provides a computer device, including a processor, configured to:

[0016] For QCOW2 disks, the bitmap is pre-extended based on the QCOW2 (QEMU copy on write) file header to record the operation status of all data blocks in the disk using the extended bitmap;

[0017] When any QEMU virtual machine needs to write data to any data block of the QCOW2 disk, query the operation status of any data block through the extended bitmap;

[0018] When the operation state of any one of the data blocks is an idle state, or is converted to an idle state, any one of the QEMU virtual machines is allowed to write data.

[0019] Optionally, recording the operation status of all data blocks in the disk using an extended bitmap is achieved through the OP Bitmap field, and the OP Bitmap field also describes the size of each data block, the start address and the end address of the data block.

[0020] Optionally, the processor is further configured to: when the corresponding virtual machine process on the host has an IO write operation, send a preset request to QEMU, so that QEMU reads the OP Bitmap from the QCOW2 disk to return the operation status of the data block that needs to be operated.

[0021] An embodiment of the present application further provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed by a processor, the steps of the aforementioned method for sharing a QCOW2 disk between QEMU virtual machines are implemented.

[0022] The embodiment of the present application realizes concurrent operation of multiple cloud servers on a cloud hard disk by modifying QEMU and expanding the QCOW2 disk without relying on other systems.

[0023] The above description is only an overview of the technical solution of the present application. In order to more clearly understand the technical means of the present application, it can be implemented in accordance with the contents of the specification. In order to make the above and other purposes, features and advantages of the present application more obvious and easy to understand, the specific implementation methods of the present application are listed below. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] Various other advantages and benefits will become apparent to those skilled in the art upon reading the detailed description of the preferred embodiment below. The accompanying drawings are for illustration purposes only and are not to be considered as limiting the present application. The same reference symbols are used throughout the drawings to represent the same components. In the drawings:

[0025] Figure 1 The NFS shared file system architecture of the prior art;

[0026] Figure 2 It is the existing HDFS shared file system architecture;

[0027] Figure 3 This is an example of an extended Op Bitmap in an embodiment of the present application;

[0028] Figure 4 The shared storage architecture of the QEMU virtual machine of the embodiment of the present application;

[0029] Figure 5This is an example of the data writing process for sharing a QCOW2 disk between QEMU virtual machines in an embodiment of the present application. DETAILED DESCRIPTION

[0030] Exemplary embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. Although exemplary embodiments of the present disclosure are shown in the accompanying drawings, it should be understood that the present disclosure can be implemented in various forms and should not be limited by the embodiments set forth herein. Rather, these embodiments are provided to enable a more thorough understanding of the present disclosure and to fully convey the scope of the present disclosure to those skilled in the art.

[0031] QEMU is a general-purpose open source machine emulator and virtualizer. QEMU can be used in many different ways. One is full-system emulation, which provides a complete set of virtual devices (CPU, memory, and emulated devices) for the running guest, and can run a complete operating system for any machine on any supported architecture. Another is user-mode emulation, where QEMU can start Linux / BSD programs compiled for different CPUs, thereby running programs for another Linux / BSD on any supported architecture. QEMU also provides many independent command-line utilities, such as the QEMU-IMG disk image utility to create, convert, and modify disk images.

[0032] QCOW2 (QCOW stands for QEMU copy on write) is a storage format for virtual machine disk images. Using QCOW2 isolates the physical and logical storage layers. QCOW2 creates a mapping between logical and physical blocks, with each logical block mapped to a corresponding physical block. Furthermore, QCOW2 only saves data changes on the physical storage. These features enable storage over-commitment and virtual machine snapshots, making the QCOW2 image format widely used in virtual machine disk technology.

[0033] This embodiment of the present application provides a method for sharing a QCOW2 disk between QEMU virtual machines, including:

[0034] For QCOW2 disks, a bitmap is pre-extended based on the QCOW2 (QEMU copy on write) file header to record the operational status of all data blocks on the disk using the extended bitmap. In some embodiments, this extended bitmap is implemented using the OP Bitmap field, which also describes the size of each data block and the start and end addresses of the data block. Figure 3An example of extending OPBitmap is shown. The method of the present application extends a bitmap (Block1 Status, Block2 Status, ..., Block n Status) that records the operation status of all data blocks in the disk based on the existing QCOW2 file header.

[0035] Figure 4 The shared storage architecture of the QEMU virtual machine is shown. When any QEMU virtual machine needs to write data to any data block of the QCOW2 disk, the operation status of any data block is queried through the extended bitmap. That is, the operation status of the corresponding data block can be determined by the Block n Status in the OP Bitmap. When the operation status of any data block is idle, or is converted to idle, any QEMU virtual machine is allowed to write data. Specifically, Figure 5 As shown in FIG, when the QEMU virtual machine writes data to a data block in the QCOW2 disk, it first queries the status of the current destination data block through the Op Bitmap.

[0036] In some embodiments, it also includes: when the corresponding virtual machine process on the host has an IO write operation, sending a preset request to QEMU so that QEMU reads the OP Bitmap from the QCOW2 disk to return the operation status of the data block that needs to be operated. The specific file system needs to add a request to qemu to obtain the status of the data block to be operated. If it is in an idle state, continue writing. If it is in a write state, wait until the data block status becomes idle before writing. If qemu returns that the current data block status is unavailable, it is necessary to continue waiting or reapply after a timeout according to the policy until the status is available before writing data.

[0037] This method, applied to scenarios where multiple cloud servers share a cloud hard drive, uses native Qcow2 disks, does not rely on third-party file systems, and does not require the deployment of a cluster system. By modifying QEMU and expanding Qcow2 disks, it enables concurrent operation of multiple cloud servers on a single cloud hard drive without relying on other systems.

[0038] The present application also provides a computer device, including a processor, configured to:

[0039] For QCOW2 disks, the bitmap is pre-extended based on the QCOW2 (QEMU copy on write) file header to record the operation status of all data blocks in the disk using the extended bitmap;

[0040] When any QEMU virtual machine needs to write data to any data block of the QCOW2 disk, query the operation status of any data block through the extended bitmap;

[0041] When the operation state of any one of the data blocks is an idle state, or is converted to an idle state, any one of the QEMU virtual machines is allowed to write data.

[0042] In some embodiments, recording the operation status of all data blocks in the disk using an extended bitmap is achieved through the OPBitmap field, and the OPBitmap field also describes the size of each data block, the start address and the end address of the data block.

[0043] In some embodiments, the processor is further configured to: when the corresponding virtual machine process on the host has an IO write operation, send a preset request to QEMU, so that QEMU reads OPBitmap from the QCOW2 disk to return the operation status of the data block that needs to be operated.

[0044] An embodiment of the present application further provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed by a processor, the steps of the aforementioned method for sharing a QCOW2 disk between QEMU virtual machines are implemented.

[0045] The embodiment of the present application realizes concurrent operation of multiple cloud servers on a cloud hard disk by modifying QEMU and expanding the QCOW2 disk without relying on other systems.

[0046] It should be noted that, in this document, the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, article, or apparatus comprising a series of elements includes not only those elements but also other elements not explicitly listed, or elements inherent to such process, method, article, or apparatus. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of other identical elements in the process, method, article, or apparatus comprising the element.

[0047] The serial numbers of the above embodiments of the present application are for description only and do not represent the advantages or disadvantages of the embodiments.

[0048] Through the description of the above implementation methods, those skilled in the art can clearly understand that the above-mentioned embodiment methods can be implemented by means of software plus the necessary general hardware platform, and of course can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk), and includes a number of instructions for enabling a terminal (which can be a mobile phone, computer, server or network device, etc.) to execute the methods described in each embodiment of the present application.

[0049] The embodiments of the present application are described above in conjunction with the accompanying drawings, but the present application is not limited to the above-mentioned specific implementation methods. The above-mentioned specific implementation methods are merely illustrative and not restrictive. Under the guidance of this application, ordinary technicians in this field can also make many forms without departing from the purpose of this application and the scope of protection of the claims, all of which are protected by this application.

Claims

1. A method for sharing QCOW2 disks between QEMU virtual machines, characterized in that: include: For QCOW2 disks, a bitmap is pre-extended based on the QCOW2 file header to record the operation status of all data blocks in the disk using the extended bitmap; When any QEMU virtual machine needs to write data to any data block of the QCOW2 disk, query the operation status of any data block through the extended bitmap; When the operation state of any one of the data blocks is an idle state, or is converted to an idle state, allowing any one of the QEMU virtual machines to write data; The extended bitmap is used to record the operation status of all data blocks in the disk through the OP Bitmap field, and the OP Bitmap field also describes the size of each data block, the start address and the end address of the data block.

2. The method for sharing QCOW2 disks between QEMU virtual machines according to claim 1, wherein: Also includes: When the corresponding virtual machine process on the host has an IO write operation, a preset request is sent to QEMU, so that QEMU reads the OP Bitmap from the QCOW2 disk to return the operation status of the data block that needs to be operated.

3. A computer device, characterized in that: comprising a processor configured to: For QCOW2 disks, a bitmap is pre-extended based on the QCOW2 file header to record the operation status of all data blocks in the disk using the extended bitmap; When any QEMU virtual machine needs to write data to any data block of the QCOW2 disk, query the operation status of any data block through the extended bitmap; When the operation state of any one of the data blocks is an idle state, or is converted to an idle state, allowing any one of the QEMU virtual machines to write data; The extended bitmap is used to record the operation status of all data blocks in the disk through the OP Bitmap field, and the OP Bitmap field also describes the size of each data block, the start address and the end address of the data block.

4. The computer device according to claim 3, wherein The processor is further configured to: when the corresponding virtual machine process on the host has an IO write operation, send a preset request to QEMU, so that QEMU reads the OP Bitmap from the QCOW2 disk to return the operation status of the data block that needs to be operated.

5. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, which, when executed by a processor, implements the steps of the method for sharing a QCOW2 disk between QEMU virtual machines as claimed in claim 1 or 2.

Images