Mirror management method and device, server, terminal and storage medium

Abstract

Embodiments of the present application disclose a mirror image management method and device, a server, a terminal and a storage medium, which comprise: receiving a first download request sent by a first terminal, the first terminal using a first mirror image file and a second mirror image file, the first mirror image file recording an operating system used by a cloud desktop in the first terminal, and the second mirror image file recording device drivers and application programs installed based on the operating system; sending a new second mirror image file to the first terminal, so that the first terminal replaces a locally original second mirror image file with the received second mirror image file and records data newly added when the cloud desktop runs in a state of setting a second snapshot in a third mirror image file, the third mirror image file being generated based on the new second mirror image file in which the second snapshot is set, and the third mirror image file being generated by the server or the first terminal. The above method can solve the technical problem that a server needs to consume a large amount of network resources to download mirror image files to a terminal in the related art.

Description

Technical Field

[0001] This application relates to the field of cloud desktop technology, and in particular to an image management method, device, server, terminal and storage medium. Background Technology

[0002] Cloud desktop, also known as desktop virtualization or cloud PC, is a new model that replaces traditional computers. It uses virtualization technology to virtualize various physical devices, thereby effectively improving resource utilization, saving costs, and improving application quality.

[0003] Intelligent Desktop Virtualization (IDV) is a common type of cloud desktop. IDV uses distributed computing and distributed storage, and features centralized management and local execution. That is, it utilizes the local computing and storage resources of the terminal, so even if there are network problems connecting to the server, the normal use of the cloud desktop can be guaranteed.

[0004] When using IDV, cloud desktop image files need to be distributed to terminals. These image files contain the operating system, device drivers, and applications required to run the cloud desktop. Generally, when upgrading the image file, the content recorded in the image file needs to be updated. At this time, the server needs to redeploy the updated image file to the terminal. However, image files have a large memory footprint. When image files are updated frequently, they need to be redeployed to the terminal frequently, which consumes a lot of network resources. Summary of the Invention

[0005] One embodiment of this application provides an image management method, apparatus, server, terminal, and storage medium to solve the technical problem in related technologies that the server needs to consume a lot of network resources to send image files to the terminal.

[0006] In a first aspect, one embodiment of this application provides an image management method applied to a server, comprising:

[0007] The system receives a first download request from a first terminal. The first terminal uses a first image, which includes a first image file and a second image file. The first image file records the operating system used by the cloud desktop in the first terminal, and the second image file records the device drivers and applications installed based on the operating system.

[0008] When the first download request is used to download a new second image file from the server, the new second image file is sent to the first terminal so that the first terminal replaces the original local second image file with the received second image file and creates a corresponding third image file based on the set second snapshot in the received second image file. The first image also includes the third image file, and the third image file records the data added by the cloud desktop when it is running in the state of the set second snapshot.

[0009] When the first download request is used to download a new second image file and the corresponding third image file from the server, the new second image file and the third image file are sent to the first terminal so that the first terminal replaces the original local second image file with the received second image file, and the third image file is generated based on the second snapshot set in the new second image file.

[0010] Secondly, one embodiment of this application also provides an image management method applied to a first terminal. The first terminal uses a first image, the first image comprising a first image file and a second image file. The first image file records the operating system used by the cloud desktop in the first terminal, and the second image file records device drivers and applications installed based on the operating system. The method includes:

[0011] Send a first download request to the server of the cloud desktop;

[0012] When the first download request is used to download a new second image file from the server, the new second image file sent by the server is received;

[0013] Replace the existing local second image file with the received second image file;

[0014] A corresponding third image file is created based on the second snapshot setting in the received second image file. The first image file also includes the third image file, which records the data added by the cloud desktop when it is running under the state of the second snapshot setting.

[0015] When the first download request is used to download a new second image file and the corresponding third image file from the server, the server sends the new second image file and the third image file, and the third image file is generated based on the set second snapshot in the new second image file;

[0016] Replace the existing local second image file with the received second image file.

[0017] Thirdly, one embodiment of this application also provides a mirror management device applied to a server, comprising:

[0018] The first receiving unit is configured to receive a first download request sent by a first terminal. The first terminal uses a first image. The first image includes a first image file and a second image file. The first image file records the operating system used by the cloud desktop in the first terminal. The second image file records the device drivers and applications installed based on the operating system.

[0019] The first sending unit is configured to send the new second image file to the first terminal when the first download request is used to download a new second image file from the server, so that the first terminal replaces the original local second image file with the received second image file and creates a corresponding third image file based on the set second snapshot in the received second image file. The first image file also includes the third image file, and the third image file records the data added by the cloud desktop when it is running in the state of the set second snapshot.

[0020] The second sending unit is configured to send the new second image file and the corresponding third image file to the first terminal when the first download request is used to download a new second image file and the corresponding third image file from the server, so that the first terminal can replace the original local second image file with the received second image file, and the third image file is generated based on the set second snapshot in the new second image file.

[0021] Fourthly, one embodiment of this application also provides an image management device applied to a first terminal. The first terminal uses a first image, the first image comprising a first image file and a second image file. The first image file records the operating system used by the cloud desktop in the first terminal, and the second image file records device drivers and applications installed based on the operating system. The device includes:

[0022] The third sending unit is used to send a first download request to the server of the cloud desktop;

[0023] The first download unit is configured to receive a new second image file sent by the server when the first download request is for downloading a new second image file from the server;

[0024] The first replacement unit is used to replace the existing local second image file with the received second image file;

[0025] The first creation unit is used to create a corresponding third image file based on the second snapshot setting in the received second image file. The first image file also includes the third image file, which records the data added by the cloud desktop when it is running under the state of the second snapshot setting.

[0026] The second download unit is configured to receive the new second image file and the corresponding third image file sent by the server when the first download request is used to download a new second image file and the corresponding third image file from the server, wherein the third image file is generated based on the set second snapshot in the new second image file;

[0027] The second replacement unit is used to replace the existing local second image file with the received second image file.

[0028] Fifthly, one embodiment of this application also provides a mirror management server, including:

[0029] The communication module is used to implement data communication;

[0030] One or more processors;

[0031] Memory, used to store one or more programs;

[0032] When the one or more programs are executed by the one or more processors, the one or more processors implement the image management method as described in the first aspect.

[0033] Sixthly, one embodiment of this application also provides a mirror management terminal, including:

[0034] The communication module is used to implement data communication;

[0035] One or more processors;

[0036] Memory, used to store one or more programs;

[0037] When the one or more programs are executed by the one or more processors, the one or more processors implement the image management method as described in the second aspect.

[0038] In a seventh aspect, one embodiment of this application also provides a computer-readable storage medium having a computer program stored thereon that, when executed by a processor, implements the image management method as described in the first aspect or the image management method as described in the second aspect.

[0039] In one embodiment of this application, the server receives a first download request sent by a first terminal and, based on the first download request, sends a second image file from a first image center to the first terminal. This allows the first terminal to replace its local second image file with the new second image file, enabling the first terminal to use the new second image file when running a cloud desktop application. Furthermore, any new data added during the first terminal's operation is written to the corresponding third image file of the new second image file. This technical approach solves the problem in related technologies where sending image files to the terminal requires significant network resources. By dividing the image into three levels of files, and when the first terminal downloads a new image file, the server does not need to send all the image files, only the second image file, reducing the memory required for downloading, saving network resources, and shortening download time. Moreover, since the third image file is created as a blank file, even if the corresponding third image file needs to be sent, it only occupies a small amount of network resources, ensuring the efficient use of network resources. Attached Figure Description

[0040] Figure 1 This is the first schematic diagram of the image file distribution process in related technologies;

[0041] Figure 2 This is a second schematic diagram of the image file distribution process in related technologies;

[0042] Figure 3 A schematic diagram of a mirror relationship provided for one embodiment of this application;

[0043] Figure 4 A flowchart illustrating an embodiment of this application provides a method for managing images;

[0044] Figure 5 A flowchart illustrating an embodiment of this application provides a method for managing images;

[0045] Figure 6 A flowchart of a mirror registration process is provided for one embodiment of this application;

[0046] Figure 7 A flowchart illustrating an embodiment of this application provides a method for managing images;

[0047] Figure 8 A flowchart illustrating a mirror merging process is provided as an embodiment of this application;

[0048] Figure 9 A flowchart illustrating an embodiment of this application provides a method for managing images;

[0049] Figure 10 A flowchart illustrating a mirror restoration process is provided as an embodiment of this application;

[0050] Figure 11 A flowchart illustrating an embodiment of this application provides a method for managing images;

[0051] Figure 12 A flowchart illustrating a mirror cloning process is provided as an embodiment of this application;

[0052] Figure 13 A flowchart illustrating an embodiment of this application provides a method for managing images;

[0053] Figure 14 This is a schematic diagram of the structure of a mirror management device provided in one embodiment of this application;

[0054] Figure 15 A schematic diagram of the structure of a mirror management device provided in one embodiment of this application.

[0055] Figure 16 This is a schematic diagram of the structure of a mirror management device provided in one embodiment of this application. Detailed Implementation

[0056] The present application will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are for illustrative purposes only and not for limiting the scope of the application. Furthermore, it should be noted that, for ease of description, only the parts relevant to the present application are shown in the drawings, not the entire structure.

[0057] Under the IDV type, there are two options for distributing image files to Guests (end users):

[0058] Option 1: Figure 1 This is the first schematic diagram of the image file distribution process in related technologies. (Reference) Figure 1 When a terminal (i.e., the end user) needs to download an image file, it sends a download request to the server. After the server verifies the validity of the download request, it sends the base image file to the terminal. The terminal then starts a virtual machine based on the base image file to run the cloud desktop. The base image file is also known as the image file; the terminal can customize it by adding its own personalized data during operation.

[0059] Option 2: Figure 2 This is the second schematic diagram of the image file distribution process in related technologies. (Reference) Figure 2 When a terminal needs to download an image file, it sends a download request to the server. After the server verifies the validity of the download request, it sends the differential image file to the terminal. The terminal then merges the differential image file into the base image file. Subsequently, the terminal starts a virtual machine based on the base image file to run the cloud desktop. The differential image file refers to an image file obtained using differential technology.

[0060] Generally, when running a cloud desktop based on an image file, the image file needs to be updated during management. For example, after the server upgrades the image file, it needs to be updated. Similarly, when a terminal uses the cloud desktop and fills in its personalized data into the image file, it also needs to be updated. In this case, when distributing image files using Solution 1, after the server upgrades or updates the image file, regardless of the size of the changes, all terminals using the image file need to download the full image file again. This consumes significant network resources, requires a long download time, and is not conducive to unified updates of image files by terminals. Using Solution 2, only the updated differential image file can be downloaded. While this reduces the amount of data downloaded, it increases the time for merging differential image files on the terminals. Furthermore, a local backup of the base image file is required to prevent corruption of the base image file due to power outages or other factors during the merging process. This not only increases the processing time for image files on the terminals but also wastes local storage space on the terminals. Furthermore, regardless of whether Option 1 or Option 2 is used to distribute image files, after an administrator modifies the image file on a terminal, the terminal must first submit the image file to the server so that the server can distribute the modified image file to all terminals using that image file. This not only requires each terminal to download the complete image file, but also requires the terminal used by the administrator to upload the complete image file, increasing the network resources and transmission time required for the download and upload processes, which is detrimental to the server's management of image files. At this point, due to the limitations of public network bandwidth, the popularization and application of IDV-type cloud desktops are also greatly hindered.

[0061] In summary, when running IDV type cloud desktops using image files, ensuring the rational use of network resources and saving transmission time during image file management has become an urgent technical problem to be solved.

[0062] Accordingly, this application provides an image management method, apparatus, server, terminal, and storage medium to ensure the rational use of network resources and save transmission time when managing image files in scenarios where an IDV-type cloud desktop is running on the terminal.

[0063] One embodiment of this application provides an image management method, which can be executed by an image management device. The image management device can be composed of two or more physical entities, or it can be composed of a single physical entity.

[0064] In one embodiment, the image management device is an image management server (also referred to as a server). This server can act as a server for IDV-type cloud desktops, used to manage images and provide the image files required for terminals to run cloud desktops. Currently, terminals (also referred to as terminal devices, electronic terminals, etc.) can be any terminal that supports virtualization, such as personal computers, tablets, interactive whiteboards, mobile phones, etc. Virtualization typically refers to computing components running on a virtual rather than a real basis. Virtualization technology can expand hardware capacity and simplify the software reconfiguration process. Virtual machines are one way to implement virtualization. A virtual machine refers to a complete computer system simulated by software, possessing full hardware system functionality and running in a completely isolated environment. Currently, terminals running cloud desktops are achieved through virtual machines.

[0065] An image, also referred to as an image file, is a file that a terminal depends on when starting a virtual machine. In one embodiment, each image contains three types of image files. These three types of image files can be referred to as: BaseImage, LowerImage, and UpperImage.

[0066] The BaseImage records the operating system used by the cloud desktop. Currently, the BaseImage records the clean operation, without any applications or additional device drivers from the operating system. Each image can have its own independent BaseImage, or multiple images can share the same BaseImage. When multiple images share the same BaseImage, the BaseImage is provided to the images as a hard link, which saves server storage space. A hard link refers to one or more filenames linked to the same file; these filenames can be in the same directory or different directories. Optionally, when the terminal is running the cloud desktop, the BaseImage can be read but not modified to protect it from corruption.

[0067] LowerImage is a sub-disk of BaseImage; that is, LowerImage is created based on BaseImage and serves as a next-level file. LowerImage records device drivers and applications installed based on the operating system. In one embodiment, each Guest image includes an initial LowerImage for different terminal models. This LowerImage contains the applications and device drivers built into the terminal running the corresponding operating system. Users can then derive their own LowerImage based on the initial LowerImage. This LowerImage contains personalized data from the user's usage, such as newly installed device drivers, applications, saved files, or data. Optionally, each user can have an independent LowerImage.

[0068] UpperImage is a sub-disk of LowerImage; it is created based on LowerImage and serves as a next-level file. UpperImage records new data added when the terminal runs the cloud desktop. Optionally, UpperImage can be considered a blank file when it is created, without recording any user-related data. New data is recorded in UpperImage while the user is using the cloud desktop. Data recorded in UpperImage can be submitted to LowerImage to add personalized data based on the user's usage.

[0069] At this point, BaseImage, LowerImage, and UpperImage can also be considered as three levels of files contained in the image.

[0070] In one embodiment, a mirror snapshot (also called a snapshot or Snapshot) refers to a restore point of a mirror file at a certain moment, meaning the mirror file can be restored from any state to the state corresponding to the snapshot (i.e., the restore point). Each snapshot has a corresponding snapshot name. The naming rules for snapshots are not currently limited, but generally, the snapshot name contains a unique identifier to distinguish each snapshot. Optionally, snapshots can be created for BaseImage, LowerImage, and UpperImage. Each mirror file can look up its corresponding snapshot list. For example, the snapshot list corresponding to LowerImage records the names of the snapshots it contains, and LowerImage can find the required snapshot based on the snapshot list.

[0071] In one embodiment, a unique snapshot is created in the BaseImage, and a LowerImage is created based on the state of the BaseImage at the time of the unique snapshot. Optionally, before creating the LowerImage, the filename of the BaseImage is changed to the snapshot name of the unique snapshot of the BaseImage. Then, when creating the LowerImage, the filename of the BaseImage is recorded in the LowerImage to ensure that the snapshot name of the BaseImage is accurately recorded in the LowerImage, and thus the BaseImage corresponding to the LowerImage can be found through the snapshot name of the BaseImage.

[0072] In one embodiment, multiple snapshots are created in the LowerImage. Optionally, when creating a LowerImage for different terminal models (currently the initial LowerImage), a driver snapshot is created after installing the operating system's built-in device driver in the LowerImage, and an application snapshot is created after installing the operating system's built-in application (also known as a basic application). These two snapshots allow the LowerImage to be restored to the state when the device driver and application were installed, respectively. Optionally, when the LowerImage is used by the terminal, newly added personalized data can also be written to it, and corresponding snapshots can be created based on the written personalized data. In one embodiment, a corresponding UpperImage can be created based on a snapshot state of the LowerImage. That is, the UpperImage corresponds to a snapshot of the LowerImage. Similar to creating the LowerImage, the UpperImage records the snapshot name of its corresponding snapshot in the LowerImage, so that the corresponding LowerImage can be found through the snapshot name of the LowerImage in the UpperImage, and the corresponding snapshot can be determined in the LowerImage. Optionally, when a snapshot is created in LowerIamge, a corresponding UpperImage is generated. When the terminal runs a cloud desktop based on the LowerIamge under this snapshot, new data added during the cloud desktop runtime can be written to the UpperImage, using this snapshot as the node. Then, the server submits the UpperImage to LowerIamge, writing the personalized data under the corresponding snapshot node into LowerIamge. Afterwards, a new snapshot can be created in LowerIamge, and a corresponding UpperImage can be created again based on the new snapshot, allowing the terminal to run the cloud desktop based on the LowerIamge corresponding to the new snapshot, and writing the new data into the UpperImage. In this case, for the terminal, the snapshot of LowerIamge serves as the distinguishing factor; the data added by the terminal is written to the UpperImage corresponding to the snapshot, without modifying the BaseImage and LowerIamge in the terminal.

[0073] In one embodiment, each snapshot in the LowerImage corresponds to a version (also known as an image version or revision). Creating a new snapshot in the LowerImage is considered creating a new version. For the terminal, switching between different snapshots in the LowerImage allows switching between different versions. Each version has a unique version ID, the specific naming rules of which are not currently limited. Each version also has a corresponding version UUID (a universally unique identifier for the version). When a terminal is running a cloud desktop and wants to change the version it is using, it only needs to retrieve the corresponding LowerImage (which represents the snapshot state of that version) from the server and use it. It can be understood that when an image is used by multiple users, for data security reasons, each user has their own independent LowerImage file. Each user's version data is stored in their own LowerImage file as a built-in snapshot, and users are only allowed to download their own LowerImage files. Each version for the same user corresponds to a built-in snapshot in the LowerImage, and the snapshot name of this built-in snapshot is the version UUID. The snapshot name of the built-in snapshot determines whether the current version is available to the user. Optionally, each version and its corresponding snapshot name can be associated and recorded in the snapshot list. The version allows you to find the corresponding snapshot name, the snapshot name allows you to find the corresponding LowerImage, the snapshot name of the BaseImage recorded in the LowerImage allows you to find the corresponding BaseImage, and the snapshot name corresponding to the version allows you to find the corresponding UpperImage. In this case, the found BaseImage, LowerImage, and UpperImage can be considered associated with the corresponding version. That is, each version of each image has associated BaseImage, LowerImage, and UpperImage. In one embodiment, each version has a corresponding version record and version directory. The version record records the version's metadata (used to describe the version's attributes), and the version directory records its associated BaseImage and LowerImage. Optionally, the version directory can also be recorded as its associated UpperImage. Optionally, the BaseImage is linked to the version directory using a hard link, and different versions can share the BaseImage.

[0074] In one embodiment, an image can have one or more branches (also called image version branches), and a branch can have one or more versions. Each user of the image can have their own independent branch. Different images or different branches of the same image can share a single BaseImage. For ease of understanding, Figure 3 This is a schematic diagram illustrating a mirror relationship in one embodiment of this application, which exemplarily shows the relationship between mirrors, branches, and versions, as well as the relationship between BaseImage, LowerImage, and UpperImage. Figure 3 As shown, a single BaseImage can be used by multiple images via hard links. Figure 3 It contains mirror A and mirror B. Mirror A contains branch a, and mirror B contains branches b and c. Branch a is used by user A, who has an independent LowerImage (LowerImageA). LowerImageA contains snapshots A1, A2, and A3. Snapshot A1 corresponds to version 1, A2 to version 2, and A3 to version 3. Each snapshot can generate a corresponding UpperImage. Figure 3 To illustrate the correspondence between snapshots and versions, the snapshots contained in LowerViewA are shown with dashed boxes. In actual applications, snapshots are contained within LowerViewA. Furthermore, Figure 3 The fact that snapshots A1, A2, and A3 point to UpperImageA means that each snapshot creates a corresponding UpperImage, not that the three snapshots share a single UpperImage. Branch b is used by user B, and branch c is used by user c. In this case, the relationships between the snapshots, versions, and three types of files corresponding to branches b and c are similar to those of branch a, and will not be elaborated upon here. Based on Figure 3 As shown, a file chain can be formed between BaseImage, LowerImage, and UpperImage, which can avoid confusion in the file relationships between different branches.

[0075] For the terminal, the virtual machine requires BaseImage, LowerImage, and UpperImage to start. Furthermore, the virtual machine can start directly based on UpperImage, without needing to merge BaseImage, LowerImage, and UpperImage into a single file.

[0076] The server also stores an image table (osimages), which contains multiple image records. Each image record corresponds to an image and records the image's metadata (used to describe the image's attributes).

[0077] The BaseImage, LowerImage, and UpperImage stored on the server are available for download by the terminal. Optionally, BaseImage, LowerImage, and UpperImage are all provided for download as torrent files. That is, the server can generate a BaseImage torrent file, a LowerImage torrent file, and an UpperImage torrent file, respectively. These torrent files refer to P2P download torrent files. P2P (peer-to-peer) is a peer-to-peer computer network where clients can obtain the corresponding BaseImage, LowerImage, or UpperImage after downloading the torrent file via P2P.

[0078] It should be noted that the users mentioned above refer to users who use terminals. A user can use different terminals, and a terminal can be used by multiple users. Each user can be distinguished by the user ID used when logging in.

[0079] In one embodiment, Figure 4 This is a flowchart illustrating an image management method provided in one embodiment of this application. When the server executes the image management method, it may include:

[0080] Step 110: Receive the first download request sent by the first terminal. The first terminal uses the first image. The first image contains a first image file and a second image file. The first image file records the operating system used by the cloud desktop in the first terminal. The second image file records the device drivers and applications installed based on the operating system.

[0081] For example, taking a server providing services to a terminal as an example, this describes how the server implements image management. Currently, the terminal providing services is referred to as the first terminal. The image used by the first terminal is referred to as the first image, meaning the first terminal runs the cloud desktop through the first image. When the first terminal runs the cloud desktop based on the first image, the BaseImage, LowerImage, and UpperImage used are referred to as the first image file, the second image file, and the third image file, respectively. Currently, the snapshot in the second image file is referred to as the second snapshot, and the snapshot in the first image file is referred to as the first snapshot. Based on the foregoing, the first image file contains a unique first snapshot, the second image file contains the first snapshot name of the first snapshot; the second image file contains at least one second snapshot, and the third image file contains the second snapshot name of the corresponding second snapshot. The snapshot name of the first snapshot is referred to as the first snapshot name, and the snapshot name of the second snapshot is referred to as the second snapshot name. The second image file used by the first terminal when running the cloud desktop corresponds to a version, and the third image file used is generated based on the snapshot corresponding to that version in the second image file. The first image has at least one version recorded on the server. Each version corresponds to a second snapshot in the second image file and is associated with the second image file, the first image file corresponding to the first snapshot name in the second image file, and the third image file corresponding to the second snapshot. Each version has a corresponding version ID. Optionally, running the first image on the first terminal can be considered as running a branch of the first image. The first image has at least one image branch recorded on the server, and each image branch contains at least one version. The first terminal applies an image branch of the first image. Optionally, the first image run by the terminal can specifically be a version under that image branch. In this case, the first image ID mentioned later can also be considered as the ID of the image branch in the first image.

[0082] Before the first terminal runs the cloud desktop for the first time, it needs to download the first and second image files from the server, and then determine whether to create or download a third image file based on its own situation. Optionally, if the first terminal has the ability to create a third image file, it can create the third image file based on the second snapshot corresponding to the current version. If the first terminal does not have the ability to create a third image file, the server can generate the third image file and distribute it to the first terminal. Afterwards, the first terminal runs a virtual machine based on the first, second, and third image files, and runs the cloud desktop through the virtual machine.

[0083] When the first terminal needs a version update, it generates a corresponding download request and retrieves the corresponding second image file from the server based on the download request, thus implementing the version update based on the second image file. Currently, the download request generated by the first terminal is denoted as the first download request. When the first terminal generates the first download request, it already has the first and second image files stored locally. The second image file may or may not contain the user's personalized data.

[0084] The method for generating the first download request is currently not limited. For example, when the server determines that the second image file has been updated (i.e., a new version has been generated), it sends a version update notification to the first terminal using the second image file. The user of the first terminal can then determine whether to update the version based on this notification, and upon confirming the update, generate the first download request and send it to the server. Alternatively, the user of the first terminal may generate the first download request and send it to the server when they need to update the version. Another example is when the user of the first terminal confirms the need to create a restore point (i.e., a snapshot) based on the current running state of the cloud desktop. They upload the third image file containing the newly added data to the server, which then submits the third image file to the second image file and creates the corresponding snapshot and version, thus updating the version of the second image file. In this case, the server can create the restore point through the first terminal, and then the first terminal generates the first download request and sends it to the server. Alternatively, the first terminal may generate the first download request before uploading the third image file and send both the third image file and the first download request to the server together.

[0085] In one embodiment, depending on whether the first terminal has the function of creating a third image file, the first download request is divided into two types: one type is for downloading a second image file from the server, in which case the first terminal can create a third image file locally based on the second image file; the other type is for downloading both the second and third image files from the server. It is understood that if the first terminal has the function of creating the third image file first, it can also choose to download the third image file from the server.

[0086] After receiving the first download request, the server parses it. If it determines that the request is for downloading the second image file, step 120 is executed; if it determines that the request is for downloading both the second and third image files, step 130 is executed. Optionally, the first terminal writes an identifier indicating whether it can generate the third image file into the first download request, so that the server can determine whether to send the third image file based on this identifier. Alternatively, the server pre-records terminal models that can locally generate third image files. When the first terminal generates the first download request, it writes its terminal model into the request, and the server determines whether to send the third image file based on the terminal model in the first download request.

[0087] It should be noted that the following examples illustrate two different processing methods, one where the first terminal has the ability to create a third image file and the other where it does not. In practical applications, all terminals served by the server may have the ability to create a third image file. In this case, the first download request is only used to download a new second image file from the server. Alternatively, none of the terminals served by the server may have the ability to create a third image file. In this case, the first download request is only used to download a new second image file and its corresponding third image file from the server. In practical applications, the server may also generate the third image file regardless of whether the terminal has the ability to create it. In this case, the first download request is only used to download a new second image file from the server.

[0088] Step 120: When the first download request is used to download a new second image file from the server, the new second image file is sent to the first terminal so that the first terminal can replace the original local second image file with the received second image file and create a corresponding third image file based on the second snapshot setting in the received second image file. The first image also contains the third image file, which records the data added when the cloud desktop is running in the state of setting the second snapshot.

[0089] For example, the second image file downloaded by the first terminal from the server and the original second image file on the local machine can be considered as different versions of the same second image file. The content of the second image file differs between the different versions. In this case, for easy distinction, the downloaded second image file is recorded as the new second image file.

[0090] Currently, the first download request is used to download a new second image file from the server. After receiving the first download request, the server parses it to locate the new second image file to be downloaded. In one embodiment, the first download request may contain the version ID to be downloaded. Optionally, the version ID to be downloaded may be sent by the server to the first terminal; for example, after the server updates the version, it sends the current version ID to the first terminal. Alternatively, the version ID to be downloaded may be selected by the user of the first terminal. For example, after logging in, the user of the first terminal can search the server for versions corresponding to the currently used second image file in the first image, and then select the version to download. To ensure data security, the server may display all available versions to the user, while versions not available to the user will not be displayed. Alternatively, the server may set different permissions for different users, allowing only users with specific permissions to search for versions. After receiving the first download request, the server obtains the version ID and locates the corresponding version-associated second image file as the new second image file. In one embodiment, the first download request may include an image ID of the first image. After obtaining the image ID, the server finds the latest version of the second image file in the first image for use by the first terminal based on the image ID, and uses the second image file associated with the latest version as the new second image file. In another embodiment, the first download request may include an image ID and a version ID. Subsequently, the server finds the new second image file based on the image ID and the version ID. In yet another embodiment, the first download request includes a user ID. The server determines the first image used by the first terminal based on the user ID, and uses the latest version of the second image file in the first image for use by the first terminal as the new second image file. The server may also determine the new second image file through other methods.

[0091] The server sends the new second image file to the first terminal. Upon receiving the new second image file, the first terminal replaces its existing local second image file with the new one to update the version. Optionally, after the version update, a third image file corresponding to the current version needs to be used to record the data added when the first terminal runs the cloud desktop based on the current version. In this case, the first terminal obtains the second snapshot corresponding to the current version from the second image file and generates the third image file based on the second snapshot. That is, the third image file is generated based on the second snapshot set in the second image file (currently the second snapshot corresponding to the updated version). Afterward, the first terminal can run the cloud desktop based on the current version. Optionally, before the update, the first terminal's original version may also have a corresponding third image file. Before the version update, the user can determine whether the data recorded in the original third image file needs to be discarded. If discarded, the third image file can be directly deleted locally, thus abandoning the modification of the original version. If not discarded, the third image file can be uploaded to the server first, and the server will submit the third image file to the corresponding second image file. Then, the server creates a new version based on the submission result, and the second image file corresponding to the new version can be used as the new second image file for the first terminal to download. After the first terminal uploads the third image file, it can delete the local third image file, or associate the third image file with the corresponding version and save it, or the server can associate the third image file with the corresponding version and save it.

[0092] Step 130: When the first download request is used to download a new second image file and a corresponding third image file from the server, the new second image file and the third image file are sent to the first terminal so that the first terminal can replace the original local second image file with the received second image file, and the third image file is generated based on the settings of the second snapshot in the new second image file.

[0093] The difference between this step and step 120 is that the third image file is generated on the server in this step. In one embodiment, when the server creates a snapshot (i.e., a version) for the second image file, it generates the third image file corresponding to that version, and upon receiving the first download request, it sends the second image file and the corresponding third image file together to the first terminal.

[0094] Optionally, after receiving the first download request, the server parses it to find the new second image file and the corresponding third image file to be downloaded. Optionally, the corresponding third image file can be found based on the version of the new second image file. The process of the server parsing the first download request can be referred to the relevant description in step 120, and will not be repeated here.

[0095] The server sends the newly found second image file and the corresponding third image file to the first terminal. For example, when the first terminal receives the new second image file, it replaces the existing local second image file with the new one to update the version. Then, it runs the cloud desktop based on the current version and writes the newly added data into the corresponding third image file for the current version. Optionally, before the update, the first terminal may also have a corresponding third image file for its original version. In this case, the processing of the third image file can be referred to the relevant description in step 120, which will not be repeated here.

[0096] The above-described method, in which the server receives a first download request from the first terminal and, based on the request, sends a second image file from the first image center to the first terminal, allows the first terminal to replace its local second image file with the new one. This enables the first terminal to use the new second image file when running the cloud desktop application. Furthermore, any new data added during the first terminal's operation is written to the corresponding third image file of the new second image file. This method solves the technical problem in related technologies where sending image files to the terminal requires significant network resources. By dividing the image into three levels, and when the first terminal downloads a new image file, the server does not need to send the entire image file, only the second image file, reducing the memory required for downloading, saving network resources, and shortening download time. Moreover, since the third image file is created as a blank file, even if it needs to be sent, it only consumes a small amount of network resources, ensuring the efficient use of network resources.

[0097] In one embodiment of this application, the image in the server needs to be registered before it can be used by the terminal. Here, the registration process of the image is described using the first image as an example. Figure 5 This application provides a flowchart of an image management method according to one embodiment, which illustrates the specific process of image registration management on a server. (Refer to...) Figure 5 The image management method includes:

[0098] Step 210: Obtain the first image file and the second image file.

[0099] For example, after the first and second image files are created, they need to be uploaded to the server for registration. The first and second image files can be uploaded separately or simultaneously. The terminal that creates the first and second image files and the upload rules used are not currently limited. In one embodiment, the currently uploaded first and second image files can be considered as the initial BaseImage and the initial LowerImage, respectively. The second image file is created based on the first image file.

[0100] It is understandable that the process of uploading the first and second image files can also be considered as the process of the server obtaining the first and second image files.

[0101] Step 220: Hard link the first image file and the second image file to the first image file respectively.

[0102] For example, to ensure the terminal correctly uses the first image, the first image file and the second image file are hard-linked to the first image, respectively. This explicitly defines the first and second image files currently used by the first image. It can be understood that if the second image file is used by a branch, then hard-linking the first and second image files to the first image can link them to that branch. Subsequently, when a new branch of the first image is created, the image metadata of the first image can be updated based on the second image file used by the new branch, and then the first image text and the second image file used by the new branch can be hard-linked to the first image (specifically, the new branch).

[0103] In one embodiment, when hard-linking the first image file and the second image file to the first image respectively, the method further includes: creating an image record for the first image and adding image metadata of the first image to the image record.

[0104] The image metadata of the first image describes its attributes, such as the branches it contains and the user IDs corresponding to each branch. The image metadata can be determined based on the first and second image files. Optionally, after generating the image metadata of the first image, it is recorded. This image metadata is recorded in an image record. For example, an image record for the first image is created, added to the image table, and then the image metadata of the first image is added to the image record. Optionally, when the first image is updated (e.g., a new branch or version is created in the first image), the image metadata in the image record is also updated synchronously.

[0105] The above process can also be considered as a mirror registration process.

[0106] Step 230: Create a corresponding version directory based on the initial second snapshot of the second image file, and hard link the first image file and the second image file to the version directory respectively to obtain the first image.

[0107] For example, after registration, version creation is performed. In one embodiment, the first image file contains a unique first snapshot. Before the second image file is created, the filename of the first image file is changed to the first snapshot name of the first snapshot. When the second image file is created, the first snapshot name of the first snapshot is recorded. Optionally, an initial second snapshot is created after the second image file is created. When the initial second snapshot is created, the second image file contains the device drivers and applications built into the operating system. Subsequently, users can derive their own second image files based on the second image file. The first image file and the initial second image file (containing only device drivers and vendor-built-in applications, and generating a second snapshot) can be created by the vendor of the first image and uploaded to the server. Subsequently, users generate their own snapshots based on the second image file (at this time, personalized data, such as application upgrade patches, are included).

[0108] A version corresponding to the initial second snapshot is created based on the initial second snapshot, and a version directory corresponding to this version is created. The first and second image files used by this version are added to this version directory. Optionally, when creating a version, a version ID can be determined, and when creating a version directory, the version ID corresponding to the version directory can be recorded to associate the version and the version directory. In one embodiment, both the first and second image files are added to the version directory as hard links. Optionally, for the first image file, it is first hard-linked to the first image, and then the first image file in the first image is hard-linked to the version directory. The hard-linking process for the second image file is similar to that of the first image file and will not be described in detail here. At this point, after adding the first and second image files to the version directory, the first image can be considered obtained. Optionally, since the terminal downloads the corresponding image through a torrent file, after hard-linking the first and second image files to the version directory, corresponding P2P download torrent files need to be created for the first and second image files respectively, so that the terminal can download them.

[0109] In one embodiment, when creating a corresponding version directory based on the initial second snapshot of the second image file, the method further includes: creating a version record corresponding to the initial second snapshot, and recording version metadata of the version corresponding to the initial second snapshot in the version record.

[0110] For example, when creating a version, in addition to creating a version directory, a version record is also created. The version record can also be associated with a version ID. In one embodiment, the version metadata is determined based on the first and second image files used in the version. The version metadata may include a user ID, a version ID, and a previous version ID, where the previous version refers to the version preceding the current version, i.e., the version created before the second image file created the current version. The version metadata can be updated in conjunction with version attributes. Then, the version metadata is added to the version record corresponding to the version.

[0111] In one embodiment, the creation of a third image file by the server is taken as an example. In this case, step 240 is included after step 230.

[0112] Step 240: Create the corresponding third image file based on the initial second snapshot.

[0113] Optionally, after the server creates the initial second snapshot of the second image file, it creates the corresponding third image file based on the initial second snapshot. One feasible approach is to rename the filename of the second image file to the snapshot name of the initial second snapshot, so that the snapshot name of the second snapshot is recorded in the third image file when it is created.

[0114] Optionally, after creation, a third image file can be added to the corresponding version directory to clearly indicate the three types of image files included in the corresponding version. The method for adding the third image file to the version directory is currently not limited.

[0115] Optionally, after creating the third image file, a corresponding P2P download seed file can be created for the third image file so that the terminal can download it.

[0116] Before the first terminal runs the cloud desktop for the first time, it needs to download the first image file, the initial second image file, and the third image file corresponding to the initial second image file from the server (currently, the torrent file is downloaded; later, the corresponding image files will be obtained based on the torrent file). Subsequent updates do not require repeatedly downloading the first image file.

[0117] In practical applications, the first terminal can also create the third image file. Optionally, after the first terminal creates the third image file, it can notify the server so that the server adds the third image file to the corresponding version directory.

[0118] The image registration process is described below as an example. Figure 6 This is a flowchart illustrating a mirror registration process according to one embodiment of this application. (Reference) Figure 6It illustrates the process of image upload and registration, as well as the processing method of image files in each process. After registration begins, the first step is to upload the image, i.e., upload the required files. Figure 6 Taking the first and second image files as examples, the server obtains the first and second image files respectively during this process. Then, image registration is performed. During this process, image metadata for the first image is generated, and the corresponding file processing method is to hard link the first and second image files to the first image. Next, an image record for the first image is created, and the image metadata is added to the image record. Then, an initial restore point (which can also be understood as creating an initial version) is created. The initial restore point refers to the initial second snapshot of the second image file. The corresponding file processing method is to create a version directory for the corresponding version, and hard link the first and second image files hard-linked during image registration to the version directory. Furthermore, a corresponding third image file is created based on the initial second snapshot of the second image file. Finally, seed creation is performed, that is, seed files are created for the first, second, and third image files respectively, for the first terminal to download.

[0119] Optionally, after the first terminal downloads the first image file and the initial second image file, it can embed the first image file and the initial second image file.

[0120] As mentioned above, during the image registration process, image files can be reused through hard links. Furthermore, the first and second image files are uploaded and registered independently, which facilitates subsequent image management. For example, when updating the version, only the second image file needs to be modified, without modifying the first image file.

[0121] In one embodiment of this application, when the server manages the image, it also needs to perform image merging management. Image merging can be understood as writing the user's personalized data recorded in the UpperImage into the corresponding LowerImage, thereby adding the user's personalized data to the LowerImage. Currently, taking the first image as an example, the image merging process is described. The first image has a corresponding snapshot list recorded on the server. The snapshot list records each version of the first image and the corresponding second snapshot for each version. Optionally, the snapshot list records the version ID and the corresponding second snapshot name. Figure 7 This application provides a flowchart of an image management method according to one embodiment, which is the process of a server performing image merging management. (Refer to...) Figure 7 The image management method includes:

[0122] Step 310: Receive the third image file uploaded by the first terminal.

[0123] For example, when the first terminal runs the cloud desktop, newly added data (i.e., user-personalized data) is written to the third image file. For instance, when the first terminal installs a new application or device driver in the cloud desktop, the new application and device driver are written to the third image file. Similarly, when the first terminal stores new files and data in the cloud desktop, the new files or data are written to the third image file. When the user of the first terminal needs to write data from the third image file to the second image file, the third image file can be uploaded to the server. Optionally, during the upload, an image merge request can be sent to allow the server to perform image merging.

[0124] Optionally, before merging the images, the server first determines the first image used by the first terminal, and then locks the first image. For example, the technical means used to determine the first image used by the first terminal are not currently limited. For instance, when the first terminal uploads a third image file, it informs the server of the first image it is using. Alternatively, the server records each terminal using each image; when the first terminal uploads a third image file, it provides its identity data (such as a user ID), and the server then determines the first image used by the first terminal based on this identity data. For example, locking the first image aims to prevent it from being downloaded; in this case, terminals cannot download the various sub-files contained in the first image.

[0125] Optionally, the third image file already contains the second snapshot name, allowing the server to locate the corresponding version, second image file, and other information based on the second snapshot name. Therefore, version verification is not required before the first terminal uploads the third image file. Optionally, the third image file can be uploaded using a differential upload method.

[0126] Step 320: Obtain the current version ID of the first image in the first terminal.

[0127] For example, the server determines the version ID currently used by the first terminal, i.e., determines the ClientRevisionId. For instance, when the first terminal uploads a third image file, it uploads the version ID, which the server can directly obtain. Alternatively, after the first terminal uploads the third image file, the server parses the third image file to obtain the second snapshot name recorded in the third image file. Then, based on the second snapshot name, it searches the snapshot list for the corresponding version to obtain the version ID. Another example is that the server parses the version metadata corresponding to the version currently used by the first terminal to obtain the version ID from the version metadata. In this case, the server can search for the version record of the version currently used by the first terminal and then obtain the version ID based on the version metadata in the version record.

[0128] Step 330: Locate the second image file corresponding to the version ID.

[0129] In one embodiment, the data stored on the server can be stored in a database; that is, BaseImage, LowerImage, and UpperImage are all stored in the database. After obtaining the version ID, the server searches for the corresponding second image file in the database based on the version ID.

[0130] Optionally, when searching for the second image file, first, based on the version ID, find the storage path (Client Upper Image Path) of the third image file used by the first terminal and the storage path (Lower Image Path) of the second image file in the database. Specifically, the version ID can be used to find the corresponding version directory, and the Client Upper Image Path and Lower Image Path can be obtained from the records in the version directory. Alternatively, the corresponding second snapshot name can be obtained based on the version ID, and the Client Upper Image Path and Lower Image Path can be obtained based on the second snapshot name. Then, the corresponding second image file can be retrieved based on the Lower Image Path.

[0131] Step 340: Submit the third image file to the second image file to obtain a new second image file.

[0132] For example, data recorded in the third image file is written into the second image file as information blocks to achieve image merging. The submission of the third image file to the second image file can also be considered a commit process. After the third image file is submitted to the second image file, the second image file can be considered updated. At this point, to distinguish it from the original second image file, the submitted second image file is recorded as the new second image file.

[0133] In one embodiment, since the second image file may contain multiple snapshots, the current version (i.e., the latest version) of the second image file found in step 330 may not be the version used by the first terminal; that is, the second image file is not the version used when creating the third image file. To ensure the normal implementation of image merging, the second image file needs to be adjusted to the version corresponding to the third image file. At this time, step 340 may include steps 341-343:

[0134] Step 341: Restore the second image file to the second snapshot corresponding to the third image file.

[0135] For example, the corresponding second snapshot is determined based on the second snapshot name recorded in the third image file, and then the second image file is restored to the state corresponding to the second snapshot.

[0136] Step 342: Rename the restored second image file so that the second image file uses the second snapshot name of the second snapshot.

[0137] Understandably, when creating a new second snapshot in the second image file, the filename of the second image file is changed to the name of the new second snapshot to clearly identify the current version used in the second image file. Furthermore, when submitting the third image file to the second image file, it is necessary to ensure that the name of the second snapshot recorded in the third image file matches the filename of the second image file. If the filename of the second image file does not match the name of the second snapshot recorded in the third image file, the third image file cannot be accurately and securely submitted to the second image file. Therefore, after restoring the second image file, it is renamed. After renaming, the filename of the second image file is changed to the name of the second snapshot recorded in the third image file uploaded by the first terminal.

[0138] Step 343: Submit the third image file to the renamed second image file.

[0139] For example, the third image file is committed to the renamed second image file.

[0140] Step 350: Create a new second snapshot in the new second image file.

[0141] For example, after the third image file is submitted to the second image file, the new second image file includes the user's personalized data. Then, a new second snapshot is created for the second image file so that it can be restored to its state after the third image file was submitted if needed later. Optionally, when creating a new second snapshot, a new snapshot name is generated. Optionally, creating a new snapshot can also be understood as creating a new version. In this case, a new version record and version directory can be created, new version metadata can be added to the new version record, and the first, second, and third image files corresponding to this version can be recorded in the version directory.

[0142] In one embodiment, each UpperImage has a unique identifier, which distinguishes different UpperImages. This unique identifier can be generated when the UpperImage is created. Optionally, when the first terminal uploads the third image file, it provides the unique identifier of the third image file. When the second image file creates a corresponding new second snapshot, the unique identifier can be used as the name of the corresponding second snapshot, thus satisfying the requirement for the uniqueness of the second snapshot name.

[0143] Currently, taking the creation of a third image file on the server as an example, after step 350, steps 360-370 are also included:

[0144] Step 360: Delete the third image file.

[0145] For example, since the data recorded in the third image file has already been written into the new second image file, the third image file can be deleted. Optionally, if the first terminal stores the third image file, it can be notified to delete the third image file.

[0146] Step 370: Create a new third image file based on the new second snapshot.

[0147] For example, a new second snapshot is created in the new second image file. Therefore, a new third image file needs to be created based on the new second snapshot so that when the first terminal uses the new second image file, the newly added data is recorded in the new third image file. It can be understood that the new third image file contains the snapshot name of the new second snapshot.

[0148] In one embodiment, after creating a new second snapshot, the content of the second image file used in the first image changes, therefore, the snapshot list and image records need to be updated. In this case, step 380 may also be included after step 370.

[0149] Step 380: Update the snapshot list and update the image metadata in the image record.

[0150] For example, after creating a new second snapshot or a third image file, the snapshot list of the first image is updated to add the new second snapshot and the version corresponding to the new second snapshot to the snapshot list.

[0151] Optionally, after updating the snapshot list, corresponding torrent files can be created for the new second and third image files, respectively, for the first terminal to download.

[0152] For example, after updating the snapshot list, it is also necessary to update the image record corresponding to the first image in the image table, that is, to update the image metadata of the first image in the image record based on the new second image file. Optionally, updating the image record can be performed after the torrent file is created.

[0153] After updating the image metadata of the first image, the first image is unlocked for download by the first terminal. Optionally, the server notifies the first terminal of a version update. Subsequently, the first terminal generates a first download request to download the new second image file and the corresponding third image file and sends it to the server. Based on the first download request, the server sends the new second image file and the corresponding third image file to the first terminal for its use.

[0154] It should be noted that this step can also be performed after creating a new second snapshot in the new second image file.

[0155] Understandably, in practical applications, when the third image file is created by the first terminal, the process of creating the new third image file in step 370 is implemented in the first terminal.

[0156] The general process of image registration is described below as an example. Figure 8 This is a flowchart illustrating a mirror merging process according to one embodiment of this application. (Reference) Figure 8 After the merge begins, the corresponding image is locked. Then, the version metadata (i.e., ClientRevisionmeta) corresponding to the version used by the terminal is parsed to obtain the ClientRevisionID (the version ID used by the terminal). Next, based on the ClientRevisionID, the Client UpperImage Path (i.e., the path to the third image file used by the terminal) and LowerImage Path (i.e., the path to the second image file) are retrieved from the database. Then, the LowerImage is restored to the snapshot that the Client UpperImage depends on, the LowerImage is renamed, the ClientUpperImage is committed to the LowerImage, a new snapshot is created for the LowerImage, the old UpperImage is deleted, a new UpperImage is created, the snapshot list is updated, the seed files for the LowerImage and UpperImage are created, the image records in the image table are updated, and the lock is released. In this way, the image merge is completed.

[0157] As mentioned above, when the first terminal runs the cloud desktop, all newly added data is written to the third image file without modifying the first and second image files. Therefore, when the first terminal or the server needs to merge images, it is only necessary to upload the local third image file to the server, and then the server submits the third image file to the second image file. This reduces the amount of data uploaded by the first terminal, improves the upload speed and efficiency, saves network resources, and thus improves the efficiency and speed of image merging.

[0158] In one embodiment of this application, when the server is managed, it also needs to perform image restoration management. Image restoration can be understood as restoring the LowerImage to a specific version. Currently, the image restoration process is described using the first image as an example. Figure 9 A flowchart of an image management method provided in one embodiment of this application is shown, which is the process of a server performing image restoration management. Referring to the figure, the image management method includes:

[0159] Step 410: Receive the image restoration command.

[0160] For example, an image restore command is used to instruct the server to perform an image restore. It can be generated at the terminal or at the server. When the server generates the image restore command, the server user (such as an administrator with certain permissions) can select the LowerImage to be restored and the version to be restored. The server then generates the image restore command based on the selection and subsequently receives the image restore command. Currently, the example of restoring the second image file within the first image is used for description.

[0161] Optionally, after receiving the image restoration instruction, the server determines to perform image restoration and locks the first image used by the first terminal. The process of locking the first image can be referred to in step 310, and will not be described in detail here.

[0162] Step 420: Obtain the version ID to be restored according to the image restoration command.

[0163] For example, the version ID to be restored refers to the version ID to which the second image file is expected to be restored. Optionally, the image restoration instruction includes the version ID to be restored. Further, the server calls the corresponding parameters according to the image restoration instruction to obtain the version ID to be restored through these parameters. The called parameters are presented as string variables and may include the image ID of the first image, the user ID of the first terminal, the version ID, etc.

[0164] Step 430: Locate the corresponding second image file and the corresponding second snapshot name based on the version ID.

[0165] Optionally, since each second snapshot corresponds to a version, the corresponding second snapshot name can be obtained by querying the snapshot list corresponding to the first image through the version ID to be restored, and the second image file where the second snapshot is located can be obtained.

[0166] Step 440: Restore the second image file to the corresponding second snapshot according to the second snapshot name.

[0167] For example, the second image file is restored according to the second snapshot corresponding to the second snapshot name, that is, restored to the state of the second image file when the second snapshot was created. At this time, the user's personalized data added in the second image file after the second snapshot will be deleted.

[0168] In one embodiment, a third image file is created by the server. In this case, after step 440, steps 450 and 460 are also included.

[0169] Step 450: Delete the third image file corresponding to the second image file.

[0170] For example, since the second image file has changed, it is necessary to delete the third image file that was in the previous state before the change, i.e., the old third image file.

[0171] Step 460: Create a new third image file based on the restored second snapshot.

[0172] For example, a corresponding third image file is created based on the restored second snapshot, which can be considered as a new third image file corresponding to the second image file.

[0173] In one embodiment, seed files corresponding to the second and third image files are generated respectively for the first terminal to download.

[0174] Optionally, since the second image file contained in the first image has been updated, it is also necessary to update the image record corresponding to the first image in the image table. In this case, after step 460, the process also includes:

[0175] Step 470: Update the image metadata in the image record.

[0176] Optionally, after the image metadata is updated, the image restoration is considered complete. At this point, the server can unlock the first image to allow the first terminal to download the corresponding torrent file. In one embodiment, after image restoration, the server can notify the first terminal that the restoration is complete. Subsequently, the first terminal generates a corresponding first download instruction based on the server's notification and sends it back to the server. The server then responds to the first download instruction by pushing the restored second image file as the new second image file to the first terminal.

[0177] In one embodiment, the server records the latest version ID of each image. After the image is restored, the latest version ID of the corresponding image is changed to the restored version ID.

[0178] The following is an exemplary description of the image restoration process. Figure 10 This is a flowchart illustrating a mirror restoration process according to one embodiment of this application. (Reference) Figure 10After starting, the corresponding image is locked. Then, the parameters of the call (i.e., ParseArgs) are parsed to obtain the ImageID and RevisionID. Next, the target SnapshotName to which the corresponding LowerImage needs to be restored is located based on the RevisionID. Then, the LowerImage is restored to the corresponding target Snapshot. After that, the old UpperImage is deleted, a new UpperImage is created, seed files for both LowerImage and UpperImage are created, the image record in the image table is updated, the image is unlocked, and the image download is resumed to complete the image restoration.

[0179] As mentioned above, when there is a need for image restoration, it is only necessary to restore the second image file to the corresponding version without modifying the first image file, which saves the amount of data processing during restoration and improves the efficiency and speed of image restoration.

[0180] In one embodiment of this application, when the server is managed, it also needs to perform image cloning management. Image cloning can be understood as obtaining another image based on one image clone. Currently, the image cloning process is described using the first image as an example. Figure 11 A flowchart of an image management method provided in one embodiment of this application is shown, which is the process of a server performing image cloning management. Referring to the figure, the image management method includes:

[0181] Step 510: Receive the image cloning instruction, which is used to clone the first image.

[0182] For example, an image cloning command is used to instruct a server to perform an image cloning. Currently, the first image is the image to be cloned, and in this case, the image cloning command can be considered as being used to clone the first image.

[0183] For example, an image cloning command can be issued by a user on a first terminal or server, or by the image administrator on the server. Optionally, when generating an image restore command, the ID of the image to be restored is written into the image restore command so that the server can identify the image to be restored (currently, the image restore command writes the image ID of the first image). Optionally, when cloning an image, it is possible to clone only a specific version; in this case, the image restore command can also include the version ID to be cloned. Optionally, however, since the first image may contain user-specific data, for data security, only administrators with certain permissions can issue image cloning commands, or only users can clone the first image they are using.

[0184] Step 520: Clone the second image based on the first image file and the second image file contained in the first image. The second image is the cloned image.

[0185] For example, the image cloned from the first image is designated as the second image. Optionally, since the first image file used in the first image only records the operating system and will not be modified during use, the first image file can be shared by the second image. In one embodiment, the first image file can be linked to the second image via a hard link. Optionally, the second image file in the first image can be copied to the second image. Subsequently, a corresponding third image file can be created based on the second image file to ensure that the second image can be used normally through three levels of image files.

[0186] In one embodiment, step 510 may include steps 511-516:

[0187] Step 511: According to the image cloning instruction, generate the image record and version directory of the second image. The image record of the second image records the image metadata of the first image.

[0188] For example, when cloning a second image, image registration may also be required, which involves creating an image record and version directory for the second image, as well as a version record for the second image. Currently, the image metadata of the first image is first written into the image record of the second image.

[0189] Step 512: Create a hard link to the first image file in the first image in the version directory.

[0190] For example, the second image and the first image share the first image file. Therefore, the first image file is linked to the second image as a hard link. Currently, the first image file is hard linked to the version directory of the second image.

[0191] Step 513: Copy the second image file from the first image to the version directory.

[0192] For example, since each image needs its own LowerImage, during cloning, the second image file used in the first image is copied and pasted into the version directory of the second image to explicitly specify the second image file used by the second image. It can be understood that the currently copied second image file contains all current second snapshots.

[0193] Step 514: In the copied second image file, retain the target version and delete other second versions. The target second version is determined by the image cloning command.

[0194] For example, during image cloning, only the specified version in the second image file is cloned. Currently, the specified version is recorded as the target version. Therefore, after copying the second image file, it needs to be initialized. During initialization, only the state corresponding to the target version is retained in the second image file, and other versions are deleted. That is, after initialization, the second image file contains only one version, and this version is the target version. At this time, the initialized second image file can be considered as the initial second image file in the second image. Subsequently, the metadata corresponding to the target version can be recorded in the version record of the second image. It should be noted that the version directory mentioned in steps 511-513 can be considered as the version directory corresponding to the target version.

[0195] In one embodiment, the third image file is generated by the server; therefore, step 514 may further include: creating a corresponding third image file based on the target version.

[0196] For example, a corresponding third image file is created based on the second image file in the second image. In this case, the third image file corresponds to the target version of the second image file, that is, the third image file contains the second snapshot name of the second snapshot corresponding to the target version.

[0197] Optionally, seed files for the second and third image files can be created for the terminal to download. It can be understood that when the terminal downloads the image for the first time and the downloaded image is the second image, the server can find the first image file through the hard link in the version directory and send the seed file of the first image file to the terminal for the terminal to use.

[0198] Step 515: Update the image metadata in the image record of the second image.

[0199] For example, when creating the image record of the second image, the image metadata of the first image recorded in the image record will also change after the second image file is initialized. Therefore, the image metadata in the image record of the second image is updated according to the initialized second image file.

[0200] Optionally, during the cloning process, the second image may contain multiple states to indicate the current cloning node of the second image. In one embodiment, when generating the image record and version directory of the second image according to the image cloning instruction, the method further includes: marking the second image as waiting to be cloned. When updating the image metadata in the image record of the second image, the method further includes: marking the second image as cloning complete.

[0201] The "waiting" state indicates the process is waiting for cloning to begin, while the "ready" state indicates that cloning is complete and the image is ready to be used. Additionally, a "copying" state can be included, indicating that cloning is in progress. Optionally, when generating the image record and version directory of the second image, the second image is marked as being in the "waiting" state; when copying the second image files from the first image to the version directory, the "waiting" state is changed to the "copying" state; and when updating the image metadata in the image record of the second image, the "copying" state is changed to the "cloning complete" state.

[0202] The mirror cloning process is described below as an example. Figure 12 This is a flowchart illustrating a mirror cloning process according to one embodiment of this application. (Reference) Figure 12 After starting, image metadata is created first. This image metadata is for the new image obtained after cloning. An image record, initial version record, and initial version directory for the new image are generated. At this point, the new image is in a waiting state. Next, a hard link to the source image's (the cloned image's) BaseImage is created in the initial version directory. Then, the source image's LowerImage is copied to the initial version directory. The copied LowerImage is initialized, retaining the target version. Then, an UpperImage is created based on the LowerImage. Seed files for both the LowerImage and UpperImage are created. The image record in the image table is updated, and the new image is changed to a completed clone state to complete the image cloning.

[0203] As described above, when the first terminal or server needs to clone an image, it is only necessary to copy the second image file and create an image record. The first image file can be added to the new image by hard linking, without needing to be copied, thus saving server disk space and improving the efficiency and speed of image cloning.

[0204] Understandably, no modification to the BaseImage is required during image merging, image restoration, and image cloning, ensuring the security of the BaseImage and preventing the terminal from repeatedly downloading the BaseImage.

[0205] In one embodiment of this application, the image management device can be a server or an image management terminal. This terminal can also be considered a user-accessible terminal, such as a personal computer, tablet computer, interactive whiteboard, or mobile phone, and is not currently limited to any particular type. The terminal implements a cloud desktop by running a virtual machine. The image required for the terminal to run can be obtained from the server. In this case, the terminal and server work together to implement the image management method. In one embodiment, a first terminal is used as an example to describe how the terminal executes the image management method.

[0206] Figure 13 A flowchart illustrating an image management method provided in one embodiment of this application is shown below. Figure 13 When the first terminal executes this image management method, it may include:

[0207] Step 610: Send the first download request to the cloud desktop server.

[0208] For example, the first terminal uses a first image, which includes a first image file and a second image file. The first image file records the operating system used by the cloud desktop in the first terminal, and the second image file records the device drivers and applications installed based on the operating system.

[0209] After the first terminal generates the first download request, it sends the first download request to the server.

[0210] If the second image file can be downloaded through the first download request, step 620 is executed; if the second image file and the corresponding third image file can be downloaded through the first download request, step 650 is executed.

[0211] Step 620: When the first download request is used to download a new second image file from the server, receive the new second image file sent by the server.

[0212] Step 630: Replace the existing local second image file with the received second image file.

[0213] Optionally, the new second image file sent by the server can be used locally as the second image file. In this case, the first terminal considers that a version change has been performed. Optionally, the initial second image file can be kept locally, while other versions of the second image file can be kept on the first terminal or deleted from the first terminal when a version is replaced.

[0214] Step 640: Create a corresponding third image file based on the second snapshot setting in the received second image file. The first image also contains the third image file, which records the data added when the cloud desktop is running in the state of setting the second snapshot.

[0215] For example, the latest second snapshot in the received second image file is used as the setting second snapshot, and a corresponding third image file is created locally based on the setting second snapshot. Then, the cloud desktop is run.

[0216] Step 650: When the first download request is used to download a new second image file and a corresponding third image file from the server, the server sends the new second image file and the third image file. The third image file is generated based on the settings of the second snapshot in the new second image file.

[0217] Step 660: Replace the existing local second image file with the received second image file.

[0218] As described above, when the first terminal needs to update the first image, it only needs to obtain the new second image file from the server and replace it, without needing to obtain the first image file. This solves the technical problem in related technologies where the server needs to consume a lot of network resources to send the image file to the terminal. Furthermore, since the third image file is a blank file after creation, even if the corresponding third image file needs to be downloaded, it only consumes a small amount of network resources, ensuring the rational use of network resources.

[0219] In one embodiment of this application, the first terminal can submit newly added data during the operation of the local cloud desktop to the second image file for version upgrade (i.e., image merging). At this time, when the first terminal executes the image management method, it may further include: running the cloud desktop according to the existing local first image file, second image file and corresponding third image file, and writing the newly added data into the third image file during the operation; uploading the third image file to the server so that the server submits the third image file to the corresponding second image file.

[0220] For example, when the first terminal starts the virtual machine, it needs a first image file, a second image file, and a third image file. The virtual machine starts directly based on the third image file, without needing to merge the three types of files. Furthermore, when running the cloud desktop within the virtual machine, the newly added data is recorded in the third image file. If the user needs to create a restore point (i.e., create a new version) during the cloud desktop's operation, they can send the currently used third image file to the server and instruct the server to merge the images. The server, based on the instruction, submits the third image file to the corresponding second image file. Afterward, the server notifies the first terminal that the merging is complete. The first terminal can then generate a first download instruction based on the server's notification to download the second image file of the second snapshot corresponding to the created restore point, and, depending on the actual situation, create or download the corresponding third image file from the server.

[0221] Understandably, since the third image file is used to write new data, when the user of the first terminal wants to abandon the modifications to the cloud desktop, they only need to delete the current third image file and rebuild or obtain the third image file from the server, which simplifies the image restoration process in the first terminal.

[0222] As described above, during operation, the first terminal writes new data to the third image file without modifying the first and second image files. Therefore, when creating a new version, it is only necessary to upload the local third image file to the server to create a new version on the server, which greatly reduces the amount of data uploaded and improves upload efficiency.

[0223] In one embodiment of this application, the first terminal may also synchronize the second image file used locally to the second terminal to run the cloud desktop in the first terminal on the second terminal. In this case, when the first terminal executes the image management method, it may further include: receiving a synchronization request sent by the second terminal, wherein the second terminal and the first terminal use the same first image file; and sending the existing second image file locally to the second terminal so that the second terminal can replace the original second image file with the received second image file.

[0224] For example, the second terminal can be a terminal that enables physical migration of the cloud desktop, that is, the cloud desktop used by the first terminal is migrated to the second terminal for use. The second terminal can also be a terminal replaced by the user, that is, the user uses the second terminal to replace the first terminal currently in use.

[0225] In one embodiment, the second terminal has previously run a cloud desktop and already stores a first image file and a second image file. In this case, the first terminal can send its own second image file to the second terminal. The second terminal then replaces its own second image file with the received second image file to ensure the cloud desktop running on the first terminal continues to function. In another embodiment, the second terminal has not previously run a cloud desktop. In this case, the second terminal can first download the files contained in the first image from the server, and then replace its own second image file with the received second image file.

[0226] Optionally, when creating a third image file, the second terminal may create the third image file based on the set version in the received second image file, or the server may create the third image file and send it to the second image file.

[0227] Optionally, when the first terminal sends the second image file to the second terminal, it can send it directly to the second terminal or send it through the server. If a third image file needs to be generated when sending it through the server, both the second image file and the generated third image file can be sent to the second terminal together.

[0228] Optionally, after synchronizing the second terminal, a record can be made on the server so that the server knows the current image version used by the second terminal.

[0229] As described above, during the synchronization process, it is only necessary to send the LowerImage from the first terminal to the second terminal, which simplifies the steps required for synchronization.

[0230] It is understood that any technical details not mentioned in the above process can be referred to the relevant descriptions in the foregoing embodiments, and have corresponding functions and beneficial effects.

[0231] Figure 14 This is a schematic diagram of a mirror management device provided in one embodiment of the present application. The mirror management device is applied to a server, see reference... Figure 14 The mirror management device includes: a first receiving unit 701, a first sending unit 702, and a second sending unit 703.

[0232] The first receiving unit 701 is configured to receive a first download request sent by a first terminal. The first terminal uses a first image, which includes a first image file and a second image file. The first image file records the operating system used by the cloud desktop in the first terminal, and the second image file records the device drivers and applications installed based on the operating system. The first sending unit 702 is configured to send a new second image file to the first terminal when the first download request is used to download a new second image file from the server, so that the first terminal uses the received second image file to replace the original local second image file and creates a corresponding third image file based on the second snapshot setting in the received second image file. The first image also includes a third image file, which records data added when the cloud desktop runs in the state of the second snapshot setting. The second sending unit is configured to send a new second image file and a corresponding third image file to the first terminal when the first download request is used to download a new second image file and a corresponding third image file from the server, so that the first terminal uses the received second image file to replace the original local second image file, and the third image file is generated based on the second snapshot setting in the new second image file.

[0233] In one embodiment, the first image file contains a unique first snapshot, the second image file contains a first snapshot name of the first snapshot; the second image file contains at least one second snapshot, and the third image file contains a second snapshot name of the corresponding second snapshot.

[0234] In one embodiment, the first image is recorded in the server with at least one version. Each version corresponds to a second snapshot in the second image file and is associated with the second image file, the first image file corresponding to the first snapshot name in the second image file, and the third image file corresponding to the second snapshot. Each version has a corresponding version ID.

[0235] In one embodiment, the first image has at least one image branch recorded in the server, each image branch containing at least one version, and the first terminal applies one image branch of the first image.

[0236] In one embodiment, the system further includes: a first acquisition unit for acquiring a first image file and a second image file; a first linking unit for hard linking the first image file and the second image file to the first image file respectively; and a second linking unit for creating a corresponding version directory based on the initial second snapshot of the second image file, and hard linking the first image file and the second image file to the version directory respectively, thereby obtaining the first image file.

[0237] In one embodiment, the system further includes a first creation unit, configured to create a corresponding third image file based on the initial second snapshot after hard-linking the first image file and the second image file to the version directory.

[0238] In one embodiment, the first linking unit is further configured to: create an image record of the first image and add image metadata of the first image to the image record; the second linking unit is further configured to: create a version record corresponding to the initial second snapshot and record version metadata of the version corresponding to the initial second snapshot in the version record.

[0239] In one embodiment, the system further includes: a second receiving unit for receiving a third image file uploaded by a first terminal; a second obtaining unit for obtaining the current version ID of the first image in the first terminal; a first searching unit for searching for a second image file corresponding to the version ID; a submitting unit for submitting the third image file to the second image file to obtain a new second image file; and a second creating unit for creating a new second snapshot in the new second image file.

[0240] In one embodiment, the first deletion unit is configured to delete the third image file after creating a new second snapshot in the new second image file; the third creation unit is configured to create a new third image file based on the new second snapshot.

[0241] In one embodiment, the submission unit includes: a first restoration subunit, used to restore the second image file to the second snapshot corresponding to the third image file; a renaming subunit, used to rename the restored second image file so that the second image file uses the second snapshot name of the second snapshot; and a file submission subunit, used to submit the third image file to the renamed second image file.

[0242] In one embodiment, the first image has a corresponding snapshot list recorded in the server, and the snapshot list records each version of the first image and the second snapshot corresponding to each version; the device further includes: a first update unit, used to update the snapshot list and update the image metadata in the image record after creating a new second snapshot in the new second image file.

[0243] In one embodiment, the system further includes: a third receiving unit for receiving an image restoration instruction; a third obtaining unit for obtaining a version ID to be restored according to the image restoration instruction; a second searching unit for searching for the corresponding second image file and the corresponding second snapshot name according to the version ID; and a second restoring unit for restoring the second image file to the corresponding second snapshot according to the second snapshot name.

[0244] In one embodiment, the system further includes: a second deletion unit, configured to restore the second image file to the corresponding second snapshot according to the second snapshot name, and then delete the third image file corresponding to the second image file; and a fourth creation unit, configured to create a new third image file based on the restored second snapshot.

[0245] In one embodiment, the system further includes: a fourth receiving unit, configured to receive an image cloning instruction, the image cloning instruction being used to clone a first image; and a cloning unit, configured to clone a second image based on a first image file and a second image file contained in the first image, the second image being the cloned image.

[0246] In one embodiment, the cloning unit includes: a generation subunit, configured to generate an image record and a version directory of a second image according to an image cloning instruction, wherein the image record of the second image records the image metadata of the first image; a third linking subunit, configured to create a hard link to the first image file in the first image in the version directory; a copying subunit, configured to copy the second image file in the first image to the version directory; a third deletion subunit, configured to retain the target version and delete other versions in the copied second image file, wherein the target version is determined by the image cloning instruction; and a second updating subunit, configured to update the image metadata in the image record of the second image.

[0247] In one embodiment, the generating subunit is further configured to: mark the second image as awaiting cloning; the second updating subunit is further configured to: mark the second image as completed cloning.

[0248] The image management device provided above can be used to execute the image management method executed by the server provided in any of the above embodiments, and has corresponding functions and beneficial effects.

[0249] Figure 15 This is a schematic diagram of an image management device according to an embodiment of this application. The image management device is applied to a first terminal, which uses a first image. The first image includes a first image file and a second image file. The first image file records the operating system used by the cloud desktop in the first terminal, and the second image file records device drivers and applications installed based on the operating system. (See reference...) Figure 15 The image management device includes: a third sending unit 801, a first downloading unit 802, a first replacement unit 803, a first creation unit 804, a second downloading unit 805, and a second replacement unit 806.

[0250] The third sending unit 801 is used to send a first download request to the cloud desktop server; the first download unit 802 is used to receive a new second image file sent by the server when the first download request is used to download a new second image file from the server; the first replacement unit 803 is used to replace the original local second image file with the received second image file; the first creation unit 804 is used to create a corresponding third image file based on the second snapshot setting in the received second image file, the first image also includes the third image file, the third image file records the data added when the cloud desktop is running in the state of setting the second snapshot; the second download unit 805 is used to receive a new second image file and a corresponding third image file sent by the server when the first download request is used to download a new second image file and a corresponding third image file from the server, the third image file is generated based on the second snapshot setting in the new second image file; the second replacement unit 806 is used to replace the original local second image file with the received second image file.

[0251] In one embodiment, the system further includes: a running unit, configured to run the cloud desktop based on the existing local first image file, second image file, and corresponding third image file, and to write newly added data into the third image file during the running process; and an uploading unit, configured to upload the third image file to the server so that the server submits the third image file to the corresponding second image file.

[0252] In one embodiment, the system further includes: a fifth receiving unit, configured to receive a synchronization request sent by a second terminal, wherein the second terminal uses the same first image file as the first terminal; and a fourth sending unit, configured to send an existing local second image file to the second terminal, so that the second terminal can replace the original second image file with the received second image file.

[0253] The image management device provided above can be used to execute the image management method executed by the first terminal provided in any of the above embodiments, and has corresponding functions and beneficial effects.

[0254] It is worth noting that in the above-described embodiments of the mirror management device, the various units and modules included are only divided according to functional logic, but are not limited to the above division, as long as the corresponding functions can be achieved; in addition, the specific names of each functional unit are only for easy differentiation and are not used to limit the scope of protection of this application.

[0255] Figure 16 This is a schematic diagram illustrating the structure of a mirror management device according to one embodiment of this application. The mirror management device can be a mirror management server or a mirror management terminal. Figure 16 As shown, the mirror management device includes a processor 90, a memory 91, and a communication module 92; the number of processors 90 can be one or more. Figure 16 Taking a processor 90 as an example, the processor 90, memory 91, and communication module 92 in the mirror management device can be connected via a bus or other means. Figure 16 Taking the example of a connection between China and Israel via a bus.

[0256] The memory 91, as a computer-readable storage medium, can be used to store software programs, computer-executable programs, and modules, such as the program instructions / modules corresponding to the image management method in the embodiments of this application (for example, when the image management device is an image management server, the first receiving unit 701, the first sending unit 702, and the second sending unit 703 in the image management device; when the image management device is an image management terminal, the third sending unit 801, the first downloading unit 802, the first replacement unit 803, the first creation unit 804, the second downloading unit 805, and the second replacement unit 806 in the image management device). The processor 90 executes various functional applications and data processing of the image management device by running the software programs, instructions, and modules stored in the memory 91, thereby implementing the above-described image management method.

[0257] The memory 91 may primarily include a program storage area and a data storage area. The program storage area may store the operating system and at least one application program required for a given function; the data storage area may store data created based on the use of the mirror management device. Furthermore, the memory 91 may include high-speed random access memory and non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state storage device. In some instances, the memory 91 may further include memory remotely located relative to the processor 90, which can be connected to the mirror management device via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0258] The communication device 92 is used to perform data communication according to the instructions of the processor. For example, when the mirror management device is a server, it can communicate with the terminal; conversely, when the mirror management device is a terminal, it can communicate with the server. The mirror management device may also include input devices and output devices. The input devices can be used to receive input digital or character information and generate key signal inputs related to user settings and function control of the mirror management device. They may also include audio input devices such as microphones. The output devices may include devices such as displays and speakers.

[0259] The aforementioned image management device includes a corresponding image management apparatus, which can be used to execute the corresponding image management method provided in any embodiment, and has corresponding functions and beneficial effects.

[0260] Furthermore, one embodiment of this application also provides a storage medium containing computer-executable instructions, which, when executed by a computer processor, are used to perform relevant operations in the image management method provided in any embodiment of this application, and have corresponding functions and beneficial effects.

[0261] Those skilled in the art will understand that embodiments of this application may be provided as methods, systems, or computer program products.

[0262] Therefore, this application may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application may take the form of a computer program product implemented 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. 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 should 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, produce implementations of the flowchart... Figure 1 One or more processes and / or boxes Figure 1 The 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 operate 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 functions specified in one or more boxes. These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable apparatus 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.

[0263] In a typical configuration, a computing device includes one or more processors (CPUs), input / output interfaces, network interfaces, and memory. Memory may include non-persistent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0264] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0265] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0266] Note that the above are merely preferred embodiments and the technical principles employed in this application. Those skilled in the art will understand that this application is not limited to the specific embodiments described herein, and various obvious changes, readjustments, and substitutions can be made without departing from the scope of protection of this application. Therefore, although this application has been described in detail through the above embodiments, this application is not limited to the above embodiments, and may include many other equivalent embodiments without departing from the concept of this application, the scope of which is determined by the scope of the appended claims.

Claims

1. A mirror management method applied to a server, characterized in that, include: The system receives a first download request from a first terminal. The first terminal uses a first image. The first image contains a first image file and a second image file. The first image file records the operating system used by the cloud desktop in the first terminal. The second image file records the device drivers and applications installed based on the operating system. Each user of the terminal has an independent second image file. When the first download request is used to download a new second image file from the server, the new second image file is sent to the first terminal so that the first terminal replaces the original local second image file with the received second image file and creates a corresponding third image file based on the set second snapshot in the received second image file. The first image also includes the third image file, and the third image file records the data added by the cloud desktop when it is running in the state of the set second snapshot. When the first download request is used to download a new second image file and the corresponding third image file from the server, the new second image file and the third image file are sent to the first terminal so that the first terminal replaces the original local second image file with the received second image file, and the third image file is generated based on the second snapshot set in the new second image file.

2. The mirror management method according to claim 1, characterized in that, The first image file contains a unique first snapshot, and the second image file contains the first snapshot name of the first snapshot; The second image file contains at least one second snapshot, and the third image file contains the second snapshot name corresponding to the second snapshot.

3. The mirror management method according to claim 2, characterized in that, The first image has at least one version recorded in the server. Each version corresponds to a second snapshot in the second image file and is associated with the second image file, the first image file corresponding to the first snapshot name in the second image file, and the third image file corresponding to the second snapshot. Each version has a corresponding version ID.

4. The mirror management method according to claim 3, characterized in that, The first image has at least one image branch recorded in the server, each image branch contains at least one version, and the first terminal applies one image branch of the first image.

5. The mirror management method according to claim 3, characterized in that, Also includes: Obtain the first and second image files; Hard link the first image file and the second image file to the first image respectively; A corresponding version directory is created based on the initial second snapshot of the second image file, and the first image file and the second image file are hard-linked to the version directory to obtain the first image.

6. The mirror management method according to claim 5, characterized in that, After hard-linking the first image file and the second image file to the version directory respectively, the method further includes: A corresponding third image file is created based on the initial second snapshot.

7. The mirror management method according to claim 5 or 6, characterized in that, When hard-linking the first image file and the second image file to the first image respectively, the method further includes: Create an image record for the first image and add the image metadata of the first image to the image record; When creating the corresponding version directory based on the initial second snapshot of the second image file, the method further includes: Create a version record corresponding to the initial second snapshot, and record the version metadata of the version corresponding to the initial second snapshot in the version record.

8. The mirror management method according to claim 3, characterized in that, Also includes: Receive the third image file uploaded by the first terminal; Obtain the current version ID of the first image in the first terminal; Locate the second image file corresponding to the version ID; Submit the third image file to the second image file to obtain a new second image file; Create a new second snapshot in the new second image file.

9. The mirror management method according to claim 8, characterized in that, After creating the new second snapshot in the new second image file, the following is also included: Delete the third image file; A new third image file is created based on the new second snapshot.

10. The mirror management method according to claim 8, characterized in that, The step of submitting the third image file to the second image file includes: Restore the second image file to the second snapshot corresponding to the third image file; Rename the restored second image file so that it uses the second snapshot name of the second snapshot; Submit the third image file to the renamed second image file.

11. The mirror management method according to claim 9, characterized in that, The first image has a corresponding snapshot list recorded in the server, and the snapshot list records each version of the first image and the second snapshot corresponding to each version; After creating the new second snapshot in the new second image file, the following is also included: Update the snapshot list and update the image metadata in the image record.

12. The mirror management method according to claim 3, characterized in that, Also includes: Receive image restoration command; According to the image restoration command, obtain the version ID to be restored; Find the corresponding second image file and the corresponding second snapshot name based on the version ID; Based on the second snapshot name, restore the second image file to the corresponding second snapshot.

13. The mirror management method according to claim 12, characterized in that, After restoring the second image file to the corresponding second snapshot based on the second snapshot name, the method further includes: Delete the third image file corresponding to the second image file; Create a new third image file based on the restored second snapshot.

14. The mirror management method according to claim 3, characterized in that, Also includes: Receive an image cloning instruction, the image cloning instruction being used to clone the first image; A second image is obtained by cloning the first image file and the second image file contained in the first image. The second image is the cloned image.

15. The mirror management method according to claim 14, characterized in that, The process of cloning the second image based on the first image file and the second image file contained in the first image includes: According to the image cloning instruction, an image record and version directory for the second image are generated, and the image record of the second image records the image metadata of the first image. Create a hard link to the first image file in the first image within the version directory; Copy the second image file from the first image to the version directory; In the copied second image file, the target version is retained and other versions are deleted. The target version is determined by the image cloning command. Update the image metadata in the image record of the second image.

16. The mirror management method according to claim 15, characterized in that, When generating the image record and version directory of the second image according to the image cloning instruction, the process further includes: Mark the second image as awaiting cloning; When updating the image metadata in the image record of the second image, it also includes: Mark the second image as a completed clone.

17. A mirror management method, applied to a first terminal, characterized in that, The first terminal uses a first image, which includes a first image file and a second image file. The first image file records the operating system used by the cloud desktop in the first terminal, and the second image file records the device drivers and applications installed based on the operating system. Each user of the terminal has an independent second image file. The method includes: Send a first download request to the server of the cloud desktop; When the first download request is used to download a new second image file from the server, the new second image file sent by the server is received; Replace the existing local second image file with the received second image file; A corresponding third image file is created based on the second snapshot setting in the received second image file. The first image file also includes the third image file, which records the data added by the cloud desktop when it is running under the state of the second snapshot setting. When the first download request is used to download a new second image file and the corresponding third image file from the server, the server sends the new second image file and the third image file, and the third image file is generated based on the set second snapshot in the new second image file; Replace the existing local second image file with the received second image file.

18. The mirror management method according to claim 17, characterized in that, Also includes: The cloud desktop is run based on the existing first image file, second image file and corresponding third image file on the local machine, and new data is written to the third image file during the process; The third image file is uploaded to the server so that the server submits the third image file to the corresponding second image file.

19. The mirror management method according to claim 17, characterized in that, Also includes: Receive a synchronization request sent by a second terminal, the second terminal using the same first image file as the first terminal; The existing local second image file is sent to the second terminal so that the second terminal can replace the original second image file with the received second image file.

20. A mirror management device, applied to a server, characterized in that, include: The first receiving unit is used to receive a first download request sent by a first terminal. The first terminal uses a first image. The first image includes a first image file and a second image file. The first image file records the operating system used by the cloud desktop in the first terminal. The second image file records the device drivers and applications installed based on the operating system. Each user of the terminal has an independent second image file. The first sending unit is configured to send the new second image file to the first terminal when the first download request is used to download a new second image file from the server, so that the first terminal replaces the original local second image file with the received second image file and creates a corresponding third image file based on the set second snapshot in the received second image file. The first image file also includes the third image file, and the third image file records the data added by the cloud desktop when it is running in the state of the set second snapshot. The second sending unit is configured to send the new second image file and the corresponding third image file to the first terminal when the first download request is used to download a new second image file and the corresponding third image file from the server, so that the first terminal can replace the original local second image file with the received second image file, and the third image file is generated based on the set second snapshot in the new second image file.

21. A mirror management device, applied to a first terminal, characterized in that, The first terminal uses a first image, which includes a first image file and a second image file. The first image file records the operating system used by the cloud desktop in the first terminal, and the second image file records the device drivers and applications installed based on the operating system. Each user of the terminal has an independent second image file. The device includes: The third sending unit is used to send a first download request to the server of the cloud desktop; The first download unit is configured to receive a new second image file sent by the server when the first download request is for downloading a new second image file from the server; The first replacement unit is used to replace the existing local second image file with the received second image file; The first creation unit is used to create a corresponding third image file based on the second snapshot setting in the received second image file. The first image file also includes the third image file, which records the data added by the cloud desktop when it is running under the state of the second snapshot setting. The second download unit is configured to receive the new second image file and the corresponding third image file sent by the server when the first download request is used to download a new second image file and the corresponding third image file from the server, wherein the third image file is generated based on the set second snapshot in the new second image file; The second replacement unit is used to replace the existing local second image file with the received second image file.

22. A mirror management server, characterized in that, include: The communication module is used to implement data communication; One or more processors; Memory, used to store one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the image management method as described in any one of claims 1-16.

23. A mirror management terminal, characterized in that, include: The communication module is used to implement data communication; One or more processors; Memory, used to store one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the image management method as described in any one of claims 17-19.

24. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the image management method as described in any one of claims 1-16 or the image management method as described in any one of claims 17-19.

Images