WO2023197862A1

WO2023197862A1 - Mirror image management methods, apparatus, server, terminal, and storage medium

Info

Publication number: WO2023197862A1
Application number: PCT/CN2023/084551
Authority: WO
Inventors: 龙小斌
Original assignee: 广州视源电子科技股份有限公司; 广州视睿电子科技有限公司
Priority date: 2022-04-13
Filing date: 2023-03-29
Publication date: 2023-10-19
Also published as: CN116954681A

Abstract

Mirror image management methods, an apparatus, a server, a terminal, and a storage medium. A method comprises: receiving a first downloading request sent by a first terminal, the first terminal using a first mirroring file and a second mirroring file, the first mirroring file recording an operating system used by a cloud desktop in the first terminal, and the second mirroring file recording a device driver and an application program which are installed on the basis of the operating system; and sending a new second mirroring file to the first terminal, so that the first terminal replaces an original local second mirroring file by the received second mirroring file and records in a third mirroring file data which is newly added when the cloud desktop runs in a state of a set second snapshot, the third mirroring file being generated on the basis of the set second snapshot in the new second mirroring file, wherein the third mirroring file may be generated by a server or the first terminal. The method can be used to solve the technical problem in the prior art that a server consumes many network resources when issuing a mirroring file to a terminal.

Description

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

This application claims priority to the Chinese patent application with application number 202210385398.X, which was submitted to the China Patent Office on April 13, 2022. The entire content of this application is incorporated into this application by reference.

Technical field

Embodiments of the present application relate to the field of cloud desktop technology, and in particular, to an image management method, device, server, terminal and storage medium.

Background technique

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

Intelligent Desktop Virtualization (IDV) is a common type of cloud desktop. IDV uses distributed computing and distributed storage, with the characteristics of centralized management and local execution, that is, using the local computing and storage resources of the terminal, so that even if there is a problem with the network connecting to the server, the normal use of the cloud desktop can be guaranteed.

When applying IDV, the image file of the cloud desktop needs to be distributed to the terminal. The image file records the operating system, device drivers, applications, etc. required to run the cloud desktop. Generally speaking, when upgrading an image file, the content recorded in the image file needs to be updated. At this time, the server needs to re-deliver the updated image file to the terminal. However, the image file has a large memory. When the image file is updated frequently, the image file needs to be frequently delivered to the terminal, which consumes more network resources.

Contents of the invention

One embodiment of the present application provides an image management method, device, server, terminal and storage medium to solve the technical problem in related technologies that the server consumes a lot of network resources when delivering image files to the terminal.

In the first aspect, an embodiment of the present application provides an image management method, which is applied to a server and includes:

Receive a first download request sent by a first terminal, the first terminal applies a first image, the first image includes a first image file and a second image file, the first image file records the first terminal The operating system used by Zhongyun Desktop, the second image file records device drivers and applications installed based on the operating system;

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 uses the received second image file. The file replaces the local original 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 is The third image file records data newly added when the cloud desktop is running in the state of setting the 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 third image file. A terminal, so that the first terminal uses the received second image file to replace the local original second image file, and the third image file is generated based on the second snapshot of the settings in the new second image file. .

In a second aspect, an embodiment of the present application also provides an image management method, applied to a first terminal, where the first terminal applies a first image, and 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, including:

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, receive the new second image file sent by the server;

Use the received second image file to replace the original local second image file;

Create 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. The third image file records the location of the cloud desktop. The data added when running in the second snapshot state is set as described above;

When the first download request is used to download a new second image file and the corresponding third image file from the server, receive the new second image file and the third image file sent by the server , the third image file is generated based on the set second snapshot in the new second image file;

Use the received second image file to replace the local original second image file.

In a third aspect, an embodiment of the present application also provides an image management device, which is applied to a server and includes:

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

A first sending unit, 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 The terminal uses the received second image file to replace the local original 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. Three image files, the third image file records data newly added when the cloud desktop is running in the state of setting the second snapshot;

A second sending unit configured to, when the first download request is used to download a new second image file and the corresponding third image file from the server, send the new second image file and the corresponding third image file to the server. The image file is sent to the first terminal, so that the first terminal uses the received second image file to replace the local original second image file, and the third image file is based on the new second image file. The second snapshot of the settings is generated.

In the fourth aspect, an embodiment of the present application also provides an image management device, applied to a first terminal, the first terminal applies a first image, and 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. The device includes:

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

A first download unit configured to receive the 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 is used to replace the original local second image file with the received second image file;

A first creation unit configured to create a corresponding third image file based on the set second snapshot in the received second image file, where the first image also includes the third image file, and the third image file records There is data newly added when the cloud desktop is running in the state of setting the second snapshot;

A second download unit configured to receive the new second 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. and the third image file, 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 original local second image file with the received second image file.

In the fifth aspect, an embodiment of the present application also provides an image management server, including:

Communication module, 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 are caused to implement the image management method as described in the first aspect.

In the sixth aspect, an embodiment of the present application also provides an image management terminal, including:

Communication module, 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 are caused to implement the image management method as described in the second aspect.

In a seventh aspect, an embodiment of the present application further provides a computer-readable storage medium on which a computer program is stored. When the program is executed by a processor, the image management method as described in the first aspect or the image management method as described in the second aspect is implemented. Described image management method.

In one embodiment of the present application, the server receives the first download request sent by the first terminal, and delivers the second image file of the first image center to the first terminal based on the first download request, so that the first terminal uses the new The second image file replaces the local second image file, so that the first terminal uses the new second image file when the first terminal runs the cloud desktop, and all new data added during the operation of the first terminal is written into the new The technical means of creating a third image file corresponding to the second image file solves the technical problem in related technologies that the server needs to consume a lot of network resources to deliver the image file to the terminal. 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 deliver all the image files, but only the second image file, which reduces the memory for downloading files and saves money. Use network resources and reduce download time. Moreover, since the third image file is a blank file after creation, even if the corresponding third image file needs to be delivered, only a small amount of network resources will be occupied, ensuring the rational use of network resources.

Description of the drawings

Figure 1 is a first schematic diagram of the image file distribution process in related technologies;

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

Figure 3 is a schematic diagram of a mirroring relationship provided by an embodiment of the present application;

Figure 4 is a flow chart of an image management method provided by an embodiment of the present application;

Figure 5 is a flow chart of an image management method provided by an embodiment of the present application;

Figure 6 is an image registration flow chart provided by an embodiment of the present application;

Figure 7 is a flow chart of an image management method provided by an embodiment of the present application;

Figure 8 is a flow chart of image merging provided by an embodiment of the present application;

Figure 9 is a flow chart of an image management method provided by an embodiment of the present application;

Figure 10 is an image restoration flow chart provided by an embodiment of the present application;

Figure 11 is a flow chart of an image management method provided by an embodiment of the present application;

Figure 12 is an image cloning flow chart provided by an embodiment of the present application;

Figure 13 is a flow chart of an image management method provided by an embodiment of the present application;

Figure 14 is a schematic structural diagram of an image management device provided by an embodiment of the present application;

Figure 15 is a schematic structural diagram of an image management device provided by an embodiment of the present application.

Figure 16 is a schematic structural diagram of an image management device provided by an embodiment of the present application.

Detailed ways

The present application will be further described in detail below in conjunction with the accompanying drawings and examples. It can be understood that the specific embodiments described here are used to explain the present application, but not to limit the present application. In addition, it should be noted that, for convenience of description, only some but not all structures related to the present application are shown in the drawings.

Under the IDV type, there are two options when distributing image files to Guests (end users):

Option 1: Figure 1 is the first schematic diagram of the image file distribution process in related technologies. Referring to Figure 1, when the terminal (that is, the end user) has a need to download an image file, it sends a download request to the server. After the server determines that the download request is legal, it sends the basic image file to the terminal. After that, the terminal starts the virtual machine based on the basic image file. , to run cloud desktop. Among them, the basic image file is also an image file. When the terminal is customized based on the basic image file, it can add its own personalized data during operation.

Option 2: Figure 2 is a second schematic diagram of the image file distribution process in related technologies. Referring to Figure 2, when the terminal needs to download an image file, it sends a download request to the server. After the server determines that the download request is legal, it sends the differential image file to the terminal. The terminal merges the differential image file into the basic image file. After that, the terminal The basic image file starts the virtual machine to run the cloud desktop. Among them, the differential image file refers to the image file obtained by using differential technology.

Generally speaking, when running a cloud desktop based on an image file, the image file usually needs to be updated during the management of the image file. For example, after the server upgrades the image file, the image file needs to be updated. For another example, when a terminal uses a cloud desktop, after filling in its own personalized data into the image file, the image file needs to be updated. At this time, when using scheme 1 to distribute the image file, after the server upgrades the image file, no matter the size of the change, all terminals using the image file need to re-download the full amount of the image file, which consumes a lot of network resources and requires a lot of time. The long download time is not conducive to the unified update of image files by the terminal. When using option 2, you can only download updated differential image files. This reduces the amount of data downloaded, but increases the time for merging differential image files on the terminal. In addition, you also need to perform a local backup of the basic image file to prevent The basic image file is damaged due to power outage during the merge process. This not only increases the processing time of the image file by the terminal, but also wastes the local storage space of the terminal. Moreover, whether using option 1 or 2 to distribute image files, after the administrator modifies the image file on the terminal, the terminal needs to submit the image file to the server first so that the server can deliver the modified image file to each terminal using the image file. Image file, which 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, which increases the network resources required for the download and upload process and the transmission time, which is not conducive to the server's use of the image file. manage. At this time, due to the limitations of public network bandwidth, the popularity and application of IDV-type cloud desktops have also been greatly hindered.

In summary, when using image files to run IDV-type cloud desktops, how to ensure the rational use of network resources and save time on transmission during image file management has become an urgent technical issue that needs to be solved.

Accordingly, embodiments of the present application provide an image management method, device, server, terminal and storage medium to ensure reasonable utilization and saving of network resources when managing image files in a scenario where the terminal runs an IDV-type cloud desktop. The transfer takes time.

An embodiment of the present application provides an image management method. The image management method 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 one physical entity.

In one embodiment, the image management device is an image management server (also called a server). The server can be used as a server of the IDV type cloud desktop to implement image (image) management and provide terminals with the necessary information to run the cloud desktop. Image file. Currently, a terminal (which can also be recorded as a terminal device, electronic terminal, etc.) can be any terminal that supports virtualization. For example, the terminal can be a personal computer, a tablet computer, an interactive tablet, a mobile phone, etc. Among them, virtualization usually means that computing elements run on a virtual basis rather than a real basis. Virtualization technology can expand the capacity of hardware and simplify the reconfiguration process of software. A virtual machine is a way of realizing virtualization. A virtual machine refers to a complete computer system with complete hardware system functions simulated through software and running in a completely isolated environment. Currently, terminals run cloud desktops through virtual machines. .

Image can also be recorded as an image file, which is a file that the terminal relies on when starting a virtual machine. In one embodiment, each image includes three types of image files. The three types of image files can be recorded as: BaseImage, LowerIamge and UpperImage.

BaseImage records the operating system, which is used by the cloud desktop. Currently, BaseImage records pure operations without operating system applications or additional device drivers. Each image can have an independent BaseImage, or multiple images can share the same BaseImage. When multiple images share the same BaseImage, the BaseImage is used by the image in the form of a hard link, which can save storage space on the server. Among them, the hard link is Refers to one or more file names of a file, that is, multiple file names are used to link to the same file. These file names can be in the same directory or different directories. Optionally, when the terminal runs the cloud desktop, the BaseImage can be read but will not be modified to protect the BaseImage from damage.

LowerImage is a sub-disk of BaseImage, that is, LowerImage is created based on BaseImage and serves as the next-level file of BaseImage. LowerImage records content such as device drivers and applications installed based on the operating system. In one embodiment, each Guest image carries an initial LowerImage for different terminal models. The LowerImage contains built-in applications and device drivers when the terminal under the corresponding model runs the operating system. After that, the user can derive his or her own LowerImage based on the initial LowerImage. The LowerImage contains personalized data during the user's use, such as the user's newly installed device drivers, applications, saved files or data, etc. Optionally, each user can have an independent LowerImage.

UpperImage is a sub-disk of LowerImage, that is, UpperImage is created based on LowerImage and serves as a lower-level file of LowerImage. UpperImage records the data newly added when the terminal runs the cloud desktop. Optionally, when the UpperImage is created, it can be considered as a blank file, and no user-related data is recorded. When the user uses the cloud desktop, the current newly added data is recorded in the UpperImage. The data recorded in the UpperImage can be submitted to the LowerImage to add personalized data during the user's use in the LowerImage.

At this time, BaseImage, LowerIamge and UpperImage can also be considered as three levels of files included in the image.

In one embodiment, an image snapshot (also called snapshot or Snapshot) refers to a restore point of an image file at a certain moment, that is, the image file can be restored from any state to the state corresponding to the snapshot (ie, the restore point). Each snapshot has a corresponding snapshot name. The naming rules for snapshot names are currently not limited. Generally speaking, the snapshot name contains a unique identifier to distinguish each snapshot through the snapshot name. Optionally, BaseImage, LowerIamge and UpperImage can all create snapshots. Each image file can be searched for its corresponding snapshot list. For example, the snapshot list corresponding to LowerIamge records the name of each snapshot it contains, and LowerIamge can find the required snapshot based on the snapshot list.

In one embodiment, a unique snapshot is created in BaseImage, and a LowerIamge is created based on the state of BaseImage at the time of the unique snapshot. Optionally, before creating LowerIamge, first change the file name of BaseImage to the snapshot name of the unique snapshot of BaseImage. Then, when creating LowerIamge, record the file name of BaseImage in LowerIamge to ensure that the snapshot name of BaseImage is accurately recorded in LowerIamge. , and then find the BaseImage corresponding to LowerIamge through the snapshot name of BaseImage.

In one embodiment, multiple snapshots are created in LowerIamge. Optional, when creating a LowerIamge for different terminal models (currently the initial LowerIamge), create a driver snapshot after installing the device driver built into the operating system in the LowerIamge, and install the application built into the operating system (also called a basic application) Create an application snapshot. Through these two snapshots, the LowerImage can be restored to the state when the device driver and application were installed. Optionally, when LowerIamge is used by the terminal, the terminal's new personalized data can also be written into 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 certain snapshot status of LowerIamge, that is, UpperImage corresponds to a snapshot of LowerIamge. Similar to creating LowerIamge, UpperImage records the snapshot name of its corresponding snapshot in LowerIamge, so as to pass LowerIamge in UpperImage. Find the corresponding LowerIamge based on the snapshot name and determine the corresponding snapshot in LowerIamge. Optionally, when creating a snapshot in LowerIamge, the corresponding UpperImage can be generated. At this time, when the terminal runs the cloud desktop based on the LowerIamge under the snapshot, it can write in the UpperImage that the snapshot is used as the node. When running the cloud desktop After adding the new data, the server submits the UpperImage to LowerIamge, that is, writes the personalized data under the corresponding snapshot node to LowerIamge. After that, a new snapshot can be created in LowerIamge, and the corresponding UpperImage can be created again based on the new snapshot. , so that the terminal runs the cloud desktop based on the LowerIamge corresponding to the new snapshot and writes the new data in the UpperImage. At this time, for the terminal, the snapshot of LowerIamge is used as a distinction, and the new data added by the terminal is written to the UpperImage corresponding to the snapshot, without modifying BaseImage and LowerIamge in the terminal.

In one embodiment, each snapshot in LowerIamge corresponds to a version (also called a mirror version or revision). That is, when a new snapshot is created in LowerIamge, it can be considered that a new version is created. For the terminal, switching operations can be achieved by switching different snapshots of LowerIamge. different versions. Each version has a corresponding version ID. The version ID is unique. Its specific naming rules are currently not limited. Each version also has a corresponding version UUID (that is, the universal unique identification code of the version). When the terminal is running the cloud desktop, if you want to change the version it is using, you only need to obtain the LowerIamge corresponding to the version from the server (LowerIamge is the snapshot status corresponding to the version) and use it. It is understandable that when an image is used by multiple users, based on data security considerations, each user has his own independent LowerImage file. At the same time, each user's version data is stored in his own LowerImage file in the form of a built-in snapshot. Only your own LowerImage files are allowed to be downloaded. Each version of the same user corresponds to a built-in snapshot in LowerIamge. The snapshot name of the built-in snapshot is version UUID. Through the snapshot name of the built-in snapshot, you can determine whether the current corresponding version can be used by the user. Optionally, each version and the snapshot name of the corresponding snapshot can be associated and recorded in the snapshot list. You can find the corresponding snapshot name through the version. You can find the corresponding LowerIamge through the snapshot name. You can find the corresponding BaseImage based on the snapshot name of BaseImage recorded in LowerIamge. You can also find the corresponding UpperImage through the snapshot name corresponding to the version. . At this time, the found BaseImage, LowerIamge, and UpperImage can be considered to be associated with the corresponding versions. That is, each version of each image has an associated BaseImage, LowerIamge, and UpperImage. In one embodiment, each version has a corresponding version record and version directory, where the version record is used to record metadata (used to describe the attributes of the version) and other contents of the version, and the version directory is used to record its associated BaseImage and LowerIamge, optionally, the version directory can also record its associated UpperImage. Optionally, BaseImage is linked to the version directory as a hard link, and BaseImage can be shared between different versions.

In one embodiment, an image can have one or more branches (also called image version branches, branches), a branch can have one or more versions, and each user who uses the image can have an independent branch. Different images or different branches of the same image can share a BaseImage. To facilitate understanding, Figure 3 is a schematic diagram of an image relationship provided by an embodiment of the present application, which exemplarily shows the relationship between images, branches, and versions, as well as the relationship between BaseImage, LowerIamge, and UpperImage. As shown in Figure 3, a BaseImage can be used by multiple images through hard links. Figure 3 contains image A and image B. Image A contains branch a, and image B contains branch b and branch c. Branch a is used by user A, who has an independent LowerIamge (LowerIamgeA). LowerIamgeA includes snapshot A1 (SnapshotA1), snapshot A2 (SnapshotA2) and snapshot A3 (SnapshotA3). Snapshot A1 corresponds to version 1, and snapshot A2 Corresponds to version 2, and snapshot A3 corresponds to version 3. Each snapshot can generate the corresponding UpperImage. It is understandable that Figure 3 is an example to facilitate the description of the corresponding relationship between snapshots and versions. The snapshots included in LowerIamgeA are shown in a dotted box. ,In actual applications, the snapshot is included in LowerIamgeA. Moreover, pointing snapshot A1, snapshot A2 and snapshot A3 to UpperImageA in Figure 3 means that each snapshot will create a corresponding UpperImage, not that the three snapshots share one UpperImage. Branch b is used by user B, and branch c is used by user c. At this time, the relationship between the snapshots, versions, and three types of files corresponding to branch b and branch c is similar to that of branch a, and will not be described in detail at this time. Based on the content shown in Figure 3, it can be seen that a file chain can be formed between BaseImage, LowerIamge and UpperImage, which can avoid confusion of file relationships between different branches.

For the terminal, its virtual machine needs to have BaseImage, LowerIamge and UpperImage at the same time. Moreover, the virtual machine can be started directly based on the UpperImage, without merging BaseImage, LowerIamge and UpperImage into one file.

The server also stores an image table (osimages). There are multiple image records recorded in the image table. Each image record corresponds to an image and is used to record the metadata of the image (used to describe the attributes of the image) and other contents.

The BaseImage, LowerIamge and UpperImage stored in the server can be downloaded and used by the terminal. Optionally, BaseImage, LowerIamge and UpperImage are available for terminal download in the form of seed files, that is, the server can respectively generate the BaseImage seed file corresponding to BaseImage, the LowerIamge seed file corresponding to LowerIamge, and the UpperImage seed file corresponding to UpperImage. Among them, the torrent file refers to the P2P download of the torrent file. P2P (peer-to-peer) is a peer-to-peer computer network. After the client downloads the torrent file through P2P, it can obtain the corresponding BaseImage, LowerIamge or UpperImage.

It should be noted that the users mentioned above refer to users who use terminals. One user can use different terminals, one terminal can be used by multiple users, and each user can be distinguished by the user ID used when logging in.

In one embodiment, Figure 4 is a flow chart of an image management method provided by an embodiment of the present application. When the server executes the image management method, it may include:

Step 110: Receive the first download request sent by the first terminal. The first terminal applies the first image. The first image includes a first image file and a second image file. The first image file records the cloud desktop used by the first terminal. operating system, the second image file records device drivers and applications installed based on the operating system.

As an example, the server provides services for a terminal to describe how the server implements image management. Currently, the terminal where the server provides services is recorded as the first terminal. The image used by the first terminal is recorded as the first image, that is, 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, LowerIamge, and UpperImage used are recorded as the first image file, the second image file, and the third image file respectively. Currently, the snapshot in the second image file is recorded as the second snapshot, and the snapshot in the first image file is recorded as the first snapshot. Based on the foregoing content, it can be known that 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 corresponding first snapshot. The second snapshot name of the second snapshot. Wherein, the snapshot name of the first snapshot is recorded as the first snapshot name, and the snapshot name of the second snapshot is recorded as the second snapshot name. The second image file used when the first terminal runs the cloud desktop corresponds to one version, and the third image file used is generated based on the corresponding snapshot of the version in the second image file. 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 Each version of the third image file corresponding to the second snapshot 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 is recorded in the server with at least one image branch, each image branch includes at least one version, and the first terminal applies one image branch of the first image. Optionally, the first image run by the terminal may be specifically a version under the image branch. In this case, the first image ID mentioned later may also be considered as the ID of the image branch in the first image.

Before the first terminal runs the cloud desktop for the first time, it needs to download the first image file and the second image file from the server, and then create a third image file based on its own actual determination or download the third image file from the server. Optionally, when the first terminal has the function of creating a third image file, the third image file can be created in combination with the second snapshot corresponding to the current version. When the first terminal does not have the function of creating the third image file, the server can generate the third image file and deliver it to the first terminal. Afterwards, the first terminal runs the virtual machine based on the first image file, the second image file and the third image file, and runs the cloud desktop through the virtual machine.

When the first terminal has a need for version update, a corresponding download request is generated, and a corresponding second image file is obtained from the server based on the download request, so as to implement version update based on the second image file. Currently, the download request generated by the first terminal is recorded as the first download request. When the first terminal generates the first download request, the first image file and the second image file have been stored locally, and the second image file may record the user's personalized data, or may not have the user's personalized data added.

The method of generating the first download request is currently not limited. For example, when the server determines that the version of the second image file is updated (that is, a new version is generated), it sends a notification of the version update to the first terminal using the second image file, and then , the user of the first terminal can determine whether to update the version based on the notification, and when determining to update the version, generate a first download request and send it to the server. For another example, when the user of the first terminal has a need for version update, a first download request is generated and sent to the server. For another example, when the user of the first terminal confirms that a restore point (that is, a snapshot) needs to be created based on the current running status of the cloud desktop, the third image file currently recording the new data is uploaded to the server, and the server submits the third image file. to the second image file, and create the corresponding snapshot and version, that is, update the version of the second image file. At this time, the server can complete the creation of the restore point through the first terminal. After that, the first terminal generates the first download request, and Send to the server, or the first terminal generates a first download request before uploading the third image file, and sends the third image file and the first download request to the server together.

In one embodiment, based 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 used to download the second image file from the server. At this time, the first The terminal can create a third image file locally based on the second image file. Another type is used to download the second image file and the third image file from the server. It is understandable that when the first terminal has the function of creating a third image file first, it can also choose to download the third image file from the server.

After the server receives the first download request, it parses it and determines that it is used to download the second image file, and then executes step 120 to determine that it is used to download the second image file. image file and the third image file, perform step 130. Optionally, the first terminal writes an identifier of whether the first terminal can generate the third image file in the first download request, so that the server determines whether the third image file needs to be sent based on the identifier. Optionally, the server pre-records the terminal model that can locally generate the third image file. When the first terminal generates the first download request, the terminal model of the first terminal is written in the first download request, and the server determines the first download request based on the first download request. The terminal model in the request determines whether a third image file needs to be sent.

It should be noted that two different processing methods are currently described, taking the first terminal having the function of creating a third image file and not having the function of creating the third image file as an example. In actual applications, all terminals provided by the server can also have the function of creating a third image file. In this case, the first download request is only used to download a new second image file from the server, or the terminals provided by the server can Each terminal does not have the function of creating a third image file. At this time, the first download request is only used to download a new second image file and the corresponding third image file from the server. In practical applications, the server may generate the third image file regardless of whether the terminal has the function of creating the third image file. In this case, the first download request is only used to download a new second image file from the server.

Step 120: When the first download request is used to download a new second image file from the server, send the new second image file to the first terminal, so that the first terminal uses the received second image file to replace the local original image file. The second image file is a second image file and a corresponding third image file is created based on the second snapshot of settings in the received second image file. The first image also includes a third image file, and the third image file records the settings of the cloud desktop in the third image file. Data newly added when running in the second snapshot state.

For example, the second image file downloaded by the first terminal from the server and the local original second image file can be considered as different versions of the same second image file. There are differences in the contents of the second image file under different versions. This is In order to facilitate the distinction, the downloaded second image file is recorded as the new second image file.

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 find the new second image file that needs to be downloaded. In one embodiment, the first download request may include the version ID that currently needs to be downloaded. Optionally, the version ID that currently needs to be downloaded may be issued by the server to the first terminal. For example, after the server performs a version update, the current version The ID is sent to the first terminal. Optionally, the version ID that currently needs to be downloaded can 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 each version corresponding to the second image file currently used in the first image. , and then select the version that currently needs to be downloaded. At this time, in order to ensure data security, the server can display to the user the versions that are available for the user, while the versions that are not available for the user will not be displayed, or the server can Set different permissions for different users. Only users with specific permissions can perform version search. After receiving the first download request, the server obtains the version ID and searches for the second image file associated with the corresponding version as the new second image file. In one embodiment, the first download request may include the 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 according to the image ID, and adds the The second image file associated with the latest version is used as the new second image file. In one embodiment, the first download request may include the image ID and the version ID. After that, the server finds the new second image file based on the image ID and the version ID. In one embodiment, the first download request includes a user ID, and 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 third image. Two image files. The server can also determine the new second image file through other methods.

The server delivers the new second image file to the first terminal. When the first terminal receives the new second image file, it uses the new second image file to replace the original local second image file to implement version updating. Optionally, after the version is updated, the third image file corresponding to the current version needs to be used to record the data newly added when the first terminal runs the cloud desktop based on the current version. At this time, the first terminal obtains the second image file corresponding to the current version. a second snapshot, and generate a 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). After that, the first terminal can run the cloud desktop based on the current version. Optionally, before the update, the original version of the first terminal may also have a corresponding third image file. The user can determine whether the data recorded in the original third image file needs to be discarded before the version is updated. If so, then You can directly delete the third image file locally, that is, give up modifications to the original version; if you do not need to give up, you can upload the third image file to the server first, and the server will submit the third image file to the corresponding second image. file, and 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 a 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 and save the third image file with the corresponding version, or the server can associate and save the third image file with the corresponding version.

Step 130: When the first download request is used to download the new second image file and the corresponding third image file from the server, send the new second image file and the third image file to the first terminal, so that the first The terminal uses the received second image file to replace the local original second image file, and the third image file is generated based on the set second snapshot in the new second image file.

The difference between this step and step 120 is that in this step, the third image file is generated in the server. In one embodiment, when the server creates a snapshot (ie, a version) of the second image file, it generates a third image file corresponding to the version, and when receiving the first download request, combines the second image file and the corresponding third image file. The three image files are sent to the first terminal together.

Optionally, the server parses the first download request after receiving it to find the new second image file that needs to be downloaded and the corresponding third image file. Optionally, the corresponding third image file can be searched according to the version of the new second image file. For the process of the server parsing the first download request, reference can be made to the relevant description in step 120, which will not be described in detail at this time.

The server sends the found new 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 uses the new second image file to replace the original local second image file to update the version, and then runs the cloud desktop based on the current version. And write the newly added data into the third image file corresponding to the current version. Optionally, before the update, the original version of the first terminal may also have a corresponding third image file. At this time, for the processing of the third image file, refer to the relevant description in step 120, which will not be described again at this time.

As mentioned above, the server receives the first download request sent by the first terminal, and delivers the second image file of the first image center to the first terminal based on the first download request, so that the first terminal uses the new second image file to replace The local second image file enables the first terminal to use the new second image file when the first terminal runs the cloud desktop, and the new data added during the operation of the first terminal is written into the new second image file corresponding to The technical means of the third image file solves the technical problem in related technologies that the server needs to consume a lot of network resources to deliver the image file to the terminal. 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 deliver all the image files, but only the second image file, which reduces the memory for downloading files and saves money. Use network resources and reduce download time. Moreover, since the third image file is a blank file after creation, even if the corresponding third image file needs to be delivered, only a small amount of network resources will be occupied, ensuring the rational use of network resources.

In one embodiment of the present application, the image in the server needs to be registered before it can be used by the terminal. Currently, the first image is taken as an example to describe the image registration process. Figure 5 is a flow chart of an image management method provided by an embodiment of the present application. It is a specific process when the server performs image registration and management. Referring to Figure 5, the image management method includes:

Step 210: Obtain the first image file and the second image file.

For example, after the first image file and the second image file are created, they need to be uploaded to the server first for server registration. The first image file and the second image file can be uploaded separately or at the same time to create the first image file. There are currently no restrictions on the terminals and upload rules for image files and second image files. In one embodiment, the first image file and the second image file currently uploaded can be considered as the initial BaseImage and the initial LowerImage respectively. The second image file is created based on the first image file.

It can be understood that the process of uploading the first image file and the second image file can also be considered as the process of the server obtaining the first image file and the second image file.

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

For example, in order to ensure that the terminal uses the first image correctly, the first image file and the second image file are hard-linked to the first image respectively, that is, the first image file and the second image file currently used by the first image are clearly defined. It is understood that if the second image file is used by a branch, then when the first image file and the second image file are hard-linked to the first image, they can be connected to the branch to which they belong. Later, 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 updated. Hard link to the first image (specifically the new Branch) in.

In one embodiment, hard linking the first image file and the second image file to the first image respectively also includes: creating an image record of the first image, and adding image metadata of the first image to the image record.

Among them, the image metadata of the first image describes the attributes of the first image. For example, the image metadata records the branches included in the first image and the user ID corresponding to each branch. The image metadata may be determined based on the first image file and the second image file. Optionally, after generating the image metadata of the first image, record the image metadata of the first image. Among them, the image metadata is recorded in the image record. For example, a mirror record of the first mirror is created, the mirror record is added to the mirror table, and then the mirror metadata of the first mirror is added to the mirror record. Optionally, when the first image is updated (for example, a new branch, a new version, etc. is created in the first image), the image metadata in the image record is also updated simultaneously.

The above process can also be considered as the image registration process.

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.

For example, after registration is completed, version creation is performed. In one embodiment, the first image file contains a unique first snapshot. Before the second image file is created, the file name 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 is recorded. The first snapshot name of a snapshot. Optionally, create an initial second snapshot 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, the user can derive his or her own second image file based on the second image file. The first image file and the initial second image file (which only contains device drivers and vendor-built applications and generates a second snapshot) can be created by the vendor of the first image and uploaded to the server. Subsequent users generate their own snapshots based on the second image file (this time, including personalized data, such as application upgrade patches).

Create a version corresponding to the initial second snapshot based on the initial second snapshot, create a version directory corresponding to the version, and add the first image file and the second image file used by the version in the version directory. Optionally, when creating a version, the 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 with the version directory. In one embodiment, both the first image file and the second image file are added in the version directory in the form of 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, and the second image file and the first image file are The hard connection process is similar and will not be described in detail at this time. At this time, after adding the first image file and the second image file to the version directory, it can be considered that the first image is obtained. Optionally, since the terminal downloads the corresponding image through the seed file, after hard linking the first image file and the second image file to the version directory, it is also necessary to create corresponding P2P images for the first image file and the second image file respectively. Download the torrent file to enable the terminal to download.

In one embodiment, when creating a corresponding version directory based on the initial second snapshot of the second image file, it also includes: creating a version record corresponding to the initial second snapshot, and recording the version corresponding to the initial second snapshot in the version record. Version metadata.

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 the version through the version ID. In one embodiment, the version metadata of the version is determined based on the first image file and the second image file used in the version. The version metadata may include user ID, version ID, pre-order version ID, etc. The pre-order version refers to the previous version of the current version, that is, the version before the current version is created in the second image file. Version metadata can be updated in conjunction with version attributes. Afterwards, the version metadata is added to the version record corresponding to the version.

In one embodiment, taking the server creating a third image file as an example. At this time, step 240 is also included after step 230.

Step 240: Create a corresponding third image file based on the initial second snapshot.

Optionally, after the server creates an initial second snapshot of the second image file, the server creates a corresponding third image file based on the initial second snapshot. A feasible method is to change the file name of the second image file to the snapshot name of the initial second snapshot, so as to record the snapshot of the second snapshot in the third image file when creating the third image file. name.

Optionally, after creation, add a third image file in the corresponding version directory to identify the three types of image files included in the corresponding version through the version directory. Among them, the implementation method of adding the third image file to the version directory is currently not limited.

Optionally, after creating the third image file, create a corresponding P2P download seed file for the third image file so that the terminal can download it.

Before the first terminal runs the cloud desktop for the first time, it needs to download the first image file of the first image, the initial second image file, and the third image file corresponding to the initial second image file from the server (currently downloading the seed file , and then obtain the corresponding image file based on the seed file). During subsequent updates, there is no need to download the first image file again.

In actual applications, the third image file can also be created by the first terminal. Optionally, after the first terminal creates the third image file, it may notify the server so that the server adds the third image file in the corresponding version directory.

The following is an exemplary description of the image registration process. Figure 6 is an image registration flow chart provided by an embodiment of the present application. Referring to Figure 6, it shows the process of image uploading and registration as well as the processing method of image files under each process. After registration starts, image upload is performed first, that is, the required files are uploaded. Figure 6 takes the first image file and the second image file as an example. During this process, the server obtains the first image file and the second image file respectively. After that, perform image registration. In this process, image metadata of the first image is generated, and the corresponding file processing method is to hard-link the first image file and the second image file to the first image respectively. After that, create an image record for the first image and add image metadata to the image record. After that, create an initial restore point (which can also be understood as creating an initial version). 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 of the corresponding version and register the image. The first image file and the second image file hard-linked during the process are hard-linked to the version directory respectively. Furthermore, a corresponding third image file is created based on the initial second snapshot of the second image file. After that, seed creation is performed, that is, seed files corresponding to the first image file, the second image file, and the third image file are respectively created for the first terminal to download.

Optionally, after downloading the first image file and the initial second image file, the first terminal builds the first image file and the initial second image file.

As mentioned above, during the image registration process, image files can be reused through hard links, and the first image file and the second image file are uploaded and registered independently, which facilitates subsequent image management. For example, when the version is updated, only modifications are required. The second image file does not need to modify the first image file.

In one embodiment of the present application, when the server is managed, image merging management is also required. Image merging can be understood as writing the user personalized data recorded in the UpperImage into the corresponding LowerImage, so as to add the user's data in the LowerImage. Personalized data. Currently, the first image is taken as an example to describe the image merging process. Among them, the first image is recorded in the server with a corresponding snapshot list. The snapshot list records each version of the first image and the second snapshot corresponding to each version. Optionally, the snapshot list records each version ID and the corresponding second snapshot. Snapshot name. Figure 7 is a flow chart of an image management method provided by an embodiment of the present application. It is a process when the server performs image merge management. Referring to Figure 7, the image management method includes:

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

Exemplarily, when the first terminal runs the cloud desktop, the new data (ie, the user's personalized) data is written into the third image file. For example, the first terminal installs a new application or a new application in the cloud desktop. When the device is driven, new applications and new device drivers are written into the third image file. For another example, when the first terminal stores new files and data in the cloud desktop, the new files or data are written into the third image file. in the file. When the user of the first terminal needs to write the data of the third image file into the second image file, the third image file can be uploaded to the server. Optionally, when uploading, an image merging request can also be sent. to enable the server to perform image merging.

Optionally, before merging 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 example, when the first terminal uploads the third image file, it informs the server of the first image used by itself. For another example, the server records Each terminal using each image, when the first terminal uploads the third image file, informs the first terminal of its identity data (such as user ID, etc.), and then The server determines the first image used by the first terminal based on the identity data. For example, the purpose of locking the first image is to prohibit the first image from being downloaded. At this time, each terminal cannot download various sub-files included in the first image.

Optionally, the third image file already contains the second snapshot name, and the server can find the corresponding version, the second image file, and other contents based on the second snapshot name. Therefore, the first terminal does not need to perform version verification before uploading the third image file. Optionally, the third image file can be uploaded in a differential manner.

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

For example, the server determines the version ID currently used by the first terminal, that is, the ClientRevisionId. For example, when the first terminal uploads the third image file, the server can directly obtain the version ID by uploading the version ID. Another example is, after the first terminal uploads the third image file, the server obtains the records in the third image file by parsing the third image file. The second snapshot name of the second snapshot, and then, based on the second snapshot name, search the corresponding version in the snapshot list to obtain the version ID. For example, the server parses the version metadata corresponding to the version currently used by the first terminal to obtain the version ID. The version ID is obtained from the metadata, where 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.

Step 330: Search for the second image file corresponding to the version ID.

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

Optionally, when searching for the second image file, first find the storage path of the third image file (Client UpperIamge Path) and the storage path of the second image file (LowerIamge Path) used by the first terminal in the database based on the version ID. . Among them, the corresponding version directory can be found according to the version ID, and the Client UpperIamge Path and LowerIamge Path can be obtained according to the records in the version directory. Or, obtain the corresponding second snapshot name based on the version ID, and obtain the Client UpperIamge Path and LowerIamge Path based on the second snapshot name. After that, the corresponding second image file can be obtained according to the LowerIamge Path.

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

For example, the data recorded in the third image file is written into the second image file in the form of information blocks to achieve image merging. Among them, the submission of the third image file to the second image file can also be considered as a commit process. After the third image file is submitted to the second image file, it can be considered that the second image file has been updated. At this time, in order to distinguish it from the original second image file, the submitted second image file is recorded as the new third image file. Two image files.

In one embodiment, since the second image file may contain multiple snapshots, the current version of the second image file found in step 330 (ie, the latest version) may not be the version used by the first terminal, that is, the second The image file is not the version used when creating the third image file. In order to ensure the normal implementation of image merging, it is necessary to first adjust the second image file to the version corresponding to the third image file. At this time, step 340 may include steps 341 to 343:

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

For example, the corresponding second snapshot is determined according to the second snapshot name recorded in the third image file, and then the second image file is restored to a state corresponding to the second snapshot.

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

It can be understood that when creating a new second snapshot in the second image file, the file name of the second image file is modified to the second snapshot name of the new second snapshot, so as to clarify the version currently used by the second image file. , and when submitting the third image file to the second image file, it is necessary to ensure that the second snapshot name recorded in the third image file is consistent with the file name of the second image file. If the file name of the second image file is inconsistent with the second snapshot name recorded in the third image file, the third image file cannot be accurately and safely submitted to the second image file. Therefore, the second image file must be restored. After that, rename the second image file. After renaming, the second The file name of the image file is changed to the second snapshot name recorded in the third image file uploaded by the first terminal.

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

For example, commit the third image file to the renamed second image file.

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

For example, after the third image file is submitted to the second image file, the new second image file adds the user's personalized data, and then a new second snapshot is created for the second image file for subsequent needs. When, restore the second image file to the state after submitting the third image file. Optionally, when creating a new second snapshot, generate a snapshot name for the new second snapshot. Optionally, creating a new snapshot can also be understood as creating a new version. At this time, you can create a new version record and version directory, add new version metadata to the new version record, and add new version metadata to the version directory. The first image file, second image file and third image file corresponding to this version are recorded in.

In one embodiment, each UpperIamge has a unique identifier. Different UpperIamges can be distinguished through the unique identifier. The unique identifier can be generated when the UpperIamge is created. Optionally, when the first terminal uploads the third image file, it provides a 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 corresponding second snapshot name. That is, the requirement for uniqueness of the second snapshot name is met.

Currently, taking the creation of the third image file in the server as an example, at this time, after step 350, steps 360 to 370 are also included:

Step 360: Delete the third image file.

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

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

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 to use the new second image file on the first terminal. Record the newly added data 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.

In one embodiment, after a new second snapshot is created, the content of the second image file used in the first image changes. Therefore, the snapshot list and the image record need to be updated. At this time, after step 370, step 380 may also be included.

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

For example, after creating a new second snapshot or creating 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 in the snapshot list.

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

For example, after updating the snapshot list, you also need to update the image record corresponding to the first image in the image table, that is, 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 creating the seed file.

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. After that, the first terminal generates a first download request for downloading the new second image file and the corresponding third image file and sends it to the server. Upon a download request, the new second image file and the corresponding third image file are sent to the first terminal for use by the first terminal.

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

It can be understood that in actual applications, when the third image file is created by the first terminal, the process of creating a new third image file in step 370 is implemented in the first terminal.

The following is an exemplary description of the general process of image registration. Figure 8 is an image merging flow chart provided by an embodiment of the present application. Referring to Figure 8, after the merger starts, the corresponding image is first locked, and 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). After that, the clientRevisionID is retrieved from the database based on the ClientRevisionID. Find the Client UpperImage Path (that is, the path of the third image file used by the terminal) and the LowerImage Path (that is, the path of the second image file). After that, restore the LowerImage to the snapshot that the Client UpperImage depends on, rename the LowerImage, and submit the Client UpperImage. Go to LowerImage, create a new snapshot for LowerImage, delete the old UpperImage, create a new UpperImage, update the snapshot list, create seed files for LowerImage and UpperImage, update the mirror record in the mirror table, and unlock. In this way, the image merge is completed.

As mentioned above, the newly added data when the first terminal runs the cloud desktop is written to the third image file, and the first image file and the second image file will not be modified. Therefore, when there is a need for image merging on the first terminal or server, You only need 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 upload speed and efficiency, and saves network resources. , thereby improving the efficiency and speed of image merging.

In one embodiment of this application, when the server is managed, image restoration management is also required. Image restoration can be understood as restoring the LowerImage to a certain specified version. Currently, the first image is used as an example to describe the image restoration process. Figure 9 is a flow chart of an image management method provided by an embodiment of the present application. It is a process when the server performs image restoration management. Referring to the figure, the image management method includes:

Step 410: Receive the image restoration instruction.

For example, the image restoration instruction is used to instruct the server to perform image restoration, which can be generated at the terminal or at the server. When the server generates the image restoration instruction, the user of the server (such as an administrator with certain permissions) can select The LowerImage that needs to be restored and the version that needs to be restored. After that, the server generates an image restoration instruction based on the selection, and then receives the image restoration instruction. Currently, the image restoration instruction is used to restore the second image file in the first image as an example for description.

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 refer to the process of locking the first image in step 310, which is not currently performed. Repeat.

Step 420: Obtain the version ID to be restored according to the image restoration instruction.

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 restore command includes the version ID to be restored. Optionally, the server calls the corresponding parameter according to the image restoration instruction to obtain the version ID to be restored through the parameter. The parameter called is presented in the form of a string variable and may include the image ID of the first image, The user ID, version ID and other contents of the first terminal.

Step 430: Search the corresponding second image file and the corresponding second snapshot name according to the version ID.

Optionally, since each second snapshot corresponds to a version, query the snapshot list corresponding to the first image through the version ID to be restored to obtain the corresponding second snapshot name, and obtain the second snapshot name Corresponds to the second image file where the second snapshot is located.

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

Exemplarily, 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, after the second snapshot, the second image file The user's personalization data added to the file will be deleted.

In one embodiment, the server creates a third image file. At this time, after step 440, steps 450 and 460 are also included.

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

For example, since the second image file has changed, the third image file corresponding to the second image file before the change, that is, the old third image file needs to be deleted.

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

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

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

Optionally, since the second image file contained in the first image has been updated, the image record corresponding to the first image in the image table also needs to be updated. At this time, after step 460, it also includes:

Step 470: Update the image metadata in the image record.

Optionally, after the image metadata is updated, it can be determined that the image restoration is completed. At this time, the server can unlock the first image so that the first terminal can download the corresponding seed file. In one embodiment, after the image is restored, the server can notify the first terminal to complete the image restoration. After that, the first terminal generates the corresponding first download instruction according to the notification from the server and feeds it back to the server, and the server executes the first download instruction. In response, the restored second image file is pushed to the first terminal as a new second image file.

In one embodiment, the server records the latest version ID of each image, and after the image is restored, changes the latest version ID of the corresponding image to the restored version ID.

The following is an exemplary description of the image restoration process. Figure 10 is a flow chart of an image restoration provided by an embodiment of the present application. Referring to Figure 10, after starting, first lock the corresponding image, and then parse the parameters of the call (i.e. Parse Args) to get the ImageID and RevisionID. Then, locate the target SnapshotName to which the corresponding LowerImage needs to be restored based on the RevisionID. After that, LowerImage is restored to the corresponding target Snapshot. After that, delete the old UpperImage, create a new UpperImage, create seed files for LowerImage and UpperImage respectively, update the image record in the image table, unlock the image, and resume the download of the image to complete the image restoration.

As mentioned above, when there is a need for image restoration, you only need 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.

In one embodiment of the present application, when the server is managed, image cloning management is also required. Image cloning can be understood as obtaining another image based on one image clone. Currently, the first image is used as an example to describe the image cloning process. Figure 11 is a flow chart of an image management method provided by an embodiment of the present application. It is a process when the server performs image cloning management. Referring to the figure, the image management method includes:

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

For example, the image cloning instruction is used to instruct the server to perform image cloning. Currently, the first image is used as the cloned image. At this time, the image clone instruction can be considered as being used to clone the first image.

For example, the image cloning instruction may be issued by the user in the first terminal or server, or may be issued by the administrator of the image in the server. Optionally, when generating an image restore command, write the ID of the restored image in the image restore command so that the server can determine the restored image (currently, the image restore command writes The image ID of the first image). Optionally, when cloning an image, you can clone only a certain version. At this time, the image restore command can also include the ID of the version that needs to be cloned. Optional, but because the user's personalized data may be recorded in the first image, for data security, only administrators with certain permissions can issue image cloning instructions, or only users can use the second image for themselves. Clone an image.

Step 520: Clone the first image file and the second image file included in the first image to obtain a second image, and the second image is the cloned image.

For example, the image cloned based on the first image is recorded 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 Files can be linked to the secondary image via hard links. Optionally, the second image file in the first image can be copied to the second image, and then a corresponding third image file can be created based on the second image file to ensure that the third image file is used through the three levels of image files. The second image is used normally.

In one embodiment, step 510 may include steps 511 to 516:

Step 511: Generate an image record and a version directory of the second image according to the image cloning instruction, and record the image metadata of the first image in the image record of the second image.

For example, when cloning the second image, you may also need to perform image registration, that is, create an image record and version directory of the second image, and also create a version record of the second image. Currently, the image metadata of the first image is first written in the image record of the second image.

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

For example, the second image and the first image share the first image file. Therefore, the first image file is connected to the second image in a hard link. Currently, the first image file is hard linked to the second image. version directory.

Step 513: Copy the second image file in the first image to the version directory.

For example, since each image needs to have its own LowerImage, when cloning, copy the second image file used in the first image and paste it in the version directory of the second image to clarify the second image The second image file used. It can be understood that the currently copied second image file includes all current second snapshots.

Step 514: Keep the target version in the copied second image file and delete other second versions. The target second version is determined through the image cloning instruction.

For example, when cloning an image, 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, you need to initialize the second image file. During initialization, only the state corresponding to the target version is retained in the second image file, and other versions are deleted. That is, there is only one version in the second image file after initialization. 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. After that, the metadata corresponding to the target version can be processed in the version record of the second image. Record. It should be noted that the version directory mentioned in steps 511 to 513 can be considered as the version directory corresponding to the target version.

In one embodiment, the server generates the third image file. Therefore, after step 514, it may also include: creating a corresponding third image file based on the target version.

Exemplarily, a corresponding third image file is created based on the second image file in the second image. At this time, the third image file corresponds to the target version of the second image file, that is, the third image file contains the second image file corresponding to the target version. The second snapshot name of the snapshot.

Optionally, seed files of the second image file and the third image file are respectively created for the terminal to download. It is understandable that when the terminal downloads the image for the first time and the downloaded image is the second image, the server passes the hard disk in the version directory. The link can find the first image file and send the seed file of the first image file to the terminal for use by the terminal.

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

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 is currently based on the initialized The second image file updates the image metadata in the image record of the second image.

Optionally, during the cloning process, the second image may contain multiple states to indicate the current clone node of the second image through different states. In one embodiment, the image record and version directory of the second image are generated according to the image cloning instruction. When, it also includes: marking the second image as waiting for cloning. When updating the image metadata in the image record of the second image, it also includes: marking the second image as a completed clone state.

Among them, the waiting clone state (waiting) refers to the state waiting for cloning to start, and the completed clone state (ready) refers to the state when the clone is completed and can be used. In addition, the cloning status (copy) can also be included, which means that cloning is in progress. Optionally, when generating the image record and version directory of the second image, mark the second image as waiting for cloning, and when copying the second image file in the first image to the version directory, mark the second image as waiting for cloning. When changing to the cloning state and updating the image metadata in the image record of the second image, the cloning state of the second image is changed to the completed cloning state.

The following is an exemplary description of the image cloning process. Figure 12 is an image cloning flow chart provided by an embodiment of the present application. Referring to Figure 12, after starting, first create the image metadata, which is the image metadata of the new image obtained after cloning, and generate the image record, initial version record and initial version directory of the new image. At this time, the new image In waiting state (waiting). After that, create a hard link to the BaseImage of the source image (the cloned image) in the initial version directory. Then, copy the LowerImage of the source image to the initial version directory, initialize the copied LowerImage, and retain the target version. After that, based on LowerImage creates UpperImage, creates seed files for LowerImage and UpperImage respectively, updates the image record in the image table, and changes the new image to the clone completion status to complete the image cloning.

As mentioned above, when there is a need for image cloning on the first terminal or server, you only need to copy the second image file and create an image record. The first image file can be added to the new image through a hard link. No need to Copying saves server disk space and improves the efficiency and speed of image cloning.

It is understandable that there is no need to modify the BaseImage during image merging, image restoration, and image cloning, which ensures the security of the BaseImage and avoids repeated downloading of the BaseImage by the terminal.

In one embodiment of the present application, in addition to a server, the image management device can also be an image management terminal. The terminal can also be considered as a terminal for users. The terminal can be a personal computer, a tablet computer, an interactive tablet, a mobile phone, etc. There are currently no restrictions. The terminal implements a cloud desktop by running a virtual machine. The image required when the terminal is running can be obtained from the server. At this time, after the terminal cooperates with the server, the image management method can be implemented. In one embodiment, the first terminal is taken as an example to describe how the terminal performs the image management method.

Figure 13 is a flow chart of an image management method provided by an embodiment of the present application. Referring to Figure 13, when the first terminal executes the image management method, it may include:

Step 610: Send the first download request to the server of the cloud desktop.

Exemplarily, the first terminal applies 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.

After generating the first download request, the first terminal sends the first download request to the server.

When the second image file can be downloaded through the first download request, step 620 is executed. When the second image file and the corresponding third image file can be downloaded through the first download request, step 650 is executed.

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.

Step 630: Use the received second image file to replace the original local second image file.

Optionally, the new second image file sent by the server is used as the second image file for local use. At this time, the first terminal considers that the version has been changed. Optionally, the initial second image file can always be saved locally, and other versions of the second image file can be saved in the first terminal or deleted in the first terminal as versions are replaced.

Step 640: Create a corresponding third image file based on the setting of the second snapshot in the received second image file. The first image also includes a third image file. The third image file records that the cloud desktop is setting the second snapshot. Data added when running in the state.

For example, the latest second snapshot in the received second image file is used as the set second snapshot, and a corresponding third image file is created locally based on the set second snapshot. After that, run the cloud desktop.

Step 650: When the first download request is used to download the new second image file and the corresponding third image file from the server, receive the new second image file and the third image file sent by the server, and the third image file is based on the new The second snapshot is generated based on the settings in the second image file.

Step 660: Use the received second image file to replace the original local second image file.

As mentioned 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. There is no need to obtain the first image file, which solves the problem in the related technology that the server delivers the image file to The terminal needs to consume more network resources due to technical issues. Moreover, since the third image file is a blank file after creation, even if the corresponding third image file needs to be downloaded, it only takes up very few network resources, ensuring the rational use of network resources.

In one embodiment of the present application, the first terminal can submit the newly added data during the operation of the local cloud desktop to the second image file for version upgrade (ie, image merging). At this time, the first terminal executes the image management method When running, it may also include: running the cloud desktop based on the local existing first image file, second image file and corresponding third image file, and writing the newly added data into the third image file during the running 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.

For example, when the first terminal starts the virtual machine, it needs to have the first image file, the second image file and the third image file, and the virtual machine is started directly based on the third image file, without merging the three types of files, and in the virtual machine When the cloud desktop is running on the computer, the newly added data is recorded in the third image file. If the user needs to create a restore point for the current running status while running the cloud desktop, that is, create a new version, the user can send the currently used third image file to the server and instruct the server to merge the images. The server will follow the instructions. Submit the third image file to the corresponding second image file. After that, the server notifies the first terminal that the merger is completed. The first terminal can generate a first download instruction based on the server's notification to download the second snapshot corresponding to the created restore point. the second image file, and create or download the corresponding third image file from the server based on the actual situation.

It is understandable that since the third image file is used to write new data, when the user of the first terminal wants to give up modifying the cloud desktop, he only needs to delete the current third image file and rebuild the third image. file or obtain the third image file from the server, which simplifies the image restoration process in the first terminal.

As mentioned above, during the running process, the first terminal writes the newly added data to the third image file and does not modify the first image file and the second image file. Therefore, when creating a new version, only the local third image file needs to be Once the three image files are uploaded to the server, a new version can be created in the server, which greatly reduces the amount of uploaded data and improves upload efficiency.

In one embodiment of the present application, the first terminal can also synchronize the second image file used locally to the second terminal to run the cloud desktop in the first terminal in the second terminal. At this time, the first terminal executes the image The management method may also include: receiving a synchronization request sent by the second terminal, and the second terminal uses the same first image file as the first terminal; sending the locally existing second image file to the second terminal, so that the second terminal The second terminal uses the received second image file to replace the original second image file.

For example, the second terminal can be a terminal that implements physical cloud desktop drift, that is, the cloud desktop used by the first terminal is moved 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. Replaces the currently used first terminal.

In one embodiment, the second terminal has run the cloud desktop and has stored the first image file and the second image file. At this time, the first terminal can send its second image file to the second terminal. After that, the second terminal Use the received second image file to replace its own second image file to ensure that the cloud desktop in the first terminal runs. In one embodiment, the second terminal has not run Cloud Desktop. At this time, the second terminal can first download the files of each layer contained in the first image from the server, and then replace its own second image with the received second image file. document.

Optionally, when creating the 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.

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 to the second terminal through the server. When sending to the second terminal through the server, if a third image file needs to be generated, the second image file and the generated third image file can be sent to the second terminal together.

Optionally, after the second terminal is synchronized, it can be recorded in the server so that the server can know the image version currently used by the second terminal.

As mentioned 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.

It can be understood that technical details not mentioned in the above process can refer to the relevant descriptions in the foregoing embodiments, and have corresponding functions and beneficial effects.

Figure 14 is a schematic structural diagram of an image management device provided by an embodiment of the present application. The image management device is applied to a server. Referring to Figure 14, the image management device includes: a first receiving unit 701, a first sending unit 702 and a second sending unit 703.

The first receiving unit 701 is configured to receive a first download request sent by a first terminal. The first terminal applies a first image. The first image includes a first image file and a second image file. The first image file records the first terminal. The operating system used by Zhongyun Desktop, the second image file records device drivers and applications installed based on the operating system; the first sending unit 702 is used to download a new second image from the server when the first download request is made file, sending the new second image file to the first terminal, so that the first terminal uses the received second image file to replace the local original second image file and based on the settings in the received second image file. The snapshot creates a third image file corresponding to the first image. The first image also contains the third image file. The third image file records the data newly added when the cloud desktop is running in the state of setting the second snapshot; the second sending unit is used for When the first download request is used to download the 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 uses the receive The second image file replaces 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.

In one embodiment, 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 corresponding first snapshot. The second snapshot name of the second snapshot.

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

In one embodiment, the first image is recorded in the server with at least one image branch, each image branch includes at least one version, and the first terminal applies one image branch of the first image.

In one embodiment, the method further includes: a first acquisition unit, used to acquire the first image file and a second image file; a first linking unit, used to convert the first image file and the second image file are respectively hard-linked to the first image; the second link unit is used to 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 respectively. Go to the version directory and get the first image.

In one embodiment, the method 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 respectively.

In one embodiment, the first link unit is also used to: create a mirror record of the first mirror, and add the mirror metadata of the first mirror to the mirror record; the second link unit is also used to: create an initial second snapshot corresponding to version record, and record the version metadata of the corresponding version of the initial second snapshot in the version record.

In one embodiment, the system further includes: a second receiving unit for receiving the third image file uploaded by the first terminal; a second obtaining unit for obtaining the current version ID of the first image in the first terminal; and a first search unit. , used to find the second image file corresponding to the version ID; the submission unit is used to submit the third image file to the second image file to obtain a new second image file; the second creation unit is used to create a new second image file in the new image file. Create a new second snapshot in the second image file.

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

In one embodiment, the submission unit includes: a first restoration sub-unit, used to restore the second image file to the second snapshot corresponding to the third image file; a renaming sub-unit, used to restore the restored second image file Renaming is performed so that the second image file uses the second snapshot name of the second snapshot; the file submission subunit is used to submit the third image file to the renamed second image file.

In one embodiment, the first image is recorded in the server with a corresponding snapshot list, 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, configured to After creating a new second snapshot in the new second image file, update the snapshot list and update the image metadata in the image record.

In one embodiment, the method further includes: a third receiving unit, configured to receive an image restoration instruction; a third acquisition unit, configured to obtain the version ID to be restored according to the image restoration instruction; and a second search unit, configured to search according to the version ID. The corresponding second image file and the corresponding second snapshot name; the second restoration unit is used to restore the second image file to the corresponding second snapshot according to the second snapshot name.

In one embodiment, the method 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; a fourth creation Unit used to create a new third image file based on the second snapshot restored to.

In one embodiment, the method further includes: a fourth receiving unit, configured to receive an image cloning instruction, which is used to clone the first image; and a cloning unit, configured to clone the first image according to the first image file and the second image contained in the first image. The file is cloned to obtain a second image, and the second image is the cloned image.

In one embodiment, the cloning unit includes: a generation subunit, configured to generate an image record and a version directory of the second image according to the image cloning instruction, and the image metadata of the first image is recorded in the image record of the second image; a third link The subunit is used to create a hard link to the first image file in the first image in the version directory; the copy subunit is used to copy the second image file in the first image to the version directory; the third deletion subunit is, It is used to retain the target version and delete other versions in the copied second image file. The target version is determined by the image clone instruction; the second update subunit is used to update the image metadata in the image record of the second image.

In one embodiment, the generation subunit is also used to mark the second image as waiting for cloning; the second update subunit is also used to mark the second image as cloning completed.

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.

Figure 15 is a schematic structural diagram of an image management device provided by an embodiment of the present application. The image management device is applied to a first terminal. The first terminal applies 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. Second mirror The file records device drivers and applications installed based on the operating system. Referring to Figure 15, the image management device includes: a third sending unit 801, a first download unit 802, a first replacement unit 803, a first creation unit 804, a second Download unit 805 and second replacement unit 806.

The third sending unit 801 is used to send the first download request to the server of the cloud desktop; the first download unit 802 is used to receive the 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 second image file; the first replacement unit 803 is used to replace the local original second image file with the received second image file; the first creation unit 804 is used to based on the settings in the received second image file The second snapshot creates a corresponding third image file. The first image also includes a third image file. The third image file records the data newly added when the cloud desktop is running in the state of setting the second snapshot; the second download unit 805 , used when the first download request is used to download a new second image file and the corresponding third image file from the server, and receive the new second image file and the third image file sent by the server, and the third image file is based on The second snapshot of the settings in the new second image file is generated; the second replacement unit 806 is configured to replace the original local second image file with the received second image file.

In one embodiment, it also includes: an operating unit, configured to run the cloud desktop based on the local existing first image file, the second image file and the corresponding third image file, and write the newly added data during the operation process. Enter the third image file; the upload unit is used to upload the third image file to the server, so that the server submits the third image file to the corresponding second image file.

In one embodiment, the method further includes: a fifth receiving unit, configured to receive a synchronization request sent by a second terminal, which uses the same first image file as the first terminal; and a fourth sending unit, configured to transfer the local existing The second image file is sent to the second terminal, so that the second terminal uses the received second image file to replace the original second image file.

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.

It is worth noting that in the above embodiment of the image 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 realized; in addition, each unit and module is not limited to the above division. The specific names of the functional units are only for the convenience of distinguishing each other and are not used to limit the scope of protection of the present application.

Figure 16 is a schematic structural diagram of an image management device provided by an embodiment of the present application. The image management device may be an image management server or an image management terminal. As shown in Figure 16, the image management device includes a processor 90, a memory 91 and a communication module 92; the number of processors 90 can be one or more, and one processor 90 is taken as an example in Figure 16. The processor 90, the memory 91 and the communication module 92 in the image management device can be connected through a bus or other means. In Figure 16, connection through a bus is taken as an example.

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

The memory 91 may mainly include a stored program area and a stored data area, wherein the stored program area may store an operating system and at least one application program required for a function; the stored data area may store data created according to the use of the image management device, etc. In addition, the memory 91 may include high-speed random access memory, and may also include non-volatile memory, such as at least one magnetic disk storage device, flash memory device, or other non-volatile solid-state storage device. In some examples, the memory 91 may further include memory located remotely relative to the processor 90 , and these remote memories may be connected to the image management device through a network. Examples of the above networks include but Not limited to the Internet, intranet, local area network, mobile communication network and combinations thereof.

The communication device 92 is used to implement data communication according to instructions of the processor. For example, when the image management device is a server, it can perform data communication with the terminal. If the image management device is a terminal, it can perform data communication with the server. The image management device may also include an input device and an output device. The input device may be used to receive input numeric or character information and generate key signal input related to user settings and function control of the image management device. It may also include audio input devices such as microphones. . Output devices may include displays, speakers, and other devices.

The above image management device includes a corresponding image management device, which can be used to execute the corresponding image management method provided by any embodiment, and has corresponding functions and beneficial effects.

In addition, one embodiment of the present application also provides a storage medium containing computer-executable instructions. When executed by a computer processor, the computer-executable instructions are used to perform relevant aspects of the image management method provided by any embodiment of the present application. operation, and has corresponding functions and beneficial effects.

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

Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment that combines software and hardware aspects. Furthermore, the present application may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein. The present application is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the application. It will be understood that each process and/or block in the flowchart illustrations and/or block diagrams, and combinations of processes and/or blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing device to produce a machine, such that the instructions executed by the processor of the computer or other programmable data processing device produce a use A device for realizing the functions specified in one process or multiple processes of the flowchart and/or one block or multiple blocks of the block diagram. These computer program instructions may also be stored in a computer-readable memory that causes a computer or other programmable data processing apparatus to operate in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including the instruction means, the instructions The device implements the functions specified in a process or processes of the flowchart and/or a block or blocks of the block diagram. These computer program instructions may also be loaded onto a computer or other programmable data processing device, causing a series of operating steps to be performed on the computer or other programmable device to produce computer-implemented processing, thereby executing on the computer or other programmable device. Instructions provide steps for implementing the functions specified in a process or processes of a flowchart diagram and/or a block or blocks of a block diagram.

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

Computer-readable media includes both persistent and non-volatile, removable and non-removable media that can be implemented by any method or technology for storage of information. Information may 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), and read-only memory. (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, Magnetic tape cassettes, tape magnetic disk storage or other magnetic storage devices or any other non-transmission medium can be used to store information that can be accessed by a computing device. As defined in this article, computer-readable media does not include transitory media, such as modulated data signals and carrier waves.

It should also be noted that the terms "comprises,""comprises," or any other variation thereof are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that includes a list of elements not only includes those elements, but also includes Other elements not expressly listed or included for the process, method, business factors inherent in the product or equipment. Without further limitation, an element qualified by the statement "comprises a..." does not exclude the presence of additional identical elements in the process, method, good, or device that includes the element.

Note that the above are only the preferred embodiments of the present application and the technical principles used. Those skilled in the art will understand that the present application is not limited to the specific embodiments described herein, and that various obvious changes, readjustments and substitutions can be made by those skilled in the art without departing from the scope of the present application. Therefore, although the present application has been described in detail through the above embodiments, the present application is not limited to the above embodiments, and may also include more other equivalent embodiments without departing from the concept of the present application, and the present application The scope is determined by the scope of the appended claims.

Claims

An image management method, applied to servers, is characterized by including:

Receive a first download request sent by a first terminal, the first terminal applies a first image, the first image includes a first image file and a second image file, the first image file records the first terminal The operating system used by Zhongyun Desktop, the second image file records device drivers and applications installed based on the operating system;

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 uses the received second image file. The file replaces the local original 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 is The third image file records data newly added when the cloud desktop is running in the state of setting the 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 third image file. A terminal, so that the first terminal uses the received second image file to replace the local original second image file, and the third image file is generated based on the second snapshot of the settings in the new second image file. .
The image management method according to claim 1, wherein the first image file contains a unique first snapshot, and the second image file contains a first snapshot name of the first snapshot;

The second image file includes at least one second snapshot, and the third image file includes a second snapshot name of the corresponding second snapshot.
The image management method according to claim 2, characterized in that the first image is recorded in the server with at least one version, and each version corresponds to a second snapshot in the second image file and is associated with Each version of 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 has a corresponding version ID.
The image management method according to claim 3, characterized in that the first image is recorded in the server with at least one image branch, each of the image branches contains at least one version, and the first terminal application A mirror branch of the first mirror.
The image management method according to claim 3, further comprising:

Obtain the first image file and the second image file;

Hard link the first image file and the second image file to the first image respectively;

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.
The image 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, it further includes:

Create a corresponding third image file based on the initial second snapshot.
The image 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, it further includes:

Create a mirror record of the first mirror, and add mirror metadata of the first mirror to the mirror record;

When creating the corresponding version directory based on the initial second snapshot of the second image file, it also includes:

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.
The image management method according to claim 3, further comprising:

Receive the third image file uploaded by the first terminal;

Obtain the current version ID of the first image in the first terminal;

Find 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.
The image management method according to claim 8, characterized in that after creating a new second snapshot in the new second image file, it further includes:

Delete the third image file;

Create a new third image file based on the new second snapshot.
The image management method according to claim 8, wherein said 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 the second image file uses the second snapshot name of the second snapshot;

Submit the third image file to the renamed second image file.
The image management method according to claim 9, characterized in that the first image is recorded in the server with a corresponding snapshot list, and the snapshot list records each version of the first image and each of the The second snapshot corresponding to the version;

After creating a new second snapshot in the new second image file, the method further includes:

Update the snapshot list and update the image metadata in the image record.
The image management method according to claim 3, further comprising:

Receive image restore instructions;

Obtain the version ID to be restored according to the image restoration instruction;

Search the corresponding second image file and the corresponding second snapshot name according to the version ID;

According to the second snapshot name, the second image file is restored to the corresponding second snapshot.
The image management method according to claim 12, characterized in that after restoring the second image file to the corresponding second snapshot according to the second snapshot name, it further includes:

Delete the third image file corresponding to the second image file;

Create a new tertiary image file based on the restored second snapshot.
The image management method according to claim 3, further comprising:

Receive an image cloning instruction, which is used to clone the first image;

A second image is obtained by cloning the first image file and the second image file included in the first image, and the second image is a cloned image.
The image management method according to claim 14, wherein cloning the first image file and the second image file included in the first image to obtain the second image includes:

According to the image cloning instruction, generate an image record and a version directory of the second image, and record the image metadata of the first image in the image record of the second image;

Create a hard link to the first image file in the first image in the version directory;

Copy the second image file in the first image to the version directory;

Keep the target version in the copied second image file and delete other versions, where the target version is determined by the image cloning instruction;

Update the image metadata in the image record of the second image.
The image 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, it further includes:

Mark the second image as waiting for cloning;

When updating the image metadata in the image record of the second image, it also includes:

Mark the second image as clone complete.
An image management method, applied to a first terminal, characterized in that the first terminal applies a first image, the first image includes a first image file and a second image file, and 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 methods include:

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, receive the new second image file sent by the server;

Use the received second image file to replace the local original second image file;

Create 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. The third image file records the location of the cloud desktop. The data added when running in the second snapshot state is set as described above;

When the first download request is used to download a new second image file and the corresponding third image file from the server, receive the new second image file and the third image file sent by the server , the third image file is generated based on the set second snapshot in the new second image file;

Use the received second image file to replace the local original second image file.
The image management method according to claim 17, further comprising:

Run the cloud desktop based on the local existing first image file, second image file and corresponding third image file, and during the operation process, write new data into the third image file;

Upload the third image file to the server, so that the server submits the third image file to the corresponding second image file.
The image management method according to claim 17, further comprising:

Receive a synchronization request sent by a second terminal, where the second terminal and the first terminal use the same first image file;

Send the locally existing second image file to the second terminal, so that the second terminal uses the received second image file to replace the original second image file.
An image management device, applied to servers, is characterized by including:

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

A first sending unit, 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 The terminal uses the received second image file to replace the local original 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. Three image files, the third image file records data newly added when the cloud desktop is running in the state of setting the second snapshot;

A second sending unit configured to, when the first download request is used to download a new second image file and the corresponding third image file from the server, send the new second image file and the corresponding third image file to the server. The image file is sent to the first terminal, so that the first terminal uses the received second image file to replace the local original second image file, and the third image file is based on the new second image file. The second snapshot of the settings is generated.
An image management device, applied to a first terminal, characterized in that the first terminal applies a first image, the first image includes a first image file and a second image file, and 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:

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

A first download unit configured to receive the 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 is used to replace the original local second image file with the received second image file;

A first creation unit configured to create a corresponding third image file based on the set second snapshot in the received second image file, where the first image also includes the third image file, and the third image file records There is data newly added when the cloud desktop is running in the state of setting the second snapshot;

A second download unit configured to receive the new second 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. and the third image file, 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 original local second image file with the received second image file.
An image management server, which is characterized by including:

Communication module, 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 are caused to implement the image management method as described in any one of claims 1-16.
An image management terminal is characterized by including:

Communication module, 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 are caused to implement the image management method as described in any one of claims 17-19.
A computer-readable storage medium with a computer program stored thereon, characterized in that when the program is executed by a processor, the image management method as described in any one of claims 1-16 is implemented or the image management method as claimed in claims 17-19 is implemented The image management method described in any one of the above.