A virtual machine restoration method, device and electronic equipment

Abstract

The application discloses a virtual machine restoring method, device and electronic equipment, the method comprises the following steps: in response to starting a GuestOS in a target virtual machine, reading starting information from a specified storage area; if a restoring identifier in the starting information indicates to restore, restoring data in a to-be-restored object to data corresponding to a target restoring point according to restoring strategy information corresponding to the target virtual machine, and mounting each virtual disk in the target virtual machine as a disk recognizable by the GuestOS. Through the scheme, the restoring of the virtual machine is configured to the GuestOS stage, and serious consequences such as data loss caused by defects of the writable advanced file system driver itself when the writable advanced file system driver running in the UEFI stage is avoided.

Description

Technical Field

[0001] This application relates to the field of virtual machine technology, and in particular to a method, apparatus and electronic device for restoring a virtual machine. Background Technology

[0002] With the rapid development of virtualization and cloud computing technologies, cloud desktops are becoming increasingly popular. Virtual Operating System Infrastructure (VOI) in cloud desktops avoids the overhead of virtualization layers by eliminating any hardware virtualization layer, resulting in near-zero performance consumption and maximized compatibility. Consequently, it has gradually become one of the mainstream virtual machine technologies and is widely adopted by many vendors.

[0003] Currently, among traditional VOI solutions, the UEFI VOI solution, which uses the Unified Extensible Firmware Interface (UEFI) and Basic Input Output System (BIOS) to directly boot a Virtual Machine (VM), is gradually gaining attention because it only introduces a brief boot manager loading time and is compatible with various Central Processing Unit (CPU) architectures.

[0004] When starting a VM using the aforementioned UEFI VOI solution, a restore operation needs to be introduced into the UEFI VOI solution based on user requirements. This restores the object to be restored to the target restore point, thereby avoiding data loss issues caused by VM failure or crashes. The UEFI VOI solution can be divided into two stages: the UEFI stage and the Guest Operating System (GuestOS) stage.

[0005] When introducing restore operations in the UEFI phase, it is first necessary to read the VM image file in the high file system through a readable high file system driver, and then restore the object to be restored based on a writable high file system driver.

[0006] However, UEFI only has a readable high-level file system driver. Therefore, when introducing restore operations in the UEFI stage, it is also necessary to implement a complete writable high-level file system driver in UEFI, and then restore the object to be restored based on the writable high-level file system driver.

[0007] However, implementing a complete writable high-level file system driver in UEFI requires engineers with in-depth knowledge of high-level file systems to write the relevant code, as well as a large number of test datasets to test the correctness of the relevant code, making it very difficult to implement a complete writable high-level file system driver. At the same time, if the writable high-level file system driver itself has defects during operation, it can lead to serious consequences such as data loss, data overwriting, and data inconsistency. Summary of the Invention

[0008] This application provides a method, apparatus, and electronic device for restoring a virtual machine, to solve the problems of difficulty in implementing a complete writable high-level file system driver in UEFI for restoring objects, and serious consequences such as data loss due to inherent defects in the driver during its execution. The specific implementation scheme is as follows:

[0009] Firstly, this application provides a method for restoring a virtual machine, the method comprising:

[0010] In response to starting the Guest OS in the target virtual machine, startup information is read from a specified storage area. The startup information includes a restore flag, which indicates whether to restore the data in the object to be restored to the data corresponding to the target restore point.

[0011] If the restore identifier indicates that a restore should be performed, the data in the object to be restored is restored to the data corresponding to the target restore point according to the restore policy information corresponding to the target virtual machine, and each virtual disk in the target virtual machine is mounted as a disk recognizable by the GuestOS, wherein the restore policy information indicates the object to be restored.

[0012] By using the above method, based on the restore identifier and restore policy information, the virtual machine's restore operation is configured in the GuestOS stage. Because the GuestOS contains a writable high-level file system driver, the data in the object to be restored can be restored to the data corresponding to the target restore point according to the restore policy information based on this writable high-level file system driver in the GuestOS stage. Therefore, it avoids implementing a complete writable high-level file system driver in the UEFI stage, and avoids serious consequences such as data loss caused by the inherent defects of the writable high-level file system driver when running it in the UEFI stage.

[0013] In one possible implementation, prior to reading the startup information from the designated storage area, the method further includes:

[0014] During the Unified Extensible Firmware Interface (UEFI) phase or in the maintenance system, the boot information is generated and saved to the designated storage area.

[0015] The above method allows boot information to be generated either during the UEFI phase or in the maintenance system, and this boot information is stored in a designated storage area. This enables the electronic device to directly read the generated boot information from the designated storage area when determining whether to perform a restore operation during the GuestOS phase. Furthermore, if the boot information is generated in the maintenance system, it can be directly parsed during the UEFI phase, reducing the UEFI phase's runtime.

[0016] In one possible implementation, generating the startup information includes:

[0017] Obtain the metadata file path, which corresponds to the target virtual machine to be started;

[0018] The startup information is generated based on the restore identifier and the metadata file path.

[0019] The above method generates startup information based on the restore identifier and metadata file path. Based on the restore identifier in the startup information, the electronic device can determine whether to perform a restore operation, further ensuring that the restore operation is delayed until the GuestOS stage. This avoids the limitation of UEFI lacking a writable high-level file system driver, thus further guaranteeing that the electronic device can perform the restore operation. Furthermore, storing the restore identifier in the startup information allows for dynamic adjustment of its content, facilitating real-time updates each time the virtual machine starts. Additionally, based on the metadata file path, the metadata in the metadata file can be read. Metadata is the entry point for accessing persistent data in the target virtual machine, containing various key information about that target virtual machine. Therefore, the target virtual machine to be started can be determined based on the metadata file path, enabling the electronic device to identify the virtual machine to operate on when multiple virtual machines exist.

[0020] In one possible implementation, before generating the startup information based on the restore identifier and the metadata file path, the method further includes:

[0021] Receive a restore command generated based on user operation or a restore command generated based on the restore strategy information;

[0022] Update the restore identifier according to the restore command.

[0023] The above methods allow for updating the restore flag based on user-generated restore commands, thus enabling the system to determine whether to perform a restore operation on the target virtual machine upon startup, based on user selection. Alternatively, restore commands can be automatically generated based on restore policy information, and the restore flag can be updated accordingly, allowing the electronic device to determine whether to perform a restore action on the target virtual machine upon startup.

[0024] In one possible implementation, prior to reading the startup information from the designated storage area, the method further includes:

[0025] Obtain the restore time corresponding to the target virtual machine and the object to be restored in the target virtual machine;

[0026] The restoration strategy information is generated based on the restoration time and the object to be restored.

[0027] Using the above method, restoration policy information is generated based on the restoration time and the object to be restored corresponding to the received target virtual machine. Based on this restoration policy information, the restoration operation is further guaranteed to be delayed to the GuestOS stage, avoiding the limitation of UEFI not having a writable high-level file system driver, thereby further ensuring that the electronic device can perform the restoration operation. Furthermore, based on the restoration time in the restoration policy information, data can be provided for the restoration flag in the boot information to support the restoration flag indicating whether to perform a restoration. At the same time, based on the object to be restored in the restoration policy information, the electronic device can clearly identify the object to be restored when performing the restoration operation.

[0028] In one possible implementation, prior to reading the startup information from the designated storage area, the method further includes:

[0029] Receive an instruction indicating the target restoration point;

[0030] Based on the instruction, the initial restore point is modified to the target restore point in the startup information.

[0031] In the above manner, based on the received instruction containing the target restore point, the initial restore point is modified to the target restore point in the startup information. Thus, the target restore point can be determined through the startup information, so that the electronic device can clearly identify the data to be restored when restoring the data in the object to be restored. Furthermore, setting the target restore point in the startup information allows for dynamic adjustment of the specific target restore point, which can be modified in real time each time the VM is started.

[0032] In one possible implementation, after reading the startup information from the designated storage area, the method further includes:

[0033] If the restore flag indicates that no restore should be performed, then each virtual disk in the target virtual machine will be mounted as a disk that the GuestOS can recognize.

[0034] In this way, when the restore flag indicates that no restore is to be performed, the electronic device directly mounts each virtual disk in the target virtual machine as a disk that the GuestOS can recognize, so that the target virtual machine can still be started even if no restore action is performed during the current startup of the target virtual machine.

[0035] In one possible implementation, after mounting each virtual disk in the target virtual machine as a disk recognizable by the GuestOS, the method further includes:

[0036] When the target virtual machine is running, the data in the change information generated by the target virtual machine is saved to the created differential file;

[0037] The new path in the change information is updated in the metadata file of the corresponding metadata file path or in the temporary file that has been created, wherein the new path is the path after the path corresponding to the file in the target virtual machine has changed.

[0038] By using the above method, the changes generated when running the target virtual machine are saved, thus avoiding the inability to restore the changes generated when running the target virtual machine the previous time after the target virtual machine is restarted and a restore action is performed.

[0039] In one possible implementation, the startup information is stored in the designated, readable, and persistent storage area. After mounting each virtual disk in the target virtual machine as a disk recognizable by the GuestOS, the method further includes:

[0040] Obtain the restoration time from the restoration strategy information or receive a new restoration command generated based on user operation;

[0041] A new restore identifier is generated based on the restore time or the new restore instruction;

[0042] New startup information is generated based on the new restore identifier and the obtained new metadata file path, and the new startup information is saved to the specified storage area that is readable, writable and persistent, wherein the new metadata file path corresponds to the target virtual machine to be started;

[0043] Based on the newly launched information, perform a restart operation on the target virtual machine.

[0044] Using the above method, a new restore identifier is generated based on the restore time in the restore policy information or the new restore command from the user operation; then, new startup information is generated based on the new restore identifier and the new metadata file path; thus, based on the new metadata file path in the new startup information, the electronic device can clearly identify the virtual machine to be started, and thus the electronic device can perform a restart operation on the target virtual machine; furthermore, based on the new restore identifier in the new startup information, the electronic device can determine whether a restore operation needs to be performed when starting the target virtual machine.

[0045] Secondly, this application also provides a virtual machine restoration device, the device comprising:

[0046] The read module is used to read startup information from a specified storage area in response to starting the guest operating system (GuestOS) in the target virtual machine. The startup information includes a restore flag, which indicates whether to restore the data in the object to be restored to the data corresponding to the target restore point.

[0047] The processing module is configured to, if the restore identifier indicates that a restore is to be performed, restore the data in the object to be restored to the data corresponding to the target restore point according to the restore policy information corresponding to the target virtual machine, and mount each virtual disk in the target virtual machine as a disk recognizable by the GuestOS, wherein the restore policy information indicates the object to be restored.

[0048] In one possible implementation, the reading module is specifically used to generate the boot information in the Unified Extensible Firmware Interface (UEFI) phase or in the maintenance system, and save the boot information to the designated storage area.

[0049] In one possible implementation, the reading module is specifically used to obtain the metadata file path, which corresponds to the target virtual machine to be started;

[0050] The startup information is generated based on the restore identifier and the metadata file path.

[0051] In one possible implementation, the reading module is specifically used to receive a restore command generated based on user operation or a restore command generated based on the restore strategy information;

[0052] Update the restore identifier according to the restore command.

[0053] In one possible implementation, the reading module is specifically used to obtain the restore time corresponding to the target virtual machine and the object to be restored in the target virtual machine;

[0054] The restoration strategy information is generated based on the restoration time and the object to be restored.

[0055] In one possible implementation, the reading module is specifically configured to receive an instruction indicating the target restoration point;

[0056] Based on the instruction, the initial restore point is modified to the target restore point in the startup information.

[0057] In one possible implementation, the processing module is specifically configured to mount each virtual disk in the target virtual machine as a disk recognizable by the GuestOS if the restore flag indicates that no restore should be performed.

[0058] In one possible implementation, the processing module is specifically used to save the data in the change information generated by the target virtual machine to a pre-created differential file when the target virtual machine is running;

[0059] The new path in the change information is updated in the metadata file of the corresponding metadata file path or in the temporary file that has been created, wherein the new path is the path after the path corresponding to the file in the target virtual machine has changed.

[0060] In one possible implementation, the processing module is specifically used to obtain the restoration time in the restoration strategy information or to receive a new restoration instruction generated based on user operation;

[0061] A new restore identifier is generated based on the restore time or the new restore instruction;

[0062] New startup information is generated based on the new restore identifier and the obtained new metadata file path, and the new startup information is saved to the specified storage area that is readable, writable and persistent, wherein the new metadata file path corresponds to the target virtual machine to be started;

[0063] Based on the newly launched information, perform a restart operation on the target virtual machine.

[0064] Thirdly, this application provides an electronic device, comprising:

[0065] Memory, used to store computer programs;

[0066] When the processor executes the computer program stored in the memory, it implements the steps of the virtual machine restoration method described above.

[0067] Fourthly, this application provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the virtual machine restoration method described above.

[0068] For the various aspects of the second to fourth aspects mentioned above, and the technical effects that each aspect may achieve, please refer to the above description of the technical effects that can be achieved for the first aspect or the various possible solutions in the first aspect, which will not be repeated here. Attached Figure Description

[0069] Figure 1 A flowchart illustrating a virtual machine restoration method provided in this application;

[0070] Figure 2 A snapshot illustration provided for this application;

[0071] Figure 3 A schematic diagram illustrating the process of a virtual machine restoration method provided in this application;

[0072] Figure 4 A schematic diagram of the structure of a virtual machine restoration device provided in this application;

[0073] Figure 5 A schematic diagram of an electronic device provided in this application. Detailed Implementation

[0074] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. The specific operational methods in the method embodiments can also be applied to the device embodiments or system embodiments. It should be noted that in the description of this application, "multiple" is understood as "at least two". "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. A connected to B can represent: A and B directly connected, and A and B connected through C. Furthermore, in the description of this application, terms such as "first" and "second" are used only for distinguishing the purpose of description and should not be construed as indicating or implying relative importance or order.

[0075] Furthermore, the data collection, dissemination, and use in the technical solution of this application all comply with the requirements of relevant national laws and regulations.

[0076] The embodiments of this application will now be described in detail with reference to the accompanying drawings.

[0077] Currently, when introducing restore operations in the UEFI stage, since there is no writable high-level file system driver in UEFI, it is necessary to implement a complete writable high-level file system driver in UEFI so that the object to be restored can be restored based on the writable high-level file system driver.

[0078] However, implementing a complete writable high-level file system driver in UEFI requires engineers with in-depth knowledge of high-level file systems to write the relevant code, as well as a large number of test datasets to test the correctness of the relevant code, making it very difficult to implement a complete writable high-level file system driver. At the same time, if the writable high-level file system driver itself has defects during operation, it can lead to serious consequences such as data loss, data overwriting, and data inconsistency.

[0079] Therefore, this application proposes a method for restoring a virtual machine, which specifically includes: in response to starting the GuestOS in the target VM, reading startup information from a specified storage area; if the restore flag in the startup information indicates that a restore should be performed, restoring the data in the object to be restored to the data corresponding to the target restore point according to the restore policy information corresponding to the target VM, and mounting each virtual disk in the target VM as a disk recognizable by the GuestOS.

[0080] This method configures the VM's restore operation to the GuestOS stage based on the restore identifier and restore policy information. Since the GuestOS contains a writable high-level file system driver, the data in the object to be restored can be restored to the data corresponding to the target restore point according to the restore policy information based on the writable high-level file system driver in the GuestOS stage. Therefore, it avoids implementing a complete writable high-level file system driver in the UEFI stage and avoids serious consequences such as data loss caused by the defects of the writable high-level file system driver itself when running the writable high-level file system driver in the UEFI stage.

[0081] Reference Figure 1 The diagram shown is a flowchart of a virtual machine restoration method provided in an embodiment of this application. This method is applied to an electronic device and includes:

[0082] S1, in response to starting the Guest OS in the target virtual machine, reads startup information from the specified storage area.

[0083] When an electronic device boots the target VM, it can be divided into the UEFI stage and the GuestOS stage. In the UEFI stage, boot information is generated and the system disk in the target VM is mounted. Then, the loader in the system disk is started. Based on the loader's startup, the GuestOS in the target VM is started. Then, in the GuestOS stage, the electronic device reads the boot information from the specified storage area.

[0084] It is worth noting that, in addition to generating startup information during the UEFI phase, startup information can also be generated in the maintenance system and saved to a designated storage area. In this embodiment, the user's choice can determine whether to generate startup information during the UEFI phase or in the maintenance system.

[0085] It is understood that, in one embodiment, the maintenance system may include maintenance function modules stored locally, which may not be located within the VM. One maintenance system corresponds to M VMs; M is an integer greater than or equal to 1. The maintenance system may install and configure the UEFI initiator during the deployment phase prior to the UEFI phase. Optionally or additionally, the maintenance system may resolve disk failure issues when a third-party system is required to address the problem.

[0086] In this embodiment, the specified storage area can be a readable, writable, and persistent location, such as an Extensible Firmware Interface System Partition (ESP) on a hard drive, a readable and writable UEFI variable, or a Baseboard Manager Controller (BMC) on a server-type terminal. In this embodiment, the specified storage area can also be memory when the reboot operation is abandoned.

[0087] The above method allows boot information to be generated either during the UEFI phase or in the maintenance system, and this boot information is stored in a designated storage area. This enables the electronic device to directly read the generated boot information from the designated storage area when determining whether to perform a restore operation during the GuestOS phase. Furthermore, if the boot information is generated in the maintenance system, it can be directly parsed during the UEFI phase, reducing the UEFI phase's runtime.

[0088] Before an electronic device reads the boot information, that is, before entering the GuestOS stage, it needs to perform the corresponding operations in the UEFI stage before entering the GuestOS stage. Before the UEFI stage, it also needs to deploy the relevant information of the VM so that the relevant information can be obtained in the UEFI stage or in the GuestOS stage.

[0089] Specifically, when deploying VM-related information, electronic devices include partitioning and formatting the native hard disk through the maintenance system, installing and configuring the UEFI bootloader, configuring the virtual machine list, and deploying virtual disk files, which are also a type of persistent data.

[0090] It should be noted that in this embodiment of the application, the virtual machine list contains multiple metadata file paths, each metadata file path corresponds to a metadata file, and the metadata in a metadata file corresponds to a VM. Therefore, when configuring the virtual machine list, it is also necessary to configure the metadata file.

[0091] The metadata in the aforementioned metadata file contains disk information for each virtual disk in the VM. This virtual disk can be the system disk or the data disk in the VM. Therefore, the disk information can be the path information of the data disk, the path information of the system disk, the location information of the loader in the system disk, etc. For example, the loader mentioned above is bootx64.efi.

[0092] In particular, restore policy information has been added to the metadata mentioned above. This restore policy information includes the restore time. For example, if the restore time is daily, it means that the electronic device performs a restore operation the first time the VM is started during the day. If the restore time is every time, it means that the electronic device performs a restore operation every time the VM is started.

[0093] In addition to the restoration time, the above restoration strategy information also includes the object to be restored. For example, if the object to be restored is the system disk, it means that when starting the VM, the electronic device only needs to restore the system disk in the VM; if the object to be restored is both the data disk and the system disk in the VM, it means that when starting the VM, the electronic device performs restoration operations on both the data disk and the system disk in the VM.

[0094] In one possible implementation, when generating the above-mentioned restoration strategy information, the restoration time corresponding to the target VM and the objects to be restored in the target VM are first obtained; then the restoration strategy information is generated based on the restoration time and the objects to be restored.

[0095] Using the above method, restoration policy information is generated based on the restoration time and the object to be restored corresponding to the target VM. Based on this restoration policy information, the restoration operation is further delayed to the GuestOS stage, avoiding the limitation of UEFI not having a writable high-level file system driver, thereby further ensuring that the electronic device can perform the restoration operation. Furthermore, based on the restoration time in the restoration policy information, data can be provided for the restoration flag in the boot information to support the restoration flag indicating whether to perform a restoration. At the same time, based on the object to be restored in the restoration policy information, the electronic device can clearly identify the object to be restored when performing the restoration operation.

[0096] Furthermore, in order for the electronic device to perform the restore operation, it is necessary to determine the restore point, that is, to restore the object to be restored to a certain historical operating state. In the embodiments of this application, the restore point can be determined by external snapshots or internal snapshots.

[0097] Specifically, snapshots can be taken of files on each virtual disk in the VM based on external or internal snapshot mechanisms to preserve snapshot points, i.e. restore points. Furthermore, the restore points should be able to be found through metadata or files on the virtual disks so that electronic devices can perform restore operations based on the restore points.

[0098] For example, based on an external snapshot mechanism, a snapshot of file a on the data disk in the VM is taken, and a differential file b is created for file a. The moment when differential file b is created for file a is taken as the restore point S1. Then file a becomes a read-only file. All data generated when the VM runs thereafter is saved in differential file b, so that electronic devices can restore the VM to the state corresponding to file a based on restore point S1.

[0099] Furthermore, in order for electronic devices to clearly identify the restore location of the object to be restored, that is, to enable electronic devices to clearly identify the restore point, relevant descriptions of the restore point can be added to the metadata. For example, if the snapshot device takes three snapshots of the VM, and the snapshot points of the three snapshots are A, B, and C respectively, then the restore point can be A, B, and C. In other words, the set of restore points can be {A, B, C}. That is to say, electronic devices can restore the object to be restored to A, B, or C, and at the same time set the default restore point to A in the metadata.

[0100] Furthermore, after completing the deployment of VM-related information, the electronic device enters the UEFI phase.

[0101] In the UEFI phase, the main component is the UEFI bootloader. In this embodiment, the UEFI bootloader is mainly for booting the UEFI assembly developed by the VM in this embodiment. The UEFI bootloader includes bootmgr, which is directly started by the UEFI Boot option. That is, the UEFI assembly includes bootmgr, which is directly started by the UEFI Boot option.

[0102] In one possible implementation, the above-mentioned bootmgr mainly has the following functions:

[0103] 1) VM image selection and boot information generation functions;

[0104] 2) Activate the information parsing function;

[0105] 3) Load UEFI advanced file system, virtual disk and other driver functions;

[0106] 4) Mount the system disk file in the target VM in read-only mode according to the startup information, and start the Loader function in the system disk.

[0107] Before generating boot information via bootmgr, electronic devices need to determine whether boot information already exists. If boot information exists, it is directly parsed by bootmgr and subsequent steps are executed; otherwise, boot information is generated via bootmgr.

[0108] In one possible implementation, when the electronic device generates boot information via bootmgr during the UEFI phase, it first obtains the metadata file path, which corresponds to the target VM to be booted; then it generates boot information based on the restore identifier and the metadata file path.

[0109] It should be noted that when electronic devices generate startup information in the maintenance system, the startup information is also generated based on the restore identifier and the metadata file path.

[0110] The above method generates startup information based on the restore identifier and metadata file path. This allows the electronic device to determine whether to perform a restore operation based on the restore identifier in the startup information, further ensuring that the restore operation is delayed until the GuestOS stage. This avoids the limitation of UEFI not having a writable advanced file system driver, thus further ensuring that the electronic device can perform the restore operation. Furthermore, storing the restore identifier in the startup information allows for dynamic adjustment of its content, facilitating real-time modification of the restore identifier each time the VM is started. In addition, the metadata in the metadata file can be read based on the metadata file path. Metadata is the entry point for accessing persistent data in the target VM and contains various key information about the target VM. Therefore, the target VM to be started can be determined based on the metadata file path, so that when multiple VMs exist, the electronic device can determine the VM to be operated on.

[0111] Furthermore, before generating startup information based on the restore identifier and metadata file path, the system first receives a restore instruction generated based on user operations or a restore instruction generated based on restore policy information; then, it updates the restore identifier based on the restore instruction.

[0112] When generating restore commands based on restore policy information, the restore commands are related to the restore time in the restore policy information. For example, if the restore time is "every time," it means that the electronic device performs a restore operation every time the VM is started. In this case, each time a restore command is generated, the restore flag is set to TRUE. Furthermore, when the default value of the restore flag is FALSE, FALSE is updated to TRUE according to the restore command.

[0113] Using the methods described above, the restore flag can be updated based on restore commands generated by user operations, thus allowing the system to determine whether to perform a restore operation on the target VM based on user selection. Alternatively, restore commands can be automatically generated based on restore policy information, and the restore flag can be updated accordingly, enabling the electronic device to determine whether to perform a restore action on the target VM. Furthermore, boot information can be generated based on this restore flag.

[0114] Furthermore, in order for the electronic device to further clarify the restoration location of the object to be restored, a target restoration point is also determined in the startup information. Specifically, firstly, an instruction indicating the target restoration point is received; then, based on the instruction, the initial restoration point is modified to the target restoration point in the startup information.

[0115] It is worth noting that the initial restore point is the default restore point set in the metadata.

[0116] For example, the set of restore points in the metadata is {A, B, C}, and the default restore point in the metadata is A. When the VM starts and generates boot information, the electronic device receives an instruction from the user through bootmgr, which indicates that the target restore point is B. Thus, bootmgr updates the initial restore point in the boot information from A to B.

[0117] In this way, based on the received instruction indicating the target restore point, the initial restore point is updated to the target restore point in the startup information. Thus, the target restore point can be determined through the startup information, so that the electronic device can clearly know the data in the object to be restored to. Furthermore, setting the target restore point in the startup information allows for dynamic adjustment of the specific target restore point, which can be modified in real time each time the VM is started.

[0118] In addition, it should be noted that when electronic devices generate boot information, the restore flag in the boot information is set to FALSE for the following special scenarios. That is to say, the electronic device does not perform a restore operation. The special scenarios are:

[0119] 1) Restarting the VM disables the restore function;

[0120] 2) Pause the restore function during image editing;

[0121] 3) The periodic restore strategy only performs a restore action once after the period expires (the period is recalculated after the execution is completed).

[0122] Taking restart as an example, the specific steps an electronic device takes when performing a restart are as follows:

[0123] First, obtain the restore time from the restore policy information or the new restore command generated based on user operation; then, generate a new restore identifier based on the restore time or the new restore command; next, generate new startup information based on the new restore identifier and the obtained new metadata file path, and save the new startup information to a specified readable, writable, and persistent storage area, where the new metadata file path corresponds to the target VM to be started; finally, execute the restart operation of the target VM based on the new startup information.

[0124] It should be noted that when generating new boot information in a reboot scenario, the electronic device generates the new boot information through a driver or program in the GuestOS.

[0125] Using the above method, a new restore identifier is generated based on the restore time in the restore policy information or the new restore command from the user operation; then, new startup information is generated based on the new restore identifier and the new metadata file path; thus, based on the new metadata file path in the new startup information, the electronic device can clearly identify the VM to be started, and thus the electronic device can perform a restart operation on the target VM; and based on the new restore identifier in the new startup information, the electronic device can also determine whether a restore operation needs to be performed.

[0126] Furthermore, in the embodiments of this application, in the above-mentioned special scenario 2), when performing the image editing process, the image editing can be performed based on a remote management platform.

[0127] Furthermore, after generating boot information and identifying the target VM to be booted, the electronic device uses bootmgr to determine whether the system disk needs to be restored.

[0128] Specifically, if the object to be restored in the restoration policy information includes the system disk and the restoration identifier indicates that restoration should be performed, then the metadata file is determined according to the metadata file path. Then, according to the system disk path in the metadata file, the system disk is mounted as a UEFI-recognizable disk through the advanced file system driver in UEFI. That is, the system disk is mounted. Mounting the system disk is actually mounting the differential file of the restore point location. This differential file is a differential file about the system disk.

[0129] For example, refer to Figure 2 The snapshot diagram shows that the system disk is currently in a writable state, and the corresponding differential file is the latest differential file. Snapshot 2 corresponds to the second newest differential file, and Snapshot 1 is equivalent to the base file. If the restore flag indicates that a restore should be performed, the system disk needs to be restored to Snapshot 2. Therefore, the second newest differential file is mounted, which means mounting the differential file corresponding to Snapshot 2. If the restore flag indicates that a restore should not be performed, the latest differential file is mounted, which means mounting the differential file corresponding to the writable state.

[0130] After the electronic device mounts the system disk, it starts the Loader on the system disk, initializes the GuestOS through the Loader, thus indicating that it has entered the GuestOS stage, and then the electronic device reads the boot information.

[0131] Next, during the GuestOS phase, after reading the startup information, the electronic device determines whether to execute step S2 or step S3 based on the specific instructions of the restore flag in the startup information.

[0132] Specifically, if the restore flag indicates that a restore should be performed, then step S2 is executed;

[0133] If the restore flag indicates that no restore should be performed, then proceed to step S3.

[0134] S2, restore the data in the object to be restored to the data corresponding to the target restore point according to the restore policy information corresponding to the target virtual machine, and mount each virtual disk in the target virtual machine as a disk that can be recognized by GuestOS.

[0135] Specifically, the electronic device first determines the object to be restored based on the restoration policy information corresponding to the target VM, and determines the target restore point based on the boot information. Then, based on the writable high-level file system driver in the GuestOS, it restores the data in the object to be restored to the data corresponding to the target restore point, thereby completing the restoration operation. After the restoration operation is completed, each virtual disk in the target VM is mounted as a disk that can be recognized by the GuestOS.

[0136] In one possible implementation, after mounting each virtual disk in the target VM as a disk recognizable by the GuestOS, the electronic device creates a differential file in the restored location. This allows the data from the change information generated by the target VM to be saved to this created differential file when the target VM is running. For example, if an Excel spreadsheet containing personal information is generated in file b while the VM is running, this Excel spreadsheet is saved to the created differential file; this Excel spreadsheet contains the data from the change information.

[0137] Furthermore, the new path from the change information is updated in the metadata file or the created temporary file. The new path is the path of the file in the target VM after the change. For example, if the path of file 'a' in the target VM changes from "user / c / us / a.doc" to "user / c / df / a.doc", the path of file 'a' in the metadata is updated from "user / c / us / a.doc" to "user / c / df / a.doc", or the new path "user / c / df / a.doc" is stored in the created temporary file; this new path "user / c / df / a.doc" is the new path in the change information.

[0138] It is worth noting that when updating the new path of the file path in the target VM to the metadata or the created temporary file after the file path in the target VM changes, in addition to updating the changed path to the metadata or saving it to the temporary file, the newly generated restore point information and the latest difference file can also be updated to the metadata or saved to the temporary file. The latest difference file represents the outermost virtual disk file in the VM after this VM startup.

[0139] If the file path in the target VM has not changed, then there will be no new path in the change information. The file path in the target VM can be the path of the system disk in the target VM, the path of the data disk in the target VM, or the path of the loader in the target VM. In this embodiment of the application, the specific file path included in the file path in the target VM is not limited.

[0140] The above method saves the change information generated when the target virtual machine is running, so that the change information generated when the target virtual machine was run again cannot be restored after the target virtual machine is restarted and a restore action is performed.

[0141] In one possible implementation, after updating the created temporary file with the new path corresponding to the file in the target VM after the path has changed, the historical temporary files are deleted from the temporary file list according to the temporary file deletion policy. The temporary file list contains the name and path of each temporary file, and the temporary files are used to store change information.

[0142] The aforementioned temporary file deletion strategy can be to delete a historical temporary file as soon as the electronic device detects its existence; or it can be to receive an instruction from a user to delete a specified historical temporary file and then delete that specified historical temporary file. In this embodiment, the temporary file deletion strategy can be adjusted according to the specific application scenario.

[0143] By using the above method, based on the temporary file deletion strategy, historical temporary files in the temporary file list are deleted, thereby reducing disk space requirements.

[0144] Furthermore, after the electronic device mounts each virtual disk in the target VM as a disk that the GuestOS can recognize, it continues to execute the remaining steps in booting the VM.

[0145] However, since the remaining steps in starting the VM are common in the prior art, the remaining steps in the VM are not explained in this embodiment.

[0146] S3 mounts each virtual disk in the target virtual machine as a disk that GuestOS can recognize.

[0147] If the restore flag in the startup information indicates that a restore should not be performed, then the restore operation will not be executed, and the electronic device will directly mount each virtual disk in the target VM as a disk that can be recognized by the GuestOS.

[0148] Furthermore, after mounting each virtual disk in the target VM as a disk recognizable by the GuestOS, the electronic device continues to execute the remaining steps in starting the VM, consistent with step S2.

[0149] Similarly, since the remaining steps in starting the VM are common in the prior art, the remaining steps in the VM are not explained in this embodiment.

[0150] In summary, the virtual machine restoration method proposed in this application reads startup information from a specified storage area in response to starting the GuestOS in the target VM; if the restoration flag in the startup information indicates restoration, the data in the object to be restored is restored to the data corresponding to the target restoration point according to the restoration policy information corresponding to the target VM, and each virtual disk in the target VM is mounted as a disk recognizable by the GuestOS.

[0151] This method configures the VM's restore operation to the GuestOS stage based on the restore identifier and restore policy information. Since the GuestOS contains a writable high-level file system driver, the object to be restored can be restored to the target restore point according to the restore policy information based on the writable high-level file system driver in the GuestOS stage. This avoids the need to implement a complete writable high-level file system driver in the UEFI stage, and also avoids serious consequences such as data loss caused by the defects of the writable high-level file system driver itself when running the writable high-level file system driver in the UEFI stage.

[0152] Furthermore, by adding a restore identifier and metadata file path to the boot information, as well as generating restore policy information containing the restore time and the object to be restored, the restore operation is further guaranteed to be delayed to the GuestOS stage, avoiding the limitation of UEFI not having a writable advanced file system driver, thereby further ensuring that electronic devices can perform restore operations.

[0153] Furthermore, storing the restore identifier in the startup information allows for dynamic adjustment of its contents, facilitating real-time modification of the restore identifier each time a VM is started. Based on the metadata file path in the startup information, the target VM to be started can be determined, enabling electronic devices to identify the VM to be operated on when multiple VMs exist. Based on the object to be restored in the restore policy information, the electronic device can clearly identify the object to be restored when performing a restore operation.

[0154] The technical solution of this application will be further explained below with reference to a specific application process.

[0155] like Figure 3The diagram shows the process of restoring a virtual machine. First, during the deployment phase, the electronic device deploys relevant information about the VM, including partitioning and formatting the native hard disk through the maintenance system, installing and configuring the UEFI bootloader, configuring the virtual machine list, deploying virtual disk files, metadata files, etc. The metadata in the metadata file contains restoration policy information, which includes the restoration time and the object to be restored.

[0156] Then, in the UEFI phase, firstly in the boot information judgment module, the electronic device uses bootmgr to determine whether boot information exists. If no boot information exists, the generation module receives user instructions and generates boot information. This boot information includes a restore identifier, a metadata file path, and a target restore point. The restore identifier indicates whether to perform a restore, and the metadata file path is used to read the metadata file. Based on the metadata in the metadata file, the target VM to be booted can be determined. If boot information exists, the parsing module directly parses the boot information to determine the target VM to be booted.

[0157] After generating boot information through the generation module or parsing boot information through the parsing module, the first mounting module reads the restore policy information in the metadata. If the object to be restored in the restore policy information includes the system disk, the system disk path in the metadata is read. Then, based on the system disk path and the restore identifier in the boot information, the system disk in the target VM is mounted as a UEFI-recognizable disk.

[0158] Secondly, start the Loader on the aforementioned system disk to indicate that you are entering the GuestOS stage;

[0159] During the GuestOS phase, the electronic device reads the startup information generated in the generation module, and then inputs the restore flag in the startup information into the restore judgment module;

[0160] In the restoration judgment module, if the received restoration identifier indicates that restoration should be performed, the restoration operation module reads the restoration policy information and the target restoration point from the metadata to obtain the object to be restored from the restoration policy information. Then, based on the writable high-level file system driver in GuestOS, the data in the object to be restored is restored to the data corresponding to the target restoration point. Then, in the second mounting module, each virtual disk in the target VM is mounted as a disk that GuestOS can recognize.

[0161] In the restore judgment module, if the received restore flag indicates that no restore should be performed, then in the second mount module, each virtual disk in the target VM is directly mounted as a disk that can be recognized by GuestOS.

[0162] By using the above method, based on the restore judgment module in the GuestOS stage, it is determined whether the restore flag in the boot information indicates that a restore should be performed or not. If the restore flag indicates that a restore should be performed, then in the restore operation module, the data in the object to be restored is restored to the data corresponding to the target restore point according to the restore policy information in the metadata. Then, the virtual disk is mounted in the second mount module. Thus, based on the restore flag and restore policy information, the VM's restore operation is configured in the GuestOS stage. Because the GuestOS has a writable high-level file system driver, the data in the object to be restored can be restored to the data corresponding to the target restore point according to the restore policy information based on this writable high-level file system driver in the GuestOS stage. Therefore, it avoids implementing a complete writable high-level file system driver in the UEFI stage, and avoids serious consequences such as data loss caused by the defects of the writable high-level file system driver itself when running the writable high-level file system driver in the UEFI stage.

[0163] Furthermore, by adding a restore identifier and metadata file path to the boot information during the startup information generation process in the generation module, and by adding restore policy information containing the restore time and the object to be restored to the metadata during the metadata generation process, the restore operation is further guaranteed to be delayed to the GuestOS stage. This avoids the limitation that UEFI does not have a writable advanced file system driver, thereby further ensuring that the electronic device can perform the restore operation.

[0164] Furthermore, storing the restore identifier in the startup information allows for dynamic adjustment of its contents, facilitating real-time modification of the restore identifier each time a VM is started. Based on the metadata file path in the startup information, the target VM to be started can be determined, enabling electronic devices to identify the VM to be operated on when multiple VMs exist. Based on the object to be restored in the restore policy information, the electronic device can clearly identify the object to be restored when performing a restore operation.

[0165] Based on the same inventive concept, this application also provides a virtual machine restoration device, such as... Figure 4 The diagram shown is a structural schematic of a virtual machine restoration device provided in this application. The device includes:

[0166] The reading module 401 is used to read startup information from a specified storage area in response to starting the guest operating system (GuestOS) in the target virtual machine. The startup information includes a restore flag, which indicates whether to restore the data in the object to be restored to the data corresponding to the target restore point.

[0167] The processing module 402 is used to restore the data in the object to be restored to the data corresponding to the target restore point according to the restore policy information corresponding to the target virtual machine if the restore identifier indicates that a restore is to be performed, and to mount each virtual disk in the target virtual machine as a disk that can be recognized by GuestOS. The restore policy information indicates the object to be restored.

[0168] In one possible implementation, the reading module 401 is specifically used to generate boot information in the Unified Extensible Firmware Interface (UEFI) phase or in the maintenance system, and save the boot information to a specified storage area.

[0169] In one possible implementation, the reading module 401 is specifically used to obtain the metadata file path, which corresponds to the target virtual machine to be started.

[0170] Startup information is generated based on the restore identifier and metadata file path.

[0171] In one possible implementation, the reading module 401 is specifically used to receive a restore instruction generated based on user operation or a restore instruction generated based on restore strategy information.

[0172] Update the restore flag according to the restore command.

[0173] In one possible implementation, the reading module 401 is specifically used to obtain the restore time corresponding to the target virtual machine and the objects to be restored in the target virtual machine;

[0174] Restore strategy information is generated based on the restore time and the object to be restored.

[0175] In one possible implementation, the reading module 401 is specifically used to receive an instruction indicating the target restoration point;

[0176] Based on the instructions, the initial restore point is modified to the target restore point in the startup information.

[0177] In one possible implementation, the processing module 402 is specifically configured to mount each virtual disk in the target virtual machine as a disk recognizable by the GuestOS if the restore flag indicates that no restore should be performed.

[0178] In one possible implementation, the processing module 402 is specifically used to save the data in the change information generated by the target virtual machine to the created differential file when the target virtual machine is running;

[0179] Update the new path in the change information to the metadata file of the corresponding metadata file path or the temporary file that has been created. The new path is the path of the file in the target virtual machine after the path has changed.

[0180] In one possible implementation, the processing module 402 is specifically used to obtain the restoration time in the restoration strategy information or to receive a new restoration instruction generated based on user operation.

[0181] Generate a new restore identifier based on the restore time or the new restore command;

[0182] New startup information is generated based on the new restore identifier and the obtained new metadata file path, and the new startup information is saved to a specified storage area that is readable, writable and persistent. The new metadata file path corresponds to the target virtual machine to be started.

[0183] Based on the newly started information, perform a restart operation on the target virtual machine.

[0184] Based on the same inventive concept, this application also provides an electronic device that can realize the function of the aforementioned virtual machine restoration device. (Refer to...) Figure 5 The aforementioned electronic devices include:

[0185] At least one processor 501 and a memory 502 connected to at least one processor 501. In this embodiment, the specific connection medium between the processor 501 and the memory 502 is not limited. Figure 5 The example shown is the connection between processor 501 and memory 502 via bus 500. Bus 500 is... Figure 5 The connections between other components are indicated by thick lines and are for illustrative purposes only, not as limiting information. The Bus 500 can be divided into address bus, data bus, control bus, etc., for ease of representation. Figure 5 The term 501 is represented by a single thick line, but this does not imply that there is only one bus or one type of bus. Alternatively, the processor 501 can also be called a controller; there is no restriction on the name.

[0186] In this embodiment, memory 502 stores instructions executable by at least one processor 501. By executing the instructions stored in memory 502, at least one processor 501 can perform the virtual machine restoration method described above. Processor 501 can implement... Figure 4 The functions of each module in the device shown.

[0187] The processor 501 is the control center of the device. It can connect to various parts of the control device through various interfaces and lines. By running or executing instructions stored in memory 502 and calling data stored in memory 502, the processor can perform various functions and process data, thereby monitoring the device as a whole.

[0188] In one possible design, processor 501 may include one or more processing units. Processor 501 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operating system, user interface, and applications, and the modem processor mainly handles wireless communication. It is understood that the modem processor may also not be integrated into processor 501. In some embodiments, processor 501 and memory 502 may be implemented on the same chip; in some embodiments, they may also be implemented on separate chips.

[0189] Processor 501 can be a general-purpose processor, such as a CPU, digital signal processor, application-specific integrated circuit, field-programmable gate array or other programmable logic device, discrete gate or transistor logic device, or discrete hardware component, capable of implementing or executing the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the virtual machine restoration method disclosed in the embodiments of this application can be directly manifested as execution by a hardware processor, or execution by a combination of hardware and software modules within the processor.

[0190] Memory 502, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules. Memory 502 may include at least one type of storage medium, such as flash memory, hard disk, multimedia card, card-type memory, random access memory (RAM), static random access memory (SRAM), programmable read-only memory (PROM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), magnetic memory, magnetic disk, optical disk, etc. Memory 502 can be any other medium capable of carrying or storing desired program code in the form of instructions or data structures that can be accessed by a computer, but is not limited thereto. In the embodiments of this application, memory 502 can also be a circuit or any other device capable of implementing storage functions for storing program instructions and / or data.

[0191] By designing and programming the processor 501, the code corresponding to the virtual machine restoration method described in the foregoing embodiments can be embedded into the chip, enabling the chip to execute the code during runtime. Figure 1 The steps of the virtual machine restoration method in the illustrated embodiment are as follows. How to design and program the processor 501 is a technique well-known to those skilled in the art and will not be described further here.

[0192] Based on the same inventive concept, embodiments of this application also provide a storage medium storing computer instructions that, when executed on a computer, cause the computer to perform the virtual machine restoration method described above.

[0193] In some possible implementations, various aspects of the virtual machine restoration method provided in this application can also be implemented in the form of a program product, which includes program code that, when the program product is run on a device, causes the control device to perform the steps in the virtual machine restoration method according to the various exemplary embodiments of this application described above.

[0194] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0195] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0196] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0197] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0198] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A method for restoring a virtual machine, characterized in that, The method includes: In response to starting the Guest OS in the target virtual machine, startup information is read from a specified storage area. The startup information includes a restore flag, which indicates whether to restore the data in the object to be restored to the data corresponding to the target restore point. If the restore identifier indicates that a restore should be performed, the data in the object to be restored is restored to the data corresponding to the target restore point according to the restore policy information corresponding to the target virtual machine, and each virtual disk in the target virtual machine is mounted as a disk recognizable by the GuestOS, wherein the restore policy information indicates the object to be restored.

2. The method as described in claim 1, characterized in that, Before reading the startup information from the designated storage area, the method further includes: During the Unified Extensible Firmware Interface (UEFI) phase or in the maintenance system, the boot information is generated and saved to the designated storage area.

3. The method as described in claim 2, characterized in that, The generation of the startup information includes: Obtain the metadata file path, which corresponds to the target virtual machine to be started; The startup information is generated based on the restore identifier and the metadata file path.

4. The method as described in claim 3, characterized in that, Before generating the startup information based on the restore identifier and the metadata file path, the method further includes: Receive a restore command generated based on user operation or a restore command generated based on the restore strategy information; Update the restore identifier according to the restore command.

5. The method as described in claim 1, characterized in that, Before reading the startup information from the designated storage area, the following is also included: Obtain the restore time corresponding to the target virtual machine and the object to be restored in the target virtual machine; The restoration strategy information is generated based on the restoration time and the object to be restored.

6. The method as described in claim 1, characterized in that, Before reading the startup information from the designated storage area, the following is also included: Receive an instruction indicating the target restoration point; Based on the instruction, the initial restore point is modified to the target restore point in the startup information.

7. The method as described in claim 1, characterized in that, After reading the startup information from the designated storage area, the process also includes: If the restore flag indicates that no restore should be performed, then each virtual disk in the target virtual machine will be mounted as a disk that the GuestOS can recognize.

8. The method as described in claim 1 or 7, characterized in that, After mounting each virtual disk in the target virtual machine as a disk recognizable by the GuestOS, the method further includes: When the target virtual machine is running, the data in the change information generated by the target virtual machine is saved to the created differential file; The new path in the change information is updated in the metadata file of the corresponding metadata file path or in the temporary file that has been created, wherein the new path is the path after the path corresponding to the file in the target virtual machine has changed.

9. The method as described in claim 1 or 7, characterized in that, The startup information is stored in the designated, readable, and persistent storage area. After mounting each virtual disk in the target virtual machine as a disk recognizable by the GuestOS, the method further includes: Obtain the restoration time from the restoration strategy information or receive a new restoration command generated based on user operation; A new restore identifier is generated based on the restore time or the new restore instruction; New startup information is generated based on the new restore identifier and the obtained new metadata file path, and the new startup information is saved to the specified storage area that is readable, writable and persistent, wherein the new metadata file path corresponds to the target virtual machine to be started; Based on the newly launched information, perform a restart operation on the target virtual machine.

10. A virtual machine restoration device, characterized in that, The device includes: The read module is used to read startup information from a specified storage area in response to starting the guest operating system (GuestOS) in the target virtual machine. The startup information includes a restore flag, which indicates whether to restore the data in the object to be restored to the data corresponding to the target restore point. The processing module is configured to, if the restore identifier indicates that a restore is to be performed, restore the data in the object to be restored to the data corresponding to the target restore point according to the restore policy information corresponding to the target virtual machine, and mount each virtual disk in the target virtual machine as a disk recognizable by the GuestOS, wherein the restore policy information indicates the object to be restored.

11. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, when executing a computer program stored in the memory, implements the method steps of any one of claims 1-9.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the method described in any one of claims 1-9.

Images