CN116954681A

CN116954681A - Mirror image management method, device, server, terminal and storage medium

Info

Publication number: CN116954681A
Application number: CN202210385398.XA
Authority: CN
Inventors: 龙小斌
Original assignee: Guangzhou Shiyuan Electronics Thecnology Co Ltd; Guangzhou Shirui Electronics Co Ltd
Current assignee: Guangzhou Shiyuan Electronics Thecnology Co Ltd; Guangzhou Shirui Electronics Co Ltd
Priority date: 2022-04-13
Filing date: 2022-04-13
Publication date: 2023-10-27
Also published as: WO2023197862A1

Abstract

The embodiment of the application discloses a mirror image management method, a device, a server, a terminal and a storage medium, which comprise the following steps: receiving a first downloading request sent by a first terminal, wherein the first terminal uses a first image file and a second image file, the first image file records an operating system used by a cloud desktop in the first terminal, and the second image file records a device driver and an application program which are installed based on the operating system; and 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 records newly added data when the cloud desktop runs in a state of setting the second snapshot in a third image file, wherein the third image file is generated based on the set second snapshot in the new second image file, and the third image file can be generated by the server or the first terminal. The method can solve the technical problem that the server needs to consume more network resources when sending the image file to the terminal in the related technology.

Description

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

Technical Field

The embodiment of the application relates to the technical field of cloud desktops, in particular to a mirror image management method, a device, a server, a terminal and a storage medium.

Background

The cloud desktop is also called desktop virtualization and cloud computer, is a new mode for replacing the traditional computer, and performs virtualization treatment on various physical devices by using a virtual technology, so that the utilization rate of resources is effectively improved, the cost is saved, and the application quality is improved.

Smart desktop virtualization (Intelligent Desktop Virtualization, IDV) is a common type of cloud desktop. The IDV adopts distributed computation and distributed storage, has the characteristics of centralized management and local execution, namely utilizes the local computation and storage resources of the terminal, so that even if the network connected with the server has a problem, the normal use of the cloud desktop can be ensured.

When the IDV is applied, an image file of the cloud desktop needs to be distributed to the terminal, and contents such as an operating system, a device driver, an application program and the like required by running the cloud desktop are recorded in the image file. In general, when an image file is updated, the content of the record of the image file needs to be updated, and at this time, the server needs to resend the updated image file to the terminal. However, the image file has a larger memory, and when the image file is updated more frequently, the image file needs to be frequently issued to the terminal, which requires more network resources to be consumed.

Disclosure of Invention

An embodiment of the application provides a mirror image management method, a device, a server, a terminal and a storage medium, which are used for solving the technical problem that a server needs to consume more network resources when issuing mirror image files to the terminal in the related art.

In a first aspect, an embodiment of the present application provides a method for managing images, applied to a server, including:

receiving a first downloading request sent by a first terminal, wherein the first terminal applies a first mirror image, the first mirror image comprises a first mirror image file and a second mirror image file, the first mirror image file records an operating system used by a cloud desktop in the first terminal, and the second mirror image file records a device driver and an application program which are installed based on the operating system;

when the first downloading request is used for downloading 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 to replace a local original second image file and creates a corresponding third image file based on a set second snapshot in the received second image file, the first image also comprises the third image file, and the third image file records newly added data when the cloud desktop runs in the state of the set second snapshot;

And when the first downloading request is used for downloading a new second image file and the corresponding third image file from the server, the new second image file and the third image file are sent to the first terminal, so that the first terminal uses the received second image file to replace the local original second image file, and the third image file is generated based on a set second snapshot in the new second image file.

In a second aspect, an embodiment of the present application further provides a method for managing an image, where the method is applied to a first terminal, where the first terminal applies a first image, where the first image includes a first image file and a second image file, where the first image file records an operating system used by a cloud desktop in the first terminal, and the second image file records a device driver and an application installed based on the operating system, and the method includes:

sending a first downloading request to a server of the cloud desktop;

when the first downloading request is used for downloading a new second image file from the server, receiving the new second image file sent by the server;

replacing the local original second image file with the received second image file;

Creating a corresponding third image file based on a set second snapshot in the received second image file, wherein the first image further comprises the third image file, and the third image file records newly added data of the cloud desktop when the cloud desktop runs in the state of the set second snapshot;

when the first downloading request is used for downloading a new second image file and the corresponding third image file from the server, receiving the new second image file and the third image file sent by the server, wherein the third image file is generated based on a set second snapshot in the new second image file;

and replacing the original second image file locally by using the received second image file.

In a third aspect, an embodiment of the present application further provides a mirror management apparatus, applied to a server, including:

the first receiving unit is used for receiving a first downloading request sent by a first terminal, the first terminal applies a first mirror image, the first mirror image comprises a first mirror image file and a second mirror image file, the first mirror image file records an operating system used by a cloud desktop in the first terminal, and the second mirror image file records a device driver and an application program which are installed based on the operating system;

A first sending unit, configured to send a new second image file to the first terminal when the first download request is used to download the new second image file from the server, so that the first terminal uses the received second image file to replace a local original second image file and creates a corresponding third image file based on a set second snapshot in the received second image file, where the first image further includes the third image file, and the third image file records newly added data when the cloud desktop runs in the state of the set second snapshot;

and the second sending unit is used for sending the new second image file and the third image file to the first terminal when the first downloading request is used for downloading the new second image file and the corresponding third image file from the server, 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 a set second snapshot in the new second image file.

In a fourth aspect, an embodiment of the present application further provides an image management apparatus applied to a first terminal, where 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 an operating system used by a cloud desktop in the first terminal, and the second image file records a device driver and an application program installed based on the operating system, and the apparatus includes:

The third sending unit is used for sending a first downloading request to a server of the cloud desktop;

a first downloading unit, configured to receive a new second image file sent by the server when the first downloading request is used to download the new second image file from the server;

the first replacing unit is used for replacing the local original second image file by using the received second image file;

the first creating unit is used for creating a corresponding third image file based on a set second snapshot in the received second image file, the first image also comprises the third image file, and the third image file records newly added data of the cloud desktop when the cloud desktop runs in the state of the set second snapshot;

a second downloading unit, configured to, when the first downloading 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, where the third image file is generated based on a set second snapshot in the new second image file;

and the second replacing unit is used for replacing the original second image file locally by using the received second image file.

In a fifth aspect, an embodiment of the present application further provides a mirror management server, including:

the communication module is used for realizing data communication;

one or more processors;

a memory for storing one or more programs;

the one or more programs, when executed by the one or more processors, cause the one or more processors to implement the image management method as described in the first aspect.

In a sixth aspect, an embodiment of the present application further provides a mirror management terminal, including:

the communication module is used for realizing data communication;

one or more processors;

a memory for storing one or more programs;

the one or more programs, when executed by the one or more processors, cause the one or more processors 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, which when executed by a processor implements the image management method according to the first aspect or the image management method according to the second aspect.

In one embodiment of the application, the server receives the first downloading request sent by the first terminal, and issues the second image file of the first image center to the first terminal based on the first downloading request, so that the first terminal uses the new second image file to replace the local second image file, and further the first terminal uses the new second image file when the first terminal operates the cloud desktop, and the newly added data in the operation process of the first terminal is written into the third image file corresponding to the new second image file, thereby solving the technical problem that the server issues the image file to the terminal in the related art, and more network resources are required to be consumed. By dividing the image into three levels of files, and when the first terminal downloads the new image file, the server does not need to issue all image files, only needs to issue the second image file, thereby reducing the memory of the downloaded file, saving network resources and reducing the downloading time. And because the third image file is a blank file after being created, even if the corresponding third image file needs to be issued, only a small amount of network resources are occupied, and the reasonable use of the network resources is ensured.

Drawings

FIG. 1 is a first schematic diagram of a related art image file distribution process;

FIG. 2 is a second schematic diagram of a mirrored file distribution process in the related art;

FIG. 3 is a schematic diagram of a mirror relationship according to an embodiment of the present application;

FIG. 4 is a flowchart of a method for managing images according to an embodiment of the present application;

FIG. 5 is a flowchart of a method for managing images according to an embodiment of the present application;

FIG. 6 is a flow chart of image registration according to one embodiment of the present application;

FIG. 7 is a flowchart of a method for managing images according to an embodiment of the present application;

FIG. 8 is a flow chart of a mirror image merge process according to one embodiment of the present application;

FIG. 9 is a flowchart of a method for managing images according to an embodiment of the present application;

FIG. 10 is a flow chart of a mirror image restoration according to an embodiment of the present application;

FIG. 11 is a flowchart of a method for managing images according to an embodiment of the present application;

FIG. 12 is a flow chart of a mirrored cloning according to one embodiment of the present application;

FIG. 13 is a flowchart of a method for managing images according to an embodiment of the present application;

FIG. 14 is a schematic diagram of a mirror management device according to an embodiment of the present application;

FIG. 15 is a schematic diagram of a mirror management device according to an embodiment of the present application

Fig. 16 is a schematic structural diagram of a mirror management device according to an embodiment of the present application.

Detailed Description

The application is described in further detail below with reference to the drawings and examples. It is to be understood that the specific embodiments described herein are for purposes of illustration and not of limitation. It should be further noted that, for convenience of description, only some, but not all of the structures related to the present application are shown in the drawings.

Under IDV type, two schemes can be included when distributing image files to guests (end users):

scheme one: fig. 1 is a first schematic diagram of an image file distribution process in the related art. Referring to fig. 1, when a terminal (i.e., a terminal user) has a need to download an image file, a download request is sent to a server, after the server determines that the download request is legal, a base image file is sent to the terminal, and then the terminal starts a virtual machine based on the base image file to run a cloud desktop. The terminal is customized based on the basic image file, and personalized data of the terminal can be added in the running process.

Scheme II: fig. 2 is a second schematic diagram of an image file distribution process in the related art. Referring to fig. 2, when a terminal has a need of downloading an image file, a download request is sent to a server, after the server determines that the download request is legal, the server sends a differential image file to the terminal, the terminal merges the differential image file into a basic image file, and then the terminal starts a virtual machine based on the basic image file to operate a cloud desktop. The differential image file refers to an image file obtained by utilizing a differential technology.

Generally, when a cloud desktop is operated based on an image file, the image file needs to be updated in the process of managing the image file, for example, after the image file is updated by a server, the image file needs to be updated. For another example, when the terminal uses the cloud desktop, after the terminal fills the personalized data into the image file, the image file needs to be updated. At this time, when the scheme one distributes the image file, after the server upgrades and updates the image file, all terminals using the image file need to download the image file again regardless of the changed size, thus a large amount of network resources are required to be consumed, a longer downloading time is required, and unified updating of the image file by the terminals is not facilitated. When the scheme II is used, only the updated differential image file can be downloaded, so that although the data downloading amount is reduced, the differential image file merging time is increased at the terminal, and the base image file needs to be locally backed up to prevent the base image file from being damaged due to the power failure and other conditions in the merging process. Therefore, the processing time of the terminal to the image file is increased, and the local storage space of the terminal is wasted. In addition, no matter the scheme I or the scheme II is used, after the manager modifies the image file at the terminal, the manager needs to submit the image file to the server first so that the server can send the modified image file to each terminal using the image file, thus not only downloading the complete image file at each terminal, but also uploading the complete image file at the terminal used by the manager, increasing network resources and time consumption for transmission required in the downloading and uploading processes, and being unfavorable for management of the image file by the server. At this time, due to the limitation of public network bandwidth, the popularization and application of the IDV type cloud desktop are also greatly hindered.

In summary, when the mirror image file is used to run the IDV type cloud desktop, how to ensure reasonable use of network resources and save time for transmission during management of the mirror image file becomes a technical problem to be solved urgently.

Accordingly, the embodiment of the application provides a mirror image management method, a device, a server, a terminal and a storage medium, so that reasonable utilization of network resources is ensured and transmission time is saved when mirror image file management is performed under the scene that the terminal runs an IDV type cloud desktop.

An embodiment of the present application provides a mirroring management method, which may be performed by a mirroring management apparatus, where the mirroring management apparatus may be configured by two or more physical entities or may be configured by one physical entity.

In one embodiment, the image management device is an image management server (which may also be referred to as a server), and the server may be used as a server of the IDV type cloud desktop, to implement image (image) management, and provide an image file required for running the cloud desktop for the terminal. Currently, the terminal (which may also be denoted as a terminal device, an electronic terminal, etc.) may be any terminal supporting virtualization, such as a personal computer, a tablet, an interactive tablet, a mobile phone, etc. Virtualization generally refers to that computing elements run on a virtual basis rather than a real basis, and virtualization technology can expand the capacity of hardware and simplify the software reconfiguration process. The virtual machine is an expression mode for realizing virtualization, and is a complete computer system which is simulated by software and has complete hardware system functions and operates in a complete isolation environment, and currently, a cloud desktop is operated by a terminal.

The image (image) may also be recorded as an image file, which is a file on which the terminal depends when starting up the virtual machine. In one embodiment, each image contains three types of image files. The three types of image files can be respectively recorded as: baseImage, lowerIamge and UpperImage.

The BaseImage records an operating system, which is used by the cloud desktop. Currently, baseImage records pure operations without application programs and additional device drivers in the operating system. Each image may have a separate BaseImage, or multiple images may share the same BaseImage. When a plurality of images share the same BaseImage, baseImage is used for the images in a hard link mode, so that the storage space of a server can be saved. Where hard linking refers to one or more file names of a file, i.e., multiple file names are used to link to the same file, the file names may be in the same directory or different directories. Optionally, when the terminal runs the cloud desktop, the BaseImage may be read, but not modified, so as to protect the BaseImage from being damaged.

The LowerImage is a subdisc of the BaseImage, i.e., the LowerImage is created based on the BaseImage and is the next-level file of the BaseImage. The 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, where the LowerImage includes an application program and a device driver that are built in when the terminal under the corresponding model runs an operating system. After that, the user can derive own LowerImage based on the initial LowerImage, and personalized data in the use process of the user, such as a device driver, an application program, a stored file or data and other contents newly installed by the user, exist in the LowerImage. Alternatively, each user may have a separate LowerImage.

The UpperImage is a subdisc of the LowerImage, i.e., the UpperImage is created based on the LowerImage and is the next-level file of the LowerImage. The UpperImage records newly added data when the terminal runs the cloud desktop. Optionally, when the UpperImage is created, the UpperImage may be regarded as a blank file, no data related to the user is recorded, and 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 in the use process of the user in the LowerImage.

At this time, baseImage, lowerIamge and UpperImage can also be considered as three hierarchical files contained in the image.

In one embodiment, the image Snapshot (also referred to as Snapshot or snappshot) refers to a restore point of the image file at a certain moment, that is, the image file may be restored from any state to a state corresponding to the Snapshot (i.e., the restore point). Each snapshot has a corresponding snapshot name whose naming convention is not currently limited, and in general, the snapshot names contain unique identifiers to distinguish the snapshots by snapshot name. Alternatively, both BaseImage, lowerIamge and UpperImage may create a snapshot. Each image file may look up its corresponding snapshot list. For example, the snapshot list corresponding to the loweramage records contents such as the names of all the snapshots contained in the snapshot list, and the loweramage can search for the required snapshot based on the snapshot list.

In one embodiment, a unique snapshot is created in the BaseImage, and loweramage is created based on the state of the BaseImage at the time of the unique snapshot. Optionally, before the loweramage is created, the file name of the BaseImage is changed into the snapshot name of the unique snapshot of the BaseImage, and then when the loweramage is created, the file name of the BaseImage is recorded in the loweramage, so that the snapshot name of the BaseImage is ensured to be accurately recorded in the loweramage, and then the BaseImage corresponding to the loweramage is searched through the snapshot name of the BaseImage.

In one embodiment, multiple snapshots are created in loweramage. Optionally, when a loweramage is created for different terminal models (the original loweramage is the original loweramage), a drive snapshot is created after a device driver built in an operating system is installed in the loweramage, an application snapshot is created after an application program (also called as a basic application) built in the operating system is installed, and the loweramage can be restored to a state when the device driver and the application program are installed respectively through the two snapshots. Optionally, when the loweramage is applied by the terminal, newly added personalized data of the terminal can be written in the loweramage, and a corresponding snapshot can be created based on the written personalized data. In one embodiment, a corresponding upperemage may be created based on a certain snapshot state of lowereamage, i.e., the upperemage corresponds to one snapshot of lowereamage, and the snapshot name of its corresponding snapshot in lowereamage is recorded in the uppereimage, similar to the creation of lowereamage, so as to find the corresponding lowereamage by the snapshot name of lowereamage in the upperemage and determine the corresponding snapshot in lowereamage. Optionally, when a snapshot is created in the lowerlmage, a corresponding upperlmage can be generated, at this time, when the terminal runs the cloud desktop based on the lowerlmage under the snapshot, newly-added data when the cloud desktop is run by taking the snapshot as a node can be written in the upperlmage, then the upperlmage is submitted to the lowerlmage by the server, that is, personalized data under the corresponding snapshot node is written in the lowerlmage, then a new snapshot can be created in the lowerlmage, and a corresponding upperlmage can be created again based on the new snapshot, so that the terminal runs the cloud desktop based on the lowerlmage corresponding to the new snapshot, and the newly-added data is written in the upperlmage. At this time, the terminal is distinguished by taking the snapshot of the lowerlmage, and the newly added data of the terminal is written into the UpperImage corresponding to the snapshot, without modifying the BaseImage and the lowerlmage in the terminal.

In one embodiment, each snapshot in the loweramage corresponds to a version (also referred to as a mirrored version, version), i.e., when a new snapshot is created in the loweramage, it may be considered that a new version is created. For the terminal, different versions of the switching operation can be realized by switching different snapshots of the lowerlamage. Each version has a corresponding version ID, which has uniqueness, and its specific naming rule is not limited at present, and each version also has a corresponding version UUID (i.e., a universally unique identifier of the version). When the terminal runs the cloud desktop, if the version used by the terminal needs to be changed, the terminal only needs to acquire the lowerlamage corresponding to the version from the server (the lowerlamage is a snapshot state corresponding to the version) and use the lowerlamage. It can be understood that when one mirror image is used by a plurality of users, each user has own independent lowerage file based on the consideration of data security, and meanwhile, version data of each user is stored in own lowerage file in a built-in snapshot mode, and the user only allows downloading of own lowerage file. Each version of the same user corresponds to a built-in snapshot in the lowerlamange, the snapshot name of the built-in snapshot is version UUID, and whether the currently corresponding version can be used by the user can be determined through the snapshot name of the built-in snapshot. Alternatively, each version and the snapshot name of the corresponding snapshot may be recorded in association in the snapshot list. Through the version, the corresponding snapshot name can be found, the corresponding loweramage can be found through the snapshot name, the corresponding BaseImage can be found based on the snapshot name of the BaseImage recorded in the loweramage, and the corresponding UpperImage can also be found through the snapshot name corresponding to the version. At this time, the searched BaseImage, lowerIamge and UpperImage may be considered to be associated with the corresponding version. I.e. each version of each mirror has an associated BaseImage, lowerIamge and UpperImage. In one embodiment, each version has a corresponding version record and a version directory, where the version record is used to record content such as metadata of the version (for describing attributes of the version), and the version directory is used to record its associated BaseImage and lowerlamage, and optionally, the version directory may also be recorded as its associated UpperImage. Alternatively, the BaseImage is linked under the version directory in a hard-linked manner, and the BaseImage may be shared between different versions.

In one embodiment, a mirror may have one or more branches (also referred to as mirror version branches, branches), a branch may have one or more versions, and each user using the mirror may have a separate branch. Different images or different branches of the same image may share one BaseImage. For ease of understanding, fig. 3 is a schematic diagram of a mirror relationship provided in an embodiment of the present application, which exemplarily illustrates a relationship among mirrors, branches, and versions, and a relationship between BaseImage, lowerIamge and UpperImage. As shown in fig. 3, one BaseImage may be used by a hard link for multiple images, in fig. 3, the image a includes a branch a, and the image B includes a branch B and a branch c. Branch a is used by user a, which has independent lowerlamage (i.e., lowerlamage a), the lowerlamage a includes snapshot A1 (i.e., snapshuta 1), snapshot A2 (i.e., snapshuta 2) and snapshot A3 (i.e., snapshuta 3), the snapshot A1 corresponds to version 1, the snapshot A2 corresponds to version 2, the snapshot A3 corresponds to version 3, each snapshot can generate a corresponding upperemage, it is understood that fig. 3 is convenient for describing the correspondence between the snapshot and the version, the snapshots included in the lowerlamage a are shown in a dotted line frame, and in practical application, the snapshots are included in the lowerlamage a. In fig. 3, pointing snapshot A1, snapshot A2, and snapshot A3 to UpperImageA means that each snapshot creates a corresponding UpperImage, and not that three snapshots share one UpperImage. The branch B is used by the user B, the branch c is used by the user c, and at this time, the relationship of the snapshot, version and three types of files corresponding to the branch B and the branch c is similar to the branch a, and is not described in detail. Based on the content shown in fig. 3, a file chain can be formed between BaseImage, lowerIamge and UpperImage, so that the disorder of file relationships between different branches can be avoided.

For a terminal, the virtual machine start needs to be provided with BaseImage, lowerIamge and UpperImage at the same time. Moreover, the virtual machine can be started directly based on the UpperImage, and BaseImage, lowerIamge and UpperImage do not need to be combined into one file.

The server also stores a mirror image table (osseigs), in which a plurality of mirror image records are recorded, each mirror image record corresponds to a mirror image and is used for recording metadata (for describing the attribute of the mirror image) and the like.

BaseImage, lowerIamge and UpperImage stored in the server are available for downloading by the terminal. Optionally, the BaseImage, lowerIamge and UpperImage are downloaded by the terminal in the form of seed files, that is, the server may generate a BaseImage seed file corresponding to the BaseImage, a lowerlamage seed file corresponding to the lowerlamage, and an UpperImage seed file corresponding to the UpperImage, respectively. The seed file refers to a P2P download seed file, and P2P (peer-to-peer) is a peer-to-peer computer network, and after the client downloads the seed file through P2P, the client can obtain a corresponding BaseImage, lowerIamge or UpperImage.

The above-mentioned user refers to a user who uses a terminal, wherein one user may use a different terminal, one terminal may be used by a plurality of users, and each user may be distinguished by a user ID or the like used at the time of login.

In one embodiment, fig. 4 is a flowchart of a method for managing images according to an embodiment of the present application, where when a server executes the method for managing images, the method may include:

step 110, receiving a first downloading request sent by a first terminal, wherein the first terminal applies a first mirror image, the first mirror image comprises a first mirror image file and a second mirror image file, the first mirror image file records an operating system used by a cloud desktop in the first terminal, and the second mirror image file records a device driver and an application program installed based on the operating system.

By way of example, a server is taken as an example to provide services to a terminal, and how the server implements image management is described. Currently, a terminal that a server provides a service is referred to as a first terminal. And recording the mirror image used by the first terminal as a first mirror image, namely, the first terminal runs the cloud desktop through the first mirror image. When the first terminal runs the cloud desktop based on the first mirror image, the BaseImage, lowerIamge and UpperImage used are respectively recorded as a first mirror image file, a second mirror image file and a third mirror image file. Currently, the snapshot in the second image file is denoted as the second snapshot, and the snapshot in the first image file is denoted as the first snapshot. Based on the foregoing, 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 comprises at least one second snapshot, and the third image file comprises a second snapshot name of the corresponding second snapshot. The snapshot names of the first snapshot are named as first snapshot names, and the snapshot names of the second snapshot are named as second snapshot names. The second image file used when the first terminal runs the cloud desktop corresponds to a version, and the third image file used is generated based on a snapshot corresponding to the version in the second image file. The first image records at least one version in the server, each version corresponds to one second snapshot in the second image files and is related to the second image files, the first image files corresponding to the first snapshot names in the second image files and the third image files corresponding to the second snapshots, and each version has a corresponding version ID. Alternatively, the first terminal running the first image may be considered as running a branch of the first image. The first image has at least one image branch recorded in the server, each image branch containing at least one version, and the first terminal applies one image branch of the first image. Alternatively, the first image operated by the terminal may be specifically a version under the image branch, and in this case, the later mentioned first image ID may also be considered as the ID of the image branch in the first image.

Before the first terminal runs the cloud surface for the first time, the first image file and the second image file need to be downloaded from the server, and a third image file is created by combining the actual determination of the first terminal or the third image file is downloaded from the server. Optionally, when the first terminal has a function of creating the third image file, the third image file may 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 send the third image file to the first terminal. And then, the first terminal operates the virtual machine based on the first image file, the second image file and the third image file, and operates the cloud desktop through the virtual machine.

When the first terminal has the version updating requirement, a corresponding downloading request is generated, and a corresponding second image file is acquired from the server based on the downloading request, so that the version updating is realized based on the second image file. Currently, a download request generated by a first terminal is denoted as a first download request. When the first terminal generates the first downloading request, the first image file and the second image file are already stored locally, and the second image file can be recorded with personalized data of the user, or the personalized data of the user can not be added yet.

The manner of generating the first download request is not limited currently, for example, when the server determines that the version of the second image file is updated (i.e., a new version is generated), a notification of the version update is sent to the first terminal using the second image file, and then, the user of the first terminal may determine whether to update the version based on the notification, and when determining the updated version, generate the first download request and send the first download request to the server. For another example, when a user of the first terminal has a version update requirement, a first downloading request is generated and sent to the server. For another example, when the user of the first terminal confirms that the restore point (i.e. snapshot) needs to be created based on the current running state of the cloud desktop, uploading a third image file of the current record newly added data to the server, submitting the third image file to the second image file by the server, creating a corresponding snapshot and version, i.e. updating the version of the second image file, at this time, the server can complete the creation of the restore point through the first terminal, and then the first terminal generates a first download request and sends the first download request to the server, or the first terminal generates the 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, the first download request is divided into two types in combination with whether the first terminal has the function of creating the third image file, wherein one type is used for downloading the second image file from the server, and at this time, the first terminal can create the third image file locally based on the second image file, and the other type is used for downloading the second image file and the third image file from the server. It will be appreciated that, when the first terminal has the function of creating the third image file first, the third image file may be downloaded from the server.

After receiving the first download request, the server parses the first download request, and when determining that the server is used to download the second image file, performs step 120, and when determining that the server is used to download the second image file and the third image file, performs 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 according to the identifier. Optionally, the server pre-records a terminal model capable of locally generating the third image file, when the first terminal generates the first downloading request, the terminal model of the first terminal is written in the first downloading request, and the server determines whether the third image file needs to be sent according to the terminal model in the first downloading request.

It should be noted that two different processing manners are described by taking the example that the first terminal includes the function of creating the third image file and does not include the function of creating the third image file. In practical applications, all terminals served by the server may have a function of creating the third image file, where the first download request is only used to download the new second image file from the server, or none of the terminals served by the server has a function of creating the third image file, where the first download request is only used to download the new second image file and the corresponding third image file from the server. In practical applications, the server may generate the third image file no matter whether the terminal has a function of creating the third image file, and at this time, the first download request is only used to download the new second image file from the server.

Step 120, when the first download request is used for downloading 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 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 further comprises the third image file, and the third image file records newly added data when the cloud desktop runs in the state of setting the second snapshot.

The second image file downloaded by the first terminal from the server and the local original second image file may be considered as different versions of the same second image file, where the content of the second image file in the different versions is different, and in this case, for convenience of distinction, the downloaded second image file is recorded as a new second image file.

Currently, a first download request is used to download a new second image file from a server. After receiving the first downloading request, the server analyzes the first downloading request to find out a new second image file to be downloaded. In one embodiment, the first downloading request may include a version ID that needs to be downloaded currently, and optionally, the version ID that needs to be downloaded currently may be issued to the first terminal by the server, for example, after the server performs version update, the current version ID is issued to the first terminal. Alternatively, the version ID currently required to be downloaded may be selected by the user of the first terminal, for example, after the user of the first terminal logs in, each version corresponding to the second image file currently used in the first image may be searched in the server, and then the version currently required to be downloaded is selected. After receiving the first downloading request, the server acquires the version ID therein and searches the second image file associated with the corresponding version as a new second image file. In one embodiment, the first download request may include an image ID of the first image, and after the server obtains the image ID, the server searches for a latest version of the second image file in the first image for use by the first terminal according to the image ID, and uses the second image file associated with the latest version as a new second image file. In one embodiment, the first download request may include an image ID and a version ID, and then the server locates a new second image file according to the image ID and the version ID. In one embodiment, the first download request includes a user ID, and the server determines a first image used by the first terminal according to the user ID, and uses a latest version of a second image file used by the first terminal in the first image as a new second image file. The server may also determine the new second image file in other ways.

And the server issues the new second image file to the first terminal. When the first terminal receives the new second image file, the new second image file is used for replacing the original second image file so as to update the version. Optionally, after the version is updated, the third image file corresponding to the current version needs to be used for recording newly-added data when the first terminal runs the cloud desktop based on the current version, at this time, the first terminal obtains a second snapshot corresponding to the current version in the second image file, and generates the third image file based on the second snapshot, that is, the third image file is generated based on setting a second snapshot (currently being the second snapshot corresponding to the updated version) in the second image file. Then, the first terminal can operate the cloud desktop based on the current version. Optionally, before updating, the original version of the first terminal may also have a corresponding third image file, and before updating the version, the user may determine whether the data recorded in the original third image file needs to be discarded, and if so, may delete the third image file directly locally, that is, discard the modification to the original version; if the third image file does not need to be abandoned, the third image file can be uploaded to the server, the server submits the third image file to the corresponding second image file, then the server creates a new version based on the submitting result, and the second image file corresponding to the new version can be used as the new second image file for the first terminal to download. After the first terminal uploads the third image file, the local third image file may be deleted, or the third image file and the corresponding version association may be saved, or the server may save the third image file and the corresponding version association.

And 130, when the first downloading request is used for downloading 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 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.

This step differs from step 120 in that in this step a third image file is generated in the server. In one embodiment, when the server creates a snapshot (i.e. a version) for the second image file, a third image file corresponding to the version is generated, and when the first download request is received, the second image file and the corresponding third image file are sent to the first terminal together.

Optionally, after receiving the first downloading request, the server analyzes the first downloading request to find out a new second image file and a corresponding third image file which need to be downloaded. Optionally, a corresponding third image file may be found according to the version of the new second image file. The process of the server parsing the first download request may refer to the related description in step 120, which is not described in detail.

And the server sends the searched new second image file and the corresponding third image file to the first terminal. When the first terminal receives the new second image file, the first terminal uses the new second image file to replace the local original second image file so as to update the version, then operates the cloud desktop based on the current version, and writes the newly added data into a third image file corresponding to the current version. Optionally, before updating, the corresponding third image file may also exist in the original version of the first terminal, and at this time, the processing of the third image file may refer to the related description in step 120, which is not described in detail at present.

The server receives the first downloading request sent by the first terminal, and issues the second image file of the first image center to the first terminal based on the first downloading request, so that the first terminal uses the new second image file to replace the local second image file, and further the first terminal uses the new second image file when the first terminal operates the cloud desktop, and the newly added data in the operation process of the first terminal is written into the third image file corresponding to the new second image file, so that the technical problem that the server issues the image file to the terminal in the related art needs to consume more network resources is solved. By dividing the image into three levels of files, and when the first terminal downloads the new image file, the server does not need to issue all image files, only needs to issue the second image file, thereby reducing the memory of the downloaded file, saving network resources and reducing the downloading time. And because the third image file is a blank file after being created, even if the corresponding third image file needs to be issued, only a small amount of network resources are occupied, and the reasonable use of the network resources is ensured.

In one embodiment of the present application, the image in the server is available to the terminal after registration, and currently, the registration process of the image is described using the first image as an example. Fig. 5 is a flowchart of a method for managing images according to an embodiment of the present application, which is a specific flow when a server performs image registration management, and referring to fig. 5, the method for managing images includes:

step 210, acquiring a first image file and a second image file.

For example, after the first image file and the second image file are created, the first image file and the second image file need to be uploaded to the server for registration by the server, where the first image file and the second image file may be uploaded separately or simultaneously, a terminal for creating the first image file and the second image file, and an uploading rule are not limited currently. In one embodiment, the first image file and the second image file that are currently uploaded may be considered an initial BaseImage and an 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 may also be considered as a process that the server obtains the first image file and the second image file.

Step 220, hard linking the first image file and the second image file to the first image, respectively.

For example, in order to ensure that the terminal correctly uses the first image, the first image file and the second image file are respectively hard-linked to the first image, that is, the first image file and the second image file currently used by the first image are definitely used by the first image, and it is understood that if the second image file is used by one branch, the hard-linking of the first image file and the second image file to the first image may be connected to the branch to which the first image belongs. Thereafter, when a new branch of the first image is created, the image metadata of the first image may be updated in a second image file used based on the new branch, and the first image text and the second image file used by the new branch may be hard-linked into the first image (in particular, the new branch).

In one embodiment, when the first image file and the second image file are respectively hard-linked to the first image, the method further comprises: and creating an image record of the first image, and adding image metadata of the first image into the image record.

The mirror metadata of the first mirror describes the attribute of the first mirror, for example, the mirror metadata describes the branches included in the first mirror 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 mirror metadata of the first mirror, the mirror metadata of the first mirror is recorded. Wherein the mirror metadata is recorded in the mirror record. Illustratively, a mirror record of the first mirror is created, the mirror record being added to the mirror table, after which mirror metadata of the first mirror is added to the mirror record. Optionally, when the first image is updated (e.g., a new branch, a new version, etc. is created in the first image), the image metadata in the image record is also updated synchronously.

The above procedure can also be considered as a procedure of image registration.

And 230, creating a corresponding version directory based on the initial second snapshot of the second image file, and respectively hard linking the first image file and the second image file into the version directory to obtain the first image.

Illustratively, after registration is completed, version creation is performed. In one embodiment, the first image file includes a unique first snapshot, the file name of the first image file is changed to the first snapshot name of the first snapshot before the second image file is created, and the first snapshot name of the first snapshot is recorded when the second image file is created. Optionally, the initial second snapshot is created after the second image file is created. When the initial second snapshot is created, the second image file contains device drivers and applications built in the operating system, and subsequently, the user can derive its own second image file based on the second image file. The first image file and the initial second image file (containing only the device driver and the built-in application of the vendor and generating the second snapshot) may be created by the vendor of the first image and uploaded to the server. The subsequent user generates his own snapshot (at this point, containing personalized data, such as an upgrade patch for the application) from the second image file.

And creating a version corresponding to the initial second snapshot based on the initial second snapshot, creating a version directory corresponding to the version, and adding the first image file and the second image file used by the version in the version directory. Alternatively, when creating the version, the version ID may be determined, and when creating the version directory, the version ID corresponding to the version directory may be recorded to associate the version with the version directory. In one embodiment, the first image file and the second image file are each added in the version directory in a hard-linked manner. Optionally, for the first image file, the first image file is 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 hard-linking process of the second image file and the first image file is similar, which is not described in detail. At this time, after the first image file and the second image file are added to the version directory, the first image can be considered to be obtained. Optionally, since the terminal downloads the corresponding images through the seed file, after hard linking the first image file and the second image file to the version directory, the corresponding P2P downloaded seed file needs to be created for the first image file and the second image file respectively, so that the terminal downloads the seed file.

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

Illustratively, when creating a version, in addition to creating a version directory, a version record is created, which may also be associated with the version by a version ID. In one embodiment, version metadata for a version is determined based on a first image file and a second image file used in the version. The version metadata may include content such as a user ID, a version ID, and a preamble version ID, where the preamble version refers to a version before the current version is created by the second image file. Version metadata may be updated in conjunction with attributes of the version. And then, adding the version metadata into the version record corresponding to the version.

In one embodiment, the server creates a third image file. At this time, step 230 is followed by step 240.

Step 240, creating a corresponding third image file based on the initial second snapshot.

Optionally, after the server creates the initial second snapshot of the second image file, a corresponding third image file is created based on the initial second snapshot. One possible approach is to change the file name of the second image file to the snapshot name of the original second snapshot to record the snapshot name of the second snapshot in the third image file in creating the third image file.

Optionally, after the creation is completed, a third image file is added in the corresponding version directory, so that three types of image files contained in the corresponding version are defined through the version directory. The implementation means for adding the third image file to the version directory is not limited at present.

Optionally, after the third image file is created, a seed file of the corresponding P2P download is created for the third image file, so that the terminal downloads the seed file.

Before the first terminal runs the cloud surface for the first time, 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 need to be downloaded from the server (the current downloading is the seed file, and then the corresponding image file is obtained based on the seed file). And in the subsequent updating process, the first image file does not need to be repeatedly downloaded.

In practical applications, the first terminal may also create the third image file. Optionally, after the first terminal creates the third image file, the server may be notified, so that the server adds the third image file in the corresponding version directory.

An exemplary image registration process is described below, and fig. 6 is a flowchart of image registration provided in one embodiment of the present application. Referring to fig. 6, a process of uploading and registering an image and a processing manner of an image file under each process are shown. After registration starts, the first image is uploaded, that is, the files required for uploading, fig. 6 takes the first image file and the second image file as an example, and in this process, the server obtains the first image file and the second image file respectively. Thereafter, mirror registration is performed. In the process, mirror metadata of the first mirror image is generated, and the corresponding file processing mode is to respectively hard link the first mirror image file and the second mirror image file to the first mirror image. Thereafter, a mirror record of the first mirror is created and mirror metadata is added to the mirror record. Then, an initial restore point (also understood as creating an initial version) is created, wherein the initial restore point refers to an initial second snapshot of the second image file, the corresponding file processing mode is to create a version directory of the corresponding version, and the first image file and the second image file which are hard-linked in the image registration process are respectively hard-linked to the version directory. And creating a corresponding third image file based on the initial second snapshot of the second image file. And then, creating seeds, namely respectively creating seed files corresponding to the first image file, the second image file and the third image file for the first terminal to download.

Optionally, after the first terminal downloads the first image file and the initial second image file, the first terminal embeds the first image file and the initial second image file.

In the image registration process, the multiplexing of the image files can be realized in a hard link mode, and the first image file and the second image file are independently uploaded and registered, so that the subsequent image management, such as version update, is convenient, and only the second image file is required to be modified without modifying the first image file.

In one embodiment of the present application, when the server manages, mirror image merging management is further required, where mirror image merging can be understood as writing the user personalized data recorded in the UpperImage into the corresponding LowerImage, so as to implement adding the personalized data of the user into the LowerImage. Currently, taking the first mirror image as an example, the merging process of the mirror images is described. The first mirror image records a corresponding snapshot list in the server, each version of the first mirror image and a second snapshot corresponding to each version are recorded in the snapshot list, and optionally, each version ID and a corresponding second snapshot name are recorded in the snapshot list. Fig. 7 is a flowchart of a method for managing images according to an embodiment of the present application, which is a flow chart when a server performs image merging management, and referring to fig. 7, the method for managing images includes:

Step 310, receiving the third image file uploaded by the first terminal.

The first terminal writes the newly added data (i.e. personalized data of the user) into the third image file when running the cloud desktop, for example, when the first terminal installs a new application program or a new device driver in the cloud desktop, the new application program and the new device driver are written into the third image file, for example, when the first terminal stores the new file and the data in the cloud desktop, the new file or the data is written into the third image file. When the user of the first terminal has a need of writing the data of the third image file into the second image file, the third image file can be uploaded to the server, and optionally, an image merging request can be sent during uploading, so that the server performs image merging.

Optionally, before the server performs the image merging, the first image used by the first terminal is determined, and then the first image is locked. The technical means used in determining the first image used by the first terminal is not limited currently, for example, the first terminal notifies the server of the first image used by itself when uploading the third image file, for example, the server records each terminal using each image, notifies the first terminal of identity data (such as a user ID) when uploading the third image file, and then the server determines the first image used by the first terminal according to the identity data. The purpose of locking the first image is to prohibit the first image from being downloaded, and at this time, each terminal cannot download various sub files contained in the first image.

Optionally, the third image file already includes the second snapshot name, and the server may 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 carry out version verification before uploading the third image file. Alternatively, the third image file may be uploaded in a differential manner.

Step 320, obtaining the current version ID of the first mirror image in the first terminal.

Illustratively, the server determines the version ID currently used by the first terminal, i.e., determines the clientrisionid. For example, when the first terminal uploads the third image file, the server may directly obtain the version ID, for example, after the first terminal uploads the third image file, the server may obtain a second snapshot name of the second snapshot recorded in the third image file by parsing the third image file, and then, based on the second snapshot name, search a corresponding version in the snapshot list to obtain the version ID, for example, the server may parse version metadata corresponding to a currently used version of the first terminal to obtain the version ID in the version metadata, where the server may search a version record of the currently used version of the first terminal, and then, based on the version metadata in the version record, obtain the version ID.

Step 330, searching the second image file corresponding to the version ID.

In one embodiment, each data stored in the server may be stored in a database, i.e., baseImage, lowerIamge and UpperImage are both stored in the database. After the server obtains the version ID, the corresponding second image file is searched in the database based on the version ID.

Optionally, when searching the second image file, a storage Path (Client UpperIamge Path) of the third image file and a storage Path (loweramage Path) of the second image file used by the first terminal are searched in the database according to the version ID. The corresponding version directory can be found according to the version ID, and Client UpperIamge Path and loweramage Path can be obtained according to the record of the version directory. Or, obtaining a corresponding second snapshot name according to the version ID, and obtaining Client UpperIamge Path and the loweramage Path based on the second snapshot name. And then, a corresponding second image file can be acquired according to the lower Iage Path.

Step 340, submitting the third image file to the second image file to obtain a new second image file.

The data recorded in the third image file is written in the second image file in an information block manner, so as to realize the merging of images. Wherein the submission of the third image file into the second image file may also be considered as a commit process. After the third image file is submitted to the second image file, the second image file can be considered to be updated, and at this time, in order to distinguish from the original second image file, the submitted second image file is recorded as a new second image file.

In one embodiment, since the second image file may include a plurality of snapshots, the current version (i.e., the latest version) of the second image file found in step 330 may not be the version used by the first terminal, i.e., the second image file is not the version used when creating the third image file. In order to ensure the normal implementation of the image merging, the second image file needs to be adjusted to the version corresponding to the third image file, and step 340 may include steps 341-343:

and 341, restoring the second image file to a second snapshot corresponding to the third image file.

The method includes determining a corresponding second snapshot according to a second snapshot name recorded in the third image file, and then restoring the second image file to a state corresponding to the second snapshot.

And 342, renaming the restored second image file to enable the second image file to use the second snapshot name of the second snapshot.

It can be understood that when a new second snapshot is created in the second image file, the file name of the second image file is modified to be the second snapshot name of the new second snapshot, so as to be convenient for defining the current used version of the second image file, and when the third image file is submitted to the second image file, it is required 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, so that after the second image file is restored, the second image file is renamed, and after the renaming, the file name of the second image file is changed into the second snapshot name recorded in the third image file uploaded by the first terminal.

Step 343, submitting the third image file to the renamed second image file.

Illustratively, the third image file is committed to the renamed second image file.

Step 350, creating a new second snapshot in the new second image file.

After the third image file is submitted to the second image file, the new second image file is added with personalized data of the user, and then a new second snapshot is created for the second image file, so that the second image file is restored to a state after the third image file is submitted when needed later. Optionally, when the new second snapshot is created, a snapshot name of the new second snapshot is generated. Alternatively, creating a new snapshot may also be understood as creating a new version, at this time, a new version record and a version directory may be created, new version metadata may be added in the new version record, and the first image file, the second image file, and the third image file corresponding to the version may be recorded in the version directory.

In one embodiment, each upperimage has a unique identifier by which different upperimages can be distinguished, the unique identifier being generated at the creation of upperimage. Optionally, when the first terminal uploads the third image file, the unique identifier of the third image file is provided, and when the second image file creates a corresponding new second snapshot, the unique identifier can be used as the corresponding second snapshot name, so that the requirement of uniqueness of the second snapshot name is met.

Taking the creation of a third image file in the server as an example, step 350 is followed by steps 360-370:

step 360, deleting the third image file.

For example, since the data recorded by the third image file has been written in the new second image file, the third image file may 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, creating a new third image file based on the new second snapshot.

Illustratively, a new second snapshot is created in the new second image file, and thus, a new third image file needs to be created based on the new second snapshot to record newly added data in the new third image file when the first terminal uses the new second image file. It is 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 contents of the second image file used in the first image change, and therefore, the snapshot list and image record need to be updated. At this time, step 380 may also be included after step 370.

Step 380, update the snapshot list and update the mirror metadata in the mirror record.

Illustratively, after creating the new second snapshot or creating the third image file, the snapshot list of the first image is updated to add the new second snapshot to the snapshot list and based on the version corresponding to the new second snapshot.

Optionally, after updating the snapshot list, a corresponding seed file may be created for the new second image file and the new third image file, respectively, so as to be downloaded by the first terminal.

For example, after the snapshot list is updated, the image record corresponding to the first image in the image table needs to be updated, that is, the image metadata of the first image in the image record is updated based on the new second image file. Alternatively, updating the image record may be performed after creating the seed file.

After updating the mirror metadata of the first mirror, unlocking the first mirror for downloading by the first terminal. Optionally, the server notifies the first terminal of version update, and then the first terminal generates a first downloading request for downloading the new second image file and the corresponding third image file and sends the first downloading request to the server, and the server sends the new second image file and the corresponding third image file to the first terminal according to the first downloading request so as to be used by the first terminal.

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

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

An exemplary general procedure for image registration is described below, and FIG. 8 is a flow chart of image merge provided by one embodiment of the present application. Referring to fig. 8, after merging starts, the corresponding image is locked, then version metadata (i.e., clientrisionmeta) corresponding to the version used by the terminal is parsed to obtain a clientrisionid (version ID used by the terminal), then Client UpperImage Path (i.e., path of the third image file used by the terminal) and a LowerImage Path (i.e., path of the second image file) are searched from the database according to the clientrisionid, then LowerImage is restored to Client UpperImage dependent snapshot, lowerImage is renamed, client UpperImage is submitted to LowerImage, a new snapshot is created for LowerImage, an old UpperImage is deleted, a new UpperImage is created, a snapshot list is updated, seed files of LowerImage and UpperImage are created, and the image record in the image list is updated, and locking is released. Thus, the mirror image merging is completed.

According to the cloud desktop data processing method, when the first terminal runs the cloud desktop, newly added data are written into the third image file, the first image file and the second image file cannot be modified, therefore, when the first terminal or the server has the image merging requirement, only the local third image file is uploaded to the server, and then the server submits the third image file to the second image file, so that the uploading data amount of the first terminal is reduced, the uploading speed and the uploading efficiency are improved, network resources are saved, and the image merging efficiency and speed are further improved.

In one embodiment of the present application, when the server performs management, mirror image restoration management is further required, where mirror image restoration can be understood as restoring LowerImage to a certain formulated version. Currently, taking the first mirror image as an example, a mirror image restoration process is described. Fig. 9 is a flowchart of a method for managing an image according to an embodiment of the present application, which is a flow chart when a server performs image restoration management, and referring to the figure, the method for managing an image includes:

step 410, receiving a mirror restore instruction.

The mirror image restoration instruction is used for indicating the server to perform mirror image restoration, and can be generated at the terminal or at the server, when the server generates the mirror image restoration instruction, a user (such as a manager with a certain authority) of the server can select a LowerImage to be restored and a version to be restored, and then the server generates the mirror image restoration instruction according to the selection, and further receives the mirror image restoration instruction. Currently, description will be given taking an example of restoring the second image file in the first image by the image restoring instruction.

Optionally, after receiving the image restoration instruction, the server determines to perform image restoration and locks the first image used by the first terminal, where the process of locking the first image may refer to the process of locking the first image in step 310, which is not described in detail currently.

Step 420, according to the mirror image restoration instruction, the version ID to be restored is obtained.

Illustratively, the version ID to be restored refers to the version ID to which the second image file is desired to be restored. Optionally, the mirror restore instruction contains the version ID to be restored. Optionally, the server invokes a corresponding parameter according to the mirror image restoration instruction to obtain the version ID to be restored through the parameter, where the invoked parameter is presented in a string variable manner and may include the mirror image ID of the first mirror image, the user ID of the first terminal, the version ID, and other contents.

Step 430, searching the corresponding second image file and the corresponding second snapshot name according to the version ID.

Optionally, because each second snapshot corresponds to a version, the version ID to be restored is used to query in the snapshot list corresponding to the first image, so as to obtain a corresponding second snapshot name, and a second image file where the second snapshot name corresponds to the second snapshot is obtained.

And step 440, restoring the second image file to the corresponding second snapshot according to the second snapshot name.

The second image file is restored according to the second snapshot corresponding to the second snapshot name, that is, the state of the second image file is restored when the second snapshot is created, and at this time, personalized data of the user added in the second image file after the second snapshot is deleted.

In one embodiment, the third image file is created by the server, at this point, after step 440, steps 450 and 460 are also included.

And 450, deleting the third image file corresponding to the second image file.

Illustratively, since the second image file has changed, the corresponding third image file, i.e., the old third image file, before the second image file is changed needs to be deleted.

Step 460, creating a new third image file based on the restored second snapshot.

Illustratively, a corresponding third image file is created based on the restored second snapshot, which may be considered 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 text included in the first image is updated, the image record corresponding to the first image in the image table needs to be updated, and after step 460, the method further includes:

step 470, updating the mirror metadata in the mirror record.

Optionally, after updating the mirror metadata, it may be determined that mirror restoration is completed, and at this time, the server may unlock the first mirror, so that the first terminal downloads the corresponding seed file. In one embodiment, after the mirror image restoration, the server may notify the first terminal that the mirror image restoration is completed, and then, the first terminal generates a corresponding first downloading instruction according to the notification of the server, and feeds back the first downloading instruction to the server, and the server responds to the first downloading instruction to push the restored second mirror image file to the first terminal as a new second mirror image file.

In one embodiment, the server records the current latest version ID of each image, and after the images are restored, changes the current latest version ID of the corresponding image into the restored version ID.

An exemplary image restoration process is described below, and fig. 10 is a flowchart of image restoration according to an embodiment of the present application. Referring to fig. 10, after starting, the corresponding image is locked, then the called parameters (i.e., parse areas) are analyzed to obtain the image ID and the revisionID, then the target snapshuttime to which the corresponding LowerImage needs to be restored is located according to the revisionID, then the LowerImage is restored to the corresponding target snapshut, then the old UpperImage is deleted, a new UpperImage is created, seed files of the LowerImage and the UpperImage are respectively created, the image record in the image table is updated, the image is unlocked, and the downloading of the image is restored to complete the image restoration.

When the demand of mirror image restoration exists, the second mirror image file is restored to the corresponding version, and the first mirror image file is not required to be modified, so that the data processing amount during restoration is saved, and the efficiency and speed of mirror image restoration are improved.

In one embodiment of the present application, when the server performs management, mirror clone management is also needed, where mirror clone can be understood as obtaining another mirror image based on one mirror clone. Currently, taking the first mirror image as an example, the cloning procedure of the mirror image is described. Fig. 11 is a flowchart of a method for managing images according to an embodiment of the present application, which is a flow chart when a server performs image clone management, and referring to the figure, the method for managing images includes:

step 510, receiving a mirror image cloning instruction, where the mirror image cloning instruction is used to clone the first mirror image.

Illustratively, the mirror clone instruction is used to instruct the server to mirror clone. Currently, the first image is the cloned image, at which point the image clone instruction may be considered to clone the first image.

The mirror clone instruction may be issued by a user in the first terminal or server, or by an administrator of the mirror in the server, for example. Optionally, when the image restoration instruction is generated, writing the ID of the restored image in the image restoration instruction, so that the server determines the restored image (currently, the image restoration instruction writes the image ID of the first image). Alternatively, when the image is cloned, only a certain version can be cloned, and at this time, the image restoration instruction may further include a version ID to be cloned. Optionally, however, because the personalized data of the user may be recorded in the first image, only an administrator with a certain authority may issue an image cloning instruction for data security, or alternatively, only the user may clone the first image used by the user.

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

Illustratively, the image cloned based on the first image is recorded as a second image. Alternatively, since the first image file used in the first image only records the operating system and is not modified during use, the first image file may be shared by the second image, and in one embodiment, the first image file may be connected to the second image by way of a hard link. Optionally, the second image file in the first image may be copied to the second image, and then a corresponding third image file may be created based on the second image file, so as to ensure that the second image is normally used by three levels of image files.

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

and 511, generating a mirror image record and a version directory of the second mirror image according to the mirror image cloning instruction, wherein the mirror image metadata of the first mirror image is recorded in the mirror image record of the second mirror image.

For example, when cloning the second image, image registration may be required, that is, an image record and a version directory of the second image may be created, and a version record of the second image may also be created. At present, the mirror metadata of the first mirror is written in the mirror record of the second mirror.

Step 512, creating a hard link to the first image file in the first image in the version directory.

Illustratively, the second image and the first image share the first image file, and thus the first image file is connected to the second image in a hard-linked manner, and currently, the first image file is hard-linked to the version directory of the second image.

Step 513, copying 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, the second image file used in the first image is copied and pasted in the version directory of the second image, so as to define the second image file used in the second image. It is understood that the second image file that is currently being replicated contains all of the second snapshots that are currently being made.

And step 514, maintaining the target version in the copied second image file and deleting other second versions, wherein the target second version is determined through the image cloning instruction.

For example, when the images are cloned, only the appointed version in the second image file is cloned, and the appointed version is recorded as a target version currently. Therefore, after the second image file is copied, the second image file needs to be initialized, only the state corresponding to the target version is reserved in the second image file during initialization, other versions are deleted, namely only one version in the second image file after initialization is the target version, at this time, the initialized second image file can be regarded as the initial second image file in the second image, and then metadata corresponding to the target version can be recorded in the version record of the second image. It should be noted that the version directory mentioned in steps 511-513 may be regarded as a version directory corresponding to the target version.

In one embodiment, the third image file is generated by the server, so step 514 may further include: and creating a corresponding third image file based on the target version.

For example, a corresponding third image file is created based on the second image file in the second image, where the third image file corresponds to the target version of the second image file, that is, the third image file includes the second snapshot name of the second snapshot corresponding to the target version.

Optionally, seed files of the second image file and the third image file are respectively created for downloading by the terminal, and it can be understood that when the terminal downloads the image for the first time and the downloaded image is the second image, the server can find the first image file through the hard link in the version directory, and send the seed files of the first image file to the terminal for use by the terminal.

Step 515, updating the mirror metadata in the mirror record of the second mirror.

For example, when the image record of the second image is created, the image metadata of the first image recorded in the image record is changed after the second image file is initialized, so that the image metadata in the image record of the second image is updated currently according to the initialized second image file.

Optionally, in the cloning process, the second image may include multiple states to indicate, through the different states, a current cloning node of the second image, and in one embodiment, when generating the image record and the version directory of the second image according to the image cloning instruction, the method further includes: the second image is marked as waiting for clone status. When updating the mirror metadata in the mirror record of the second mirror, the method further comprises: the second image is marked as complete clone status.

The wait for clone state (wait) refers to a state waiting for clone to start, and the complete clone state (ready) refers to a state in which clone completion can be used. In addition, a cloning status (copy), which refers to the cloning being performed, may be included. Optionally, when the image record and the version directory of the second image are generated, the second image is marked as a waiting cloning state, when the second image file in the first image is copied to the version directory, the waiting cloning state of the second image is converted into a cloning state, and when the image metadata in the image record of the second image is updated, the cloning state of the second image is converted into a completed cloning state.

An exemplary mirror cloning process is described below, and FIG. 12 is a flow chart of a mirror cloning process according to one embodiment of the present application. Referring to fig. 12, after starting, image metadata is created first, the image metadata is the image metadata of a new image obtained after cloning, and an image record, an initial version record and an initial version directory of the new image are generated, at this time, the new image is in a waiting state (waiting). Then, creating a hard link of the Baseimage of the source image (cloned image) under the initial version catalog, copying the LowerImage of the source image under the initial version catalog, initializing the LowerImage obtained by copying, reserving a target version, creating an UpperImage based on the LowerImage, respectively creating seed files of the LowerImage and the UpperImage, updating image records in an image table, and changing the new image into a finished cloning state to finish image cloning.

When the first terminal or the server has the demand of image cloning, the first terminal or the server only needs to copy the second image file and create the image record, and the first image file can be added in a new image in a hard link mode without copying, so that the disk space of the server is saved, and the efficiency and the speed of image cloning are improved.

It can be understood that the BaseImage does not need to be modified during mirror image merging, mirror image restoration and mirror image cloning, so that the safety of the BaseImage is ensured, and the terminal is prevented from repeatedly downloading the BaseImage.

In one embodiment of the present application, the image management device may be a server, or may be a image management terminal, where the terminal may also be considered as a terminal for a user, and the terminal may be a personal computer, a tablet computer, an interactive tablet, a mobile phone, or the like, which is not limited at present. The cloud desktop is realized by running the virtual machine, wherein the mirror image required by the running of the terminal can be obtained from the server, and at the moment, the mirror image management method can be realized after the terminal is matched with the server. In one embodiment, taking the first terminal as an example, how the terminal performs the image management method is described.

Fig. 13 is a flowchart of a method for managing images according to an embodiment of the present application, and referring to fig. 13, when a first terminal executes the method for managing images, the method may include:

Step 610, a first download request is sent to a server of the cloud desktop.

The first terminal uses a first image, the first image includes a first image file and a second image file, the first image file records an operating system used by a cloud desktop in the first terminal, and the second image file records a device driver and an application program installed based on the operating system.

After the first terminal generates the first downloading request, the first terminal sends the first downloading request to the server.

Step 620 is performed when the second image file and the corresponding third image file can be downloaded by the first download request, and step 650 is performed when the second image file and the corresponding third image file can be downloaded by the first download request.

Step 620, when the first download request is used for downloading a new second image file from the server, receiving the new second image file sent by the server.

Step 630, replacing the local original second image file with the received second image file.

Optionally, the new second image file sent by the server is used as a locally used second image file, and at this time, the first terminal considers that the version is replaced. Alternatively, for the initial second image file, the initial second image file may be stored locally all the time, and the second image files of other versions may be stored in the first terminal or may be deleted in the first terminal along with the replacement of the version.

Step 640, creating a corresponding third image file based on the set second snapshot in the received second image file, where the first image further includes the third image file, and the third image file records newly added data of the cloud desktop when the cloud desktop runs in the state of setting the second snapshot.

Illustratively, 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. And then, running the cloud desktop.

Step 650, when the first download request is used for downloading the new second image file and the corresponding third image file from the server, the new second image file and the third image file sent by the server are received, and the third image file is generated based on the set second snapshot in the new second image file.

Step 660, replacing the local original second image file with the received second image file.

When the first terminal needs to update the first mirror image, the first terminal only needs to acquire the new second mirror image file from the server and replace the new second mirror image file, the first mirror image file is not needed to be acquired, and the technical problem that the server needs to consume more network resources when issuing the mirror image file to the terminal in the related technology is solved. In addition, because the third image file is a blank file after being created, even if the corresponding third image file needs to be downloaded, only a small amount of network resources are occupied, and the reasonable use of the network resources is ensured.

In one embodiment of the present application, the first terminal may submit newly added data in the running process of the local cloud desktop to the second image file to perform version upgrade (i.e. image merging), where when the first terminal executes the image management method, the method may further include: operating the cloud desktop according to the first image file, the second image file and the corresponding third image file which are locally present, and writing newly added data into the third image file in the operation process; and uploading the third image file to the server so that the server submits the third image file to the corresponding second image file.

The first terminal is provided with a first image file, a second image file and a third image file when the first terminal starts the virtual machine, the virtual machine is directly started based on the third image file, three types of files are not required to be combined, and when a cloud desktop is operated in the virtual machine, currently added data is recorded in the third image file. If a user needs to create an restore point for the current running state, that is, create a new version, the server may send the third image file currently used to the server and instruct the server to perform image merging, the server submits the third image file to the corresponding second image file according to the instruction, and then the server notifies the first terminal that the merging is completed, and the first terminal may generate a first download instruction based on the notification of the server to download the second image file of the second snapshot corresponding to the restore point, and create or download the corresponding third image file from the server in combination with the actual situation.

It can be understood that, because the third image file is used for writing the newly added data, when the user of the first terminal thinks of giving up the modification to the cloud desktop, only the current third image file needs to be deleted, and the third image file is rebuilt or obtained from the server, so that the image restoration process in the first terminal is simplified.

In the operation process, the first terminal writes the newly added data into the third image file without modifying the first image file and the second image file, so that when a new version is created, only the local third image file is required to be uploaded to the server, the new version can be created in the server, the uploading data volume is greatly reduced, and the uploading efficiency is improved.

In an embodiment of the present application, the first terminal may further synchronize a second image file used locally to the second terminal, so as to run a cloud desktop in the first terminal in the second terminal, where when the first terminal executes the image management method, the method may further include: receiving a synchronization request sent by a second terminal, wherein the second terminal and the first terminal use the same first image file; and sending 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.

The second terminal may be a terminal for realizing physical drift of the cloud desktop, that is, the cloud desktop used by the first terminal drifts into the second terminal for use, and the second terminal may also be a terminal replaced by a user, that is, the user replaces the first terminal currently used with the second terminal.

In one embodiment, the second terminal runs through the cloud desktop, and the first image file and the second image file are already stored, at this time, the first terminal may send the second image file of itself to the second terminal, and then the second terminal uses the received second image file to replace the second image file of itself, so as to ensure that the cloud desktop in the first terminal is run. In one embodiment, the second terminal does not run on the cloud desktop, where the second terminal may first download, from the server, each layer of files included in the first image, and then replace the second image file of the second terminal with the received second image file.

Optionally, when the second terminal may create the third image file, the third image file is created based on the set version in the received second image file, or the third image file is created by the server and sent to the second image file.

Optionally, when the first terminal sends the second image file to the second terminal, the second image file may be directly sent to the second terminal, or sent to the second terminal through the server. When the third image file is sent to the second terminal through the server, if the 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, the second terminal may be recorded in the server, so that the server determines the current mirror version used by the second terminal.

In the synchronization process, only the LowerImage is required to be sent from the first terminal to the second terminal, so that links required by synchronization are simplified.

It will be appreciated that technical details not mentioned in the above process may be referred to the relevant description of the foregoing embodiments, and that corresponding functions and advantages may be provided.

Fig. 14 is a schematic structural diagram of a mirror management apparatus according to an embodiment of the present application. The image management apparatus is applied to a server, and referring to fig. 14, the image management apparatus includes: a first receiving unit 701, a first transmitting unit 702, and a second transmitting unit 703.

The first receiving unit 701 is configured to receive a first download request sent by a first terminal, where 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 an operating system used by a cloud desktop in the first terminal, and the second image file records a device driver and an application program installed based on the operating system; a first sending unit 702, configured to send a new second image file to the first terminal when the first download request is used to download the new second image file from the server, so that the first terminal uses the received second image file to replace a local original second image file and create a corresponding third image file based on a set second snapshot in the received second image file, where the first image further includes the third image file, and the third image file records newly added data when the cloud desktop runs in a state where the second snapshot is set; and the second sending unit is used for sending the new second image file and the third image file to the first terminal when the first downloading request is used for downloading the new second image file and the corresponding third image file from the server, 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 set second snapshot in the new second image file.

In one embodiment, 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 comprises at least one second snapshot, and the third image file comprises a second snapshot name of the corresponding second snapshot.

In one embodiment, the first image records at least one version in the server, each version corresponds to one second snapshot in the second image files and is associated with the second image files, the first image files corresponding to the first snapshot names in the second image files, and the third image files corresponding to the second snapshots, and each version has a corresponding version ID.

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

In one embodiment, the method further comprises: the first acquisition unit is used for acquiring the first image file and the second image file; a first linking unit for hard linking the first image file and the second image file to the first image, respectively; and the second linking unit is used for creating a corresponding version directory based on the initial second snapshot of the second image file, and respectively hard linking the first image file and the second image file into the version directory to obtain the first image.

In one embodiment, the method further comprises: and the first creating unit is used for creating a corresponding third image file based on the initial second snapshot after hard linking the first image file and the second image file into the version directory respectively.

In an embodiment, the first linking unit is further configured to: creating a mirror image record of the first mirror image, and adding mirror image metadata of the first mirror image into the mirror image record; the second linking unit is further configured to: and creating a version record corresponding to the initial second snapshot, and recording version metadata of the version corresponding to the initial second snapshot in the version record.

In one embodiment, the method further comprises: the second receiving unit is used for receiving the third image file uploaded by the first terminal; the second acquisition unit is used for acquiring the current version ID of the first mirror image in the first terminal; the first searching unit is used for searching the second image file corresponding to the version ID; the submitting unit is used for submitting the third image file to the second image file so as to obtain a new second image file; and the second creating unit is used for creating a new second snapshot in the new second image file.

In one embodiment, the first deleting unit is configured to delete the third image file after creating a new second snapshot in the new second image file; and a third creating unit for creating a new third image file based on the new second snapshot.

In one embodiment, the commit unit includes: the first restoring subunit is used for restoring the second image file to a second snapshot corresponding to the third image file; a renaming subunit, configured to rename the restored second image file, so that the second image file uses a second snapshot name of the second snapshot; and the file submitting subunit is used for submitting the third image file to the renamed second image file.

In one embodiment, the first image records a corresponding snapshot list in the server, and each version of the first image and a second snapshot corresponding to each version are recorded in the snapshot list; the apparatus further comprises: and the first updating unit is used for updating the snapshot list and updating the mirror metadata in the mirror record after the new second snapshot is created in the new second mirror file.

In one embodiment, the method further comprises: the third receiving unit is used for receiving the mirror image restoration instruction; the third acquisition unit is used for acquiring the version ID to be restored according to the mirror image restoration instruction; the second searching unit is used for searching the corresponding second image file and the corresponding second snapshot name according to the version ID; and the second restoring unit is used for restoring the second image file to the corresponding second snapshot according to the second snapshot name.

In one embodiment, the method further comprises: the second deleting unit is used for deleting a third image file corresponding to the second image file after restoring the second image file to the corresponding second snapshot according to the second snapshot name; and a fourth creating unit for creating a new third image file based on the restored second snapshot.

In one embodiment, the method further comprises: the fourth receiving unit is used for receiving a mirror image cloning instruction, and the mirror image cloning instruction is used for cloning the first mirror image; the cloning unit is used for cloning the first image file and the second image file contained in the first image to obtain a second image, wherein the second image is a cloned image.

In one embodiment, the cloning unit comprises: the generation subunit is used for generating a mirror image record and a version catalog of a second mirror image according to the mirror image cloning instruction, and the mirror image metadata of the first mirror image is recorded in the mirror image record of the second mirror image; a third linking subunit, configured to create a hard link in the version directory for the first image file in the first image; a copying subunit, configured to copy the second image file in the first image to the version directory; a third deleting subunit, configured to retain a target version in the replicated second image file and delete other versions, where the target version is determined by the image cloning instruction; and the second updating subunit is used for updating the mirror metadata in the mirror record of the second mirror.

In an embodiment, the generating subunit is further configured to: marking the second mirror image as waiting for cloning; the second update subunit is further configured to: the second image is marked as complete clone status.

The image management device provided by the above embodiment can be used for executing the image management method executed by the server provided by any embodiment, and has corresponding functions and beneficial effects.

Fig. 15 is a schematic structural diagram of a mirror management apparatus according to 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 an operating system used by a cloud desktop in the first terminal, the second image file records a device driver and an application program installed based on the operating system, and referring to fig. 15, the image management device includes: a third transmitting unit 801, a first downloading unit 802, a first replacing unit 803, a first creating unit 804, a second downloading unit 805, and a second replacing unit 806.

A third sending unit 801, configured to send a first download request to a server of a cloud desktop; a first downloading unit 802, configured to receive, when a first downloading request is used to download a new second image file from a server, the new second image file sent by the server; a first replacing unit 803, configured to replace the local original second image file with the received second image file; the first creating unit 804 is configured to create a corresponding third image file based on a set second snapshot in the received second image file, where the first image further includes a third image file, and the third image file records data newly added when the cloud desktop runs in a state where the second snapshot is set; a second downloading unit 805, configured to, when the first downloading request is used to download a new second image file and a corresponding third image file from the server, receive the new second image file and the third image file sent by the server, where the third image file is generated based on a set second snapshot in the new second image file; a second replacing unit 806, configured to replace the local original second image file with the received second image file.

In one embodiment, the method further comprises: the running unit is used for running the cloud desktop according to the first image file, the second image file and the corresponding third image file which are locally present, and writing the newly added data into the third image file in the running process; and the uploading unit is used for uploading 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 comprises: a fifth receiving unit, configured to receive a synchronization request sent by a second terminal, where the second terminal and the first terminal use the same first image file; and the fourth sending unit is used for sending 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.

The image management device provided by the above embodiment can be used for executing the image management method executed by the first terminal provided by any embodiment, and has corresponding functions and beneficial effects.

It should be noted that, in the above embodiment of the mirror image management apparatus, each unit and module included are only divided according to the functional logic, but not limited to the above division, so long as the corresponding functions can be implemented; in addition, the specific names of the functional units are also only for distinguishing from each other, and are not used to limit the protection scope of the present application.

Fig. 16 is a schematic structural diagram of a mirror management device according to an embodiment of the present application. The image management device may be an image management server or an image management terminal. As shown in fig. 16, the image management apparatus includes a processor 90, a memory 91, and a communication module 92; the number of processors 90 may be one or more, one processor 90 being illustrated in fig. 16. The processor 90, memory 91 and communication module 92 in the image management device may be connected by a bus or other means, for example in fig. 16.

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

The memory 91 may mainly include a storage program area and a storage data area, wherein the storage program area may store an operating system, at least one application program required for functions; the storage data area may store data created according to the use of the image management apparatus, and the like. 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, memory 91 may further comprise memory remotely located with respect to processor 90, which may be connected to the image management device via a network. Examples of such networks include, but are not limited to, the internet, intranets, local area networks, mobile communication networks, and combinations thereof.

The communication device 92 is configured to perform data communication according to the instruction of the processor, for example, when the mirror management device is a server, data communication may be performed with the terminal, and for example, when the mirror management device is a terminal, data communication may be performed with the server. The image management device may further comprise input means operable to receive input digital or character information and to generate key signal inputs related to user settings and function control of the image management device, and output means, and may further comprise an audio input device such as a microphone. The output means may comprise a display screen, a speaker or the like.

The image management device comprises a corresponding image management device, can be used for executing the corresponding image management method provided by any embodiment, and has corresponding functions and beneficial effects.

In addition, an embodiment of the present application further provides a storage medium containing computer executable instructions, where the computer executable instructions when executed by a computer processor are used to perform the related operations in the image management method provided in any embodiment of the present application, and have corresponding functions and beneficial effects.

It will be appreciated by those skilled in the art that embodiments of the present application may be provided as a method, system, or computer program product.

Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining 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, and the like) 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 flow and/or block of the flowchart illustrations and/or block diagrams, and combinations of flows 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 apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks. These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks. These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

In one typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory. The memory may include volatile memory in a computer-readable medium, random Access Memory (RAM) and/or nonvolatile memory, etc., such as Read Only Memory (ROM) or flash RAM. Memory is an example of a computer-readable medium.

Computer readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of storage media for a computer include, but are not limited to, phase change memory (PRAM), static Random Access Memory (SRAM), dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), read Only Memory (ROM), electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices, or any other non-transmission medium, which can be used to store information that can be accessed by a computing device. Computer-readable media, as defined herein, does not include transitory computer-readable media (transmission media), such as modulated data signals and carrier waves.

It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one … …" does not exclude the presence of other like elements in a process, method, article or apparatus that comprises an element.

Note that the above is only a preferred embodiment of the present application and the technical principle applied. It will be understood by those skilled in the art that the present application is not limited to the particular embodiments described herein, but is capable of various obvious changes, rearrangements and substitutions as will now become apparent to those skilled in the art without departing from the scope of the application. Therefore, while the application has been described in connection with the above embodiments, the application is not limited to the embodiments, but may be embodied in many other equivalent forms without departing from the spirit or scope of the application, which is set forth in the following claims.

Claims

1. A method for managing images applied to a server, comprising:

2. 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 comprises at least one second snapshot, and the third image file comprises a second snapshot name of the corresponding second snapshot.

3. The image management method according to claim 2, wherein the first image has at least one version recorded in the server, each version corresponding to one second snapshot in the second image file and being associated with the second image file, a first image file corresponding to a first snapshot name in the second image file, and a third image file corresponding to the second snapshot, each version having a corresponding version ID.

4. A method of managing images according to claim 3, wherein said first image has at least one image branch recorded in said server, each of said image branches containing at least one version, and said first terminal applies one image branch of said first image.

5. The image management method according to claim 3, further comprising:

Acquiring a first image file and a second image file;

hard-linking the first image file and the second image file to the first image, respectively;

creating a corresponding version directory based on the initial second snapshot of the second image file, and hard-linking the first image file and the second image file into the version directory respectively to obtain the first image.

6. The image management method according to claim 5, wherein after the hard linking of the first image file and the second image file into the version directory, respectively, further comprising:

and creating a corresponding third image file based on the initial second snapshot.

7. The image management method according to claim 5 or 6, wherein when the first image file and the second image file are hard-linked to the first image respectively, further comprising:

creating an image record of the first image, and adding image metadata of the first image into the image record;

when the corresponding version directory is created based on the initial second snapshot of the second image file, the method further comprises:

and creating a version record corresponding to the initial second snapshot, and recording version metadata of a version corresponding to the initial second snapshot in the version record.

8. The image management method according to claim 3, further comprising:

receiving a third image file uploaded by the first terminal;

acquiring a current version ID of the first mirror image in the first terminal;

searching a second image file corresponding to the version ID;

submitting the third image file to the second image file to obtain a new second image file;

creating a new second snapshot in the new second image file.

9. The image management method according to claim 8, further comprising, after creating a new second snapshot in the new second image file:

deleting the third image file;

a new third image file is created based on the new second snapshot.

10. The image management method according to claim 8, wherein said submitting the third image file to the second image file includes:

restoring the second image file to a second snapshot corresponding to the third image file;

renaming the restored second image file to enable the second image file to use a second snapshot name of the second snapshot;

And submitting the third image file to the renamed second image file.

11. The image management method according to claim 9, wherein the first image records a corresponding snapshot list in the server, and each version of the first image and a second snapshot corresponding to each version are recorded in the snapshot list;

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

and updating the snapshot list and updating the mirror metadata in the mirror record.

12. The image management method according to claim 3, further comprising:

receiving a mirror image restoration instruction;

according to the mirror image restoration instruction, a version ID to be restored is obtained;

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

and restoring the second image file to a corresponding second snapshot according to the second snapshot name.

13. The image management method according to claim 12, wherein after restoring the second image file to the corresponding second snapshot according to the second snapshot name, further comprising:

deleting a third image file corresponding to the second image file;

A new third image file is created based on the restored second snapshot.

14. The image management method according to claim 3, further comprising:

receiving a mirror image cloning instruction, wherein the mirror image cloning instruction is used for cloning the first mirror image;

and cloning the first image file and the second image file contained in the first image to obtain a second image, wherein the second image is a cloned image.

15. The image management method according to claim 14, wherein cloning the second image from the first image file and the second image file included in the first image includes:

generating a mirror image record and a version catalog of a second mirror image according to the mirror image cloning instruction, wherein mirror image metadata of the first mirror image are recorded in the mirror image record of the second mirror image;

creating a hard link of a first image file in the first image in the version directory;

copying a second image file in the first image into the version directory;

maintaining a target version in the copied second image file and deleting other versions, wherein the target version is determined by the image cloning instruction;

And updating the mirror metadata in the mirror record of the second mirror.

16. The image management method according to claim 15, wherein when generating the image record and the version directory of the second image according to the image clone instruction, the method further comprises:

marking the second mirror image as waiting for cloning;

when updating the mirror metadata in the mirror record of the second mirror, the method further comprises:

the second image is marked as a completed clone state.

17. A mirror image management method is applied to a first terminal, and is characterized in that the first terminal applies a first mirror image, the first mirror image comprises a first mirror image file and a second mirror image file, the first mirror image file records an operating system used by a cloud desktop in the first terminal, the second mirror image file records a device driver and an application program which are installed based on the operating system,

the method comprises the following steps:

sending a first downloading request to a server of the cloud desktop;

18. The image management method according to claim 17, further comprising:

operating the cloud desktop according to the first image file, the second image file and the corresponding third image file which are locally present, and writing newly added data into the third image file in the operation process;

and uploading the third image file to the server so that the server submits the third image file to the corresponding second image file.

19. The image management method according to claim 17, further comprising:

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

and sending 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.

20. A mirror image management apparatus applied to a server, comprising:

21. An image management device is applied to a first terminal, and is characterized in that the first terminal applies a first image, the first image comprises a first image file and a second image file, the first image file records an operating system used by a cloud desktop in the first terminal, the second image file records a device driver and an application program installed based on the operating system,

the device comprises:

22. A mirror management server, comprising:

the communication module is used for realizing data communication;

one or more processors;

a memory for storing one or more programs;

the one or more programs, when executed by the one or more processors, cause the one or more processors to implement the image management method of any of claims 1-16.

23. A mirror image management terminal, comprising:

the communication module is used for realizing data communication;

one or more processors;

a memory for storing one or more programs;

the one or more programs, when executed by the one or more processors, cause the one or more processors to implement the image management method of any of claims 17-19.

24. A computer-readable storage medium, on which a computer program is stored, characterized in that the program, when being executed by a processor, implements the image management method according to any one of claims 1 to 16 or implements the image management method according to any one of claims 17 to 19.