WO2023197862A1 - Procédés de gestion d'images miroir, appareil, serveur, terminal et support de stockage - Google Patents

Procédés de gestion d'images miroir, appareil, serveur, terminal et support de stockage Download PDF

Info

Publication number
WO2023197862A1
WO2023197862A1 PCT/CN2023/084551 CN2023084551W WO2023197862A1 WO 2023197862 A1 WO2023197862 A1 WO 2023197862A1 CN 2023084551 W CN2023084551 W CN 2023084551W WO 2023197862 A1 WO2023197862 A1 WO 2023197862A1
Authority
WO
WIPO (PCT)
Prior art keywords
image
image file
snapshot
terminal
file
Prior art date
Application number
PCT/CN2023/084551
Other languages
English (en)
Chinese (zh)
Inventor
龙小斌
Original Assignee
广州视源电子科技股份有限公司
广州视睿电子科技有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 广州视源电子科技股份有限公司, 广州视睿电子科技有限公司 filed Critical 广州视源电子科技股份有限公司
Publication of WO2023197862A1 publication Critical patent/WO2023197862A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G06F8/658—Incremental updates; Differential updates

Definitions

  • Embodiments of the present application relate to the field of cloud desktop technology, and in particular, to an image management method, device, server, terminal and storage medium.
  • Cloud desktop also known as desktop virtualization and cloud computer, is a new model that replaces traditional computers. It uses virtualization technology to virtualize various physical devices, thereby effectively improving resource utilization and saving costs. , improve application quality.
  • IDV Intelligent Desktop Virtualization
  • IDV uses distributed computing and distributed storage, with the characteristics of centralized management and local execution, that is, using the local computing and storage resources of the terminal, so that even if there is a problem with the network connecting to the server, the normal use of the cloud desktop can be guaranteed.
  • the image file of the cloud desktop needs to be distributed to the terminal.
  • the image file records the operating system, device drivers, applications, etc. required to run the cloud desktop.
  • the server needs to re-deliver the updated image file to the terminal.
  • the image file has a large memory.
  • the image file needs to be frequently delivered to the terminal, which consumes more network resources.
  • One embodiment of the present application provides an image management method, device, server, terminal and storage medium to solve the technical problem in related technologies that the server consumes a lot of network resources when delivering image files to the terminal.
  • an embodiment of the present application provides an image management method, which is applied to a server and includes:
  • the first terminal applies a first image
  • the first image includes a first image file and a second image file
  • the first image file records the first terminal
  • the operating system used by Zhongyun Desktop the second image file records device drivers and applications installed based on the operating system;
  • the new second image file is sent to the first terminal, so that the first terminal uses the received second image file.
  • the file replaces the local original second image file and creates a corresponding third image file based on the set second snapshot in the received second image file.
  • the first image also includes the third image file, and the third image file is The third image file records data newly added when the cloud desktop is running in the state of setting the second snapshot;
  • the new second image file and the third image file are sent to the third image file.
  • a terminal so that the first terminal uses the received second image file to replace the local original second image file, and the third image file is generated based on the second snapshot of the settings in the new second image file. .
  • an embodiment of the present application also provides an image management method, applied to a first terminal, where the first terminal applies a first image, and the first image includes a first image file and a second image file,
  • the first image file records the operating system used by the cloud desktop in the first terminal, and the second image file records device drivers and applications installed based on the operating system, including:
  • the first image also includes the third image file.
  • the third image file records the location of the cloud desktop. The data added when running in the second snapshot state is set as described above;
  • the third image file is generated based on the set second snapshot in the new second image file
  • an embodiment of the present application also provides an image management device, which is applied to a server and includes:
  • the first receiving unit is configured to receive the first download request sent by the first terminal.
  • the first terminal applies a first image.
  • the first image includes a first image file and a second image file.
  • the first image file The operating system used by the cloud desktop in the first terminal is recorded, and the second image file records device drivers and applications installed based on the operating system;
  • a first sending unit configured to send the new second image file to the first terminal when the first download request is used to download a new second image file from the server, so that the first
  • the terminal uses the received second image file to replace the local original second image file and creates a corresponding third image file based on the set second snapshot in the received second image file.
  • the first image also includes the third image file. Three image files, the third image file records data newly added when the cloud desktop is running in the state of setting the second snapshot;
  • a second sending unit configured to, when the first download request is used to download a new second image file and the corresponding third image file from the server, send the new second image file and the corresponding third image file to the server.
  • the image file is sent to the first terminal, so that the first terminal uses the received second image file to replace the local original second image file, and the third image file is based on the new second image file.
  • the second snapshot of the settings is generated.
  • an embodiment of the present application also provides an image management device, applied to a first terminal, the first terminal applies a first image, and the first image includes a first image file and a second image file,
  • the first image file records the operating system used by the cloud desktop in the first terminal, and the second image file records device drivers and applications installed based on the operating system.
  • the device includes:
  • the third sending unit is used to send the first download request to the server of the cloud desktop
  • a first download unit configured to receive the new second image file sent by the server when the first download request is used to download a new second image file from the server;
  • the first replacement unit is used to replace the original local second image file with the received second image file
  • a first creation unit configured to create a corresponding third image file based on the set second snapshot in the received second image file, where the first image also includes the third image file, and the third image file records There is data newly added when the cloud desktop is running in the state of setting the second snapshot;
  • a second download unit configured to receive the new second image file sent by the server when the first download request is used to download a new second image file and the corresponding third image file from the server. and the third image file, the third image file is generated based on the set second snapshot in the new second image file;
  • the second replacement unit is used to replace the original local second image file with the received second image file.
  • an image management server including:
  • Communication module used to implement data communication
  • processors one or more processors
  • Memory used to store one or more programs
  • the one or more processors When the one or more programs are executed by the one or more processors, the one or more processors are caused to implement the image management method as described in the first aspect.
  • an image management terminal including:
  • Communication module used to implement data communication
  • processors one or more processors
  • Memory used to store one or more programs
  • the one or more processors When the one or more programs are executed by the one or more processors, the one or more processors are caused to implement the image management method as described in the second aspect.
  • an embodiment of the present application further provides a computer-readable storage medium on which a computer program is stored.
  • the program is executed by a processor, the image management method as described in the first aspect or the image management method as described in the second aspect is implemented. Described image management method.
  • the server receives the first download request sent by the first terminal, and delivers the second image file of the first image center to the first terminal based on the first download request, so that the first terminal uses the new
  • the second image file replaces the local second image file, so that the first terminal uses the new second image file when the first terminal runs the cloud desktop, and all new data added during the operation of the first terminal is written into the new
  • the technical means of creating a third image file corresponding to the second image file solves the technical problem in related technologies that the server needs to consume a lot of network resources to deliver the image file to the terminal.
  • the server By dividing the image into three levels of files, and when the first terminal downloads a new image file, the server does not need to deliver all the image files, but only the second image file, which reduces the memory for downloading files and saves money. Use network resources and reduce download time. Moreover, since the third image file is a blank file after creation, even if the corresponding third image file needs to be delivered, only a small amount of network resources will be occupied, ensuring the rational use of network resources.
  • Figure 1 is a first schematic diagram of the image file distribution process in related technologies
  • Figure 2 is a second schematic diagram of the image file distribution process in related technologies
  • Figure 3 is a schematic diagram of a mirroring relationship provided by an embodiment of the present application.
  • Figure 4 is a flow chart of an image management method provided by an embodiment of the present application.
  • Figure 5 is a flow chart of an image management method provided by an embodiment of the present application.
  • Figure 6 is an image registration flow chart provided by an embodiment of the present application.
  • Figure 7 is a flow chart of an image management method provided by an embodiment of the present application.
  • Figure 8 is a flow chart of image merging provided by an embodiment of the present application.
  • Figure 9 is a flow chart of an image management method provided by an embodiment of the present application.
  • Figure 10 is an image restoration flow chart provided by an embodiment of the present application.
  • Figure 11 is a flow chart of an image management method provided by an embodiment of the present application.
  • Figure 12 is an image cloning flow chart provided by an embodiment of the present application.
  • Figure 13 is a flow chart of an image management method provided by an embodiment of the present application.
  • Figure 14 is a schematic structural diagram of an image management device provided by an embodiment of the present application.
  • Figure 15 is a schematic structural diagram of an image management device provided by an embodiment of the present application.
  • Figure 16 is a schematic structural diagram of an image management device provided by an embodiment of the present application.
  • Figure 1 is the first schematic diagram of the image file distribution process in related technologies.
  • the terminal that is, the end user
  • the server determines that the download request is legal
  • it sends the basic image file to the terminal.
  • the terminal starts the virtual machine based on the basic image file. , to run cloud desktop.
  • the basic image file is also an image file.
  • the terminal is customized based on the basic image file, it can add its own personalized data during operation.
  • Figure 2 is a second schematic diagram of the image file distribution process in related technologies.
  • the terminal when the terminal needs to download an image file, it sends a download request to the server. After the server determines that the download request is legal, it sends the differential image file to the terminal. The terminal merges the differential image file into the basic image file. After that, the terminal The basic image file starts the virtual machine to run the cloud desktop.
  • the differential image file refers to the image file obtained by using differential technology.
  • the image file when running a cloud desktop based on an image file, the image file usually needs to be updated during the management of the image file. For example, after the server upgrades the image file, the image file needs to be updated. For another example, when a terminal uses a cloud desktop, after filling in its own personalized data into the image file, the image file needs to be updated.
  • scheme 1 to distribute the image file
  • the server upgrades the image file no matter the size of the change, all terminals using the image file need to re-download the full amount of the image file, which consumes a lot of network resources and requires a lot of time. The long download time is not conducive to the unified update of image files by the terminal.
  • Image file which not only requires each terminal to download the complete image file, but also requires the terminal used by the administrator to upload the complete image file, which increases the network resources required for the download and upload process and the transmission time, which is not conducive to the server's use of the image file. manage. At this time, due to the limitations of public network bandwidth, the popularity and application of IDV-type cloud desktops have also been greatly hindered.
  • embodiments of the present application provide an image management method, device, server, terminal and storage medium to ensure reasonable utilization and saving of network resources when managing image files in a scenario where the terminal runs an IDV-type cloud desktop.
  • the transfer takes time.
  • An embodiment of the present application provides an image management method.
  • the image management method can be executed by an image management device.
  • the image management device can be composed of two or more physical entities, or it can be composed of one physical entity.
  • the image management device is an image management server (also called a server).
  • the server can be used as a server of the IDV type cloud desktop to implement image (image) management and provide terminals with the necessary information to run the cloud desktop.
  • Image file can be any terminal that supports virtualization.
  • the terminal can be a personal computer, a tablet computer, an interactive tablet, a mobile phone, etc.
  • virtualization usually means that computing elements run on a virtual basis rather than a real basis. Virtualization technology can expand the capacity of hardware and simplify the reconfiguration process of software.
  • a virtual machine is a way of realizing virtualization.
  • a virtual machine refers to a complete computer system with complete hardware system functions simulated through software and running in a completely isolated environment.
  • terminals run cloud desktops through virtual machines. .
  • Image can also be recorded as an image file, which is a file that the terminal relies on when starting a virtual machine.
  • each image includes three types of image files.
  • the three types of image files can be recorded as: BaseImage, LowerIamge and UpperImage.
  • BaseImage records the operating system, which is used by the cloud desktop.
  • BaseImage records pure operations without operating system applications or additional device drivers.
  • Each image can have an independent BaseImage, or multiple images can share the same BaseImage.
  • the BaseImage is used by the image in the form of a hard link, which can save storage space on the server.
  • the hard link is Refers to one or more file names of a file, that is, multiple file names are used to link to the same file. These file names can be in the same directory or different directories.
  • the BaseImage can be read but will not be modified to protect the BaseImage from damage.
  • LowerImage is a sub-disk of BaseImage, that is, LowerImage is created based on BaseImage and serves as the next-level file of BaseImage.
  • LowerImage records content such as device drivers and applications installed based on the operating system.
  • each Guest image carries an initial LowerImage for different terminal models.
  • the LowerImage contains built-in applications and device drivers when the terminal under the corresponding model runs the operating system. After that, the user can derive his or her own LowerImage based on the initial LowerImage.
  • the LowerImage contains personalized data during the user's use, such as the user's newly installed device drivers, applications, saved files or data, etc.
  • each user can have an independent LowerImage.
  • UpperImage is a sub-disk of LowerImage, that is, UpperImage is created based on LowerImage and serves as a lower-level file of LowerImage.
  • UpperImage records the data newly added when the terminal runs the cloud desktop.
  • the UpperImage can be considered as a blank file, and no user-related data is recorded.
  • the current newly added data is recorded in the UpperImage.
  • the data recorded in the UpperImage can be submitted to the LowerImage to add personalized data during the user's use in the LowerImage.
  • BaseImage, LowerIamge and UpperImage can also be considered as three levels of files included in the image.
  • an image snapshot refers to a restore point of an image file at a certain moment, that is, the image file can be restored from any state to the state corresponding to the snapshot (ie, the restore point).
  • Each snapshot has a corresponding snapshot name.
  • the naming rules for snapshot names are currently not limited. Generally speaking, the snapshot name contains a unique identifier to distinguish each snapshot through the snapshot name.
  • BaseImage, LowerIamge and UpperImage can all create snapshots.
  • Each image file can be searched for its corresponding snapshot list. For example, the snapshot list corresponding to LowerIamge records the name of each snapshot it contains, and LowerIamge can find the required snapshot based on the snapshot list.
  • a unique snapshot is created in BaseImage, and a LowerIamge is created based on the state of BaseImage at the time of the unique snapshot.
  • a LowerIamge is created based on the state of BaseImage at the time of the unique snapshot.
  • multiple snapshots are created in LowerIamge.
  • a Driver snapshot after installing the device driver built into the operating system in the LowerIamge, and install the application built into the operating system (also called a basic application) Create an application snapshot.
  • the LowerImage can be restored to the state when the device driver and application were installed.
  • the terminal's new personalized data can also be written into it, and corresponding snapshots can be created based on the written personalized data.
  • a corresponding UpperImage can be created based on a certain snapshot status of LowerIamge, that is, UpperImage corresponds to a snapshot of LowerIamge. Similar to creating LowerIamge, UpperImage records the snapshot name of its corresponding snapshot in LowerIamge, so as to pass LowerIamge in UpperImage. Find the corresponding LowerIamge based on the snapshot name and determine the corresponding snapshot in LowerIamge.
  • the corresponding UpperImage can be generated. At this time, when the terminal runs the cloud desktop based on the LowerIamge under the snapshot, it can write in the UpperImage that the snapshot is used as the node.
  • the server submits the UpperImage to LowerIamge, that is, writes the personalized data under the corresponding snapshot node to LowerIamge.
  • a new snapshot can be created in LowerIamge, and the corresponding UpperImage can be created again based on the new snapshot.
  • the terminal runs the cloud desktop based on the LowerIamge corresponding to the new snapshot and writes the new data in the UpperImage.
  • the snapshot of LowerIamge is used as a distinction, and the new data added by the terminal is written to the UpperImage corresponding to the snapshot, without modifying BaseImage and LowerIamge in the terminal.
  • each snapshot in LowerIamge corresponds to a version (also called a mirror version or revision). That is, when a new snapshot is created in LowerIamge, it can be considered that a new version is created.
  • switching operations can be achieved by switching different snapshots of LowerIamge.
  • different versions Each version has a corresponding version ID. The version ID is unique. Its specific naming rules are currently not limited.
  • Each version also has a corresponding version UUID (that is, the universal unique identification code of the version).
  • each user has his own independent LowerImage file.
  • each user's version data is stored in his own LowerImage file in the form of a built-in snapshot. Only your own LowerImage files are allowed to be downloaded.
  • Each version of the same user corresponds to a built-in snapshot in LowerIamge.
  • the snapshot name of the built-in snapshot is version UUID. Through the snapshot name of the built-in snapshot, you can determine whether the current corresponding version can be used by the user.
  • each version and the snapshot name of the corresponding snapshot can be associated and recorded in the snapshot list. You can find the corresponding snapshot name through the version. You can find the corresponding LowerIamge through the snapshot name.
  • each version of each image has an associated BaseImage, LowerIamge, and UpperImage.
  • each version has a corresponding version record and version directory, where the version record is used to record metadata (used to describe the attributes of the version) and other contents of the version, and the version directory is used to record its associated BaseImage and LowerIamge, optionally, the version directory can also record its associated UpperImage.
  • BaseImage is linked to the version directory as a hard link, and BaseImage can be shared between different versions.
  • an image can have one or more branches (also called image version branches, branches), a branch can have one or more versions, and each user who uses the image can have an independent branch.
  • branches also called image version branches, branches
  • a branch can have one or more versions
  • each user who uses the image can have an independent branch.
  • Different images or different branches of the same image can share a BaseImage.
  • Figure 3 is a schematic diagram of an image relationship provided by an embodiment of the present application, which exemplarily shows the relationship between images, branches, and versions, as well as the relationship between BaseImage, LowerIamge, and UpperImage.
  • a BaseImage can be used by multiple images through hard links.
  • Figure 3 contains image A and image B.
  • Image A contains branch a
  • image B contains branch b and branch c.
  • Branch a is used by user A, who has an independent LowerIamge (LowerIamgeA).
  • LowerIamgeA includes snapshot A1 (SnapshotA1), snapshot A2 (SnapshotA2) and snapshot A3 (SnapshotA3). Snapshot A1 corresponds to version 1, and snapshot A2 Corresponds to version 2, and snapshot A3 corresponds to version 3. Each snapshot can generate the corresponding UpperImage. It is understandable that Figure 3 is an example to facilitate the description of the corresponding relationship between snapshots and versions. The snapshots included in LowerIamgeA are shown in a dotted box. ,In actual applications, the snapshot is included in LowerIamgeA. Moreover, pointing snapshot A1, snapshot A2 and snapshot A3 to UpperImageA in Figure 3 means that each snapshot will create a corresponding UpperImage, not that the three snapshots share one UpperImage.
  • Branch b is used by user B
  • branch c is used by user c.
  • the relationship between the snapshots, versions, and three types of files corresponding to branch b and branch c is similar to that of branch a, and will not be described in detail at this time.
  • a file chain can be formed between BaseImage, LowerIamge and UpperImage, which can avoid confusion of file relationships between different branches.
  • the terminal For the terminal, its virtual machine needs to have BaseImage, LowerIamge and UpperImage at the same time. Moreover, the virtual machine can be started directly based on the UpperImage, without merging BaseImage, LowerIamge and UpperImage into one file.
  • the server also stores an image table (osimages). There are multiple image records recorded in the image table. Each image record corresponds to an image and is used to record the metadata of the image (used to describe the attributes of the image) and other contents.
  • the BaseImage, LowerIamge and UpperImage stored in the server can be downloaded and used by the terminal.
  • BaseImage, LowerIamge and UpperImage are available for terminal download in the form of seed files, that is, the server can respectively generate the BaseImage seed file corresponding to BaseImage, the LowerIamge seed file corresponding to LowerIamge, and the UpperImage seed file corresponding to UpperImage.
  • the torrent file refers to the P2P download of the torrent file.
  • P2P peer-to-peer
  • P2P peer-to-peer
  • the users mentioned above refer to users who use terminals.
  • One user can use different terminals, one terminal can be used by multiple users, and each user can be distinguished by the user ID used when logging in.
  • Figure 4 is a flow chart of an image management method provided by an embodiment of the present application.
  • the server executes the image management method, it may include:
  • Step 110 Receive the first download request sent by the first terminal.
  • the first terminal applies the first image.
  • the first image includes a first image file and a second image file.
  • the first image file records the cloud desktop used by the first terminal. operating system, the second image file records device drivers and applications installed based on the operating system.
  • the server provides services for a terminal to describe how the server implements image management.
  • the terminal where the server provides services is recorded as the first terminal.
  • the image used by the first terminal is recorded as the first image, that is, the first terminal runs the cloud desktop through the first image.
  • the BaseImage, LowerIamge, and UpperImage used are recorded as the first image file, the second image file, and the third image file respectively.
  • the snapshot in the second image file is recorded as the second snapshot
  • the snapshot in the first image file is recorded as the first snapshot.
  • the first image file contains a unique first snapshot
  • the second image file contains the first snapshot name of the first snapshot
  • the second image file contains at least one second snapshot
  • the third image file contains the corresponding first snapshot.
  • the second snapshot name of the second snapshot wherein, the snapshot name of the first snapshot is recorded as the first snapshot name
  • the snapshot name of the second snapshot is recorded as the second snapshot name.
  • the second image file used when the first terminal runs the cloud desktop corresponds to one version
  • the third image file used is generated based on the corresponding snapshot of the version in the second image file.
  • the first image has at least one version recorded in the server.
  • Each version corresponds to a second snapshot in the second image file and is associated with the second image file, the first image file corresponding to the first snapshot name in the second image file, and Each version of the third image file corresponding to the second snapshot has a corresponding version ID.
  • running the first image on the first terminal can be considered as running a branch of the first image.
  • the first image is recorded in the server with at least one image branch, each image branch includes at least one version, and the first terminal applies one image branch of the first image.
  • the first image run by the terminal may be specifically a version under the image branch. In this case, the first image ID mentioned later may also be considered as the ID of the image branch in the first image.
  • the first terminal Before the first terminal runs the cloud desktop for the first time, it needs to download the first image file and the second image file from the server, and then create a third image file based on its own actual determination or download the third image file from the server.
  • the third image file can be created in combination with the second snapshot corresponding to the current version.
  • the server can generate the third image file and deliver it to the first terminal.
  • the first terminal runs the virtual machine based on the first image file, the second image file and the third image file, and runs the cloud desktop through the virtual machine.
  • the first terminal When the first terminal has a need for version update, a corresponding download request is generated, and a corresponding second image file is obtained from the server based on the download request, so as to implement version update based on the second image file.
  • the download request generated by the first terminal is recorded as the first download request.
  • the first image file and the second image file have been stored locally, and the second image file may record the user's personalized data, or may not have the user's personalized data added.
  • the method of generating the first download request is currently not limited.
  • the server determines that the version of the second image file is updated (that is, a new version is generated), it sends a notification of the version update to the first terminal using the second image file, and then , the user of the first terminal can determine whether to update the version based on the notification, and when determining to update the version, generate a first download request and send it to the server.
  • a first download request is generated and sent to the server.
  • the server can complete the creation of the restore point through the first terminal.
  • the first terminal generates the first download request, and Send to the server, or the first terminal generates a first download request before uploading the third image file, and sends the third image file and the first download request to the server together.
  • the first download request is divided into two types. One type is used to download the second image file from the server. At this time, the first The terminal can create a third image file locally based on the second image file. Another type is used to download the second image file and the third image file from the server. It is understandable that when the first terminal has the function of creating a third image file first, it can also choose to download the third image file from the server.
  • the server After the server receives the first download request, it parses it and determines that it is used to download the second image file, and then executes step 120 to determine that it is used to download the second image file. image file and the third image file, perform step 130.
  • the first terminal writes an identifier of whether the first terminal can generate the third image file in the first download request, so that the server determines whether the third image file needs to be sent based on the identifier.
  • the server pre-records the terminal model that can locally generate the third image file.
  • the terminal model of the first terminal is written in the first download request, and the server determines the first download request based on the first download request. The terminal model in the request determines whether a third image file needs to be sent.
  • the server can also have the function of creating a third image file.
  • the first download request is only used to download a new second image file from the server, or the terminals provided by the server can Each terminal does not have the function of creating a third image file.
  • the first download request is only used to download a new second image file and the corresponding third image file from the server.
  • the server may generate the third image file regardless of whether the terminal has the function of creating the third image file. In this case, the first download request is only used to download a new second image file from the server.
  • Step 120 When the first download request is used to download a new second image file from the server, send the new second image file to the first terminal, so that the first terminal uses the received second image file to replace the local original image file.
  • the second image file is a second image file and a corresponding third image file is created based on the second snapshot of settings in the received second image file.
  • the first image also includes a third image file, and the third image file records the settings of the cloud desktop in the third image file. Data newly added when running in the second snapshot state.
  • the second image file downloaded by the first terminal from the server and the local original second image file can be considered as different versions of the same second image file. There are differences in the contents of the second image file under different versions. This is In order to facilitate the distinction, the downloaded second image file is recorded as the new second image file.
  • the first download request is used to download a new second image file from the server.
  • the server parses it to find the new second image file that needs to be downloaded.
  • the first download request may include the version ID that currently needs to be downloaded.
  • the version ID that currently needs to be downloaded may be issued by the server to the first terminal.
  • the server performs a version update
  • the current version The ID is sent to the first terminal.
  • the version ID that currently needs to be downloaded can be selected by the user of the first terminal. For example, after logging in, the user of the first terminal can search the server for each version corresponding to the second image file currently used in the first image. , and then select the version that currently needs to be downloaded.
  • the server can display to the user the versions that are available for the user, while the versions that are not available for the user will not be displayed, or the server can Set different permissions for different users. Only users with specific permissions can perform version search.
  • the server obtains the version ID and searches for the second image file associated with the corresponding version as the new second image file.
  • the first download request may include the image ID of the first image.
  • the server finds the latest version of the second image file in the first image for use by the first terminal according to the image ID, and adds the The second image file associated with the latest version is used as the new second image file.
  • the first download request may include the image ID and the version ID.
  • the server finds the new second image file based on the image ID and the version ID.
  • the first download request includes a user ID
  • the server determines the first image used by the first terminal based on the user ID, and uses the latest version of the second image file in the first image for use by the first terminal as the new third image.
  • Two image files. The server can also determine the new second image file through other methods.
  • the server delivers the new second image file to the first terminal.
  • the first terminal uses the new second image file to replace the original local second image file to implement version updating.
  • the third image file corresponding to the current version needs to be used to record the data newly added when the first terminal runs the cloud desktop based on the current version.
  • the first terminal obtains the second image file corresponding to the current version. a second snapshot, and generate a third image file based on the second snapshot, that is, the third image file is generated based on the second snapshot set in the second image file (currently the second snapshot corresponding to the updated version). After that, the first terminal can run the cloud desktop based on the current version.
  • the original version of the first terminal may also have a corresponding third image file.
  • the user can determine whether the data recorded in the original third image file needs to be discarded before the version is updated. If so, then You can directly delete the third image file locally, that is, give up modifications to the original version; if you do not need to give up, you can upload the third image file to the server first, and the server will submit the third image file to the corresponding second image. file, and then the server creates a new version based on the submission result, and the second image file corresponding to the new version can be used as a new second image file for the first terminal to download. After the first terminal uploads the third image file, it can delete the local third image file, or associate and save the third image file with the corresponding version, or the server can associate and save the third image file with the corresponding version.
  • Step 130 When the first download request is used to download the new second image file and the corresponding third image file from the server, send the new second image file and the third image file to the first terminal, so that the first The terminal uses the received second image file to replace the local original second image file, and the third image file is generated based on the set second snapshot in the new second image file.
  • the third image file is generated in the server.
  • the server when the server creates a snapshot (ie, a version) of the second image file, it generates a third image file corresponding to the version, and when receiving the first download request, combines the second image file and the corresponding third image file. The three image files are sent to the first terminal together.
  • the server parses the first download request after receiving it to find the new second image file that needs to be downloaded and the corresponding third image file.
  • the corresponding third image file can be searched according to the version of the new second image file.
  • the server sends the found new second image file and the corresponding third image file to the first terminal.
  • the first terminal uses the new second image file to replace the original local second image file to update the version, and then runs the cloud desktop based on the current version. And write the newly added data into the third image file corresponding to the current version.
  • the original version of the first terminal may also have a corresponding third image file.
  • the processing of the third image file refer to the relevant description in step 120, which will not be described again at this time.
  • the server receives the first download request sent by the first terminal, and delivers the second image file of the first image center to the first terminal based on the first download request, so that the first terminal uses the new second image file to replace
  • the local second image file enables the first terminal to use the new second image file when the first terminal runs the cloud desktop, and the new data added during the operation of the first terminal is written into the new second image file corresponding to
  • the technical means of the third image file solves the technical problem in related technologies that the server needs to consume a lot of network resources to deliver the image file to the terminal.
  • the server By dividing the image into three levels of files, and when the first terminal downloads a new image file, the server does not need to deliver all the image files, but only the second image file, which reduces the memory for downloading files and saves money. Use network resources and reduce download time. Moreover, since the third image file is a blank file after creation, even if the corresponding third image file needs to be delivered, only a small amount of network resources will be occupied, ensuring the rational use of network resources.
  • the image in the server needs to be registered before it can be used by the terminal.
  • the first image is taken as an example to describe the image registration process.
  • Figure 5 is a flow chart of an image management method provided by an embodiment of the present application. It is a specific process when the server performs image registration and management. Referring to Figure 5, the image management method includes:
  • Step 210 Obtain the first image file and the second image file.
  • first image file and the second image file After the first image file and the second image file are created, they need to be uploaded to the server first for server registration.
  • the first image file and the second image file can be uploaded separately or at the same time to create the first image file.
  • the first image file and the second image file currently uploaded can be considered as the initial BaseImage and the initial LowerImage respectively.
  • the second image file is created based on the first image file.
  • the process of uploading the first image file and the second image file can also be considered as the process of the server obtaining the first image file and the second image file.
  • Step 220 Hard link the first image file and the second image file to the first image respectively.
  • the first image file and the second image file are hard-linked to the first image respectively, that is, the first image file and the second image file currently used by the first image are clearly defined. It is understood that if the second image file is used by a branch, then when the first image file and the second image file are hard-linked to the first image, they can be connected to the branch to which they belong. Later, when a new branch of the first image is created, the image metadata of the first image can be updated based on the second image file used by the new branch, and then the first image text and the second image file used by the new branch can be updated. Hard link to the first image (specifically the new Branch) in.
  • hard linking the first image file and the second image file to the first image respectively also includes: creating an image record of the first image, and adding image metadata of the first image to the image record.
  • the image metadata of the first image describes the attributes of the first image.
  • the image metadata records the branches included in the first image and the user ID corresponding to each branch.
  • the image metadata may be determined based on the first image file and the second image file.
  • the image metadata is recorded in the image record.
  • a mirror record of the first mirror is created, the mirror record is added to the mirror table, and then the mirror metadata of the first mirror is added to the mirror record.
  • the image metadata in the image record is also updated simultaneously.
  • the above process can also be considered as the image registration process.
  • Step 230 Create a corresponding version directory based on the initial second snapshot of the second image file, and hard-link the first image file and the second image file to the version directory respectively to obtain the first image.
  • the first image file contains a unique first snapshot.
  • the file name of the first image file is changed to the first snapshot name of the first snapshot.
  • the first snapshot name is recorded.
  • create an initial second snapshot after the second image file is created.
  • the second image file contains the device drivers and applications built into the operating system.
  • the user can derive his or her own second image file based on the second image file.
  • the first image file and the initial second image file (which only contains device drivers and vendor-built applications and generates a second snapshot) can be created by the vendor of the first image and uploaded to the server. Subsequent users generate their own snapshots based on the second image file (this time, including personalized data, such as application upgrade patches).
  • the version ID can be determined, and when creating a version directory, the version ID corresponding to the version directory can be recorded to associate the version with the version directory.
  • both the first image file and the second image file are added in the version directory in the form of hard links.
  • the first image file it is first hard-linked to the first image, and then the first image file in the first image is hard-linked to the version directory, and the second image file and the first image file are The hard connection process is similar and will not be described in detail at this time.
  • the terminal downloads the corresponding image through the seed file, after hard linking the first image file and the second image file to the version directory, it is also necessary to create corresponding P2P images for the first image file and the second image file respectively. Download the torrent file to enable the terminal to download.
  • when creating a corresponding version directory based on the initial second snapshot of the second image file it also includes: creating a version record corresponding to the initial second snapshot, and recording the version corresponding to the initial second snapshot in the version record. Version metadata.
  • a version record is also created.
  • the version record can also be associated with the version through the version ID.
  • the version metadata of the version is determined based on the first image file and the second image file used in the version.
  • the version metadata may include user ID, version ID, pre-order version ID, etc.
  • the pre-order version refers to the previous version of the current version, that is, the version before the current version is created in the second image file.
  • Version metadata can be updated in conjunction with version attributes. Afterwards, the version metadata is added to the version record corresponding to the version.
  • step 240 is also included after step 230.
  • Step 240 Create a corresponding third image file based on the initial second snapshot.
  • the server creates a corresponding third image file based on the initial second snapshot.
  • a feasible method is to change the file name of the second image file to the snapshot name of the initial second snapshot, so as to record the snapshot of the second snapshot in the third image file when creating the third image file. name.
  • the implementation method of adding the third image file to the version directory is currently not limited.
  • the first terminal Before the first terminal runs the cloud desktop for the first time, it needs to download the first image file of the first image, the initial second image file, and the third image file corresponding to the initial second image file from the server (currently downloading the seed file , and then obtain the corresponding image file based on the seed file). During subsequent updates, there is no need to download the first image file again.
  • the third image file can also be created by the first terminal.
  • the first terminal may notify the server so that the server adds the third image file in the corresponding version directory.
  • Figure 6 is an image registration flow chart provided by an embodiment of the present application. Referring to Figure 6, it shows the process of image uploading and registration as well as the processing method of image files under each process.
  • image upload is performed first, that is, the required files are uploaded.
  • Figure 6 takes the first image file and the second image file as an example.
  • the server obtains the first image file and the second image file respectively.
  • image registration image metadata of the first image is generated, and the corresponding file processing method is to hard-link the first image file and the second image file to the first image respectively.
  • the initial restore point refers to the initial second snapshot of the second image file.
  • the corresponding file processing method is to create a version directory of the corresponding version and register the image.
  • the first image file and the second image file hard-linked during the process are hard-linked to the version directory respectively.
  • a corresponding third image file is created based on the initial second snapshot of the second image file.
  • the first terminal after downloading the first image file and the initial second image file, the first terminal builds the first image file and the initial second image file.
  • image files can be reused through hard links, and the first image file and the second image file are uploaded and registered independently, which facilitates subsequent image management. For example, when the version is updated, only modifications are required. The second image file does not need to modify the first image file.
  • image merging management when the server is managed, image merging management is also required.
  • Image merging can be understood as writing the user personalized data recorded in the UpperImage into the corresponding LowerImage, so as to add the user's data in the LowerImage.
  • Personalized data Currently, the first image is taken as an example to describe the image merging process. Among them, the first image is recorded in the server with a corresponding snapshot list. The snapshot list records each version of the first image and the second snapshot corresponding to each version. Optionally, the snapshot list records each version ID and the corresponding second snapshot. Snapshot name.
  • Figure 7 is a flow chart of an image management method provided by an embodiment of the present application. It is a process when the server performs image merge management. Referring to Figure 7, the image management method includes:
  • Step 310 Receive the third image file uploaded by the first terminal.
  • the new data ie, the user's personalized
  • the first terminal installs a new application or a new application in the cloud desktop.
  • new applications and new device drivers are written into the third image file.
  • the first terminal stores new files and data in the cloud desktop
  • the new files or data are written into the third image file. in the file.
  • the third image file can be uploaded to the server.
  • an image merging request can also be sent. to enable the server to perform image merging.
  • the server before merging images, the server first determines the first image used by the first terminal, and then locks the first image.
  • the technical means used to determine the first image used by the first terminal are not currently limited.
  • the server when the first terminal uploads the third image file, it informs the server of the first image used by itself.
  • the server records Each terminal using each image, when the first terminal uploads the third image file, informs the first terminal of its identity data (such as user ID, etc.), and then The server determines the first image used by the first terminal based on the identity data.
  • the purpose of locking the first image is to prohibit the first image from being downloaded. At this time, each terminal cannot download various sub-files included in the first image.
  • the third image file already contains the second snapshot name, and the server can find the corresponding version, the second image file, and other contents based on the second snapshot name. Therefore, the first terminal does not need to perform version verification before uploading the third image file.
  • the third image file can be uploaded in a differential manner.
  • Step 320 Obtain the current version ID of the first image in the first terminal.
  • the server determines the version ID currently used by the first terminal, that is, the ClientRevisionId. For example, when the first terminal uploads the third image file, the server can directly obtain the version ID by uploading the version ID. Another example is, after the first terminal uploads the third image file, the server obtains the records in the third image file by parsing the third image file. The second snapshot name of the second snapshot, and then, based on the second snapshot name, search the corresponding version in the snapshot list to obtain the version ID. For example, the server parses the version metadata corresponding to the version currently used by the first terminal to obtain the version ID. The version ID is obtained from the metadata, where the server can search for the version record of the version currently used by the first terminal, and then obtain the version ID based on the version metadata in the version record.
  • Step 330 Search for the second image file corresponding to the version ID.
  • each data stored in the server can be stored in a database, that is, BaseImage, LowerImage, and UpperImage are all stored in the database.
  • the server After the server obtains the version ID, it searches for the corresponding second image file in the database based on the version ID.
  • the corresponding version directory can be found according to the version ID, and the Client UpperIamge Path and LowerIamge Path can be obtained according to the records in the version directory. Or, obtain the corresponding second snapshot name based on the version ID, and obtain the Client UpperIamge Path and LowerIamge Path based on the second snapshot name. After that, the corresponding second image file can be obtained according to the LowerIamge Path.
  • Step 340 Submit the third image file to the second image file to obtain a new second image file.
  • the data recorded in the third image file is written into the second image file in the form of information blocks to achieve image merging.
  • the submission of the third image file to the second image file can also be considered as a commit process.
  • the third image file is submitted to the second image file, it can be considered that the second image file has been updated.
  • the submitted second image file is recorded as the new third image file. Two image files.
  • step 340 may include steps 341 to 343:
  • Step 341 Restore the second image file to the second snapshot corresponding to the third image file.
  • the corresponding second snapshot is determined according to the second snapshot name recorded in the third image file, and then the second image file is restored to a state corresponding to the second snapshot.
  • Step 342 Rename the restored second image file so that the second image file uses the second snapshot name of the second snapshot.
  • the file name of the second image file is modified to the second snapshot name of the new second snapshot, so as to clarify the version currently used by the second image file.
  • Step 343 Submit the third image file to the renamed second image file.
  • Step 350 Create a new second snapshot in the new second image file.
  • the new second image file adds the user's personalized data, and then a new second snapshot is created for the second image file for subsequent needs.
  • creating a new second snapshot generate a snapshot name for the new second snapshot.
  • creating a new snapshot can also be understood as creating a new version. At this time, you can create a new version record and version directory, add new version metadata to the new version record, and add new version metadata to the version directory. The first image file, second image file and third image file corresponding to this version are recorded in.
  • each UpperIamge has a unique identifier. Different UpperIamges can be distinguished through the unique identifier.
  • the unique identifier can be generated when the UpperIamge is created.
  • the first terminal uploads the third image file, it provides a unique identifier of the third image file.
  • the second image file creates a corresponding new second snapshot, the unique identifier can be used as the corresponding second snapshot name. That is, the requirement for uniqueness of the second snapshot name is met.
  • steps 360 to 370 are also included:
  • Step 360 Delete the third image file.
  • the third image file can be deleted.
  • the first terminal may be notified to delete the third image file.
  • Step 370 Create a new third image file based on the new second snapshot.
  • a new second snapshot is created in the new second image file. Therefore, a new third image file needs to be created based on the new second snapshot to use the new second image file on the first terminal. Record the newly added data in the new third image file. It can be understood that the new third image file contains the snapshot name of the new second snapshot.
  • step 380 may also be included.
  • Step 380 Update the snapshot list and update the image metadata in the image record.
  • the snapshot list of the first image is updated to add the new second snapshot and the version corresponding to the new second snapshot in the snapshot list.
  • corresponding seed files can be created for the new second image file and the new third image file respectively for the first terminal to download.
  • updating the image record can be performed after creating the seed file.
  • the first image After updating the image metadata of the first image, the first image is unlocked for download by the first terminal.
  • the server notifies the first terminal of a version update.
  • the first terminal After that, the first terminal generates a first download request for downloading the new second image file and the corresponding third image file and sends it to the server.
  • the new second image file and the corresponding third image file are sent to the first terminal for use by the first terminal.
  • this step can also be performed after creating a new second snapshot in the new second image file.
  • Figure 8 is an image merging flow chart provided by an embodiment of the present application.
  • the version metadata i.e. ClientRevisionmeta
  • the clientRevisionID the version ID used by the terminal
  • the clientRevisionID is retrieved from the database based on the ClientRevisionID.
  • Find the Client UpperImage Path that is, the path of the third image file used by the terminal
  • the LowerImage Path that is, the path of the second image file.
  • the newly added data when the first terminal runs the cloud desktop is written to the third image file, and the first image file and the second image file will not be modified. Therefore, when there is a need for image merging on the first terminal or server, You only need to upload the local third image file to the server, and then the server submits the third image file to the second image file. This reduces the amount of data uploaded by the first terminal, improves upload speed and efficiency, and saves network resources. , thereby improving the efficiency and speed of image merging.
  • FIG. 9 is a flow chart of an image management method provided by an embodiment of the present application. It is a process when the server performs image restoration management. Referring to the figure, the image management method includes:
  • Step 410 Receive the image restoration instruction.
  • the image restoration instruction is used to instruct the server to perform image restoration, which can be generated at the terminal or at the server.
  • the server When the server generates the image restoration instruction, the user of the server (such as an administrator with certain permissions) can select The LowerImage that needs to be restored and the version that needs to be restored. After that, the server generates an image restoration instruction based on the selection, and then receives the image restoration instruction.
  • the image restoration instruction is used to restore the second image file in the first image as an example for description.
  • the server determines to perform image restoration and locks the first image used by the first terminal.
  • the process of locking the first image can refer to the process of locking the first image in step 310, which is not currently performed. Repeat.
  • Step 420 Obtain the version ID to be restored according to the image restoration instruction.
  • the version ID to be restored refers to the version ID to which the second image file is expected to be restored.
  • the image restore command includes the version ID to be restored.
  • the server calls the corresponding parameter according to the image restoration instruction to obtain the version ID to be restored through the parameter.
  • the parameter called is presented in the form of a string variable and may include the image ID of the first image, The user ID, version ID and other contents of the first terminal.
  • Step 430 Search the corresponding second image file and the corresponding second snapshot name according to the version ID.
  • each second snapshot corresponds to a version
  • obtain the second snapshot name Corresponds to the second image file where the second snapshot is located.
  • Step 440 Restore the second image file to the corresponding second snapshot according to the second snapshot name.
  • the second image file is restored according to the second snapshot corresponding to the second snapshot name, that is, restored to the state of the second image file when the second snapshot was created.
  • the second image file The user's personalization data added to the file will be deleted.
  • the server creates a third image file. At this time, after step 440, steps 450 and 460 are also included.
  • Step 450 Delete the third image file corresponding to the second image file.
  • the third image file corresponding to the second image file before the change that is, the old third image file needs to be deleted.
  • Step 460 Create a new third image file based on the restored second snapshot.
  • a corresponding third image file is created based on the restored second snapshot, and the third image file can be considered as a new third image file corresponding to the second image file.
  • seed files corresponding to the second image file and the third image file are respectively generated for the first terminal to download.
  • the image record corresponding to the first image in the image table also needs to be updated.
  • it also includes:
  • Step 470 Update the image metadata in the image record.
  • the server can unlock the first image so that the first terminal can download the corresponding seed file.
  • the server can notify the first terminal to complete the image restoration.
  • the first terminal generates the corresponding first download instruction according to the notification from the server and feeds it back to the server, and the server executes the first download instruction.
  • the restored second image file is pushed to the first terminal as a new second image file.
  • the server records the latest version ID of each image, and after the image is restored, changes the latest version ID of the corresponding image to the restored version ID.
  • Figure 10 is a flow chart of an image restoration provided by an embodiment of the present application.
  • first lock the corresponding image and then parse the parameters of the call (i.e. Parse Args) to get the ImageID and RevisionID.
  • LowerImage is restored to the corresponding target Snapshot.
  • delete the old UpperImage create a new UpperImage, create seed files for LowerImage and UpperImage respectively, update the image record in the image table, unlock the image, and resume the download of the image to complete the image restoration.
  • FIG. 11 is a flow chart of an image management method provided by an embodiment of the present application. It is a process when the server performs image cloning management. Referring to the figure, the image management method includes:
  • Step 510 Receive an image cloning instruction, which is used to clone the first image.
  • the image cloning instruction is used to instruct the server to perform image cloning.
  • the first image is used as the cloned image.
  • the image clone instruction can be considered as being used to clone the first image.
  • the image cloning instruction may be issued by the user in the first terminal or server, or may be issued by the administrator of the image in the server.
  • write the ID of the restored image in the image restore command so that the server can determine the restored image (currently, the image restore command writes The image ID of the first image).
  • the image restore command can also include the ID of the version that needs to be cloned.
  • the user's personalized data may be recorded in the first image, for data security, only administrators with certain permissions can issue image cloning instructions, or only users can use the second image for themselves. Clone an image.
  • Step 520 Clone the first image file and the second image file included in the first image to obtain a second image, and the second image is the cloned image.
  • the image cloned based on the first image is recorded as the second image.
  • the first image file used in the first image since the first image file used in the first image only records the operating system and will not be modified during use, the first image file can be shared by the second image.
  • the first image Files can be linked to the secondary image via hard links.
  • the second image file in the first image can be copied to the second image, and then a corresponding third image file can be created based on the second image file to ensure that the third image file is used through the three levels of image files. The second image is used normally.
  • step 510 may include steps 511 to 516:
  • Step 511 Generate an image record and a version directory of the second image according to the image cloning instruction, and record the image metadata of the first image in the image record of the second image.
  • image registration that is, create an image record and version directory of the second image, and also create a version record of the second image.
  • image metadata of the first image is first written in the image record of the second image.
  • Step 512 Create a hard link to the first image file in the first image in the version directory.
  • the second image and the first image share the first image file. Therefore, the first image file is connected to the second image in a hard link. Currently, the first image file is hard linked to the second image. version directory.
  • Step 513 Copy the second image file in the first image to the version directory.
  • each image needs to have its own LowerImage
  • when cloning copy the second image file used in the first image and paste it in the version directory of the second image to clarify the second image
  • the second image file used It can be understood that the currently copied second image file includes all current second snapshots.
  • Step 514 Keep the target version in the copied second image file and delete other second versions.
  • the target second version is determined through the image cloning instruction.
  • the initialized second image file can be considered as the initial second image file in the second image.
  • the metadata corresponding to the target version can be processed in the version record of the second image. Record.
  • the version directory mentioned in steps 511 to 513 can be considered as the version directory corresponding to the target version.
  • the server generates the third image file. Therefore, after step 514, it may also include: creating a corresponding third image file based on the target version.
  • a corresponding third image file is created based on the second image file in the second image.
  • the third image file corresponds to the target version of the second image file, that is, the third image file contains the second image file corresponding to the target version.
  • the second snapshot name of the snapshot is the second snapshot name of the snapshot.
  • seed files of the second image file and the third image file are respectively created for the terminal to download. It is understandable that when the terminal downloads the image for the first time and the downloaded image is the second image, the server passes the hard disk in the version directory. The link can find the first image file and send the seed file of the first image file to the terminal for use by the terminal.
  • Step 515 Update the image metadata in the image record of the second image.
  • the image metadata of the first image recorded in the image record will also change after the second image file is initialized. Therefore, the image metadata is currently based on the initialized
  • the second image file updates the image metadata in the image record of the second image.
  • the second image may contain multiple states to indicate the current clone node of the second image through different states.
  • the image record and version directory of the second image are generated according to the image cloning instruction. When, it also includes: marking the second image as waiting for cloning. When updating the image metadata in the image record of the second image, it also includes: marking the second image as a completed clone state.
  • the waiting clone state refers to the state waiting for cloning to start
  • the completed clone state refers to the state when the clone is completed and can be used.
  • the cloning status can also be included, which means that cloning is in progress.
  • mark the second image when generating the image record and version directory of the second image, mark the second image as waiting for cloning, and when copying the second image file in the first image to the version directory, mark the second image as waiting for cloning.
  • the cloning state of the second image is changed to the completed cloning state.
  • Figure 12 is an image cloning flow chart provided by an embodiment of the present application.
  • the image metadata which is the image metadata of the new image obtained after cloning, and generate the image record, initial version record and initial version directory of the new image.
  • the new image In waiting state (waiting).
  • copy the LowerImage of the source image to the initial version directory initialize the copied LowerImage, and retain the target version.
  • based on LowerImage creates UpperImage creates seed files for LowerImage and UpperImage respectively, updates the image record in the image table, and changes the new image to the clone completion status to complete the image cloning.
  • the image management device in addition to a server, can also be an image management terminal.
  • the terminal can also be considered as a terminal for users.
  • the terminal can be a personal computer, a tablet computer, an interactive tablet, a mobile phone, etc.
  • the terminal implements a cloud desktop by running a virtual machine.
  • the image required when the terminal is running can be obtained from the server.
  • the image management method can be implemented.
  • the first terminal is taken as an example to describe how the terminal performs the image management method.
  • Figure 13 is a flow chart of an image management method provided by an embodiment of the present application. Referring to Figure 13, when the first terminal executes the image management method, it may include:
  • Step 610 Send the first download request to the server of the cloud desktop.
  • the first terminal applies a first image.
  • the first image includes a first image file and a second image file.
  • the first image file records the operating system used by the cloud desktop in the first terminal, and the second image file records Device drivers and applications installed based on the operating system.
  • the first terminal After generating the first download request, the first terminal sends the first download request to the server.
  • step 620 is executed.
  • step 650 is executed.
  • Step 620 When the first download request is used to download a new second image file from the server, receive the new second image file sent by the server.
  • Step 630 Use the received second image file to replace the original local second image file.
  • the new second image file sent by the server is used as the second image file for local use.
  • the first terminal considers that the version has been changed.
  • the initial second image file can always be saved locally, and other versions of the second image file can be saved in the first terminal or deleted in the first terminal as versions are replaced.
  • Step 640 Create a corresponding third image file based on the setting of the second snapshot in the received second image file.
  • the first image also includes a third image file.
  • the third image file records that the cloud desktop is setting the second snapshot. Data added when running in the state.
  • the latest second snapshot in the received second image file is used as the set second snapshot, and a corresponding third image file is created locally based on the set second snapshot. After that, run the cloud desktop.
  • Step 650 When the first download request is used to download the new second image file and the corresponding third image file from the server, receive the new second image file and the third image file sent by the server, and the third image file is based on the new The second snapshot is generated based on the settings in the second image file.
  • Step 660 Use the received second image file to replace the original local second image file.
  • the first terminal needs to update the first image, it only needs to obtain the new second image file from the server and replace it. There is no need to obtain the first image file, which solves the problem in the related technology that the server delivers the image file to The terminal needs to consume more network resources due to technical issues.
  • the third image file is a blank file after creation, even if the corresponding third image file needs to be downloaded, it only takes up very few network resources, ensuring the rational use of network resources.
  • the first terminal can submit the newly added data during the operation of the local cloud desktop to the second image file for version upgrade (ie, image merging).
  • the first terminal executes the image management method When running, it may also include: running the cloud desktop based on the local existing first image file, second image file and corresponding third image file, and writing the newly added data into the third image file during the running process;
  • the third image file is uploaded to the server, so that the server submits the third image file to the corresponding second image file.
  • the first terminal when the first terminal starts the virtual machine, it needs to have the first image file, the second image file and the third image file, and the virtual machine is started directly based on the third image file, without merging the three types of files, and in the virtual machine
  • the cloud desktop is running on the computer
  • the newly added data is recorded in the third image file.
  • the user needs to create a restore point for the current running status while running the cloud desktop, that is, create a new version
  • the user can send the currently used third image file to the server and instruct the server to merge the images.
  • the server will follow the instructions. Submit the third image file to the corresponding second image file.
  • the server notifies the first terminal that the merger is completed.
  • the first terminal can generate a first download instruction based on the server's notification to download the second snapshot corresponding to the created restore point. the second image file, and create or download the corresponding third image file from the server based on the actual situation.
  • the third image file is used to write new data
  • the user of the first terminal wants to give up modifying the cloud desktop, he only needs to delete the current third image file and rebuild the third image. file or obtain the third image file from the server, which simplifies the image restoration process in the first terminal.
  • the first terminal writes the newly added data to the third image file and does not modify the first image file and the second image file. Therefore, when creating a new version, only the local third image file needs to be Once the three image files are uploaded to the server, a new version can be created in the server, which greatly reduces the amount of uploaded data and improves upload efficiency.
  • the first terminal can also synchronize the second image file used locally to the second terminal to run the cloud desktop in the first terminal in the second terminal.
  • the first terminal executes the image
  • the management method may also include: receiving a synchronization request sent by the second terminal, and the second terminal uses the same first image file as the first terminal; sending the locally existing second image file to the second terminal, so that the second terminal The second terminal uses the received second image file to replace the original second image file.
  • the second terminal can be a terminal that implements physical cloud desktop drift, that is, the cloud desktop used by the first terminal is moved to the second terminal for use.
  • the second terminal can also be a terminal replaced by the user, that is, the user uses the second terminal. Replaces the currently used first terminal.
  • the second terminal has run the cloud desktop and has stored the first image file and the second image file.
  • the first terminal can send its second image file to the second terminal.
  • the second terminal Use the received second image file to replace its own second image file to ensure that the cloud desktop in the first terminal runs.
  • the second terminal has not run Cloud Desktop.
  • the second terminal can first download the files of each layer contained in the first image from the server, and then replace its own second image with the received second image file. document.
  • the second terminal may create the third image file based on the set version in the received second image file, or the server may create the third image file and send it to the second image file.
  • the first terminal when the first terminal sends the second image file to the second terminal, it can send it directly to the second terminal, or send it to the second terminal through the server.
  • the second image file and the generated third image file can be sent to the second terminal together.
  • the second terminal after the second terminal is synchronized, it can be recorded in the server so that the server can know the image version currently used by the second terminal.
  • FIG 14 is a schematic structural diagram of an image management device provided by an embodiment of the present application.
  • the image management device is applied to a server.
  • the image management device includes: a first receiving unit 701, a first sending unit 702 and a second sending unit 703.
  • the first receiving unit 701 is configured to receive a first download request sent by a first terminal.
  • the first terminal applies a first image.
  • the first image includes a first image file and a second image file.
  • the first image file records the first terminal.
  • the operating system used by Zhongyun Desktop the second image file records device drivers and applications installed based on the operating system;
  • the first sending unit 702 is used to download a new second image from the server when the first download request is made file, sending the new second image file to the first terminal, so that the first terminal uses the received second image file to replace the local original second image file and based on the settings in the received second image file.
  • the snapshot creates a third image file corresponding to the first image.
  • the first image also contains the third image file.
  • the third image file records the data newly added when the cloud desktop is running in the state of setting the second snapshot; the second sending unit is used for When the first download request is used to download the new second image file and the corresponding third image file from the server, the new second image file and the third image file are sent to the first terminal, so that the first terminal uses the receive
  • the second image file replaces the original local second image file, and the third image file is generated based on the second snapshot setting in the new second image file.
  • the first image file contains a unique first snapshot
  • the second image file contains the first snapshot name of the first snapshot
  • the second image file contains at least one second snapshot
  • the third image file contains the corresponding first snapshot.
  • the first image is recorded in the server with at least one version, and each version corresponds to a second snapshot in the second image file and is associated with the second image file and the first snapshot name in the second image file.
  • Each version of the first image file and the third image file corresponding to the second snapshot has a corresponding version ID.
  • the first image is recorded in the server with at least one image branch, each image branch includes at least one version, and the first terminal applies one image branch of the first image.
  • the method further includes: a first acquisition unit, used to acquire the first image file and a second image file; a first linking unit, used to convert the first image file and the second image file are respectively hard-linked to the first image; the second link unit is used to create a corresponding version directory based on the initial second snapshot of the second image file, and hard-link the first image file and the second image file respectively. Go to the version directory and get the first image.
  • the method further includes: a first creation unit configured to create a corresponding third image file based on the initial second snapshot after hard-linking the first image file and the second image file to the version directory respectively.
  • the first link unit is also used to: create a mirror record of the first mirror, and add the mirror metadata of the first mirror to the mirror record; the second link unit is also used to: create an initial second snapshot corresponding to version record, and record the version metadata of the corresponding version of the initial second snapshot in the version record.
  • the system further includes: a second receiving unit for receiving the third image file uploaded by the first terminal; a second obtaining unit for obtaining the current version ID of the first image in the first terminal; and a first search unit. , used to find the second image file corresponding to the version ID; the submission unit is used to submit the third image file to the second image file to obtain a new second image file; the second creation unit is used to create a new second image file in the new image file. Create a new second snapshot in the second image file.
  • the first deletion unit is used to delete the third image file after creating a new second snapshot in the new second image file; the third creation unit is used to create a new image file based on the new second snapshot. Third image file.
  • the submission unit includes: a first restoration sub-unit, used to restore the second image file to the second snapshot corresponding to the third image file; a renaming sub-unit, used to restore the restored second image file Renaming is performed so that the second image file uses the second snapshot name of the second snapshot; the file submission subunit is used to submit the third image file to the renamed second image file.
  • the first image is recorded in the server with a corresponding snapshot list, and the snapshot list records each version of the first image and the second snapshot corresponding to each version; the device further includes: a first update unit, configured to After creating a new second snapshot in the new second image file, update the snapshot list and update the image metadata in the image record.
  • a first update unit configured to After creating a new second snapshot in the new second image file, update the snapshot list and update the image metadata in the image record.
  • the method further includes: a third receiving unit, configured to receive an image restoration instruction; a third acquisition unit, configured to obtain the version ID to be restored according to the image restoration instruction; and a second search unit, configured to search according to the version ID.
  • the corresponding second image file and the corresponding second snapshot name; the second restoration unit is used to restore the second image file to the corresponding second snapshot according to the second snapshot name.
  • the method further includes: a second deletion unit, configured to restore the second image file to the corresponding second snapshot according to the second snapshot name, and then delete the third image file corresponding to the second image file; a fourth creation Unit used to create a new third image file based on the second snapshot restored to.
  • a second deletion unit configured to restore the second image file to the corresponding second snapshot according to the second snapshot name, and then delete the third image file corresponding to the second image file
  • a fourth creation Unit used to create a new third image file based on the second snapshot restored to.
  • the method further includes: a fourth receiving unit, configured to receive an image cloning instruction, which is used to clone the first image; and a cloning unit, configured to clone the first image according to the first image file and the second image contained in the first image.
  • the file is cloned to obtain a second image, and the second image is the cloned image.
  • the cloning unit includes: a generation subunit, configured to generate an image record and a version directory of the second image according to the image cloning instruction, and the image metadata of the first image is recorded in the image record of the second image; a third link The subunit is used to create a hard link to the first image file in the first image in the version directory; the copy subunit is used to copy the second image file in the first image to the version directory; the third deletion subunit is, It is used to retain the target version and delete other versions in the copied second image file.
  • the target version is determined by the image clone instruction; the second update subunit is used to update the image metadata in the image record of the second image.
  • the generation subunit is also used to mark the second image as waiting for cloning; the second update subunit is also used to mark the second image as cloning completed.
  • the image management device provided above can be used to execute the image management method executed by the server provided in any of the above embodiments, and has corresponding functions and beneficial effects.
  • Figure 15 is a schematic structural diagram of an image management device provided by an embodiment of the present application.
  • the image management device is applied to a first terminal.
  • the first terminal applies a first image.
  • the first image includes a first image file and a second image file.
  • the first image file records the operating system used by the cloud desktop in the first terminal.
  • Second mirror The file records device drivers and applications installed based on the operating system.
  • the image management device includes: a third sending unit 801, a first download unit 802, a first replacement unit 803, a first creation unit 804, a second Download unit 805 and second replacement unit 806.
  • the third sending unit 801 is used to send the first download request to the server of the cloud desktop; the first download unit 802 is used to receive the new second image file sent by the server when the first download request is used to download a new second image file from the server. the second image file; the first replacement unit 803 is used to replace the local original second image file with the received second image file; the first creation unit 804 is used to based on the settings in the received second image file
  • the second snapshot creates a corresponding third image file.
  • the first image also includes a third image file.
  • the third image file records the data newly added when the cloud desktop is running in the state of setting the second snapshot; the second download unit 805 , used when the first download request is used to download a new second image file and the corresponding third image file from the server, and receive the new second image file and the third image file sent by the server, and the third image file is based on The second snapshot of the settings in the new second image file is generated; the second replacement unit 806 is configured to replace the original local second image file with the received second image file.
  • it also includes: an operating unit, configured to run the cloud desktop based on the local existing first image file, the second image file and the corresponding third image file, and write the newly added data during the operation process. Enter the third image file; the upload unit is used to upload the third image file to the server, so that the server submits the third image file to the corresponding second image file.
  • the method further includes: a fifth receiving unit, configured to receive a synchronization request sent by a second terminal, which uses the same first image file as the first terminal; and a fourth sending unit, configured to transfer the local existing The second image file is sent to the second terminal, so that the second terminal uses the received second image file to replace the original second image file.
  • the image management device provided above can be used to execute the image management method executed by the first terminal provided in any of the above embodiments, and has corresponding functions and beneficial effects.
  • FIG 16 is a schematic structural diagram of an image management device provided by an embodiment of the present application.
  • the image management device may be an image management server or an image management terminal.
  • the image management device includes a processor 90, a memory 91 and a communication module 92; the number of processors 90 can be one or more, and one processor 90 is taken as an example in Figure 16.
  • the processor 90, the memory 91 and the communication module 92 in the image management device can be connected through a bus or other means. In Figure 16, connection through a bus is taken as an example.
  • the memory 91 can be used to store software programs, computer executable programs and modules, such as program instructions/modules corresponding to the image management method in the embodiment of the present application (for example, the image management device is an image management server When the image management device is the first receiving unit 701, the first sending unit 702 and the second sending unit 703, when the image management device is an image management terminal, the third sending unit 801 and the first downloading unit 802 in the image management device , first replacement unit 803, first creation unit 804, second download unit 805 and second replacement unit 806).
  • the processor 90 executes various functional applications and data processing of the image management device by running software programs, instructions and modules stored in the memory 91, that is, implementing the above image management method.
  • the memory 91 may mainly include a stored program area and a stored data area, wherein the stored program area may store an operating system and at least one application program required for a function; the stored data area may store data created according to the use of the image management device, etc.
  • 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.
  • the memory 91 may further include memory located remotely relative to the processor 90 , and these remote memories may be connected to the image management device through a network. Examples of the above networks include but Not limited to the Internet, intranet, local area network, mobile communication network and combinations thereof.
  • the communication device 92 is used to implement data communication according to instructions of the processor. For example, when the image management device is a server, it can perform data communication with the terminal. If the image management device is a terminal, it can perform data communication with the server.
  • the image management device may also include an input device and an output device.
  • the input device may be used to receive input numeric or character information and generate key signal input related to user settings and function control of the image management device. It may also include audio input devices such as microphones. .
  • Output devices may include displays, speakers, and other devices.
  • the above image management device includes a corresponding image management device, which can be used to execute the corresponding image management method provided by any embodiment, and has corresponding functions and beneficial effects.
  • one embodiment of the present application also provides a storage medium containing computer-executable instructions.
  • the computer-executable instructions When executed by a computer processor, the computer-executable instructions are used to perform relevant aspects of the image management method provided by any embodiment of the present application. operation, and has corresponding functions and beneficial effects.
  • the present application may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment that combines software and hardware aspects.
  • the present application may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein.
  • the present application is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the application. It will be understood that each process and/or block in the flowchart illustrations and/or block diagrams, and combinations of processes and/or blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions.
  • These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing device to produce a machine, such that the instructions executed by the processor of the computer or other programmable data processing device produce a use A device for realizing the functions specified in one process or multiple processes of the flowchart and/or one block or multiple blocks of the block diagram.
  • These computer program instructions may also be stored in a computer-readable memory that causes a computer or other programmable data processing apparatus to operate in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including the instruction means, the instructions
  • the device implements the functions specified in a process or processes of the flowchart and/or a block or blocks of the block diagram.
  • These computer program instructions may also be loaded onto a computer or other programmable data processing device, causing a series of operating steps to be performed on the computer or other programmable device to produce computer-implemented processing, thereby executing on the computer or other programmable device.
  • Instructions provide steps for implementing the functions specified in a process or processes of a flowchart diagram and/or a block or blocks of a block diagram.
  • a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
  • Memory may include non-volatile memory in computer-readable media, random access memory (RAM) and/or non-volatile memory in the form of read-only memory (ROM) or flash memory (flash RAM).
  • RAM random access memory
  • ROM read-only memory
  • flash RAM flash memory
  • Computer-readable media includes both persistent and non-volatile, removable and non-removable media that can be implemented by any method or technology for storage of information.
  • Information may be computer-readable instructions, data structures, modules of programs, or other data.
  • Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), and read-only memory.
  • PRAM phase change memory
  • SRAM static random access memory
  • DRAM dynamic random access memory
  • RAM random access memory
  • read-only memory read-only memory
  • ROM read-only memory
  • EEPROM electrically erasable programmable read-only memory
  • flash memory or other memory technology
  • compact disc read-only memory CD-ROM
  • DVD digital versatile disc
  • Magnetic tape cassettes tape magnetic disk storage or other magnetic storage devices or any other non-transmission medium can be used to store information that can be accessed by a computing device.
  • computer-readable media does not include transitory media, such as modulated data signals and carrier waves.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

La présente invention concerne des procédés de gestion d'images miroir, un appareil, un serveur, un terminal et un support de stockage. Un procédé comprend : la réception d'une première demande de téléchargement vers l'aval envoyée par un premier terminal, le premier terminal utilisant un premier fichier miroir et un deuxième fichier miroir, le premier fichier miroir enregistrant un système d'exploitation utilisé par un bureau en nuage dans le premier terminal, et le deuxième fichier miroir enregistrant un pilote de dispositif et un programme d'application qui sont installés sur la base du système d'exploitation ; et l'envoi d'un nouveau deuxième fichier miroir au premier terminal de sorte que le premier terminal remplace un deuxième fichier miroir local d'origine par le deuxième fichier miroir reçu et enregistre dans un troisième fichier miroir des données qui sont nouvellement ajoutées lorsque le bureau en nuage se déroule dans un état d'une seconde capture d'écran définie, le troisième fichier miroir étant généré sur la base de la seconde capture d'écran définie dans le deuxième nouveau fichier miroir, le troisième fichier miroir pouvant être généré par un serveur ou par le premier terminal. Le procédé peut être utilisé pour résoudre le problème technique de l'état de la technique selon lequel un serveur consomme beaucoup de ressources de réseau lorsqu'il émet un fichier miroir vers un terminal.
PCT/CN2023/084551 2022-04-13 2023-03-29 Procédés de gestion d'images miroir, appareil, serveur, terminal et support de stockage WO2023197862A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202210385398.XA CN116954681A (zh) 2022-04-13 2022-04-13 镜像管理方法、装置、服务器、终端及存储介质
CN202210385398.X 2022-04-13

Publications (1)

Publication Number Publication Date
WO2023197862A1 true WO2023197862A1 (fr) 2023-10-19

Family

ID=88328915

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2023/084551 WO2023197862A1 (fr) 2022-04-13 2023-03-29 Procédés de gestion d'images miroir, appareil, serveur, terminal et support de stockage

Country Status (2)

Country Link
CN (1) CN116954681A (fr)
WO (1) WO2023197862A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117873506A (zh) * 2024-03-12 2024-04-12 山东乾云启创信息科技股份有限公司 一种基于voi的镜像运行实现方法及系统

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN118260006A (zh) * 2024-03-19 2024-06-28 广东林泽科技股份有限公司 一种基于信创云桌面的数据部署方法以及系统

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105260229A (zh) * 2015-10-28 2016-01-20 北京百度网讯科技有限公司 拉取虚拟机镜像文件的方法和装置
CN105450759A (zh) * 2015-12-02 2016-03-30 浙江宇视科技有限公司 一种系统镜像的管理方法和装置
US20160092202A1 (en) * 2014-09-25 2016-03-31 International Business Machines Corporation Live Operating System Update Mechanisms
CN111221537A (zh) * 2018-11-23 2020-06-02 中兴通讯股份有限公司 云桌面升级方法、装置、云端服务器及存储介质
CN112882729A (zh) * 2019-11-29 2021-06-01 顺丰科技有限公司 应用镜像升级方法、装置、计算机设备和存储介质

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160092202A1 (en) * 2014-09-25 2016-03-31 International Business Machines Corporation Live Operating System Update Mechanisms
CN105260229A (zh) * 2015-10-28 2016-01-20 北京百度网讯科技有限公司 拉取虚拟机镜像文件的方法和装置
CN105450759A (zh) * 2015-12-02 2016-03-30 浙江宇视科技有限公司 一种系统镜像的管理方法和装置
CN111221537A (zh) * 2018-11-23 2020-06-02 中兴通讯股份有限公司 云桌面升级方法、装置、云端服务器及存储介质
CN112882729A (zh) * 2019-11-29 2021-06-01 顺丰科技有限公司 应用镜像升级方法、装置、计算机设备和存储介质

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117873506A (zh) * 2024-03-12 2024-04-12 山东乾云启创信息科技股份有限公司 一种基于voi的镜像运行实现方法及系统
CN117873506B (zh) * 2024-03-12 2024-06-11 山东乾云启创信息科技股份有限公司 一种基于voi的镜像运行实现方法及系统

Also Published As

Publication number Publication date
CN116954681A (zh) 2023-10-27

Similar Documents

Publication Publication Date Title
US11375008B2 (en) Consumption of data services provisioned in cloud infrastructures
US11356509B2 (en) Service and APIs for remote volume-based block storage
WO2023197862A1 (fr) Procédés de gestion d'images miroir, appareil, serveur, terminal et support de stockage
EP3408745B1 (fr) Mise à jour automatique d'une application hybride
JP5775177B2 (ja) クローンファイル作成方法と、それを用いたファイルシステム
US20190235968A1 (en) Archiving nas servers to the cloud
US11199985B2 (en) Tracking storage capacity usage by snapshot lineages using metadata in a multi-level tree structure
US10911540B1 (en) Recovering snapshots from a cloud snapshot lineage on cloud storage to a storage system
JP2022095781A (ja) データベーステナントマイグレーションのシステム及び方法
US20160259811A1 (en) Method and system for metadata synchronization
US9515878B2 (en) Method, medium, and system for configuring a new node in a distributed memory network
US10740192B2 (en) Restoring NAS servers from the cloud
US10852996B2 (en) System and method for provisioning slave storage including copying a master reference to slave storage and updating a slave reference
US10102083B1 (en) Method and system for managing metadata records of backups
JP2014503086A (ja) ファイルシステム及びデータ処理方法
CN103002027A (zh) 基于键值对系统实现树形目录结构的数据存储系统及方法
US11537553B2 (en) Managing snapshots stored locally in a storage system and in cloud storage utilizing policy-based snapshot lineages
US11288134B2 (en) Pausing and resuming copying of snapshots from a local snapshot lineage to at least one cloud snapshot lineage
US12032847B2 (en) Cross-platform replication of logical units
US11573923B2 (en) Generating configuration data enabling remote access to portions of a snapshot lineage copied to cloud storage
US10223206B1 (en) Method and system to detect and delete uncommitted save sets of a backup
CN113811867B (zh) 用于文件系统中的文件的硬链接操作
US10620883B1 (en) Multi-format migration for network attached storage devices and virtual machines
US20090254579A1 (en) Deploying directory instances
US10713121B1 (en) Dynamic migration of a cloud based distributed file system metadata server

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23787508

Country of ref document: EP

Kind code of ref document: A1