Virtual machine data backup method, storage medium and electronic device

Abstract

The present application discloses a method, storage medium, and electronic device for backing up virtual machine data, which relates to the field of computers. The method comprises: utilizing the characteristics of a back-end driver corresponding to a virtual machine to read and write the virtual disk of the virtual machine according to the disk read and write requests sent by the virtual machine, and a data bitmap to record the disk location of the virtual machine data that has changed in the virtual disk; updating the data bitmap according to the running location of the back-end driver; and when it is detected that the back-end driver is running on a kernel-mode program, allocating target storage space for the kernel-mode program and controlling the kernel-mode program to update the data bitmap stored in the target storage space. Finally, according to the target data bitmap stored in the target storage space, backing up the target virtual machine data that has changed in the virtual disk, thereby solving technical problems such as the poor applicability of the backup method for virtual machine data and achieving the technical effect of enhancing the applicability of the backup method for virtual machine data.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of computers, and in particular to a method for backing up virtual machine data, a storage medium, and an electronic device. Background Art

[0002] In a virtualized environment, backing up virtual machine data is a crucial step in ensuring data security and system reliability. In existing technologies, virtual machine data backup typically relies on the Change Block Tracking (CBT) bitmap function to implement incremental backups. During virtual machine operation, the system obtains data change information in real time and stores this information in the CBT bitmap. When a backup is required, only the changed virtual machine data recorded in the CBT bitmap needs to be backed up to complete the backup. However, existing technologies have limitations in certain situations. For example, in specific virtual machine operating environments, traditional backup methods may be unable to capture data changes, resulting in the failure of the backup function and limiting the applicability of backup methods in different scenarios.

[0003] In view of the technical problems in related technologies, such as the poor applicability of virtual machine data backup methods, no effective solutions have been proposed. Summary of the Invention

[0004] The embodiments of the present application provide a method for backing up virtual machine data, a storage medium, and an electronic device to at least solve technical problems in related technologies such as poor applicability of the method for backing up virtual machine data.

[0005] According to one embodiment of the present application, a method for backing up virtual machine data is provided, comprising:

[0006] Detecting the current running position of a backend driver corresponding to the virtual machine, wherein the backend driver is used to read and write the virtual disk of the virtual machine according to the disk read and write requests sent by the virtual machine;

[0007] In a case where it is detected that the running location indicates that the backend driver is running on the kernel-mode program, a target storage space is allocated for the kernel-mode program;

[0008] Controlling the kernel state program to update a data bitmap stored in the target storage space, wherein the data bitmap is used to record the disk location of the changed virtual machine data in the virtual disk;

[0009] Back up the target virtual machine data that has been changed in the virtual disk according to the target data bitmap stored in the target storage space.

[0010] The present application also provides an electronic device, comprising: a memory for storing a computer program; and a processor for implementing the steps of any of the above-mentioned virtual machine data backup methods when executing the computer program.

[0011] The present application also provides a computer-readable storage medium, in which a computer program is stored. When the computer program is executed by a processor, the steps of any of the above-mentioned virtual machine data backup methods are implemented.

[0012] The present application also provides a computer program product, including a computer program, which implements the steps of any of the above-mentioned virtual machine data backup methods when executed by a processor.

[0013] The present application utilizes the characteristics that the backend driver corresponding to a virtual machine can read and write the virtual disk of the virtual machine according to disk read and write requests sent by the virtual machine, and that the data bitmap can record the disk location of the changed virtual machine data in the virtual disk. The data bitmap is updated according to the running location of the backend driver. When it is detected that the backend driver is running on a kernel-mode program, a target storage space is allocated to the kernel-mode program, and the kernel-mode program is controlled to update the data bitmap stored in the target storage space. Finally, the target virtual machine data that has changed on the virtual disk is backed up according to the target data bitmap stored in the target storage space. That is, by allocating target storage space to the kernel-mode program, even in a specific virtual machine operating environment where the backend driver is running on the kernel-mode program, the kernel-mode program can update the data bitmap in the allocated target storage space to record the disk location of the changed virtual machine data in the virtual disk, thereby achieving backup of the virtual machine data. This overcomes the problem in the prior art of the lack of backup functionality due to the inability to obtain data change information in the kernel-mode program in specific virtual machine operating environments. Therefore, this solves the technical problem of poor applicability of virtual machine data backup methods in related technologies, achieving the technical effect of enhancing the applicability of virtual machine data backup methods. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] In order to more clearly illustrate the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0015] Figure 1 This is a hardware structure block diagram of a computer device for a method for backing up virtual machine data according to an embodiment of the present application;

[0016] Figure 2This is a flowchart of a method for backing up virtual machine data in the related art;

[0017] Figure 3 is a flowchart of a method for backing up virtual machine data according to an embodiment of the present application;

[0018] Figure 4 is a schematic diagram of a backend driver running on a kernel-mode program according to an embodiment of the present application;

[0019] Figure 5 is a structural diagram of a data bitmap whose format type matches the first format according to an embodiment of the present application;

[0020] Figure 6 is a flow chart of a load control instruction indicating loading a data bitmap according to an embodiment of the present application;

[0021] Figure 7 is a schematic diagram of an electronic device according to an embodiment of the present application. DETAILED DESCRIPTION

[0022] The following will be combined with the accompanying drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0023] It should be noted that, in the description of this application, the terms "comprises," "includes," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or device 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 device. The terms "first," "second," etc., in this application are used to distinguish similar objects, and are not used to describe a particular order or sequence.

[0024] In order to enable those skilled in the art to better understand the present application, the present application is further described in detail below with reference to the accompanying drawings and specific implementation methods.

[0025] The method embodiments provided in the embodiments of the present application can be executed in a server device or a similar computing device. Taking running on a server device as an example, Figure 1 This is a hardware structure diagram of a computer device for a method of backing up virtual machine data according to an embodiment of the present application. Figure 1 As shown, the server device may include one or more ( Figure 1Only one is shown) a processor 102 (the processor 102 may include but is not limited to a microprocessor MCU or a programmable logic device FPGA) and a memory 104 for storing data. The server device may also include a transmission device 106 and an input / output device 108 for communication functions. It will be understood by those skilled in the art that Figure 1 The structure shown is only for illustration and does not limit the structure of the above server device. Figure 1 More or fewer components than shown, or with Figure 1 Different configurations shown.

[0026] The memory 104 can be used to store computer programs, for example, software programs and modules of application software, such as the computer program corresponding to the method for backing up virtual machine data in the embodiment of the present application. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, that is, implementing the above method. The memory 104 may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include a memory remotely located relative to the processor 102, and these remote memories may be connected to the server device via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0027] Transmission device 106 is used to receive or transmit data via a network. A specific example of the aforementioned network may include a wireless network provided by a communication provider of the server device. In one embodiment, transmission device 106 includes a network interface controller (NIC), which can be connected to other network devices via a base station to enable communication with the Internet. In another embodiment, transmission device 106 may be a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.

[0028] The terms involved in the embodiments of this application are explained as follows:

[0029] VMM (Virtual Machine Monitor): manages actual physical resources downward and provides logical resources to different virtual machines upward;

[0030] QEMU (Quick Emulator): A user-mode emulator that implements the VMM layer through software emulation and simulates the hardware environment of the virtual machine, including the CPU, memory, and I / O devices.

[0031] KVM (Kernel-based Virtual Machine): System virtualization module responsible for managing the operating environment of virtual machines.

[0032] This application proposes a method for backing up virtual machine data. Before describing the optional embodiments of this application, in order to better understand the inventive concept of this application and the creativity of this solution, the relevant technologies are first described: Figure 2 This is a flowchart of a method for backing up virtual machine data in related technology. Figure 2 As shown in the figure, in a virtualized environment, the front-end and back-end architecture using the Virtio protocol for IO operations includes a front-end driver and a back-end device. The front-end driver and the back-end device transmit data through shared memory. The front-end driver is the driver corresponding to the Virtio emulated device in the virtual machine kernel space, and the back-end device is the driver that can handle the virtual machine's disk read and write requests in the user-mode program (such as the QEMU layer). The backup method for virtual machine data in the above virtual machine environment is as follows:

[0033] Step 1: The application in the virtual machine user space initiates a read / write (IO) request, such as a disk read / write request or network communication;

[0034] Step 2: The front-end driver receives the IO request, encapsulates the IO request into a data packet that complies with the Virtio protocol format and stores it in the shared memory. It also marks the IO request as "available", meaning it is ready to be processed by the back-end driver, and then notifies the back-end driver in the QEMU layer of the new IO request.

[0035] Step 3: The backend driver listens to the notification mechanism. Once a notification is received, it reads the request from shared memory, parses the request, determines the request type (read or write), the disk offset and data length of the data involved, and records the data change information corresponding to this I / O request in a bitmap.

[0036] Step 4: The backend driver encapsulates the IO request into a format that conforms to the host hardware device, and requests the driver in the host kernel state program (such as the KVM layer) to perform the actual IO operation through a system call;

[0037] Step 5: After receiving the request, the driver in the KVM layer directly interacts with the physical hardware resources (such as disks, network interfaces, etc.) to complete the actual IO operation (reading data from or writing data to physical hardware resources), and then returns the processing results (such as operation success, failure reason, etc.) to the QEMU layer;

[0038] Step 6: After receiving the processing result, the back-end driver of the QEMU layer stores the processing result in the shared memory and notifies the front-end driver through the event notification mechanism;

[0039] Step 7: After receiving the notification from QEMU, the front-end driver obtains the processing result from the shared memory and returns the processing result to the application in the virtual machine user space;

[0040] When disk data needs to be backed up, data change information is obtained from the bitmap of the QEMU layer, and the changed data is backed up.

[0041] The related art virtual machine data backup method has the following technical problems:

[0042] 1) When processing I / O operations, frequent switching between the KVM layer and the QEMU layer results in additional system call overhead, affecting overall I / O processing and backup efficiency.

[0043] 2) The backup method relies on the QEMU layer being able to obtain data change information, and is only applicable when the Virtio protocol is used to handle I / O operations. However, in certain virtual machine operating environments, such as when the KVM layer handles data I / O operations, the QEMU layer may not be able to obtain this information and, therefore, cannot record data change information in the bitmap, rendering the backup function ineffective.

[0044] To solve the above problems, an embodiment of the present application provides a method for backing up virtual machine data. Figure 3 Flowchart of a method for backing up virtual machine data according to an embodiment of the present application. Figure 3 As shown, the process includes the following steps:

[0045] Step S12: detecting the current running position of a backend driver corresponding to the virtual machine, wherein the backend driver is used to read and write the virtual disk of the virtual machine according to the disk read and write request sent by the virtual machine;

[0046] Step S14, when it is detected that the running location indicates that the back-end driver is running on the kernel-mode program, allocating target storage space for the kernel-mode program;

[0047] Step S16, controlling the kernel state program to update a data bitmap stored in the target storage space, wherein the data bitmap is used to record the disk location of the changed virtual machine data in the virtual disk;

[0048] Step S18: backing up the changed target virtual machine data in the virtual disk according to the target data bitmap stored in the target storage space.

[0049] Optionally, in this embodiment, the backend driver refers to a software component responsible for processing disk read and write requests sent by virtual machines in a virtualized environment, including but not limited to the following two main forms: a virtio backend device running in a user-mode program (such as the QEMU layer), which is used to process disk read and write requests for packets encapsulated in the virtio protocol format, wherein the virtio protocol accelerates IO operations by sharing memory between the front-end driver and the back-end driver of the virtual machine; and a vhost driver running in the kernel-mode program of the host machine, which directly processes disk read and write requests sent by the virtual machine in the kernel mode. The backend driver in this embodiment takes the two cases of running in the user-mode program and running in the kernel-mode program as examples, but the running location of the backend driver is not limited. In fact, according to different system architectures or specific performance optimization requirements, there are backend drivers with other running locations to optimize the virtual machine disk IO performance in specific scenarios. For example, the backend driver can also be integrated into a specific hardware controller to further improve the efficiency and performance of IO processing.

[0050] Optionally, disk read and write requests may include, but are not limited to, read requests and write requests, wherein a read request involves reading data from the host machine's physical storage device. After the back-end driver receives the read request, it parses the location and size of the data to be read, reads the corresponding data from the physical hardware resources through the driver in the host machine's kernel state, and writes it to a specified user-state buffer. A write request involves writing data from the user-state buffer to the host machine's physical storage device. After the back-end driver receives the write request, it parses the location and size of the data to be written, reads the data from the user-state buffer, and writes the data to the physical hardware resources through the driver in the host machine's kernel state.

[0051] Optionally, in this embodiment, the method for detecting the current running location of the backend driver may include, but is not limited to: reading the virtual machine's configuration file or virtualization management interface, for example, if the vhost function is enabled, determining that the current running location of the backend driver is a kernel-mode program; monitoring process and thread activities on the host machine to identify processes or threads related to the backend driver. By analyzing the properties of these processes or threads (such as memory mappings, open file descriptors, etc.), the running location of the backend driver can be inferred. For example, if an IO operation is monitored to be performed through the vhost, the current running location of the backend driver can be determined to be a kernel-mode program; analyzing system logs and QEMU log files to identify log entries related to the backend driver, and judging whether the IO request is processed by QEMU or the vhost based on the information recorded in the log entries, thereby judging whether the running location of the backend driver is a user-mode process or a kernel-mode process.

[0052] Optionally, in this embodiment, Figure 4Schematic diagram of a back-end driver running on a kernel-mode program according to an embodiment of the present application. Figure 4 As shown, kernel-mode programs may be, but are not limited to, programs running in the kernel space of an operating system, including KVM. When it is detected that a back-end driver (back-end device) is running on a kernel-mode program, a target storage space is allocated for the kernel-mode program. The target storage space may be, but is not limited to, a specific file or directory, or a dedicated backup device or partition.

[0053] Optionally, in this embodiment, when it is detected that the running location is used to indicate that the back-end driver is running on a kernel-mode program, when the virtual machine data in the virtual disk changes, the kernel-mode program can be controlled to update the data bitmap stored in the target storage space through, but not limited to, the following steps: allocating target storage space to the kernel-mode program, the kernel-mode program listens to the disk read and write requests processed by the back-end driver, and when it is identified that the virtual machine data has changed, the data bitmap in the target storage space is updated according to the disk position of the changed virtual machine data.

[0054] Optionally, in this embodiment, when it is detected that the running position is used to indicate that the back-end driver is running on a user-mode program, when the virtual machine data in the virtual disk changes, the user-mode program can be controlled to update the data bitmap stored in the target storage space through, but not limited to, the following steps: the user-mode program listens to the disk read and write requests processed by the back-end driver, and when it is identified that the virtual machine data has changed, the data bitmap in the target storage space is updated according to the disk position of the changed virtual machine data.

[0055] Optionally, in this embodiment, the target virtual machine data that has changed in the virtual disk is backed up according to the target data bitmap stored in the target storage space. The backup process may include, but is not limited to: when virtual machine data needs to be backed up, obtaining the stored data bitmap from the target storage space, identifying the disk location of the data to be backed up (i.e., the target virtual machine data) based on the disk location of the changed virtual machine data recorded in the data bitmap, and then reading the changed data from the virtual disk, writing the read data to the corresponding location of the backup storage device, and updating the backup management information at the same time, including the backup time, backup version, backup status, etc.

[0056] By allocating target storage space to the kernel-state program, even if the virtual machine is in a specific virtual machine operating environment where the back-end driver runs on the kernel-state program, the kernel-state program can update the data bitmap in the allocated target storage space and record the disk location of the virtual machine data that has changed in the virtual disk, thereby realizing backup of the virtual machine data. This overcomes the problem in the prior art of the lack of backup function due to the inability to obtain data change information in the kernel-state program in a specific virtual machine operating environment, thereby achieving the technical effect of enhancing the applicability of the backup method for virtual machine data, and further solving the technical problem of poor applicability of the backup method for virtual machine data.

[0057] As an optional solution, allocate target storage space for kernel-mode programs, including:

[0058] S21, detecting whether there is currently a storage space that matches a bitmap parameter, wherein the bitmap parameter is used to indicate the size of the space required to store the desired data bitmap, and the desired data bitmap is a data bitmap that allows recording the disk location of the changed virtual machine data in the virtual disk;

[0059] S22, when it is detected that there is a reference storage space matching the bitmap parameter, transmitting a reference space address of the reference storage space to the kernel state program, wherein the reference space address is used to identify a location of the reference storage space, and the target storage space includes the reference storage space;

[0060] S23, when it is detected that there is no storage space matching the bitmap parameters, a candidate storage space is created according to the bitmap parameters, and the candidate space address of the candidate storage space is transmitted to the kernel state program, wherein the candidate space address is used to identify the location of the candidate storage space, and the target storage space includes the candidate storage space.

[0061] Optionally, in this embodiment, the expected data bitmap may be, but is not limited to, a data bitmap that matches virtual disk backup requirements, such as virtual disk size, bitmap granularity, and alignment requirements. The expected data bitmap is capable of recording change information for data blocks across the entire virtual disk. The bitmap parameter may be, but is not limited to, the memory space required to meet virtual disk backup requirements, such as virtual disk size, bitmap granularity, and alignment requirements.

[0062] Optionally, in this embodiment, the target storage space can be allocated to the kernel-mode program through, but not limited to, the following steps: First, it is detected whether there is a storage space whose memory space size matches the bitmap parameters. In the case where it is detected that there is a reference storage space that matches the bitmap parameters, that is, the memory space size of the reference storage space meets the virtual disk backup requirements such as the size of the virtual disk, the bitmap granularity and the alignment requirements, the target storage space will directly use the reference storage space that has been found without creating a new storage space. QEMU transmits the reference space address of the storage space to the kernel-mode program for registration, and can also transmit the size of the storage space and related memory attributes (such as whether it is readable and writable) to the kernel-mode program for registration, wherein the reference space address can be the virtual address of the reference storage space or the physical address corresponding to the reference storage space. The kernel-mode program can access the parameter storage space through the reference space address.

[0063] Optionally, in this embodiment, when it is detected that there is no storage space that matches the bitmap parameters, that is, there is no storage space whose memory space size meets the virtual disk backup requirements such as the size of the virtual disk, bitmap granularity and alignment requirements, it is necessary to create a storage space as the target storage space based on the bitmap parameters, and transmit the candidate space address of the created candidate storage space that matches the bitmap parameters to the kernel-mode program for registration. The size of the candidate storage space and related memory attributes (such as whether it is readable and writable) can also be transmitted to the kernel-mode program for registration, wherein the candidate space address can be the virtual address of the candidate storage space or the physical address corresponding to the candidate storage space. The kernel-mode program can access the candidate storage space through the candidate space address.

[0064] As an optional solution, before creating the candidate storage space according to the bitmap parameters, the method further includes:

[0065] S31, obtaining disk parameters and granularity parameters of the virtual disk, wherein the disk parameters are used to indicate the capacity of the virtual disk, and the granularity parameters are used to indicate the backup granularity of backing up data in the virtual disk;

[0066] S32: Generate bitmap parameters according to the disk parameters and the granularity parameters.

[0067] Optionally, in this embodiment, the bitmap parameters may be obtained by, but not limited to, the following steps: obtaining disk parameters and granularity parameters of the virtual disk; and then calculating the bitmap parameters according to the disk parameters and granularity parameters.

[0068] Optionally, in this embodiment, the disk parameter can be the total size of the virtual disk, which is used to determine how much storage space is required to accommodate the key information of the entire data bitmap. The granularity parameter can be the backup granularity for backing up the data in the virtual disk. The backup granularity determines the size of the data block represented by each bit in the data bitmap. A smaller granularity can provide finer-grained backup, but requires more storage space to store the bitmap. For example, when the granularity parameter is 4KB, it means that the virtual disk is divided into multiple 4KB data blocks.

[0069] Optionally, in this embodiment, when it is necessary to reduce the memory usage, the status of the virtual machine data in the virtual disk can be recorded bit by bit. Assuming that a byte is composed of 8 bits, if the granularity of the bitmap is 1MB, that is, each bit in the bitmap represents a 1MB data block, then one byte can correspond to the status of eight data blocks, that is, 8MB of data. For example, for a 1GB virtual disk, if one byte is directly used to represent the status of a data block, approximately 1GB of memory is required to store the data status information. When a bitmap is used and each bit represents the status of a 1MB data block, only approximately 1MB of memory is required to store the status information of the entire virtual disk.

[0070] As an optional solution, generate bitmap parameters based on disk parameters and granularity parameters, including:

[0071] S41, calling a space creation interface to divide the virtual disk into multiple data blocks according to disk parameters and granularity parameters to obtain a data block set;

[0072] S42, calling the space creation interface to determine the amount of data required to record the location information and status information of all data blocks in the data block set as a bitmap parameter, wherein the location information is used to indicate the disk position of the corresponding data block in the virtual disk, and the status information is used to indicate whether the virtual machine data stored in the corresponding data block has changed.

[0073] Optionally, in this embodiment, the step of generating the bitmap parameters according to the disk parameter (disksize) and the granularity parameter (granularity) may include, but is not limited to:

[0074] In the first step, QEMU divides the virtual disk into multiple data blocks according to the disk parameters and granularity parameters through the space creation interface (qmp_vhost_dirty_bitmap_add interface), and obtains the data block set, that is, the number of bits (size) required to cover the data blocks in the entire virtual disk, which can be calculated according to the following formula:

[0075] size = (((disksize + granularity–1) / granularity)+7) / 8.

[0076] The (disksize + granularity – 1) / granularity portion gives the number of blocks required to overwrite the entire virtual disk, ensuring that the entire virtual disk is fully overwritten even if the disk parameters are not integer multiples of the backup granularity. The (number of blocks + 7) / 8 portion gives the number of bytes. Since each byte contains 8 bits, the total number of bits must be a multiple of 8.

[0077] In the second step, the amount of data required to record the location and status information of all data blocks in the data block set is determined as the bitmap parameter. The specific bitmap parameter, that is, the memory size (memsize) that meets the alignment requirement (for example, 4KB), can be calculated according to the following formula:

[0078] memsize = ((size + 4095) / 4096)×4096.

[0079] The (size + 4095) / 4096 part ensures that the memory size is an integer multiple of 4096 bytes (4KB), giving the required number of 4KB blocks. The number of blocks × 4096 gives the final memory size, ensuring that the 4KB alignment requirement is met.

[0080] Optionally, in this embodiment, after obtaining the bitmap parameters, QEMU calls the memory allocation function (such as malloc, mmap, etc.) according to the bitmap parameters to apply for memory that meets the bitmap parameters in the user space. After the memory application is successful, the ioctl system is used to transmit the candidate space address of the allocated memory area (i.e., the candidate storage space) to the kernel-mode program (KVM) for registration, and the address and size of the shared memory are notified to the kernel-mode program. The kernel-mode program can access the candidate storage space through the candidate space address.

[0081] Optionally, in this embodiment, after the kernel-mode program is allocated to the created candidate storage space, it is necessary to initialize the memory area to store the data bitmap. The initialization operation includes clearing the bitmap area to zero or setting it to a specific initial value to indicate that there is no data change on the virtual disk at the initial moment.

[0082] As an optional solution, before transmitting the reference space address of the reference storage space to the kernel-mode program, the following steps are included:

[0083] S51, detecting the format type of the initial data bitmap currently stored in the reference storage space;

[0084] S52, when the format type is the first format, convert the initial data bitmap from the first format to the second format to obtain a candidate data bitmap, wherein the first format is the format type used by the user-state program to update the data bitmap stored in the reference storage space, and the second format is the format type used by the kernel-state program to update the data bitmap stored in the reference storage space.

[0085] Optionally, in this embodiment, the format type of the data bitmap can be identified by checking the metadata of the data bitmap, but is not limited to the first format. The first format is the format type used by the user mode program (such as QEMU) to update the data bitmap. Figure 5 is a structural diagram of a data bitmap whose format type matches the first format according to an embodiment of the present application, such as Figure 5 As shown, the data bitmap matching the first format can be a native QEMU bitmap, i.e., a data bitmap that conforms to the Hbitmap hierarchy. This employs an 8-layer structure, with only the topmost layer corresponding to each bit in a data block. Lower layers record modified bits in the upper layer. When a bit in the upper layer is 1, the lower layer records the corresponding bit. Queries can be traversed starting from the bottom layer and continuing to the upper layers only when the bit is 1, improving query speed and primarily used to speed up virtual machine migrations. The second format is used by kernel-mode programs to update data bitmaps. Since it is only used for backups, the data bitmap matching the second format (vhost layer bitmap format) can be a data bitmap that conforms to the topmost layer of the Hbitmap hierarchy.

[0086] Optionally, in this embodiment, when the presence of a reference storage space matching the bitmap parameters is detected, before transmitting the reference space address of the reference storage space to the kernel-mode program, it is necessary to ensure that the format type of the data bitmap currently stored in the reference storage space is the second format. Only then can the kernel-mode program update the data bitmap stored in the reference storage space. Therefore, before transmitting the reference space address of the reference storage space to the kernel-mode program, it is necessary to detect the format type of the data bitmap stored in the reference storage space (i.e., the initial data bitmap). If the format type of the initial data bitmap is the first format and does not match the second format, the format type of the initial data bitmap is converted from the first format to the second format.

[0087] Optionally, in this embodiment, before the reference space address of the reference storage space is transmitted to the kernel-state program, when it is detected that the format type of the data bitmap stored in the reference storage space matches the second format, the reference space address of the reference storage space can be transmitted to the kernel-state program without processing, so that the kernel-state program continues to use the initial data bitmap. Alternatively, two new fields can be added to the initial data bitmap to record the address and size of the shared memory.

[0088] Optionally, in this embodiment, when it is detected that the running position is used to indicate that the back-end driver is running on the user-mode program, and when it is detected that there is a storage space that matches the bitmap parameters, before the spatial address of the storage space is transmitted to the user-mode program, it is necessary to ensure that the format type of the data bitmap currently stored in the storage space is the first format, so that the user-mode program can update the data bitmap stored in the storage space. Therefore, before the reference spatial address of the storage space is transmitted to the user-mode program, it is necessary to detect the format type of the data bitmap stored therein, and when the format type of the data bitmap stored therein is the second format and does not match the first format, the format type of the data bitmap stored therein is converted from the second format to the first format. If it is detected that the format type of the data bitmap stored therein is the first format, no processing is required, and the user-mode program can continue to use the changed data bitmap.

[0089] As an optional solution, converting the initial data bitmap from the first format to the second format to obtain a candidate data bitmap includes:

[0090] S61, filtering out target location information and target status information from the initial data bitmap, wherein the target location information is used to indicate the disk location of each data block in the virtual disk, and the target status information is used to indicate whether the virtual machine data stored in each data block in the virtual disk has changed;

[0091] S62: Generate a candidate data bitmap in a second format according to the target position information and the target state information.

[0092] Optionally, in this embodiment, when the format type of the initial data bitmap is the first format and does not match the second format, the format type of the initial data bitmap can be converted from the first format to the second format through, but not limited to, the following steps: filtering out target location information indicating the disk location of each data block in the virtual disk, and target status information indicating whether the virtual machine data stored in each data block in the virtual disk has changed from the initial data bitmap, and generating a candidate data bitmap of the second format based on the target location information and the target status information.

[0093] Optionally, in this embodiment, if Figure 5As shown, if the target format is the bitmap format of the vhost layer and the initial data bitmap is the QEMU native HBitmap structure, only the top layer of the HBitmap structure is copied to form a candidate data bitmap of the second format (the bitmap format of the vhost layer).

[0094] Optionally, in this embodiment, if the target format is the QEMU native HBitmap structure and the initial data bitmap is in the vhost layer bitmap format, then 7 layers need to be completed. The hbitmap_set function of the QEMU layer can be used to set the corresponding data block to 1 in the top layer of the HBitmap structure (indicating that the data block has changed), and automatically update the modification bit record of the lower layer according to the rules of the QEMU native bitmap.

[0095] As an optional solution, controlling the kernel-mode program to update the data bitmap stored in the target storage space includes:

[0096] S71, controlling the kernel state program to detect whether the backend driver currently receives a disk read / write request;

[0097] S72, when detecting that the back-end driver currently receives a disk read / write request, controlling the kernel-mode program to extract an offset parameter and a length parameter from the disk read / write request, wherein the offset parameter is used to indicate the starting position of the reference virtual machine data requested to be changed in the disk read / write request in the virtual disk, and the length parameter is used to indicate the length of the storage location of the reference virtual machine data in the virtual disk;

[0098] S73, controlling the kernel state program to update the data bitmap stored in the target storage space according to the offset parameter and the length parameter.

[0099] Optionally, in this embodiment, the kernel-mode program monitors disk read / write requests processed by the back-end driver. When it detects that the back-end driver currently receives a disk read / write request, that is, when it detects that the virtual machine data may have changed, the kernel-mode program is controlled to extract the offset parameter and length parameter of the reference virtual machine data requested to be changed in the disk read / write request from the disk read / write request. Based on the obtained offset parameter and length parameter, the data block position corresponding to the reference virtual machine data is obtained, and the corresponding position in the data bitmap is marked. The bitmap state of the corresponding position is set to "1" or to a specific value to indicate that the data block at the corresponding position has changed.

[0100] Optionally, in this embodiment, the offset parameter of the reference virtual machine data may be the starting position of the reference virtual machine data on the virtual disk, indicating that the reference virtual machine data is calculated from the starting position of the virtual disk. Assuming that the offset parameter of the reference virtual machine data is 10KB, the starting position of the reference virtual machine data is the 10KB position on the virtual disk. The length parameter of the reference virtual machine data may be the length of the storage location occupied by the reference virtual machine data on the virtual disk, indicating the size of the storage space occupied by the reference virtual machine data starting from its starting position. Assuming that the length parameter of the reference virtual machine data is 8KB (i.e., 8192 bytes), this means that the reference virtual machine data occupies 8192 bytes of the virtual disk starting from its starting position.

[0101] As an optional solution, the control kernel state program updates the data bitmap stored in the target storage space according to the offset parameter and the length parameter, including:

[0102] S81, obtaining a granularity parameter of a virtual disk, wherein the granularity parameter is used to indicate a backup granularity for backing up data in the virtual disk;

[0103] S82, detecting reference position information of a reference data block storing reference virtual machine data according to an offset parameter, a length parameter, and a granularity parameter, wherein the reference data block is a data block in a virtual disk, the virtual disk being pre-divided into a plurality of data blocks according to the granularity parameter, and the reference position information is used to indicate a disk position of the reference data block in the virtual disk;

[0104] S83: Update the reference state information corresponding to the reference position information in the data bitmap to a first state value, wherein the state information in the first state value is used to indicate that the virtual machine data stored in the data block corresponding to the position information has changed.

[0105] Optionally, in this embodiment, when controlling the kernel-mode program to update the data bitmap stored in the target storage space based on the offset parameter and the length parameter, the kernel-mode program first obtains the virtual disk's granularity parameter. The granularity parameter may be the backup granularity for backing up the data in the virtual disk, which determines the size of the data block represented by each bit in the data bitmap. Then, based on the offset parameter (offset), the length parameter (length), and the granularity parameter (granularity), the program calculates the reference location information for the reference data block corresponding to the reference virtual machine data, i.e., the location of the data block corresponding to the reference virtual machine data. The specific calculation steps include:

[0106] The first step is to calculate the starting position (index) of the reference data block. The calculation formula is:

[0107] index = offset / granularity.

[0108] Among them, index represents the starting position of the reference data block and needs to be rounded up to ensure that the starting position is an integer.

[0109] The second step is to calculate the number of affected data blocks (count). The calculation formula is:

[0110] count = (length + granularity – 1) / granularity.

[0111] Here, count represents the total number of data blocks involved in the changed reference virtual machine data. The value is rounded up to ensure that all affected data blocks are covered.

[0112] According to the position index of the starting data block of the changed data and the total number count of data blocks involved in the changed data, the reference position information of the reference data block can be obtained, that is, count data blocks starting from the index index.

[0113] Optionally, in this embodiment, updating the reference state information in the data bitmap to the first state value based on the calculated reference position information may include: finding the corresponding bit in the data bitmap based on the calculated index and count, and setting the states of count bits in the data bitmap starting from index to "1" or a specific value (the first state value) to indicate that the data blocks at these locations have changed. Assume that the virtual disk's granularity parameter (granularity) is 4KB (i.e., 4096 bytes), and the offset parameter (offset) of the reference virtual machine data requested for change in the received disk read / write request is 10KB (i.e., 10240 bytes), and the length parameter (length) is 8KB (i.e., 8192 bytes). Substituting these values ​​into the formula for calculating the starting position (index) of the reference data block above yields index = 3, meaning that the starting position (index) of the reference data block corresponding to the reference virtual machine data is 3, indicating that the data block corresponding to the reference virtual machine data is the third data block, corresponding to the third bit in the data bitmap. Substituting the specific value into the formula for calculating the number of affected data blocks (count) above yields count = 3, indicating that the total number of data blocks affected by the changed reference virtual machine data is 3. Using index and count, we can obtain the reference location information of the reference data block, namely, count data blocks starting from index index, corresponding to the 3rd, 4th, and 5th bits in the data bitmap. The corresponding positions (3rd, 4th, and 5th bits) in the data bitmap are marked, and the bitmap status of the corresponding position is set to "1" or a specific value to indicate that the virtual machine data stored in the data block at the corresponding position has changed.

[0114] Through the above steps, the kernel-mode program can accurately update the data bitmap in the target storage space based on the offset and length parameters of the disk read and write requests, combined with the granularity parameters of the virtual disk, thereby efficiently recording changes to the virtual machine data in the virtual disk and providing support for virtual machine backup and migration.

[0115] As an optional solution, back up the target virtual machine data that has changed in the virtual disk according to the target data bitmap stored in the target storage space, including:

[0116] S91, filtering out backup location information corresponding to backup status information in a first state value from the corresponding status information and location information recorded in the target data bitmap, wherein the status information in the first state value is used to indicate that virtual machine data stored in a data block corresponding to the location information has changed, and the backup location information is used to indicate a disk location in the virtual disk of the data block in which the stored virtual machine data has changed;

[0117] S92: Back up the target virtual machine data stored in the virtual disk at the disk location indicated by the backup location information.

[0118] Optionally, in this embodiment, each bit in the target data bitmap corresponds to the status information and location information of a virtual machine data block, where a virtual machine data block is one of multiple data blocks obtained by partitioning a virtual disk at a fixed backup granularity. The status information indicates whether the virtual machine data stored in the virtual machine data block corresponding to the bit has changed, that is, whether a backup is required. If the status information corresponding to a bit in the target data bitmap is a first status value, it means that the virtual machine data stored in the virtual machine data block corresponding to the bit has changed and needs to be backed up. The location information indicates the index value of the bit, and the disk location of the virtual machine data block corresponding to the bit in the virtual disk can be obtained using the index value and the backup granularity.

[0119] Optionally, in this embodiment, the step of filtering out the backup location information corresponding to the backup status information in the first state value from the target data bitmap is as follows: first, traverse the target data bitmap, starting from the starting position of the target data bitmap, and check the status information of each bit one by one. Then, filter the backup location information that meets the conditions. If the status information of a certain bit is in the first state value (for example, "1"), it means that the virtual machine data stored in the data block at the corresponding position has changed and needs to be backed up. Then, the index value of the bit in the data bitmap, i.e., the backup location information, is recorded. The disk location of the corresponding data block in the virtual disk can be found through the backup location information, and the disk location of the virtual machine data that needs to be backed up in the virtual disk can be found.

[0120] Optionally, in this embodiment, after obtaining the location information of the data to be backed up (backup location information) from the target data bitmap, the location of the virtual machine data to be backed up in the virtual disk is located according to the backup location information, the virtual machine data corresponding to the backup location information is read, and the read target virtual machine data is written to the backup storage space, wherein the backup storage space can be a local disk, a network storage device or other storage medium that supports backup.

[0121] Optionally, in this embodiment, in order to ensure the integrity and consistency of the backup operation, the integrity of the data may be verified through checksums and / or hash values.

[0122] As an optional solution, before backing up the changed target virtual machine data in the virtual disk according to the target data bitmap stored in the target storage space, the method further includes:

[0123] S101, receiving a control instruction sent by a virtual machine;

[0124] S102, when receiving the export control instruction, calling the bitmap export interface to export the reference data bitmap stored in the target storage space to the bitmap storage space, wherein the export control instruction is used to instruct the export of the data bitmap in the storage space, and the bitmap storage space is a storage space that allows the data bitmap to be stored when the virtual machine is abnormal.

[0125] Optionally, in this embodiment, during the operation of the virtual machine, control instructions can be sent to perform corresponding operations on the data bitmap, including exporting, loading, and deleting, to ensure the security and availability of the data bitmap. The control instructions can be sent through a virtual machine management tool (such as the QEMU management tool) or an application within the virtual machine.

[0126] Optionally, in this embodiment, upon receiving a control instruction sent by a virtual machine and confirming that the control instruction is an export control instruction, a bitmap export interface, such as the QMP interface qmp_vhost_dirty_bitmap_dump of the QEMU layer, is called to export the reference data bitmap stored in the target storage space to the bitmap storage space. The export control instruction may instruct to export the data bitmap in the storage space to the bitmap storage space, wherein the bitmap storage space is a storage space that allows the data bitmap to be stored when the virtual machine is abnormal or in a specified state, and may be a dedicated backup file or storage device.

[0127] Optionally, in this embodiment, to ensure the efficiency and reliability of virtual machine data backup, recovery, and other operations, a unified export format is used to export the bitmap in memory, and detailed log information is recorded after the export is completed. Furthermore, since the bitmap is stored in little-endian byte order in the storage space, it must be converted to big-endian byte order after export for subsequent processing.

[0128] Optionally, in this embodiment, when the reference data bitmap stored in the target storage space is exported to the bitmap storage space, a unified export format may be set for the exported bitmap file. For example, the exported bitmap file may include:

[0129] name_len: records the length of the bitmap name in bytes. For example, if the bitmap name is "bitmap1", the value of name_len is 7;

[0130] name: Bitmap name, the length is specified by name_len, for example, "bitmap1".

[0131] disk_size: The total size of the virtual disk, usually in bytes. For example, if the virtual disk size is 100MB, the value of disk_size is 100 × 1024 × 1024 = 104857600.

[0132] Granularity: The granularity of the bitmap, which indicates the size of each data block, usually in bytes. For example, if the granularity is 4KB, the granularity value is 4096.

[0133] bitmapsize: the size of the bitmap, usually in bytes;

[0134] bitmap: The actual data of the bitmap, which represents the status of each data block in the virtual disk. Each bit corresponds to a data block. "1" indicates that the data block has been changed, and "0" indicates that the data block has not been changed.

[0135] After setting a unified export format, use a bitmap export API (such as qmp_vhost_dirty_bitmap_dump) to export the bitmap in memory to a local file. The export path must be specified in advance, for example, / path / to / exported_bitmap.bin.

[0136] Optionally, in this embodiment, since the bitmap in the storage space uses little-endian byte order, it needs to be converted to big-endian byte order after export, including: reading the exported bitmap file; for key fields in the file (such as name_len, disk_size, granularity, bitmapsize), reading them byte by byte and rearranging them in big-endian byte order; writing the converted data into a new file or overwriting the original file.

[0137] Optionally, in this embodiment, after the bitmap export operation is completed, detailed log information is recorded for subsequent recovery and review. The log information includes: the export time, the version of the exported data bitmap, the export path, and the export result, where the export result is used to indicate the status of the export success or failure.

[0138] Optionally, in this embodiment, when backing up the target virtual machine data that has changed in the virtual disk according to the target data bitmap stored in the target storage space, it also includes: calling the bitmap export interface, such as the QMP interface qmp_vhost_dirty_bitmap_dump of the QEMU layer, to export the target data bitmap stored in the target storage space to the bitmap storage space; converting the little-endian byte order used by the exported target bitmap file into big-endian byte order, for example, for key fields in the target bitmap file (such as name_len, disk_size, granularity, bitmapsize), read them byte by byte and rearrange them in big-endian byte order for byte parsing; converting the bitmap data in the target bitmap file into binary format; parsing the converted binary bitmap data bit by bit, and judging which data blocks need to be backed up according to the position of "1".

[0139] Through the above steps, this embodiment ensures efficient identification and processing of changed data blocks in the virtual disk during the backup process. By converting the bitmap from little-endian to big-endian, converting hexadecimal to binary, and performing bit-by-bit parsing, it is possible to accurately determine which data blocks require backup, thereby improving backup efficiency and ensuring data integrity and consistency.

[0140] As an optional solution, after calling the bitmap export interface to export the reference data bitmap stored in the storage space to the bitmap storage space, the method further includes:

[0141] S111, receiving a control instruction sent by the virtual machine;

[0142] S112, when a load control instruction is received, obtaining a reference data bitmap from the bitmap storage space, wherein the load control instruction is used to instruct to load a data bitmap in the bitmap storage space;

[0143] S113, detecting whether there is currently a storage space that matches the reference data bitmap;

[0144] S114, when it is detected that there is a first storage space matching the reference data bitmap, calling a bitmap loading interface to load the reference data bitmap into the first storage space;

[0145] S115 , when no storage space matching the reference data bitmap is detected, creating a second storage space matching the reference data bitmap, and calling a bitmap loading interface to load the reference data bitmap into the second storage space.

[0146] Optionally, in this embodiment, after the data bitmap is exported to the bitmap storage space, a control instruction sent by the virtual machine is received, and when it is confirmed that the control instruction is a loading control instruction, the currently stored reference data bitmap is obtained from the bitmap storage space, and the data bitmap in the bitmap storage space is loaded.

[0147] Optionally, in this embodiment, Figure 6 FIG. 1 is a flow chart of a load control instruction according to an embodiment of the present application indicating loading a data bitmap. Figure 6 As shown, the data bitmap in the bitmap storage space can be loaded through, but is not limited to, the following steps: First, the currently stored reference data bitmap is obtained from the bitmap storage space. Then, a detection is performed to determine whether a storage space matching the reference data bitmap exists. If a first storage space matching the reference data bitmap is detected, a bitmap loading interface is called to load the reference data bitmap into the first storage space. If no storage space matching the reference data bitmap is detected, a second storage space matching the reference data bitmap is created based on the size and format of the reference data bitmap, and the bitmap loading interface is called to load the reference data bitmap into the second storage space.

[0148] Optionally, in this embodiment, the method of creating a second storage space that matches the reference data bitmap based on the size and format of the reference data bitmap may include: QEMU calls a memory allocation function (such as malloc, mmap, etc.) to apply for memory that matches the size and format of the reference data bitmap in the user space based on the size and format of the reference data bitmap. The applied memory is the second storage space. By loading the reference data bitmap from the bitmap storage space and automatically detecting the status of the storage space to determine whether the storage space needs to be created, it can be ensured that the status of the data bitmap is quickly restored after the virtual machine is abnormal or the system is restarted, thereby ensuring the continuity and stability of the system.

[0149] Optionally, in this embodiment, after calling the bitmap loading interface to load the reference data bitmap into the first storage space / second storage space, when it is detected that the running location of the back-end driver is on the kernel-state program, QEMU uses the ioctl system to transfer the spatial address of the first storage space / second storage space to the kernel-state program for registration, and notifies the kernel-state program of the address and size of the first storage space / second storage space. The kernel-state program can access the first storage space / second storage space through the address of the first storage space / second storage space.

[0150] As an optional solution, after backing up the changed target virtual machine data in the virtual disk according to the target data bitmap stored in the target storage space, the method further includes:

[0151] S121, receiving a control instruction sent by the virtual machine;

[0152] S122 , when a deletion control instruction is received, calling a bitmap deletion interface to delete the data bitmap stored in the target storage space and release the target storage space, wherein the deletion control instruction is used to instruct to delete the data bitmap in the target storage space.

[0153] Optionally, in this embodiment, after backing up the changed target virtual machine data in the virtual disk according to the target data bitmap stored in the target storage space, when a control instruction sent by the virtual machine is received and the control instruction is confirmed to be a deletion control instruction, the bitmap deletion interface, such as the QMP interface qmp_vhost_dirty_bitmap_remove, is called to delete the data bitmap stored in the target storage space and release the target storage space to ensure the rational use of system resources, wherein the deletion control instruction can indicate the deletion of the data bitmap in the target storage space.

[0154] Optionally, in this embodiment, deleting the data bitmap stored in the target storage space using the bitmap deletion interface may include: first, the QEMU layer sends a notification to the kernel-mode process via an ioctl system call, informing it that the target storage space is about to be released. Accordingly, upon receiving the notification, the kernel-mode process stops updating the data bitmap in the target storage space, thereby avoiding data conflicts or errors during the release of the target storage space. Then, after confirming that the kernel-mode process has stopped updating the data bitmap, the QEMU layer calls the munmap system call to release the shared memory where the target storage space is located, allowing it to be reallocated by the system or used for other purposes.

[0155] Through the above steps, the data bitmap can be exported, loaded, and deleted by receiving control instructions sent by the virtual machine, ensuring that the data bitmap can be restored when the virtual machine is abnormal, while optimizing the use of storage resources.

[0156] Through the description of the above implementation methods, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus the necessary general hardware platform, and of course it can also be implemented by hardware, but in many cases the former is a better implementation method.

[0157] Based on this understanding, the technical solution of this application or the part that contributes to the existing technology can be embodied in the form of a software product. The computer software product is stored in a storage medium (such as ROM / RAM, disk, CD-ROM), and includes a number of instructions for enabling a terminal device (which can be a mobile phone, computer, server, or network device, etc.) to execute the methods described in each embodiment of this application.

[0158] An embodiment of the present application further provides an electronic device, Figure 7 is a schematic diagram of an electronic device according to an embodiment of the present application, such as Figure 7 As shown, the electronic device includes a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to execute the steps in any of the above-mentioned virtual machine data backup method embodiments.

[0159] In an exemplary embodiment, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor, and the input / output device is connected to the processor.

[0160] For specific examples in this embodiment, reference may be made to the examples described in the above embodiments and exemplary implementation modes, and this embodiment will not be described in detail here.

[0161] An embodiment of the present application further provides a computer-readable storage medium, in which a computer program is stored. The computer program is configured to execute the steps of any of the above-mentioned virtual machine data backup method embodiments when running.

[0162] In an exemplary embodiment, the computer-readable storage medium may include, but is not limited to, various media that can store computer programs, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk, or an optical disk.

[0163] An embodiment of the present application also provides a computer program product, including a computer program, which, when executed by a processor, implements the steps of the method described in each embodiment of the present application; the computer program product also includes a non-volatile computer-readable storage medium, which stores the computer program, which, when executed by a processor, implements the steps of the virtual machine data backup method described in each embodiment of the present application.

[0164] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the above description has generally described the components and steps of each example according to their functions. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0165] The above is a detailed introduction to a virtual machine data backup method provided by the present application. Specific examples are used herein to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only intended to help understand the method and core ideas of the present application. It should be noted that, for those skilled in the art, without departing from the principles of the present application, several improvements and modifications can be made to the present application, and these improvements and modifications also fall within the scope of protection of the claims of the present application.

Claims

1. A method for backing up virtual machine data, characterized in that: include: Detecting a current running position of a back-end driver corresponding to the virtual machine, wherein the back-end driver is used to read and write a virtual disk of the virtual machine according to a disk read and write request sent by the virtual machine; In a case where it is detected that the running position is used to indicate that the back-end driver is running on a kernel-mode program, allocating a target storage space for the kernel-mode program; Controlling the kernel state program to update a data bitmap stored in the target storage space, wherein the data bitmap is used to record a disk location of the changed virtual machine data in the virtual disk; Backing up the target virtual machine data that has been changed in the virtual disk according to the target data bitmap stored in the target storage space; Wherein, allocating target storage space for the kernel-mode program includes: Detecting whether there is currently a storage space that matches a bitmap parameter, wherein the bitmap parameter is used to indicate the size of the space required to store an expected data bitmap, wherein the expected data bitmap is a data bitmap that allows recording the disk location of the virtual machine data that has changed in the virtual disk; In a case where it is detected that there is a reference storage space matching the bitmap parameter, transmitting a reference space address of the reference storage space to the kernel-mode program, wherein the reference space address is used to identify a location of the reference storage space, and the target storage space includes the reference storage space; When it is detected that there is no storage space matching the bitmap parameters, a candidate storage space is created according to the bitmap parameters, and the candidate space address of the candidate storage space is transmitted to the kernel-mode program, wherein the candidate space address is used to identify the location of the candidate storage space, and the target storage space includes the candidate storage space.

2. The method according to claim 1, characterized in that Before creating the candidate storage space according to the bitmap parameters, the method further includes: Obtaining disk parameters and granularity parameters of the virtual disk, wherein the disk parameters are used to indicate the capacity of the virtual disk, and the granularity parameters are used to indicate the backup granularity of backing up data in the virtual disk; The bitmap parameters are generated according to the disk parameters and the granularity parameters.

3. The method according to claim 2, characterized in that Generating the bitmap parameters according to the disk parameters and the granularity parameters includes: Calling a space creation interface to divide the virtual disk into a plurality of data blocks according to the disk parameters and the granularity parameters to obtain a data block set; The space creation interface is called to determine the amount of data required to record the location information and status information of all the data blocks in the data block set as the bitmap parameter, wherein the location information is used to indicate the disk position of the corresponding data block in the virtual disk, and the status information is used to indicate whether the virtual machine data stored in the corresponding data block has changed.

4. The method according to claim 1, wherein Before transmitting the reference space address of the reference storage space to the kernel state program, the method includes: detecting a format type of an initial data bitmap currently stored in the reference storage space; When the format type is a first format, the initial data bitmap is converted from the first format to a second format to obtain a candidate data bitmap, wherein the first format is a format type used by a user-state program to update the data bitmap stored in the reference storage space, and the second format is a format type used by the kernel-state program to update the data bitmap stored in the reference storage space.

5. The method according to claim 4, characterized in that The converting the initial data bitmap from the first format to the second format to obtain a candidate data bitmap includes: Filtering target location information and target status information from the initial data bitmap, wherein the target location information is used to indicate the disk location of each data block in the virtual disk, and the target status information is used to indicate whether the virtual machine data stored in each data block in the virtual disk has changed; The candidate data bitmap in the second format is generated according to the target position information and the target state information.

6. The method according to claim 1, characterized in that The controlling the kernel-mode program to update the data bitmap stored in the target storage space includes: Controlling the kernel state program to detect whether the back-end driver currently receives the disk read / write request; In a case where it is detected that the back-end driver currently receives the disk read / write request, controlling the kernel-mode program to extract an offset parameter and a length parameter from the disk read / write request, wherein the offset parameter is used to indicate a starting position of the reference virtual machine data requested to be changed in the disk read / write request in the virtual disk, and the length parameter is used to indicate the length of the storage position of the reference virtual machine data in the virtual disk; The kernel-mode program is controlled to update a data bitmap stored in the target storage space according to the offset parameter and the length parameter.

7. The method according to claim 6, characterized in that The controlling the kernel-mode program to update the data bitmap stored in the target storage space according to the offset parameter and the length parameter includes: Acquire a granularity parameter of the virtual disk, wherein the granularity parameter is used to indicate a backup granularity for backing up data in the virtual disk; detecting reference position information of a reference data block storing the reference virtual machine data according to the offset parameter, the length parameter, and the granularity parameter, wherein the reference data block is a data block in the virtual disk, the virtual disk being pre-divided into a plurality of data blocks according to the granularity parameter, and the reference position information is used to indicate a disk position of the reference data block in the virtual disk; The reference state information corresponding to the reference position information in the data bitmap is updated to a first state value, wherein the state information in the first state value is used to indicate that the virtual machine data stored in the data block corresponding to the position information has changed.

8. The method according to claim 1, characterized in that The backing up the target virtual machine data that has been changed in the virtual disk according to the target data bitmap stored in the target storage space includes: Filtering out backup location information corresponding to backup status information in a first state value from the status information and location information having a corresponding relationship recorded in the target data bitmap, wherein the status information in the first state value is used to indicate that virtual machine data stored in a data block of the corresponding location information has changed, and the backup location information is used to indicate a disk location in the virtual disk of the data block of the stored virtual machine data that has changed; Back up the target virtual machine data stored in the virtual disk at the disk location indicated by the backup location information.

9. The method according to claim 1, characterized in that Before backing up the changed target virtual machine data in the virtual disk according to the target data bitmap stored in the target storage space, the method further includes: receiving a control instruction sent by the virtual machine; When an export control instruction is received, the bitmap export interface is called to export the reference data bitmap stored in the target storage space to the bitmap storage space, wherein the export control instruction is used to instruct the export of the data bitmap in the storage space, and the bitmap storage space is a storage space that allows the data bitmap to be stored when the virtual machine is abnormal.

10. The method according to claim 9, characterized in that After calling the bitmap export interface to export the reference data bitmap stored in the storage space to the bitmap storage space, the method further includes: Receive control instructions sent by the virtual machine; acquiring the reference data bitmap from the bitmap storage space upon receiving a load control instruction, wherein the load control instruction is used to instruct loading of the data bitmap in the bitmap storage space; Detecting whether there is currently a storage space that matches the reference data bitmap; In a case where it is detected that there is a first storage space matching the reference data bitmap, calling a bitmap loading interface to load the reference data bitmap into the first storage space; If no storage space matching the reference data bitmap is detected, a second storage space matching the reference data bitmap is created, and the bitmap loading interface is called to load the reference data bitmap into the second storage space.

11. The method according to claim 1, wherein After backing up the changed target virtual machine data in the virtual disk according to the target data bitmap stored in the target storage space, the method further includes: Receive control instructions sent by the virtual machine; When a deletion control instruction is received, a bitmap deletion interface is called to delete the data bitmap stored in the target storage space and release the target storage space, wherein the deletion control instruction is used to instruct the deletion of the data bitmap in the target storage space.

12. An electronic device, characterized in that: include: memory for storing computer programs; A processor, configured to implement the steps of the method for backing up virtual machine data according to any one of claims 1 to 11 when executing the computer program.

13. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, wherein when the computer program is executed by a processor, the steps of the method for backing up virtual machine data according to any one of claims 1 to 11 are implemented.

14. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the method for backing up virtual machine data according to any one of claims 1 to 11 are implemented.

Images