GUEST OS MANAGED POINT IN TIME SNAPSHOTS

Aspects of the disclosure provide solutions for managing point in time (PIT) snapshots by a guest operating system (OS) to provide more rapid start-up time for virtualized component (VC) clones (e.g., virtual machines, VMs) and simplify restoration. Examples include the guest OS determining that the VC has completed a boot process and is in a known good state. The guest OS instructs the hypervisor to store a PIT snapshot of the VC, including a memory state of the VC. Because the snapshot is captured while the VC is executing, it may be used as an instant clone that avoids delays caused by booting the clone. Some examples include the guest OS detecting a restoration point trigger (e.g., a configuration change) and determining that the VC currently has a stable configuration. The guest OS instructs the hypervisor to store a snapshot of the VC to use later as a restoration point.

RELATED APPLICATIONS

Benefit is claimed under 35 U.S.C. 119(a)-(d) to Foreign Application Serial No. 202241039360 filed in India entitled “GUEST OS MANAGED POINT IN TIME SNAPSHOTS”, on Jul. 8, 2022, by VMware, Inc., which is herein incorporated in its entirety by reference for all purposes.

BACKGROUND

In a virtual environment, in which virtual components (VCs) (e.g., containers and virtual machines (VMs)), system administrators spawn new VCs, often VC clones, to scale capacity with demand. Bringing up a new VM has a cost in terms of computational burden and time for boot-up, which may exceed the cost of bringing up a new container. This renders VMs a less-preferred option in some scenarios. Some solutions for reducing VM boot-up time do exist, but require privileges to access the hypervisor, which should be denied to most users to comport with best security practices. Thus, these solutions are unavailable to normal users when proper security practices are followed.

Additionally, system restore points for VMs are currently performed using the guest operating system (OS), which is the VM's own OS (not the host platform's OS). Unfortunately, traditional restoration solutions, which roll back individual configuration changes (e.g., software installations, patches, and updates) from within the VM may introduce instabilities. For example, a guest OS is updated and then applications running within the VM are also updated. If a need arises to roll back the guest OS update, this may render one or more of the application inoperable. Attempting to track down and resolve newly-introduced incompatibilities caused by the roll back of a single software component may be burdensome.

SUMMARY

Aspects of the disclosure provide solutions for managing point in time (PIT) snapshots by a guest operating system (OS), and include executing, by a computing platform, under control by a hypervisor, a virtualized component (VC) having a guest OS; determining, by the guest OS, that the VC has completed a boot process and is in a known good state; and while the VC is executing in the known good state, instructing, by the guest OS, the hypervisor to store a PIT snapshot of the VC, the PIT snapshot including a memory state of the VC.

Further aspects of the disclosure include executing, by a computing platform, under control by a hypervisor, a VC having a guest OS; detecting, by the guest OS, a restoration point trigger; determining, by the guest OS, that the VC has a stable configuration; and while the VC has a stable configuration, instructing, by the guest OS, the hypervisor to store a PIT snapshot of the VC.

DETAILED DESCRIPTION

Aspects of the disclosure provide solutions for managing point in time (PIT) snapshots by a guest operating system (OS) to provide more rapid start-up time for virtualized components (VCs), such as virtual machines (VMs), and simplify restoration of VCs. Examples include the guest OS determining that the VC has completed a boot process and is in a known “good” state. The guest OS instructs the hypervisor to store a PIT snapshot of the VC, including a memory state of the VC. Because the snapshot is captured while the VC is executing, it may be used as an instant clone that avoids delays caused by booting a clone. Some examples include the guest OS detecting a restoration point trigger (e.g., a configuration change) and determining that the VC currently has a stable configuration. The guest OS instructs the hypervisor to store a snapshot of the VC to use later as a restoration point.

Aspects of the disclosure reduce computing resources used when spawning VC clones at least by, while the VC is executing in the known good state, instructing, by the guest OS, the hypervisor to store a PIT snapshot of the VC that includes a memory state of the VC. The PIT snapshot may then be executed as an instant clone of the VC that bypasses a boot process to speed up execution and lower computational burden on the computing platform host, thereby reducing computing resources used when spawning VC clones. Additionally, this lower computational burden on the computing platform host reduces power consumption of the computing platform host.

Further aspects of the disclosure improve the reliability of computing operations, for example by, while the VC has a stable configuration, instructing, by the guest OS, the hypervisor to store a PIT snapshot of the VC. The PIT snapshot may then be used for restoration as the restored VC. This precludes uncertainties and risks presented by piecemeal roll-backs within the VC. Thus, aspects of the disclosure provide a practical, useful result to solve a technical problem in the domain of virtualized computing.

While aspects of the disclosure are described with example references to a known good state, those references are merely representative examples of when a VC has determined that a PIT snapshot is desired. These example references are not intended to be limiting. For example, a state that is known to a VC to be good may be described as any condition, criteria, state, or the like that the VC deems as ready or suitable for a PIT snapshot. Examples of such state include, but are not limited to the following: having a stable configuration, ready to immediately begin executing a new application, a processor of the VC is not loaded above a threshold, a processor of the VC is not currently engaging (e.g., reading to or writing from) swap memory, the VC is finished booting, the VC is not busy. However, other examples are contemplated, and may be defined by a user or administrator of the VC. Further, the VC may decide that it is in condition for a PIT snapshot even when the state is not good. For example, the VC may decide, based on current computing resource statistics of the VC, that its state is deteriorating and a PIT snapshot should be taken before there is further deterioration in the state.

FIG.1illustrates an architecture100that advantageously provides for guest OS managed last good known PIT snapshots on a computing platform102. In some examples, architecture100is implemented using a virtualization architecture, which may be implemented on one or more computing apparatus818ofFIG.8, and/or using a virtualization architecture200, as is illustrated inFIG.2. An example computing framework on which the components ofFIG.1may be implemented and executed uses a combination of virtual machines, containers, and serverless computing abstractions.

In the illustrated example, computing platform102hosts a VC110, which may be a VM or a container, and which executes under control by a hypervisor140for use by a user104. An administrator106, who may have a higher privilege level on computing platform102than does user104, sets up and configures VC110. For example, the administrator106updates, upgrades, or patches VC110with update software108. User employs VC110to perform one of any number of computing tasks associated with cloud computing, using an application116within a memory114of VC110. Application116may be business productivity software or other software useful to user104, and may be deployed as a container. User104may employ multiple ones of VC110(e.g., as clones), to employ multiple copies of application116simultaneously, or employ different applications on different VCs simultaneously.

As illustrated, VC110also has a processor112(e.g., virtualized), a timer118, and a guest OS120. Guest OS120has a snapshot manager122and a restoration manager124, and hypervisor140has a snapshot control142and a clone control144. Snapshot manager122, restoration manager124, snapshot control142, and clone control144perform operations described herein to manage VC110and its clones (e.g., instant clone130and a regular clone132). For example, some of the operations are described below in flowcharts400,500,550,600,650,700, and750ofFIGS.4,5A,5B,6A,6B,7A, and7B, respectively. Guest OS120and hypervisor140communicate with a channel146that bridges between guest OS120and hypervisor140. Examples of messages passing through channel146are shown in message diagram300ofFIG.3. In some examples, channel146comprises one or more application programming interfaces (APIs).

For example, hypervisor140performs snapshots and saves PIT snapshots151-154based at least on instructions received from guest OS120, and provides a list150of available PIT snapshots to guest OS120. For example, guest OS120is permitted to select a restoration point. Additionally, hypervisor140leverages PIT snapshots151and152, which are PIT snapshots of VC110that include memory114of VC110when VC110is in a known good state and has already completed booting up, to spawn instant clone130. Because it includes memory114of an executing version of VC110rather than a version of VC110in a non-executing state, instant clone130may begin executing more rapidly than clone132. For example, when clone132takes 10 to 20 seconds to begin executing application116because clone132needs to boot up, instant clone130may begin executing application116in approximately 1 or 2 seconds. This provides significant time savings for user104and reduces power consumption, processing resource consumption, and memory consumption of computing platform102. In some examples, PIT snapshots151and152are used to spawn instant clones, and PIT snapshots153and154are used for restoration (e.g., rollback of VC110to a prior version).

A PIT snapshot is a copy of a storage volume, file or database as it appears at a given point in time, and enables a user to select a specific version of VC110as it existed at a specific time. Some PIT snapshots store a disk snapshot of a VM, some also store a memory snapshot of an executing VM (e.g., memory114). Although storing the running memory requires more storage, it permits rapid performance as an instant clone that does not need to perform a boot process. In some examples, keeping PIT snapshots updated uses pointer remapping or copy-on-write (CoW). With pointer remapping, when new copies of a PIT snapshot are made, the more recent copy will maintain a mapping to the original copy. With CoW, when changes are made to data, only the data that is modified will be copied again, rather than make another full copy of the data set.

The PIT snapshots captured in the architecture are knowledge-based snapshots, because the knowledge of guest OS120is leveraged to select optimal time(s) for hypervisor140to perform the PIT snapshots. For example, guest OS has restore functionality that detects when changes are about to be made to VC110that merit creation of a backup restoration point. In some examples, backups may be made on a schedule (e.g., using timer118) and guest OS120knows to delay the start of a scheduled backup if VC110is not ready (e.g., VC110is in the middle of installing new software or is otherwise busy). In some examples, hypervisor140does not have the insight into the state of VC110to the same extent as guest OS120, and guest OS120is unable to perform the PIT snapshots. Thus, channel146enables the use of the capabilities of hypervisor140with the knowledge of guest OS120.

A machine learning (ML) component158may be used to fine-tune parameters of VC110, and recognition of when VC110is in a stable configuration or a known good state. As used herein, ML encompasses artificial intelligence (AI). The findings of ML component158may be provided to guest OS120as criteria for determining whether VC110is in a state suitable for a PIT snapshot, such as a known good state and/or a stable configuration. In some examples, only a fixed number of PIT snapshots are retained (e.g., a set number suitable for use as instant clones, and a set number suitable for use in restoration), and ML component158may be used to optimize the number. For example, ML component158adjusts the number of retained PIT snapshots.

Use cases for architecture100include scenarios in which a large number of containers are employed in a scalable service, and scenarios in which snapshots of a VM may be preferable to application-specific backups. For example, application116may be a database query engine, and VC may host a large database. In such scenarios, regular timed backups are common. It may be faster to create a PIT snapshot of the entirety of VC110using hypervisor140than for VC110to perform its own backup of a database.

Examples of architecture100are operable with virtualized and non-virtualized storage solutions.FIG.2illustrates a virtualization architecture200that may be used as a version of computing platform102. Virtualization architecture200is comprised of a set of compute nodes221-223, interconnected with each other and a set of storage nodes241-243according to an embodiment. In other examples, a different number of compute nodes and storage nodes may be used. Each compute node hosts multiple objects, which may be virtual machines (VMs, such as base objects, linked clones, and independent clones), containers, applications, or any compute entity (e.g., computing instance or virtualized computing instance) that consumes storage. When objects are created, they may be designated as global or local, and the designation is stored in an attribute. For example, compute node221hosts objects201,202, and203; compute node222hosts objects204,205, and206; and compute node223hosts objects207and208. Some of objects201-208may be local objects. In some examples, a single compute node may host50,100, or a different number of objects. Each object uses a VM disk (VMDK), for example VMDKs211-218for each of objects201-208, respectively. Other implementations using different formats are also possible. A virtualization platform230, which includes hypervisor functionality at one or more of compute nodes221,222, and223, manages objects201-208. In some examples, various components of virtualization architecture200, for example compute nodes221,222, and223, and storage nodes241,242, and243are implemented using one or more computing apparatus such as computing apparatus818ofFIG.8.

Virtualization software that provides software-defined storage (SDS), by pooling storage nodes across a cluster, creates a distributed, shared data store, for example a storage area network (SAN). Thus, objects201-208may be virtual SAN (vSAN) objects. In some distributed arrangements, servers are distinguished as compute nodes (e.g., compute nodes221,222, and223) and storage nodes (e.g., storage nodes241,242, and243). Although a storage node may attach a large number of storage devices (e.g., flash, solid state drives (SSDs), non-volatile memory express (NVMe), Persistent Memory (PMEM), quad-level cell (QLC)) processing power may be limited beyond the ability to handle input/output (I/O) traffic. Storage nodes241-243each include multiple physical storage components, which may include flash, SSD, NVMe, PMEM, and QLC storage solutions. For example, storage node241has storage251,252,252, and254; storage node242has storage255and256; and storage node243has storage257and258. In some examples, a single storage node may include a different number of physical storage components.

In the described examples, storage nodes241-243are treated as a SAN with a single global object, enabling any of objects201-208to write to and read from any of storage251-258using a virtual SAN component232. Virtual SAN component232executes in compute nodes221-223. Using the disclosure, compute nodes221-223are able to operate with a wide range of storage options. In some examples, compute nodes221-223each include a manifestation of virtualization platform230and virtual SAN component232. Virtualization platform230manages the generating, operations, and clean-up of objects201and202. Virtual SAN component232permits objects201and202to write incoming data from object201and incoming data from object202to storage nodes241,242, and/or243, in part, by virtualizing the physical storage components of the storage nodes.

FIG.3illustrates a message diagram300of messaging that may occur with examples of architecture100. Messages illustrated as passing between guest OS120and hypervisor140pass through channel146. Further details on the messages of message diagram300are provided in relation to flowcharts400,500,550,600, and650, and the example operations of those flowcharts are identified.

Message302represents the new installation (e.g., setup and configuration) of VC110, as described in operation402of flowchart400. Guest OS120instructs hypervisor140to create a PIT snapshot for an instant clone using message304(operation508of flowchart500). Creating a PIT snapshot for an instant clone involves storing the active memory of a running VC in the snapshot. Hypervisor140creates a PIT snapshot (e.g., PIT snapshot151) as shown as message306(operation510of flowchart500).

Based on a trigger condition (e.g., user input or detecting the pending installation of software108), guest OS120instructs hypervisor140to create a PIT snapshot for a backup (e.g., restore point) using message308(operation608of flowchart600). Creating a PIT snapshot for a restore point does not require storing the active memory of a running VC in the snapshot. Hypervisor140creates a PIT snapshot (e.g., PIT snapshot153) as shown as message310(operation610of flowchart600). Message312represents the installation of software108(e.g., new software, software update, patch, or the like).

Message314represents a request from user104, administrator106(or another source) to deploy a clone of VC110(operation414of flowchart400). Message316represents the deployment of instant clone130, in the scenario that PIT snapshot151is valid to use to spawn instant clone130(operation554of flowchart550). Message318represents the deployment of clone132, in the alternative scenario that PIT snapshot151is not valid to use to spawn instant clone130(operation558of flowchart550). Message320is the report that the deployment is complete (operation564of flowchart550).

Message322represents a request from user104, administrator106(or another source) to restore VC110to a prior version (operation408of flowchart400). In some examples, guest OS120queries hypervisor140for available PIT snapshots to use as restoration options, with message324(operation652of flowchart650). Hypervisor140provides list150of available PIT snapshots to use as restoration points to guest OS120in message326(operation654of flowchart650). In some examples, guest OS120selects an available PIT snapshot from list150to use as a restoration point, possibly based on input received from user104or administrator106. For example, user104may specify an earlier restoration point than the latest one available. The selection is represented as message328(operation656of flowchart650).

Guest OS120instructs hypervisor140to perform the restoration (e.g., using a designated PIT snapshot) in message330(operation658of flowchart650). Hypervisor140performs the restoration, which is represented as message332(operation660of flowchart650) and reports completion with message334(operation662of flowchart650).

FIG.4illustrates a flowchart400of exemplary operations associated with architecture100. In some examples, the operations of flowchart400are performed by one or more computing apparatus818ofFIG.8. Flowchart400commences with operation402, with the initial setup and configuration of VC110(e.g., by administrator106). In some examples, VC110is a “golden VM”, which is used as a base object for multiple clones in order to satisfy computing demands by user104. Computing platform102launches VC110under control by hypervisor140in operation404. VC110has guest OS120, and in some examples, comprises a VM.

Decision operation406determines whether there has been a trigger for creating a PIT snapshot for an instant clone. If so, guest OS120detects an instant clone creation trigger (e.g., input from user104or administrator106, or some other process) in decision operation406. Flowchart400then moves to flowchart500and returns.

Decision operation408determines whether there has been a trigger for creating a PIT snapshot for a restoration point. If so, guest OS120detects a restoration point trigger in decision operation406, and flowchart400moves to flowchart600and returns. In some example, the restoration point trigger comprises a timer event (e.g., lapse of timer118), a pending configuration change (e.g., administrator106begins installing software108), a user request (e.g., from user104or administrator106), or an I/O event. The configuration change of VC110(e.g., installation of software108) is performed in operation410, preferably prior to any need to perform a restoration of VC110.

In operation412, ML component158observes the execution of VC110and the PIT snapshot collection conditions, and later operations that spawn instant clone130and perform restoration of VC110. This includes taking statistics of the already-running VCs as input to an ML algorithm (e.g., applying an ML model to the input) to optimize management of the VCs. Optimizing management includes, for example, adjusting parameters of VC110and/or criteria used to determine whether VC110is in a known good state or stable configuration.

Decision operation414determines whether there has been a request to spawn a clone of VC110. If so, hypervisor140receives the request to deploy (e.g., spawn) a clone of VC110in decision operation414, and flowchart400moves to flowchart550and returns.

Decision operation416determines whether there has been a request to restore VC110, which may occur if user104notices that VC110is not operating properly. If so, guest OS120receives the request to perform a restoration of VC110in decision operation416, and flowchart400moves to flowchart650and returns. In some examples, the request to perform a restoration of VC110comprises a request to perform a restoration of VC110to an earlier configuration. In some examples, the request is received from a user account associated with user104that lacks privilege to request a restoration by hypervisor140(e.g., user104has lower privileges than administrator106and cannot access hypervisor).

Flowchart400returns to decision operation406to await a trigger to create another PIT snapshot for an instant clone or else a trigger to create another PIT snapshot for a restoration point, in decision operation408. In some examples, snapshot manager122performs at least part of decision operation406, restoration manager124performs at least part of decision operations408and416, and snapshot control142performs at least part of decision operation414.

FIGS.5A and5Billustrate flowcharts500and550, respectively, of exemplary operations associated with storing and using a PIT snapshot (e.g., PIT snapshot151) for use as instant clone130. In some examples, the operations of flowcharts500and550are performed by one or more computing apparatus818ofFIG.8. Flowchart500(FIG.5A) commences with operation502, which includes determining, by guest OS120, that VC110has completed a boot process and is in a known good state.

In some examples, determining that VC110is in a known good state comprises determining that VC110has a stable configuration. In some examples, determining that VC110is in a known good state comprises determining that VC110is ready to immediately begin executing a new application (e.g., application116). In some examples, determining that VC110is in a known good state comprises determining that a processor of VC110is not loaded above a threshold, such as an idle threshold that is typically set to 10% (ten percent). In some examples, determining that VC110is in a known good state comprises determining that a processor of VC110is not currently engaging (e.g., reading to or writing from) swap memory, which is a busy state of VC110. Essentially, the state desired for the PIT snapshot of VC110is one in which VC110is finished booting, not busy, and ready to instantly begin performing for user104. This is generally referred to herein as a state that is known to the VC100to be “good” for a PIT snapshot.

Operation502includes decision operation504, that determines whether VC110has completed a boot process and is in a known good state, and a wait operation506(e.g., a short period of time on timer118) if VC110has not completed the boot process or is not currently in a known good state. After the brief wait period, decision operation504checks again. This repeats until decision operation504determines that VC110is ready for the PIT snapshot.

While VC110is executing in the known good state, guest OS120instructs hypervisor140to store a PIT snapshot of VC110(e.g., PIT snapshot151), including a memory state of VC110, in operation508. In a subsequent pass through operation508, hypervisor140will store PIT snapshot152. In operation510, hypervisor140performs (e.g., collects, takes) PIT snapshot151, and hypervisor140stores PIT snapshot151in operation512. In some examples, snapshot manager122performs at least part of operations502and508, and snapshot control142performs at least part of operations510and512.

Flowchart550(FIG.5B) commences with decision operation552which determines whether PIT snapshot151is valid as an instant clone of VC110. If so, then based on at least determining that PIT snapshot151is valid, hypervisor140spawns a copy of PIT snapshot151as an instant clone of VC110(e.g., instant clone130) in operation554. In operation556computing platform102executes instant clone130under control by hypervisor140. Executing instant clone130comprises bypassing a boot process, because VC110was running at the time PIT snapshot was created, and includes memory114of VC110in a running state.

If PIT snapshot151is not valid as an instant clone of VC110, then based on at least determining that PIT snapshot151is not valid, hypervisor140spawns a different clone of VC110(e.g., clone132) in operation558. In operation560computing platform102executes clone132under control by hypervisor140. In some examples, executing clone132comprises performing a boot process by clone132in operation562. Operation564reports that the clone is deployed. In some examples, snapshot control142performs at least part of decision operation552, and clone control144performs at least part of operations554and558.

FIGS.6A and6Billustrate flowcharts600and650, respectively, of exemplary operations associated with storing and using a PIT snapshot (e.g., PIT snapshot153) for use as a restoration point for VC110. In some examples, the operations of flowcharts600and650are performed by one or more computing apparatus818ofFIG.8. Flowchart600(FIG.6A) commences with operation602, which includes determining, by guest OS120, that VC110has a stable configuration.

In some examples, determining that VC110has a stable configuration comprises determining that VC110is not currently undergoing a configuration change (e.g., administrator106is not part-way through installing software108). Operation602includes decision operation604, that determines whether VC110has a stable configuration, and a wait operation606(e.g., a short period of time on timer118) if VC110does not currently have a stable configuration. After the brief wait period, decision operation604checks again. This repeats until decision operation604determines that VC110is ready for the PIT snapshot.

While VC110has a stable configuration, guest OS120instructs hypervisor140to store a PIT snapshot of VC110(e.g., PIT snapshot153), in operation608. In a subsequent pass through operation608, hypervisor140will store PIT snapshot154. In operation610, hypervisor140performs (e.g., collects, takes) PIT snapshot153, and hypervisor140stores PIT snapshot153in operation612. In some examples, restoration manager124performs at least part of operations602and608, and snapshot control142performs at least part of operations610and612.

Flowchart650(FIG.6B) commences with operation652in which guest OS120queries hypervisor140for available PIT snapshots to use for restoration. Hypervisor140responds to guest OS120in operation654by providing list150of available PIT snapshots. In operation656, guest OS120selects PIT snapshot153for the restoration of VC110. In some examples, user104or administrator106is provided with a set of restoration options (e.g., different versions of VC110, corresponding to PIT snapshots153and154) and is involved with the selection.

In operation658, guest OS120instructs hypervisor140to spawn a copy of PIT snapshot153as restored VC110. In operation660, computing platform102executes the restored version of VC110under control by hypervisor140. Operation662informs user104or administrator106that restoration is complete. In some examples, restoration manager124performs at least part of operations652,656, and658, and snapshot control142performs at least part of operations654and660.

FIG.7Aillustrates a flowchart700of exemplary operations associated with architecture100. In some examples, the operations of flowchart700are performed by one or more computing apparatus818ofFIG.8. Flowchart700commences with operation702, which includes executing, by a computing platform, under control by a hypervisor, a VC having a guest operating system OS. Operation704includes determining, by the guest OS, that the VC has completed a boot process and is in a known good state. Operation706includes, while the VC is executing in the known good state, instructing, by the guest OS, the hypervisor to store a first PIT snapshot of the VC, the first PIT snapshot including a memory state of the VC.

FIG.7Billustrates a flowchart750of exemplary operations associated with architecture100. In some examples, the operations of flowchart750are performed by one or more computing apparatus818ofFIG.8. Flowchart750commences with operation752, which includes executing, by a computing platform, under control by a hypervisor, a VC having a guest OS. Operation754includes detecting, by the guest OS, a restoration point trigger. Operation756includes determining, by the guest OS, that the VC has a stable configuration. Operation758includes, while the VC has a stable configuration, instructing, by the guest OS, the hypervisor to store a PIT snapshot of the VC.

ADDITIONAL EXAMPLES

An example method comprises: executing, by a computing platform, under control by a hypervisor, a VC having a guest OS; determining, by the guest OS, that the VC has completed a boot process and is in a known good state; and while the VC is executing in the known good state, instructing, by the guest OS, the hypervisor to store a first PIT snapshot of the VC, the first PIT snapshot including a memory state of the VC.

An example computer system comprises: a processor; and a non-transitory computer readable medium having stored thereon program code executable by the processor, the program code causing the processor to: execute, by a computing platform, under control by a hypervisor, a VC having a guest OS; determine, by the guest OS, that the VC has completed a boot process and is in a known good state; and while the VC is executing in the known good state, instruct, by the guest OS, the hypervisor to store a first PIT snapshot of the VC, the first PIT snapshot including a memory state of the VC.

An example non-transitory computer storage medium has stored thereon program code executable by a processor, the program code embodying a method comprising: executing, by a computing platform, under control by a hypervisor, a VC having a guest OS; determining, by the guest OS, that the VC has completed a boot process and is in a known good state; and while the VC is executing in the known good state, instructing, by the guest OS, the hypervisor to store a first PIT snapshot of the VC, the first PIT snapshot including a memory state of the VC.

Another example method comprises: executing, by a computing platform, under control by a hypervisor, a VC having a guest OS; detecting, by the guest OS, a restoration trigger; determining, by the guest OS, that the VC has a stable configuration; and while the VC has a stable configuration, instructing, by the guest OS, the hypervisor to store a third PIT snapshot of the VC.

Another example computer system comprises: a processor; and a non-transitory computer readable medium having stored thereon program code executable by the processor, the program code causing the processor to perform a method disclosed herein. Another example non-transitory computer storage medium has stored thereon program code executable by a processor, the program code embodying a method disclosed herein.

Alternatively, or in addition to the other examples described herein, examples include any combination of the following:the VC comprises a VM;storing, by the hypervisor, the first PIT snapshot;receiving, by the hypervisor, a request to deploy a VC clone;determining whether the first PIT snapshot is valid for an instant clone of the VC;based on at least determining that the first PIT snapshot is valid, spawning a copy of the first PIT snapshot as an instant clone of the VC;based on at least determining that the first PIT snapshot is valid, executing, by the computing platform, under control by the hypervisor, the instant clone of the VC;based on at least determining that the first PIT snapshot is not valid, spawning a copy of a different clone of the VC;based on at least determining that the first PIT snapshot is not valid, executing, by the computing platform, under control by the hypervisor, the clone of the VC;detecting, by the guest OS, a restoration point trigger;determining, by the guest OS, that the VC has a stable configuration;while the VC has a stable configuration, instructing, by the guest OS, the hypervisor to store a second PIT snapshot of the VC;storing, by the hypervisor, the second PIT snapshot;receiving, by the guest OS, a request to perform a restoration of the VC;instructing, by the guest OS, the hypervisor to spawn a copy of the second PIT snapshot as restored VC;executing, by the computing platform, under control by the hypervisor, the restored VC;prior to receiving the request to perform a restoration of the VC, performing a configuration change of the VC;the request to perform a restoration of the VC comprises a request to perform a restoration of the VC to an earlier configuration;receiving the request to perform a restoration comprises receiving the request from a user account that lacks privilege to request a restoration by the hypervisor;providing, by the hypervisor, to the guest OS, a list of available PIT snapshots;selecting, by the guest OS, the second PIT snapshot for the restoration of the VC;determining that the VC is in a known good state comprises determining that the VC has a stable configuration;determining that the VC has a stable configuration comprises determining that the VC is not currently undergoing a configuration change;determining that the VC is in a known good state comprises determining that the VC is ready to immediately begin executing a new application;determining that the VC is in a known good state comprises determining that a processor of the VC is not loaded above a threshold;determining that the VC is in a known good state comprises determining that a processor of the VC is not loaded ten percent;determining that the VC is in a known good state comprises determining that a processor of the VC is not currently engaging swap memory;executing the instant clone of the VC comprises bypassing a boot process by the instant clone of the VC;executing the clone of the VC comprises performing a boot process by the clone of the VC;the restoration point trigger comprises a timer event;the restoration point trigger comprises a pending configuration change;the restoration point trigger comprises a user request;the restoration point trigger comprises an I/O event;storing, by the hypervisor, the third PIT snapshot; receiving, by the hypervisor, a request to deploy a VC clone; determining whether the third PIT snapshot is valid for an instant clone of the VC; based on at least determining that the third PIT snapshot is valid: spawning a copy of the third PIT snapshot as an instant clone of the VC; and executing, by the computing platform, under control by the hypervisor, the instant clone of the VC; and based on at least determining that the third PIT snapshot is not valid: spawning a copy of a different clone of the VC; and executing, by the computing platform, under control by the hypervisor, the clone of the VC;detecting, by the guest OS, a restoration point trigger; determining, by the guest OS, that the VC has a stable configuration; and while the VC has a stable configuration, instructing, by the guest OS, the hypervisor to store a fourth PIT snapshot of the VC;storing, by the hypervisor, the fourth PIT snapshot; receiving, by the guest OS, a request to perform a restoration of the VC; instructing, by the guest OS, the hypervisor to spawn a copy of the fourth PIT snapshot as restored VC; and executing, by the computing platform, under control by the hypervisor, the restored VC;prior to receiving the request to perform a restoration of the VC, performing a configuration change of the VC, wherein the request to perform a restoration of the VC comprises a request to perform a restoration of the VC to an earlier configuration, and wherein receiving the request to perform a restoration comprises receiving the request from a user account that lacks privilege to request a restoration by the hypervisor; andproviding, by the hypervisor, to the guest OS, a list of available PIT snapshots; and selecting, by the guest OS, the fourth PIT snapshot for the restoration of the VC.

Exemplary Operating Environment

The present disclosure is operable with a computing device (computing apparatus) according to an embodiment shown as a functional block diagram800inFIG.8. In an embodiment, components of a computing apparatus818may be implemented as part of an electronic device according to one or more embodiments described in this specification. The computing apparatus818comprises one or more processors819which may be microprocessors, controllers, or any other suitable type of processors for processing computer executable instructions to control the operation of the electronic device. Alternatively, or in addition, the processor819is any technology capable of executing logic or instructions, such as a hardcoded machine. Platform software comprising an operating system820or any other suitable platform software may be provided on the computing apparatus818to enable application software821to be executed on the device. According to an embodiment, the operations described herein may be accomplished by software, hardware, and/or firmware.

Computer executable instructions may be provided using any computer-readable medium (e.g., any non-transitory computer storage medium) or media that are accessible by the computing apparatus818. Computer-readable media may include, for example, computer storage media such as a memory822and communications media. Computer storage media, such as a memory822, include volatile and non-volatile, removable, and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or the like. Computer storage media include, but are not limited to, hard disks, RAM, ROM, EPROM, EEPROM, NVMe devices, persistent memory, phase change memory, flash memory or other memory technology, compact disc (CD, CD-ROM), digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage, shingled disk storage or other magnetic storage devices, or any other non-transmission medium (e., non-transitory) that can be used to store information for access by a computing apparatus. In contrast, communication media may embody computer readable instructions, data structures, program modules, or the like in a modulated data signal, such as a carrier wave, or other transport mechanism. As defined herein, computer storage media do not include communication media. Therefore, a computer storage medium should not be interpreted to be a propagating signal per se. Propagated signals per se are not examples of computer storage media. Although the computer storage medium (the memory822) is shown within the computing apparatus818, it will be appreciated by a person skilled in the art, that the storage may be distributed or located remotely and accessed via a network or other communication link (e.g. using a communication interface823). Computer storage media are tangible, non-transitory, and are mutually exclusive to communication media.

The computing apparatus818may comprise an input/output controller824configured to output information to one or more output devices825, for example a display or a speaker, which may be separate from or integral to the electronic device. The input/output controller824may also be configured to receive and process an input from one or more input devices826, for example, a keyboard, a microphone, or a touchpad. In one embodiment, the output device825may also act as the input device. An example of such a device may be a touch sensitive display. The input/output controller824may also output data to devices other than the output device, e.g. a locally connected printing device. In some embodiments, a user may provide input to the input device(s)826and/or receive output from the output device(s)825.

Although described in connection with an exemplary computing system environment, examples of the disclosure are operative with numerous other general purpose or special purpose computing system environments or configurations. Examples of well-known computing systems, environments, and/or configurations that may be suitable for use with aspects of the disclosure include, but are not limited to, mobile computing devices, personal computers, server computers, hand-held or laptop devices, multiprocessor systems, gaming consoles, microprocessor-based systems, set top boxes, programmable consumer electronics, mobile telephones, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices.

Aspects of the disclosure transform a general-purpose computer into a special purpose computing device when programmed to execute the instructions described herein. The detailed description provided above in connection with the appended drawings is intended as a description of a number of embodiments and is not intended to represent the only forms in which the embodiments may be constructed, implemented, or utilized. Although these embodiments may be described and illustrated herein as being implemented in devices such as a server, computing devices, or the like, this is only an exemplary implementation and not a limitation. As those skilled in the art will appreciate, the present embodiments are suitable for application in a variety of different types of computing devices, for example, PCs, servers, laptop computers, tablet computers, etc.

The term “computing device” and the like are used herein to refer to any device with processing capability such that it can execute instructions. Those skilled in the art will realize that such processing capabilities are incorporated into many different devices and therefore the terms “computer”, “server”, and “computing device” each may include PCs, servers, laptop computers, mobile telephones (including smart phones), tablet computers, and many other devices. Any range or device value given herein may be extended or altered without losing the effect sought, as will be apparent to the skilled person. Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

While no personally identifiable information is tracked by aspects of the disclosure, examples may have been described with reference to data monitored and/or collected from the users. In some examples, notice may be provided to the users of the collection of the data (e.g., via a dialog box or preference setting) and users are given the opportunity to give or deny consent for the monitoring and/or collection. The consent may take the form of opt-in consent or opt-out consent.

The order of execution or performance of the operations in examples of the disclosure illustrated and described herein is not essential, unless otherwise specified. That is, the operations may be performed in any order, unless otherwise specified, and examples of the disclosure may include additional or fewer operations than those disclosed herein. For example, it is contemplated that executing or performing a particular operation before, contemporaneously with, or after another operation is within the scope of aspects of the disclosure. It will be understood that the benefits and advantages described above may relate to one embodiment or may relate to several embodiments. When introducing elements of aspects of the disclosure or the examples thereof, the articles “a,” “an,” and “the” are intended to mean that there are one or more of the elements. The terms “comprising,” “including,” and “having” are intended to be inclusive and mean that there may be additional elements other than the listed elements. The term “exemplary” is intended to mean “an example of.”