Virtual machine disk partitioning and accelerated access method based on NVMe disk

Abstract

The invention discloses a virtual machine disk partitioning and accelerated access method based on an NVMe disk, which comprises the following steps: step 1, partitioning a virtual machine disk, appointing a virtual machine disk partitioning format and a virtual machine disk metadata format, and appointing the layout of partitions on a GPT partitioning table; the formats of the first N-1 partitions are recorded as DVMFS and the format of the last partition is recorded as VMFR in the first and last GPT Records of the GPT partition table of the host machine, and the VMFR comprises a pointer pointing to the DVMFS; and step 2, NVMe disk transparent transmission is carried out in the Hypervisor. The invention provides a virtual machine data partition format DVMFS and a metadata management partition format VMFR, and the two formats effectively solve the problems that the same disk cannot be used by multiple tenants through direct connection, and the performance of the NVMe disk cannot be fully exerted by managing the virtual machine disk in a file mode.

Description

Technical Field

[0001] The present invention relates to a virtual machine disk partitioning and acceleration method, and belongs to the technical field of NVMe solid state hard disks. Background Art

[0002] The widespread use of NVMe solid-state drives has significantly improved the performance of cloud servers, but cloud servers are generally used in a virtualized manner, using the virtualization layer to map the virtual machine's disk to a file on the host machine. Since the reading and writing of files requires the host machine's system call, this method cannot fully utilize the performance advantages of NVMe solid-state drives. At the same time, due to the large-scale use of NVMe disks in the form of U.2 and other forms, the capacity of NVMe disks is getting larger and larger, and the situation where a virtual machine exclusively occupies an entire NVMe disk device is no longer realistic.

[0003] In order to solve the above performance problems, the existing technology uses the virtual machine Virtio driver to create a virtual disk device in the virtual machine, and transparently transmits the write instructions of the virtual disk to the NVMe disk of the host machine. However, this method cannot make multiple virtual machines reuse the same NVMe disk. To solve this problem, files are used for management. For example, ESXi uses the VMDK format to store virtual machine disks, and QEMU uses QCOW2 to store virtual machine disks. The space actually occupied by virtual machine disks is optimized to a certain extent, but the performance is still compromised. Summary of the invention

[0004] The technical problem to be solved by the present invention is: for NVMe disks and virtual disks, how to improve the isolation and security of disks between multiple tenants.

[0005] To solve the above technical problems, the present invention provides a virtual machine disk partitioning and accelerated access method based on NVMe disk, comprising the following steps: Step 1. Partition the virtual machine disk, specify the virtual machine disk partition format and the virtual machine disk metadata format, and specify the layout of the partition on the GPT partition table; record the first N-1 partition formats as DVMFS and the last partition format as VMFR in the first and last two GPT Records of the host machine's GPT partition table, and VMFR contains a pointer to DVMFS; Step 2: Perform NVMe disk transparent transmission in Hypervisor.

[0006] In the aforementioned method for partitioning and accelerating access to virtual machine disks based on NVMe disks, in step 1, DVMFS is the area where the virtual machine virtual disk is stored, and includes the following fields: 1)FS Header: used to identify the file system header; 2) Metadata: saves the information of the current partition; 3) Next File System Ptr and Prev File System Ptr are used to indicate the LBA addresses of the previous and next continuous spaces in the current partition for fast addressing.

[0007] The aforementioned method for partitioning and accelerating access to virtual machine disks based on NVMe disks, in step 1, uses Algorithm 1 in the Hypervisor to adjust the disk capacity of the virtual machine, including operations of expanding and shrinking the disk, including the following steps: 1) Use the ADJUSTVMDISK(vmdisk, dst_size, force = false) function to call the operation. The input parameters include the virtual disk object vmdisk, the target size dst_size, and a mandatory parameter force; 2) If dst_size is less than or equal to 0, throw a ParamErrorException; 3) If the target size dst_size is smaller than the current disk size and force is true, call the SHRINKVMDISK(vmdisk, dst_size) function to shrink the disk. 4) If force is false and the target size is smaller than the current disk size, a DataLossException is thrown; 5) If the target size dst_size is larger than the current disk size, call the EXPANDVMDISK(vmdisk,dst_size) function to perform the expansion operation.

[0008] In the aforementioned method for partitioning and accelerating access to a virtual machine disk based on an NVMe disk, in step 3), the disk shrinking process SHRINKVMDISK (vmdisk, dst_size) includes: 31) Calculate the size nr_size that needs to be reduced, that is, the current size minus the target size; 32) When nr_size is greater than 0, perform the following steps: Recursively access the partition pointed to by the partition's NextPtr until the last host partition of the virtual disk is found; Check if the size of the last host partition of the virtual disk is greater than or equal to nr_size; If yes, call the CutDVMFS function to cut, and set nr_size to 0; the CutDVMFS function sets the size of the target partition to [original size - nr_size], modifies the Metadata part of DVMFS, modifies NextPtr to NULL, updates the field of the partition size in the VMFR part, and finally uses the actual occupied LBA position of the DVMFS partition to update the occupied space bit table in VMFR; If not, subtract the size of the partition from nr_size, delete the partition, delete the VMFR partition metadata of the partition, set the NextPtr of the previous DVMFS partition to NULL, and finally update the occupied space bit table on VMFR.

[0009] In the aforementioned method for partitioning and accelerating access to a virtual machine disk based on an NVMe disk, in step 5), the disk expansion process EXPANDVMDISK(vmdisk, dest_size) includes: 51) Calculate the size nr_size that needs to be expanded, that is, the target size minus the current size; 52) Check the available space on the host. If it is insufficient, throw NoEnoughSpaceException and the operation ends. 53) When nr_size is greater than 0, perform the following steps: Find the last host partition of the virtual disk; Get the free space outside the last host partition of the virtual disk by looking up the unused space in the VMFR occupied space bit table; If the available space is greater than or equal to nr_size, the partition is expanded and nr_size is set to 0, and the occupied space bit table in VMFR is updated; If the available space is insufficient, recursively search for free space blocks and add new partitions as needed, update nr_size to nr_size minus the current free space size, and update the occupied space bit table in VMFR.

[0010] In the aforementioned method for partitioning and accelerating access to virtual machine disks based on NVMe disks, in step 1, the Consistency bit of each DVMFS in VMFR is used to determine whether it is written correctly. If the Consistency bit is set to 1, it means that the metadata of the partition is modified and not written correctly. According to the situation of the Consistency bit, choose to accept the modification of DVMFS or accept the modification of VMFR, the method is as follows: Condition 1: Check whether the existing checksum is the same as the checksum recalculated by the current partition FS Header; Condition 2: Whether the Consistency bit in VMFR is 0; If both conditions 1 and 2 are not met, the metadata of VMFR is accepted; if condition 1 is met but condition 2 is not met, the metadata of DVMFS is accepted; if condition 1 is not met but condition 2 is met, the metadata of VMFR is accepted; if condition 1 is met and condition 2 is met, there is no data inconsistency.

[0011] The aforementioned method for partitioning and accelerating access to a virtual machine disk based on an NVMe disk includes, in step 2: 21) A middle layer DNVMe Driver is added between Hypervisor and VFIO-pci. The middle layer uses IOMMU to isolate device addresses, obtains the LBA mapping block of each virtual machine disk according to the physical address LBA of the first DVMFS to which the virtual disk bound to the virtual machine belongs, and registers the LBA mapping block of each virtual machine disk with IOMMU, registers the start LBA address and end LBA address of each DVMFS one by one, and maps the start LBA address and end LBA address of each DVMFS to a continuous virtual address space; 22) Directly obtain the physical address through IOMMU to access the virtual machine's disk. For NVMe disks, each NVMe disk is set with an Admin QPair and multiple I / O QPairs for sending and transmitting management instructions and data operation instructions. The NVMe disk includes a physical NVMe disk and a virtual NVMe disk. In the Hypervisor, the NVMe disk device of each virtual machine simulates an NVMe admin qpair using the host software, and determines whether the admin command has the corresponding authority to execute based on the metadata information of the virtual machine disk.

[0012] In the aforementioned method for partitioning and accelerating access to virtual machine disks based on NVMe disks, in step 22), the virtual NVMe disk has at most the same number of Admin qpairs and I / O qpairs as the physical NVMe disk, the adminqpair is taken over by the DNVMe Driver, and the I / O qpairs are transparently transmitted to the VFIO-pci driver; The I / O qpairs process all normal NVMe read and write instructions, converting the virtual device address into the actual physical disk address; using IOMMU to first convert the virtual address into the physical address of the physical NVMe disk, and then put the command located in the qpair into the sq queue of the physical NVMe disk. The mapping relationship between the virtual address and the physical address is submitted to the IOMMU according to the first and last addresses of the data partition of the DVMFS during initialization.

[0013] The aforementioned virtual machine disk partitioning and accelerated access method based on NVMe disk sets an LBA address translation table mechanism and saves the LBA address translation table in memory for quick search. If the LBA address mapping information cannot be found in the IOMMU, the current mapping information is obtained from the LBA address translation table. The LBA address translation table is constructed using the first and last addresses of the data partitions of each DVMFS when the host physical NVMe disk is initialized.

[0014] In the aforementioned virtual machine disk partitioning and accelerated access method based on NVMe disk, the minimum mapping unit of virtual qpair and physical qpair is queue, and the queue of virtual NVMe disk is mapped to the queue of physical NVMe disk in a one-to-one correspondence. According to the initialization order of the virtual machine, qpair0 of the starting virtual queue is mapped to different qpairs on the physical NVMe disk, and then the next queues are mapped in sequence.

[0015] In the aforementioned method for partitioning and accelerating access to virtual machine disks based on NVMe disks, the LBA mapping list and IOMMU mapping are linked, and the steps are as follows: When an I / O request reaches the IOMMU, the IOMMU first converts the virtual address of the I / O request into a physical address, and at the same time verifies the source virtual machine of the I / O request and the virtual machine that occupies the virtual disk to which the corresponding physical address belongs, using the unique number of the virtual machine for verification. If the unique number of the source virtual machine of the request is the same as the unique number of the virtual machine that occupies the virtual disk to which the corresponding physical address belongs, the I / O request proceeds normally; if it is found that the virtual machines do not match, an error is returned and the execution of the instruction is terminated.

[0016] The beneficial effects achieved by the present invention are as follows: in order to solve the problem that the VFIO hardware pass-through method cannot make multiple virtual machines reuse the same NVMe disk, and the file management method still has a certain compromise in performance, the present invention proposes a virtual machine data partition format DVMFS and a metadata management partition format VMFR. The two formats effectively solve the problem that the pass-through method cannot make multiple tenants use the same disk, and the file method management of virtual machine disks cannot give full play to the performance of NVMe disks.

[0017] At the same time, the present invention uses IOMMU to prevent the virtual machine disk from accessing data outside the management scope, thereby enhancing data isolation, and uses a staggered manner to pair the queue pairs of the virtual disk and the queue pairs of the physical NVMe disk, so that the advantages of NVMe multiple queues can be fully utilized when multiple virtual machines perform I / O. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] Figure 1A schematic diagram of a partition table layout of a virtual machine disk in GPT format in the prior art; Figure 2 Schematic diagram of the layout of DVMFS and VMFR in Example 1 of the present invention; Figure 3 The schematic diagram of Virtio and VFIO in Example 1 of the present invention is shown below; Figure 4 The schematic diagram of adding a DNVMe Driver to the Hypervisor in Embodiment 1 of the present invention is provided; Figure 5 Schematic diagram of the mapping relationship between virtual disk queue pairs and physical disk queue pairs in Example 1 of the present invention. DETAILED DESCRIPTION

[0019] The technical solution of the present invention is further described below in conjunction with the accompanying drawings and specific embodiments. Example 1

[0020] This embodiment provides a virtual machine disk partitioning and accelerated access method based on NVMe disk, including: Step 1. Partition the virtual machine disk; like Figure 1 As shown, cloud service providers use virtual machines to separate different users so that different users do not interfere with each other, and provide users with operating system-level isolation and customizability. The current way for clusters such as servers to use disks is to format blank disks into the GPT partition table format, which is compatible with the EFI system firmware.

[0021] The GPT design of the prior art can ensure compatibility and portability. On this basis, this embodiment includes specifying the virtual machine disk partition format and the virtual machine disk metadata format during the disk partitioning process, and also specifies the layout of the partition on the GPT partition table.

[0022] The overall layout specified is as follows Figure 2 As shown, the part covered by yellow shadow is the specified layout format, and the part outside the box is the GPT partition table of the virtual disk in the virtual machine, which ensures the minimum compatibility between the host disk and other disks.

[0023] The first and last two GPT Records of the host machine's GPT partition table record that the first N-1 partitions are in the format of DVMFS (Dynamic Virtual Machine File System) and the last partition is in the format of VMFR (Virutal Machine Fallback Record). Both DVMFS and VMFR are legal partition formats in the GPT partition table. Each host machine disk can have multiple DVMFS and 1 VMFR. Due to the limitation of the GPT partition table, the maximum number of partitions on the disk is 128, so the maximum number of DVMFS is 127.

[0024] DVMFS correspondence Figure 2 In Partition1data sector-N-1data sector, each partition is a GPT partition in DVMFS format.

[0025] VMFR Figure 2 In the virtualmachine –record, VMFR is connected to the Partition1data sector-N-1data sector through a pointer (LBA on the disk), and the address of Partition1data sector-N-1datasector is stored in VMFR. VMFR contains a pointer to DVMFS, that is, an index that can be used to find a DVMFS is stored in VMFR.

[0026] DVMFS is the area where virtual disks of virtual machines are stored. It includes the following fields: 1)FS Header: used to identify the file system header, including Magic Number, DVMFS version number, revision number, checksum and other information, which is a fixed-length field.

[0027] The checksum is obtained by adding the hexadecimal values ​​of all the fields of the FS Header and taking the lower 8 bits as the checksum. When power is restored after a power outage, it is checked whether the checksum is consistent with the checksum recalculated after startup.

[0028] 2) Metadata: saves the information of the current partition, including size, disk GUID in the virtual machine, etc., which is a fixed-length field; 3) Next File System Ptr / Prev File System Ptr: used to point to the next DVMFS space on the same disk used by the virtual machine. Next File System Ptr and Prev File System Ptr are used to indicate the LBA addresses of the previous and next continuous spaces on the current partition for fast addressing. The above two fields are fixed length.

[0029] If DVMFS is the first physical partition mapped to the virtual partition of the virtual machine, the sequence number of the physical partition is 1. At this time, there is no previous partition, so Prev File System Ptr is NULL (null value).

[0030] The partition header metadata information is fixed-length, and the data location can be quickly found based on the GPT partition table Entry information.

[0031] Since it is not convenient to modify the size of disk partitions, if the virtual machine needs to expand the disk, the host may need to migrate the data in the disk partition to a larger partition. Therefore, this embodiment uses a method that can span multiple partitions to connect the spaces of multiple DVMFS through LBA pointers. To the virtual machine, it is an integrated space, but in fact, the host is multiple partitions in different physical locations. The Hypervisor (virtual machine management program / virtual machine monitoring program) only needs to establish a mapping from the virtual machine LBA to the host's physical NVMe disk LBA. If there is still unused free space after the partition that needs to be expanded, the size of the current partition can be directly expanded.

[0032] Use Algorithm 1 to adjust the disk capacity of the virtual machine, including the operations of expanding and shrinking the disk. The operations of expanding and shrinking the disk are all performed in the Hypervisor, and the virtual machine itself cannot do this. The following steps are included: 1) Calling process: Use the ADJUSTVMDISK(vmdisk, dst_size, force = false) function to call the operation. The input parameters include the virtual disk object vmdisk, the target size dst_size, and a mandatory parameter force (the default value is false). 2) Parameter check: If dst_size is less than or equal to 0, throw a parameter error exception ParamErrorException; 3) Shrink the disk: If the target size dst_size is smaller than the current disk size and force is true, call the SHRINKVMDISK(vmdisk, dst_size) function to shrink the disk; 4) Data loss exception: If force is false and the target size is smaller than the current disk size, a data loss exception DataLossException is thrown; 5) Expand disk: If the target size dst_size is larger than the current disk size, call the EXPANDVMDISK(vmdisk, dst_size) function to perform the expansion operation.

[0033] In step 3), the disk shrinking process SHRINKVMDISK(vmdisk, dst_size) includes: 31) Calculate the size to be reduced: Calculate the size nr_size to be reduced, that is, the current size minus the target size; 32) Loop reduction: When nr_size is greater than 0, perform the following steps: Recursively access the partition pointed to by the partition's NextPtr until the last host partition of the virtual disk is found; Check if the size of the last host partition of the virtual disk is greater than or equal to nr_size; If yes, call the CutDVMFS function to cut, and set nr_size to 0; the CutDVMFS function sets the size of the target partition to [original size - nr_size], modifies the Metadata part of DVMFS, modifies NextPtr to NULL, updates the field of the partition size in the VMFR part, and finally uses the actual occupied LBA position of the DVMFS partition to update the occupied space bit table in VMFR; If not, subtract the size of the partition from nr_size, delete the partition, delete the VMFR partition metadata of the partition, set NextPtr of the previous DVMFS partition to NULL, and finally update the occupied space bit table on VMFR. At this time, DVMFS assumes that it does not exist.

[0034] In step 5), the expansion disk process EXPANDVMDISK(vmdisk, dest_size) includes: 51) Calculate the size to be expanded: Calculate the size nr_size to be expanded, that is, the target size minus the current size; 52) Check available space: Check the available space of the host. If it is insufficient, throw NoEnoughSpaceException, indicating that the available space of the host is insufficient to expand the partition, so the operation ends; 53) Cyclic extension: When nr_size is greater than 0, perform the following steps: Find the last host partition of the virtual disk; Get the free space outside the last host partition of the virtual disk by looking up the unused space in the VMFR occupied space bit table; If the available space is greater than or equal to nr_size, the partition is expanded and nr_size is set to 0, and the occupied space bit table in VMFR is updated; If the available space is insufficient, recursively search for free space blocks and add new partitions as needed, update nr_size to nr_size minus the current free space size, and update the occupied space bit table in VMFR.

[0035] VMFR is also used to save the correspondence between DVMFS and virtual machines, and backs up metadata information such as the Header at the front of DVMFS. At the same time, the VMFR partition is located at the end of the disk LBA position, close to the Secondary GPT Record. VMFR uses a fixed-length area to store the metadata of each DVMFS, and sets the upper limit of a VMFR to 127 DVMFS. Therefore, the field length of VMFS is fixed to 127*the length of the metadata field of each DVMFS partition. VMFR includes the header, Metadata, PrevPtr, and NextPtr of each DVMFS partition, and uses the occupied space bit table to save the current disk's LBA allocation for fast partition space size adjustment.

[0036] Each modification to the target DVMFS partition will trigger a synchronous modification to VMFR, and because of the two backups, a transactional commit is formed. Each modification to the DVMFS partition, if not synchronized to VMFR, is considered an invalid operation and requires a repair operation.

[0037] Use the Consistency bit for each DVMFS in VMFR to determine whether it is written correctly. If the Consistency bit is set to 1, it means that the metadata of the partition has been modified and not written correctly. Therefore, you need to choose to accept the DVMFS modification or the VMFR modification according to the situation of the Consistency bit. The specific method is as follows: Condition 1: Check whether the existing checksum is the same as the checksum recalculated by the current partition FS Header; Condition 2: Whether the Consistency bit in VMFR is 0; If both conditions 1 and 2 are not met, the metadata of VMFR is accepted; if condition 1 is met but condition 2 is not met, the metadata of DVMFS is accepted; if condition 1 is not met but condition 2 is met, the metadata of VMFR is accepted; if condition 1 is met and condition 2 is met, there is no data inconsistency.

[0038] Step 2: Perform NVMe disk transparent transmission in Hypervisor; In the prior art, the NVMe disk direct access process includes Virtio-blk, VFIO, etc., among which Virtio needs to pass through the host-side file system, and has poor performance. Virtio needs to pass through the host-side file system, so the call stack is longer than the direct disk, and each I / O spends more time on the function of the call stack, so the performance is relatively poor compared to the direct host access / virtual machine direct access. However, the use of files to organize and isolate disk data between different tenants has better flexibility, while VFIO completely passes the entire disk directly to a virtual machine, which can minimize the performance loss of the virtual machine compared to the host. However, because there are too many hardware that need to be passed directly, the flexibility is limited. The difference between the two is as follows: Figure 3 shown.

[0039] like Figure 4 As shown in the figure, NVMe disk transparent transmission, namely DNVMe, is performed in the Hypervisor, including the following steps: 21) A middle layer DNVMe Driver is added between Hypervisor and VFIO-pci. The middle layer uses IOMMU to isolate device addresses like VFIO. The LBA mapping block of each virtual machine disk is obtained according to the physical address (LBA) of the first DVMFS to which the virtual disk bound to the virtual machine belongs, and the LBA mapping block of each virtual machine disk is registered by IOMMU. Since the size of the DVMFS partition is variable and different DVMFS data areas of the same virtual disk are not continuous, it is necessary to register the starting LBA address and ending LBA address of each DVMFS one by one, and map the starting LBA address and ending LBA address of each DVMFS to a continuous virtual address space. From the perspective of the virtual machine, the hard disk space is continuous; 22) Then, the physical address is directly obtained through IOMMU to access the virtual machine's disk. Each NVMe disk (NVMe disk refers to the virtual concept of NVMe disk, including physical NVMe disk and virtual NVMe disk. Virtual NVMe disk is NVMe disk implemented by software) is set with an Admin QPair and multiple I / O QPairs for sending and transmitting management instructions and data operation instructions. Since each NVMe disk device requires an NVMe admin qpair to receive management information, the NVMe disk device of each virtual machine in the Hypervisor uses the host software to simulate an NVMeadmin qpair. At the same time, the admin command is determined based on the metadata information of the virtual machine disk to determine whether it has the corresponding authority to execute; This embodiment uses QEMU, one of the commonly used hypervisors, to develop DNVMe and write a virtual NVMe disk for the virtual machine. The virtual NVMe device has at most the same number of Admin qpairs (1) and I / O qpairs as the physical NVMe disk. The admin qpair is taken over by the DNVMe Driver, and the I / O qpairs are transparently transmitted to the VFIO-pci driver.

[0040] The admin qpair in the virtual NVMe disk is used to process disk operations from the virtual machine. Because the physical disk cannot be directly managed by the virtual machine, the virtual machine's disk operation and management instructions are mainly mapped to operations on the DVMFS metadata / data and metadata VMFR partitions.

[0041] In addition, because the execution of admin commands in the virtual NVMe disk is not interfered between different virtual machines, it is only necessary to ensure the correct order of admin commands within the virtual machine. In order to ensure the fairness of command processing, the round-robin algorithm is used in the mapping of multiple adminsq to physical device sq.

[0042] The I / O qpairs process all normal NVMe read and write instructions, converting the virtual device address to the actual physical disk address; using IOMMU to first convert the virtual address to the physical address of the physical NVMe disk, and then put the command located in the qpair into the sq queue of the physical NVMe disk. The mapping relationship between the virtual address and the physical address has been submitted to the IOMMU according to the first and last addresses of the data partition of the DVMFS during initialization.

[0043] Due to the limited nature of the IOMMU mapping table, an LBA address translation table mechanism similar to a page table is set up, and the LBA address translation table is saved in memory for quick search. If the LBA address mapping information cannot be found in the IOMMU, the current mapping information is obtained from the LBA address translation table. The LBA address translation table is constructed using the first and last addresses of the data partitions of each DVMFS when the host physical NVMe disk is initialized.

[0044] In order to make full use of the qpair of the physical NVMe disk, tasks are evenly distributed to the physical NVMe disk qpair according to the current number of virtual machines and the queue width supported by the physical NVMe disk.

[0045] Assume that the number of virtual machines is N, and the maximum number of I / O qpairs supported by the physical NVMe disk is M. Then the maximum number of queues for the virtual NVMe disk in the virtual machine is M, and nm represents the mth queue of the nth virtual machine.

[0046] In order to maintain the order of commands within the same qpair (NVMe does not guarantee the order of commands between qpairs), the minimum unit of mapping between virtual qpair and physical qpair is queue rather than single command. The queue of virtual NVMe disk is mapped to the queue of physical NVMe disk in a one-to-one correspondence. To avoid competition for qpair0, a staggered method is used, such as Figure 5 As shown, according to the virtual machine initialization order, the qpair0 of the starting virtual queue is mapped to different qpairs on the physical NVMe disk, and then the subsequent queues are mapped in sequence.

[0047] In addition, to ensure the reusability of operations, operations with similar locations on the physical disk are preferentially assigned to the same qpair set to increase the chance of data reuse when the device traverses the qpair to execute commands.

[0048] Since I / O qpairs are shared by all virtual machines, each virtual machine can access any address. To ensure that each virtual machine disk can only access its own DVMFS space, the LBA mapping list maintained by the software in the Hypervisor and the linkage mechanism of IOMMU mapping are used. The steps are as follows: When an I / O request reaches the IOMMU, the IOMMU first converts the virtual address of the I / O request into a physical address, and at the same time verifies the source virtual machine of the I / O request and the virtual machine occupying the virtual disk to which the corresponding physical address belongs, using the unique number of the virtual machine for verification. If the unique number of the source virtual machine of the request is the same as the unique number of the virtual machine occupying the virtual disk to which the corresponding physical address belongs, the I / O request proceeds normally; if it is found that the virtual machines do not match, an error is returned and the execution of the instruction is terminated. Since the I / O request is performed by the IOMMU hardware, the impact on performance is almost the same as that of a normal virtual machine using the IOMMU, and the worst performance is 1.13% different from the plain case. Example 2

[0049] In step 2, during NVMe disk transparent transmission, based on the existing Virtio-blk mechanism, the performance is improved by optimizing the cache strategy and improving the data transmission efficiency. An efficient cache layer is set up to store frequently accessed data in memory, reducing dependence on the host file system. This can improve the read and write speed while maintaining flexibility. Example 3

[0050] In step 1, the Hypervisor may be VMware, Virtualbox, KVM, etc.

[0051] The above is a detailed description of the implementation mode of the present invention in conjunction with the accompanying drawings, but the above is only a preferred implementation mode of the present invention. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the technical principles of the present invention. These improvements and modifications should also be regarded as the scope of protection of the present invention.

Claims

1. A virtual machine disk partitioning and accelerated access method based on NVMe disk, characterized in that: The following steps are involved: Step 1. Partition the virtual machine disk, specify the virtual machine disk partition format and the virtual machine disk metadata format, and specify the layout of the partition on the GPT partition table; record the first N-1 partition formats as DVMFS and the last partition format as VMFR in the first and last two GPT Records of the host machine's GPT partition table, and VMFR contains a pointer to DVMFS; Step 2: Perform NVMe disk transparent transmission in Hypervisor.

2. A method for partitioning and accelerating access to a virtual machine disk based on an NVMe disk according to claim 1, characterized in that: In step 1, DVMFS is the area where the virtual disk of the virtual machine is stored, including the following fields: 1)FS Header: used to identify the file system header; 2) Metadata: saves the information of the current partition; 3) Next File System Ptr and Prev File System Ptr are used to indicate the LBA addresses of the previous and next continuous spaces in the current partition for fast addressing.

3. A method for partitioning and accelerating access to virtual machine disks based on NVMe disks according to claim 1, characterized in that: In step 1, in the Hypervisor, the disk capacity of the virtual machine is adjusted using Algorithm 1, including operations of expanding and shrinking the disk, including the following steps: 1) Use the ADJUSTVMDISK(vmdisk, dst_size, force = false) function to call the operation. The input parameters include the virtual disk object vmdisk, the target size dst_size, and a mandatory parameter force; 2) If dst_size is less than or equal to 0, throw a ParamErrorException; 3) If the target size dst_size is smaller than the current disk size and force is true, call the SHRINKVMDISK(vmdisk, dst_size) function to shrink the disk. 4) If force is false and the target size is smaller than the current disk size, a DataLossException is thrown; 5) If the target size dst_size is larger than the current disk size, call the EXPANDVMDISK(vmdisk, dst_size) function to perform the expansion operation.

4. A method for partitioning and accelerating access to a virtual machine disk based on an NVMe disk according to claim 3, characterized in that: In step 3), the disk shrinking process SHRINKVMDISK(vmdisk, dst_size) includes: 31) Calculate the size nr_size that needs to be reduced, that is, the current size minus the target size; 32) When nr_size is greater than 0, perform the following steps: Recursively access the partition pointed to by the partition's NextPtr until the last host partition of the virtual disk is found; Check if the size of the last host partition of the virtual disk is greater than or equal to nr_size; If yes, call the CutDVMFS function to cut, and set nr_size to 0; the CutDVMFS function sets the size of the target partition to [original size - nr_size], modifies the Metadata part of DVMFS, modifies NextPtr to NULL, updates the field of the partition size in the VMFR part, and finally uses the actual occupied LBA position of the DVMFS partition to update the occupied space bit table in VMFR; If not, subtract the size of the partition from nr_size, delete the partition, delete the VMFR partition metadata of the partition, set the NextPtr of the previous DVMFS partition to NULL, and finally update the occupied space bit table on VMFR.

5. A method for partitioning and accelerating access to virtual machine disks based on NVMe disks according to claim 3, characterized in that: In step 5), the expansion disk process EXPANDVMDISK(vmdisk, dest_size) includes: 51) Calculate the size nr_size that needs to be expanded, that is, the target size minus the current size; 52) Check the available space on the host. If it is insufficient, throw NoEnoughSpaceException and the operation ends. 53) When nr_size is greater than 0, perform the following steps: Find the last host partition of the virtual disk; Get the free space outside the last host partition of the virtual disk by looking up the unused space in the VMFR occupied space bit table; If the available space is greater than or equal to nr_size, the partition is expanded and nr_size is set to 0, and the occupied space bit table in VMFR is updated; If the available space is insufficient, recursively search for free space blocks and add new partitions as needed, update nr_size to nr_size minus the current free space size, and update the occupied space bit table in VMFR.

6. A method for partitioning and accelerating access to virtual machine disks based on NVMe disks according to claim 1, characterized in that: In step 1, the Consistency bit of each DVMFS in VMFR is used to determine whether it is written correctly. If the Consistency bit is set to 1, it means that the metadata of the partition is modified and not written correctly. According to the situation of the Consistency bit, choose to accept the modification of DVMFS or accept the modification of VMFR. The method is as follows: Condition 1: Check whether the existing checksum is the same as the checksum recalculated by the current partition FS Header; Condition 2: Whether the Consistency bit in VMFR is 0; If both conditions 1 and 2 are not met, the metadata of VMFR is accepted; if condition 1 is met but condition 2 is not met, the metadata of DVMFS is accepted; if condition 1 is not met but condition 2 is met, the metadata of VMFR is accepted; if condition 1 is met and condition 2 is met, there is no data inconsistency.

7. A method for partitioning and accelerating access to virtual machine disks based on NVMe disks according to claim 1, characterized in that: In step 2, include: 21) A middle layer DNVMe Driver is added between Hypervisor and VFIO-pci. The middle layer uses IOMMU to isolate device addresses, obtains the LBA mapping block of each virtual machine disk according to the physical address LBA of the first DVMFS to which the virtual disk bound to the virtual machine belongs, and registers the LBA mapping block of each virtual machine disk with IOMMU, registers the start LBA address and end LBA address of each DVMFS one by one, and maps the start LBA address and end LBA address of each DVMFS to a continuous virtual address space; 22) Directly obtain the physical address through IOMMU to access the virtual machine's disk, NVMe disk, each NVMe disk is set with an Admin QPair and multiple I / O QPairs for sending and transmitting management instructions and data operation instructions, and the NVMe disk includes a physical NVMe disk and a virtual NVMe disk; in the Hypervisor, the NVMe disk device of each virtual machine uses the host software to simulate an NVMe admin qpair, and at the same time, determines whether the admin command has the corresponding authority to execute according to the metadata information of the virtual machine disk; In step 22), the virtual NVMe disk has at most the same number of Admin qpairs and I / O qpairs as the physical NVMe disk, the admin qpair is taken over by the DNVMe Driver, and the I / O qpairs are transparently transmitted to the VFIO-pci driver; The I / O qpairs process all normal NVMe read and write instructions, converting the virtual device address to the actual physical disk address; using IOMMU to first convert the virtual address to the physical address of the physical NVMe disk, and then put the command located in the qpair into the sq queue of the physical NVMe disk. The mapping relationship between the virtual address and the physical address is submitted to the IOMMU according to the first and last addresses of the data partition of the DVMFS during initialization.

8. A method for partitioning and accelerating access to virtual machine disks based on NVMe disks according to claim 7, characterized in that: In step 22), an LBA address translation table mechanism is set, and the LBA address translation table is saved in memory for quick search. If the LBA address mapping information cannot be found in the IOMMU, the current mapping information is obtained from the LBA address translation table. The LBA address translation table is constructed using the first and last addresses of the data partitions of each DVMFS when the host physical NVMe disk is initialized.

9. A method for partitioning and accelerating access to virtual machine disks based on NVMe disks according to claim 7, characterized in that: The smallest unit for mapping virtual qpair and physical qpair is queue. The queue of virtual NVMe disk is mapped to the queue of physical NVMe disk in a one-to-one correspondence. According to the initialization order of virtual machines, qpair0 of the starting virtual queue is mapped to different qpairs on the physical NVMe disk, and then the next queues are mapped in sequence.

10. The method for partitioning and accelerating access to a virtual machine disk based on an NVMe disk according to claim 7, characterized in that: The LBA mapping list and IOMMU mapping are linked. The steps are as follows: When an I / O request reaches the IOMMU, the IOMMU first converts the virtual address of the I / O request into a physical address, and at the same time verifies the source virtual machine of the I / O request and the virtual machine that occupies the virtual disk to which the corresponding physical address belongs, using the unique number of the virtual machine for verification. If the unique number of the source virtual machine of the request is the same as the unique number of the virtual machine that occupies the virtual disk to which the corresponding physical address belongs, the I / O request proceeds normally; if it is found that the virtual machines do not match, an error is returned and the execution of the instruction is terminated.

Images