VM file management with multiple file-level snapshots

Abstract

VM file management includes detecting a user request to access a virtual machine (VM) and searching a predefined list to determine if the user requesting access is identified on the list. If so, a file-level snapshot is created before allowing the user to modify the VM file. The file-level snapshot includes user attributes and is added as a top layer of a stack. The user attributes indicate the role of the user for whom the file-level snapshot is created. Each layer of the stack includes one or more other file-level snapshots. In response to the user modifying the VM file, the VM file is written to the snapshot in its entirety. A set of snapshots is selected from the stack based on the user attributes of each snapshot, and the VM is modified by merging the VM files that belong to the selected set of snapshots.

Description

[Technical Field]

[0001] The present disclosure relates to virtualization technology, and more particularly to managing virtual machine (VM) files using file-level multiple snapshot version control. [Background technology]

[0002] Virtualization is a decades-old technology that, whether used alone or as part of a network, nevertheless offers significant benefits to a wide variety of users. This technology allows a single computer system (e.g., a server) to host multiple VMs, each potentially running a different operating system. One advantage is that the failure of one VM does not automatically bring down other VMs. In a virtualized system, different servers can run on different VMs, providing multi-computer functionality at low cost and with easy maintainability. Another advantage of virtualization is that checkpointing and migrating VMs (e.g., for load balancing across multiple servers) is much easier than migrating VMs the way they are run on standard operating systems.

[0003] Other benefits include running legacy applications on operating systems (or versions) that are no longer supported on current hardware, and allowing software developers to use VMs to test the performance of their applications on various operating systems rather than using multiple computers running different operating systems. The scalability of the virtual environment created with a VM is particularly advantageous to businesses in that virtualization allows a growing business to efficiently and quickly respond to the business's needs for increased IT capabilities.

[0004] It can be useful to capture different states of a VM at different times during the VM's lifespan. One mechanism for doing this is to create snapshots that capture and electronically store various attributes of the VM's current state at a particular point in time. Snapshots are typically implemented at the block level, where each snapshot stores only the blocks of data that have changed. Block-level snapshots do not capture files in their entirety. It is not possible to determine which changed blocks belong to which files with a block-level snapshot.

[0005] Thus, block-level snapshots, including in the context of installing patches to update or modify defects in a VM operating system, are problematic in several ways. Block-level snapshots can eliminate or limit the ability to separate files modified by patches installed by an IT administrator from VM file changes made by other types of users (e.g., developers, regular VM users). When the state of a VM needs to be rolled back to a previous state, the rollback is typically performed without merging VM files captured by snapshots created over time. As a result, installed patches are lost and must be manually reinstalled after each such rollback. This can be a significant undertaking for enterprise-scale or other large-scale systems utilizing hundreds or thousands of VMs. For example, when maintaining IT security through the regular installation of patches, IT administrators and VM users can have to spend significant time and energy performing the repetitive task of manually reinstalling patches after a VM rollback. Summary of the Invention [Means for solving the problem]

[0006] In an exemplary implementation, a computer-implemented method for managing virtual machine (VM) files using file-level snapshots and versioning includes detecting a user's electronic request for access to a VM. The method includes detecting a user's electronic request for access to a VM and searching a predefined user list to determine whether the user requesting access is identified in the predefined user list. In response to identifying the user in the predefined user list, the method includes creating a file-level snapshot at the top layer of a stack before allowing the user to modify the VM file. The file-level snapshot includes a user attribute indicating the user's role for which the file-level snapshot is created and a timestamp indicating the time the file-level snapshot is created. Each layer of the stack includes a file-level snapshot containing one or more VM files in their entirety. The method includes saving the VM file in its entirety, including portions modified by the user, in the file-level snapshot in response to user input from the user modifying the VM file. The method includes selecting a set of file-level snapshots from the stack based on user attributes of each selected file-level snapshot, and modifying the VM by merging the VM files captured by the snapshots belonging to the set of file-level snapshots.

[0007] The computer-implemented method enables monitoring access requests to the VM (e.g., whether the requests are from an IT administrator or a VM user (e.g., a developer, a regular VM user)) and creating a file-level snapshot in response to each access request. Each file-level snapshot captures and saves the latest version of the VM file, not just the changed blocks of the VM file, but the entire VM file. Through monitoring the requests, the computer-implemented method further enables distinguishing VM file changes made in response to input from an IT administrator (e.g., patch installation) from changes made in response to input from another type of VM user. That is, the computer-implemented method can differentiate or distinguish and / or separate VM file changes based on the respective roles of the users providing input.

[0008] Thus, in yet another exemplary implementation of the computer-implemented method, each of the multiple snapshots selected for merging has a user attribute indicating that the role of the user for whom the selected snapshot was created is an IT administrator. The VM is modified by rolling back the VM to a previous state. The rollback is performed by merging only the most recent versions of VM file changes made by one or more IT administrators and preserving all other VM files for the VM in their original, unmodified states.

[0009] When the need arises to roll back a VM to a previous state, the computer-implemented method can merge only the VM files that have been modified by patches installed by one or more IT administrators. Changes made by users in other roles are ignored in merging the VM files. This allows the VM rollback to be accomplished without losing installed patches, thereby eliminating the need to manually reinstall each of the multiple patches, thereby saving time and resources.

[0010] In another exemplary implementation, a system for managing multiple VM files using file-level snapshots and versioning includes a processor configured to initiate instructions, including detecting a user's electronic request for access to a virtual machine (VM) and searching a predefined user list to determine whether the user requesting access is identified in the predefined user list. In response to identifying the user in the predefined user list, the instructions include creating a file-level snapshot at a top layer of a stack before allowing the user to modify the VM file. The file-level snapshot includes a user attribute indicating the user's role for which the file-level snapshot is created and a timestamp indicating the time the file-level snapshot is created. Each layer of the stack includes a file-level snapshot containing one or more VM files in their entirety. In response to user input from the user modifying the VM file, the instructions include saving the VM file in its entirety, including portions modified by the user, to the file-level snapshot. The instructions include selecting a set of file-level snapshots from the stack based on user attributes of each selected file-level snapshot, and modifying the VM by merging the VM files captured by the snapshots belonging to the set of file-level snapshots.

[0011] In yet another exemplary embodiment of a system for managing VM files using file-level snapshots and versioning, each of the snapshots selected for merging has a user attribute indicating that the role of the user for whom the selected snapshot was created is an IT administrator. The VM is modified by rolling back the VM to a previous state. The rollback is performed by merging only the latest versions of VM file changes made by one or more IT administrators and preserving all other VM files for the VM in their original, unmodified states.

[0012] In another exemplary embodiment, a computer program product includes one or more computer-readable storage media and program instructions collectively stored on the one or more computer-readable storage media. The program instructions are executable by computer hardware to initiate the program. The instructions include detecting a user's electronic request for access to a virtual machine (VM) and searching a predefined user list to determine whether the user requesting access is identified in the predefined user list. The instructions include, in response to identifying the user in the predefined user list, creating a file-level snapshot at the top layer of the stack before allowing the user to modify the VM file. The file-level snapshot includes a user attribute indicating the user's role for which the file-level snapshot is created and a timestamp indicating the time the file-level snapshot is created. Each layer of the stack includes a file-level snapshot containing one or more VM files in their entirety. The instructions include, in response to user input from the user modifying the VM file, saving the VM file in its entirety, including portions modified by the user, to the file-level snapshot. The instructions include selecting a set of file-level snapshots from the stack based on user attributes of each selected file-level snapshot, and modifying the VM by merging the VM files captured by the snapshots belonging to the set of file-level snapshots.

[0013] This "Summary" section is provided merely to introduce certain concepts, and is not intended to identify key or essential features of the claimed subject matter. Other features of the inventive arrangement will be apparent from the accompanying drawings and the detailed description that follows.

[0014] Configurations of the present invention are illustrated by way of example in the accompanying drawings. However, the drawings should not be construed as limiting the configuration of the present invention to only the particular implementations shown. Various aspects and advantages will become apparent upon review of the following detailed description and by reference to the drawings. [Brief explanation of the drawings]

[0015] [Figure 1] FIG. 1 is a block diagram illustrating an exemplary system for managing VM files using file-level snapshot and version management. [Figure 2] FIG. 2 is a flow chart diagram illustrating an exemplary method for managing VM files using the system of FIG. [Figure 3] FIG. 3 is a block diagram illustrating certain operational aspects of a VM rollback performed using the exemplary system for managing VM files shown in FIG. [Figure 4] FIG. 4 is a block diagram illustrating one example of a computer hardware system for implementing the system of FIG. [Figure 5] FIG. 5 is a block diagram illustrating an example of a cloud computing environment. [Figure 6] FIG. 6 is a block diagram illustrating an example of an abstraction model layer. DETAILED DESCRIPTION OF THE INVENTION

[0016] While this disclosure concludes with claims defining novel features, it is believed that the various features described within this disclosure will be better understood by considering this description in conjunction with the drawings. The method(s), machine(s), manufacture(s), and any variations thereof described herein are provided for illustrative purposes. Specific structural and functional details described within this disclosure are not intended to be limiting, but merely as a basis for the claims and as a representative basis for teaching those skilled in the art the various uses of the described features in substantially any appropriately detailed structure. Furthermore, the terms and phrases used within this disclosure are not intended to be limiting, but rather to provide an understandable description of the described features.

[0017] The present disclosure relates to virtualization technology, and more particularly, to managing VM files using file-level snapshots and versioning. VM files include data stored electronically within blocks of a computer system's disk space. As defined herein, a "snapshot" is a data structure that records the state of a VM, including one or more VM files, at a particular point in time. Typical mechanisms for capturing snapshots of VM files are implemented at the block level, whereby each snapshot stores only the blocks containing changed data, rather than the entire file. Block-level snapshots do not provide a logical link between changed blocks of data and the files to which the changed blocks belong.

[0018] The lack of logical linking can be problematic in several contexts. For example, during the life of a VM, an IT administrator may install any number of patches to upgrade or modify defects (e.g., security vulnerabilities) in the VM operating system. However, block-level snapshots do not provide an efficient mechanism for separating VM files modified by patch installation from VM files modified by one or more VM users in the normal course of working with one or more VM files. Therefore, it is unlikely that only VM files modified by patch installation can be merged without also merging multiple VM files modified by the VM users. Therefore, the normal procedure for performing a VM rollback involves performing the rollback without merging any multiple snapshots, resulting in the removal of installed patches. Therefore, the patches must be reinstalled with each VM rollback. Therefore, for virtual environments with a large number of VMs, achieving IT security compliance can require IT administrators and VM users to spend significant time and resources on the repetitive task of repeatedly reinstalling missing patches.

[0019] In accordance with the inventive aspects described herein, exemplary methods, systems, and computer program products are provided for efficiently managing VM file changes (including installation of patches provided by IT administrators) and merging VM file changes with file-level snapshot versioning. As defined herein, a "file-level snapshot" is a snapshot that captures and stores a VM file in its entirety. The use of file-level snapshots enhances and makes VM file management more flexible, enabling, for example, separation and isolation of VM files based on the role of the user (e.g., IT administrator or regular VM user) modifying one or more VM files.

[0020] In one or more exemplary implementations, the VM file management system includes an access request monitor (ARM) and file-level snapshot functionality. The ARM monitors access requests to the VM and determines, based on the access request, whether the requester is in a predefined user list. The predefined user list may include user attributes that identify different users who perform different roles (e.g., developer, regular VM user, IT administrator).

[0021] Based on the request to access a VM, the VM file management system identifies the user or the user's role (e.g., developer, normal VM user, IT administrator), or a combination thereof. If the user is identified in a predefined user list, a file-level snapshot is created before allowing the user to modify the VM file. The file-level snapshot created in response to the access request is initially empty. As defined herein, an "empty" snapshot is a data structure that includes only metadata corresponding to memory locations, user attributes corresponding to the user for whom the snapshot is created, and a timestamp corresponding to the time the snapshot is created. Different states of a VM file that change over time can be preserved by taking snapshots at different times, as indicated by the corresponding snapshot timestamps. Thus, a snapshot of a VM file captures and stores a special version of the VM file written to the snapshot at the identified time indicated by the corresponding timestamp. If the VM file changes over time, each modified version can be written to a special snapshot, so that different snapshots can capture and store different versions of the VM file. Each snapshot corresponds to the user for whom the snapshot was created, as indicated by the snapshot's corresponding user attribute, which allows the user's role (e.g., developer, regular VM user, IT administrator) to be identified.

[0022] The file-level snapshot is initially empty, but is the active snapshot. As defined herein, an "active snapshot" is a snapshot that supports both computer read and write operations. The active snapshot is added as the top layer of a stack of snapshots. File-level snapshots below the top layer of the stack are read-only.

[0023] During a session initiated by a user identified by ARM requesting access to the VM, when the user modifies a VM file, the modified VM file is captured and saved in an active file-level snapshot. Thus, the snapshot captures and stores the entire VM file as modified by user input. That is, the snapshot captures and stores the entire VM file, including the portion of data modified by user input, not just the portion modified using block-level snapshots. When modified, the VM file captured by the snapshot is the latest version of the VM file. Each snapshot created in response to an access request by an ARM-identified user captures and saves the VM file modified by a particular user. For example, the same VM file may be modified by both an IT administrator and a VM user. However, the changes are captured by two different snapshots. One snapshot captures and saves the changes to the VM file made by the IT administrator. Another snapshot of the same VM file captures and saves the changes to the VM file made by the VM user.

[0024] In one aspect, the VM file management system can modify a VM by merging multiple snapshots selected from the stack. As defined herein, "merging" means saving or writing to the VM's file system certain VM files saved in multiple snapshots selected from the stack according to one or more specified criteria. The criteria can include the role of the user for whom the snapshot was created. For example, snapshots containing VM files modified by one or more IT administrators can be selected. When a VM needs to be rolled back to its original state, only those VM files modified by one or more IT administrator patch installations are merged, while those VM files modified by one or more other VM users are ignored or discarded. The determination of which VM files to merge is based on identifying the role of the user who modified the VM file. VM files modified by users identified as IT administrators are merged during rollback, and VM files modified by general VM users are not merged.

[0025] During the VM rollback, the VM file management system supports both read and write operations and allows for the selection of only snapshots created for a particular user or class of users, specifically, IT administrators or users assigned the IT administrator role. As defined herein, the "IT administrator" role is assigned to a user who, as a designated IT administrator, is granted predefined privileges that allow the user to install operating system files and patches to modify operating system files. Meanwhile, other users are not granted such privileges and therefore cannot install or modify system files. This allows for efficient merging of only VM files that have been modified, for example, by patch installations made by an IT administrator, without any modifications made by other types of VM users (e.g., developers, regular VM users).

[0026] In another aspect, the VM file management system provides two attributes for each snapshot. The first attribute is a user attribute, which records the object for which the snapshot was created. The second attribute is a time attribute, which is a timestamp indicating the time when the snapshot was created. Each time a new snapshot is created, it is added to the top layer of the snapshot stack as the active snapshot. Only snapshots at the top layer are active and support both read and write data operations. If a VM file is changed (due to a user change) while the snapshot is active, the snapshot stores the entire VM file as the latest version as a file-level snapshot. If multiple versions of a VM file exist between the VM file system and the selected snapshot, only the latest version is merged. All other versions can be deleted to reclaim the corresponding data storage space.

[0027] Further aspects of the present invention are described in more detail below with reference to the drawings. For purposes of simplicity and clarity of illustration, elements shown in the drawings have not necessarily been drawn to scale. For example, the dimensions of some elements may be exaggerated relative to other elements for clarity. Furthermore, where considered appropriate, reference numerals may be repeated among the drawings to indicate corresponding, similar, or like features.

[0028] 1 and 2 respectively illustrate an exemplary VM file management system (system) 100 and methodology 200 that implement certain aspects of VM file management using file-level snapshot versioning. Illustratively, system 100 is implemented within a virtual machine (VM) 102 hosted on computer system 104. VM 102 can be one of multiple VMs hosted on computer system 104. Computer system 104 can be a computer system, such as computer system 412, that is part of a computing node (e.g., a cloud-based server), such as computing node 400 (FIG. 4). Computer system 104 can be a server, a desktop computer, a laptop, or any other such computer system.

[0029] The VM 102 is supported by a hypervisor 106. The hypervisor 106 creates a virtual disk 108 to store VM files processed by the VM 102. The VM files include, for example, system files of the VM's 102 operating system and various application files created and / or modified by a VM user. The system 100 includes an access request monitor (ARM) 110 integrated within the hypervisor 106. In block 202, the ARM 110 detects a user's electronic request for access to the VM 102. An example of a user request for access to the VM 102 is a user attempting to log in to the VM 102. In block 204, the ARM 110 searches a predefined list 112, an electronic database of user identifiers and roles (e.g., VM user, IT administrator), to determine whether the user requesting access is identified in the predefined list 112.

[0030] The predefined list 112 is a data structure for distinguishing one or more of a plurality of users from one or more other users of a VM. The data structure may include a name, a predefined code (e.g., alphanumeric), or other indicator that identifies a user who will instantiate, delete, or modify a VM file, or a combination thereof. The data structure of the predefined list 112 may specify one or more user attributes for each listed user. The user attributes may indicate the user's role, for example, IT administrator or other class of user.

[0031] Thus, the predefined list 112 can identify users or their respective roles, or a combination thereof. For example, the identified user role can be that of a regular VM user. The identified user role can be, for example, that of an IT administrator. The function of the IT administrator is to maintain the functionality and security of the VM 102. The system 100 can segregate VM file changes according to what changes were made by different users in different roles. For example, a VM file changed by a patch made by the IT administrator of the VM 102 can be captured by one snapshot, while changes made to the same VM file by a VM user can be captured by another snapshot.

[0032] In block 206, in response to the ARM 110 identifying the user in the predefined list 112, the snapshot generator 114 creates a snapshot before allowing the user requesting access to the VM 102 to modify any VM files. The snapshot includes a user attribute indicating the role of the user for whom the snapshot was created and a timestamp indicating the time the snapshot was created. The snapshot is initially empty. However, the snapshot is an active snapshot. Thus, during a VM session initiated by a user request to access the VM 102, one or more VM files can be modified by the user. Any one or more VM files modified in response to input from the user can be written to the snapshot. For example, a VM file (e.g., stored on the virtual disk 108) can be identified and modified in response to a read access request, and then written to the snapshot in response to a write access request. The single snapshot is a file-level snapshot, so that each VM file, including the changed portions, can be captured and saved in its entirety.

[0033] The file-level snapshots can be implemented using different mechanisms in different file systems. In some, but not all, configurations, the file-level snapshots of system 100 can include file-level overlay snapshots. File-level overlay snapshots can be implemented in union mount file systems (e.g., Linux 登録商標The union mount file system can be implemented using OverlayFS (OverlayFS). An operating system implemented within computer system 104 can perform mounts to make files and directories available to users through a file system, where a mount point is the location where a virtual file system is registered. The union mount file system implements an overlay, which combines multiple mount points to create a single directory structure containing separately sourced files and subdirectories. Overlays allow a read / write partition of computer system 104's memory to overlay a read-only partition. Overlays allow a read / write directory tree to be overlaid on a read-only directory tree. In other configurations using other operating systems or VM technologies, or a combination thereof, various mechanisms (e.g., Btrfs, EXT, XFS) can be used by system 100 to implement the file-level snapshots.

[0034] In block 208, in response to the user modifying the VM file, the snapshot generator 114 saves the modified VM file in its entirety to the snapshot created in response to the ARM 110 identifying the user in the predefined list 112. As an active snapshot, the snapshot supports both read and write operations and occupies the top layer of the stack 116. The stack 116 is constructed by the stack builder 118. The stack builder 118 adds each newly created snapshot created by the snapshot generator 114 in response to a user request to access the VM 102 as the top layer of the stack 116. The snapshot at the top layer of the stack 116 is active until a new snapshot is added to the top of the stack 116. Snapshots at lower layers are read-only. A timestamp may indicate the time the snapshot is created. The stack builder 118 may maintain a list of the snapshots saved in the stack 116 and may arrange the stack according to the timestamp associated with each snapshot on the stack 116. Each layer of the stack 116 contains one or more file-level snapshots, where each snapshot captures the entire VM file as modified by a particular user identified in the predefined list 112. Snapshots at the top layer are active snapshots that support both reading and writing data to the VM's VM files. Snapshots at lower layers contain read-only VM files.

[0035] Illustratively, stack 116 has four layers, but stack 116 can have fewer or more layers than four, and indeed many layers in a typical scenario. Snapshot 3, the top layer of stack 116, is a snapshot containing VM file changes made by a user identified by ARM 110 as an IT administrator. The next layer down is snapshot 2, which is created in response to VM file changes made with input from a user identified by ARM 110 as a VM user. The next two layers down in stack 116 are snapshot 1, which captures VM files changed by an IT administrator, and snapshot 0, which captures the same or different files changed by a VM user, respectively. Again, stack 116 is merely illustrative. The number of layers and the number of snapshots in each layer, as well as the users corresponding to each snapshot, can vary widely.

[0036] In block 210, a set of snapshots from stack 116 is selected by VM file selector 120 in response to the rollback request, and VM 102 is modified by merging the VM files belonging to the selected set of snapshots. VM file selector 120 selects the set of snapshots based on the user attribute of each snapshot. The user attribute indicates the role of the user for whom each snapshot was created and a timestamp indicating when each snapshot was created. For example, the selected snapshots can be selected based on corresponding user attributes indicating that each was created for a user identified as an IT administrator, which can be the same user or multiple different users assigned the IT administrator role. Thus, VM file selector 120 selects the top-level snapshot (IT administrator in snapshot 3) and a second snapshot below the top-level snapshot (IT administrator in snapshot 1). Each of the selected snapshots captures one or more VM files modified by the IT administrator in their entirety. The modifications can be made, for example, by installing a patch. If the same VM file is modified multiple times and is captured in multiple snapshots of the selected multiple snapshots, only the latest version of the VM file is selected by VM file selector 120.

[0037] In block 210, the VM is modified by merging the VM files captured by the snapshots selected by VM file selector 120. The VM files are merged by VM file aggregator 122, which creates merged VM file 124. VM file aggregator 122 writes merged VM file 124 to virtual disk 108. The merged VM files can be those VM files modified by one or more designated users operating in the role of IT administrator, for example, based on user attributes in accordance with the snapshots selected by VM file selector 120. The modification of VM 102 can include rolling back the VM by merging only the latest versions (based on timestamps indicating when each snapshot was created) of VM file changes made by one or more users operating as IT administrators. All other VM files of the VM can be retained in their original, unmodified state. A portion of the data storage space associated with VM 102 can be reclaimed by deleting each of the selected snapshots in response to completing the modification of the VM by merging the VM files captured by the selected snapshots.

[0038] FIG. 3 illustrates an operational view 300 of a VM rollback and merger 302 executed using system 100. Initially, a VM fileset 304 is stored on virtual disk 108. VM fileset 304 includes VM files A, B, C, D, and E, which have not yet been modified. Modifications to VM files A and B are made by a VM user during a session initiated by a user request for access to VM 102. Before allowing the user to modify any VM files, snapshot generator 114 creates an initially empty snapshot 306. The snapshot generator 114 then saves the VM files modified by the user to snapshot 306, capturing their entirety as versions A1 and B1, which it writes to snapshot 306. When VM files B and C are modified in response to input from an IT administrator, snapshot generator 114 prompts snapshot 308, originally created in response to the IT administrator's access request, to write the files as modified. Snapshot 308 includes VM file versions B2 and C2. Note that B2 is a change to VM file B (not B1, which results from a change by the VM user). The IT administrator also installs a newly created VM file F, which is also written to snapshot 308. Input from the same or a different VM user changes VM file version A1 (a previous VM user change to the original VM file A) and VM file C (not a previous VM user change), resulting in the writing to snapshot 310 containing VM file versions A3 and C3 and the newly created VM file G installed by the VM user. Note that A3 is a change to VM file version A1, which, as previously described, resulted from a change by the same or a different VM user.

[0039] Change input from the same or a different IT administrator prompts snapshot generator 114 to write the modified VM files to snapshot 312. Snapshot 312 includes VM file versions A4, B4, and E4, as well as a newly created VM file H. A4 is a modification of the original VM file A, which at this point had not been modified by a user assuming the role of IT administrator (although A4 had been modified twice by a VM user). B4 is a modification of version B2, which was previously modified by the IT administrator. B4 is the latest version and replaces B2, which was written to snapshot 308 in response to a change by the same or a different user identified as an IT administrator. To achieve the VM rollback, VM file selector 120 selects snapshots 308 and 312, which are snapshots that capture changes made by one or more IT administrators, based on their identification by ARM 110. By merging VM files captured by snapshots corresponding to one or more IT administrators, the VM can be rolled back to its original state without losing patches introduced by VM file changes made by one or more users in the role of IT administrators. This eliminates the need to reinstall patches after a rollback, which is typically necessary when using block-level snapshots rather than file-level snapshots in system 100. VM file aggregator 122 merges the latest version of the VM files from the selected snapshot with the original, unchanged VM files stored on virtual disk 108. The rollback creates VM fileset 314 including A4, B4, C2, D, E4, F, and H. The rollback is completed by committing VM fileset 314 to virtual disk 108. Once the rollback is performed, all snapshots can be deleted to further reclaim data storage space.

[0040] 4 shows a schematic diagram of an example computing node 400. In one or more configurations, computing node 400 is an example of a suitable cloud computing node. Computing node 400 is not intended to suggest any limitations regarding the scope of use or functionality of the inventive configurations described herein. Computing node 400 may perform any of the functionality described within this disclosure.

[0041] Computing node 400 comprises a computer system 412 that is operable with numerous other general-purpose or special-purpose computing system environments or configurations. Examples of well-known computing systems, environments, or configurations, or combinations thereof, that may be suitable for use with computer system 412 include, but are not limited to, personal computer systems, server computer systems, thin clients, thick clients, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputer systems, mainframe computer systems, distributed cloud computing environments comprising any of the above systems or devices, etc.

[0042] Computer system 412 may be described in the general context of computer system-executable instructions, such as program modules, being executed by the computer system. Generally, program modules may include routines, programs, objects, components, logic, data structures, etc. that perform particular tasks or implement particular abstract data types. Computer system 412 may also be implemented in a distributed cloud computing environment where tasks are performed by remote processing devices that are linked through a communications network. In a distributed cloud computing environment, program modules may be located in both local and remote computer system storage media, including, for example, memory storage devices.

[0043] As shown in FIG. 4, computer system 412 is illustrated in the form of a general-purpose computing device. Components of computer system 412 may include, but are not limited to, one or more processors 416, memory 428, and a bus 418 connecting various system components, including memory 428, to processor 416. As defined herein, a "processor" means at least one hardware circuit configured to execute instructions. The hardware circuit may be an integrated circuit. Examples of processors include, but are not limited to, a central processing unit (CPU), an array processor, a vector processor, a digital signal processor (DSP), a field-programmable gate array (FPGA), a programmable logic array (PLA), an application-specific integrated circuit (ASIC), a programmable logic circuit, and a controller.

[0044] The execution of instructions of a computer program by a processor includes executing or running the program. As defined herein, "run" and "execute" include a sequence of actions or events performed by the processor in accordance with one or more machine-readable instructions. As defined herein, "running" and "executing" refer to the active performance of actions or events by the processor. As used herein, the terms run, operate, execute, and execute are used interchangeably.

[0045] Bus 418 represents any one or more of several types of bus structures, including, for example, a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures, including, by way of example only and not limitation, an Industry Standard Architecture (ISA) bus, a Micro Channel Architecture (MCA) bus, an Enhanced ISA (EISA) bus, a Video Electronics Standards Association (VESA) local bus, a Peripheral Component Interconnect (PCI) bus, and a PCI Express (PCIe) bus.

[0046] Computer system 412 typically includes a variety of computer system-readable media. Such media can be any available media that is accessible by computer system 412 and can include both volatile and nonvolatile media, removable and non-removable media.

[0047] Memory 428 may include computer system-readable media in the form of volatile memory, such as random-access memory (RAM) 430 or cache memory 432, or a combination thereof. Computer system 412 may also include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example, storage system 434 may be provided for reading from and writing to non-removable, non-volatile magnetic media or one or more solid-state drives, or a combination thereof (not shown, typically referred to as "hard drives"). Although not shown, a magnetic disk drive may be provided for reading from and writing to a removable, non-volatile magnetic disk (e.g., a "floppy disk"), and an optical disk drive may be provided for reading from and writing to a removable, non-volatile optical disk, such as a CD-ROM, DVD-ROM, or other optical media. In such an embodiment, each may be connected to bus 418 by one or more data media interfaces. As further shown and described below, memory 428 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of the inventive arrangement.

[0048] Programs / utilities 440 having a set (at least one) of program modules 442 may be stored in memory 428, as well as, by way of example and not limitation, an operating system, one or more application programs, other program modules, and program data. Each of the operating system, one or more application programs, other program modules, and program data, or some combination thereof, may comprise an implementation of a network environment. Program modules 442 generally perform the functions or methodologies, or combinations thereof, of the inventive arrangements as described herein. For example, one or more of the program modules may comprise system 100 for VM file management, or portions thereof.

[0049] Programs / utilities 440 are executable by processor 416. Any data items used, created, or manipulated by programs / utilities 440 and computer system 412, or any combination thereof, are functional data structures that impart functionality when used by computer system 412. As defined within this disclosure, a "data structure" is the physical implementation of a data model's organization of data in physical memory. Thus, data structures are formed of particular electrical or magnetic structural elements in memory. Data structures impose a physical organization on data stored in memory for use by application programs executed using the processor.

[0050] The computer system 412 may also communicate with one or more external devices 414, such as a keyboard, pointing device, display 424, one or more devices that allow a user to interact with the computer system 412, or any device (e.g., a network card, modem, etc.) that allows the computer system 412 to communicate with one or more other computer devices, or a combination thereof. Such communication may occur via an input / output (I / O) interface 422. Still further, the computer system 412 may communicate with one or more networks, such as a local area network (LAN), a general wide area network (WAN), or a public network (e.g., the Internet), or a combination thereof, via a network adapter 420. As shown, the network adapter 420 communicates with other components of the computer system 412 via a bus 418. It should be understood that, although not shown, other hardware or software components, or combinations thereof, may be used in combination with the computer system 412. Examples include, but are not limited to, microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data archive storage systems.

[0051] Although computing node 400 is used to illustrate an example of a cloud computing node, it should be understood that computer systems using the same or similar architecture as that described in connection with Figure 4 may be used in non-cloud computing implementations to perform the various operations described herein. In this regard, the example configurations described herein are not intended to be limited to cloud computing environments.

[0052] Computing node 400 is an example of computer hardware. Computing node 400 may include fewer components than those shown in FIG. 4 or additional components not shown, depending on the particular type of device or system or combination thereof implemented. The particular operating system and / or one or more applications included may vary according to the type of device or system or combination thereof, as well as the type of I / O devices included. Furthermore, one or more of the illustrated components may be embedded within or form part of other components. For example, a processor may include at least some memory.

[0053] Although this disclosure includes detailed descriptions related to cloud computing, it should be expressly noted that implementation of the teachings recited herein is not limited to cloud computing environments. Rather, embodiments of the present invention can be implemented in conjunction with any other type of computing environment now known or later developed.

[0054] Cloud computing is a service delivery model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be rapidly provisioned and released with minimal administrative effort or interaction with the provider of the service. The cloud model can include at least five characteristics, at least three service models, and at least four deployment models.

[0055] The features are as follows:

[0056] On-demand self-service: A cloud consumer can unilaterally provision computing capacity, such as server time and network storage, as needed, without requiring human interaction with the provider of the service.

[0057] Broad network access: Functionality is available over the network and accessed via standard mechanisms that facilitate use by heterogeneous thin or thick client platforms (e.g., mobile phones, laptops, and PDAs).

[0058] Resource Pooling: A provider's computing resources are pooled to serve multiple consumers using a multi-tenant model, and various physical and virtual resources are dynamically allocated and reallocated according to demand. Consumers generally have no control or knowledge of the exact location of the resources provided, but are said to be location-independent in that they may be able to specify a location at a higher level of abstraction (e.g., country, state, or data center).

[0059] Rapid Elasticity: Capabilities can be provisioned quickly and elastically, sometimes automatically, scaled out quickly, released quickly, and scaled in quickly. To the consumer, the capabilities available for provisioning are often unlimited and can be purchased in any quantity at any time.

[0060] Measured Services: Cloud systems automatically control and optimize resource usage by using metering capabilities at some level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency to both providers and consumers of the services being used.

[0061] The service model is as follows:

[0062] Software as a Service (SaaS): The capability offered to consumers to use a provider's applications running on a cloud infrastructure. The applications are accessible from a variety of client devices through a thin-client interface, such as a web browser (e.g., web-based email). The consumer does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, storage, or even individual application functions, with the possible exception of limited user-specific application configuration settings.

[0063] Platform as a Service (PaaS): The capability offered to consumers to deploy applications they create or acquire, written using programming languages ​​and tools supported by the provider, onto a cloud infrastructure. The consumer does not manage or control the underlying cloud infrastructure (e.g., including networks, servers, operating systems, or storage), but does have control over the deployed applications and, in some cases, the application-hosting environment configuration.

[0064] Infrastructure as a Service (IaaS): The capability offered to consumers to provision processing, storage, network, and other basic computing resources on which they can deploy and run any software, which may include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure, but does have control over the operating systems, storage, deployed applications, and in some cases, limited control over selecting network components (e.g., host firewalls).

[0065] The deployment models are as follows:

[0066] Private Cloud: Cloud infrastructure is operated exclusively for an organization. The cloud infrastructure may be managed by the organization or a third party, and may reside on-premises or off-premises.

[0067] Community Cloud: Cloud infrastructure is shared by several organizations and supports a specific community with common interests (e.g., mission, security requirements, policies, and compliance considerations). The cloud infrastructure may be managed by the organizations or a third party and may reside on-premises or off-premises.

[0068] Public Cloud: Cloud infrastructure is available to the general public or large industry groups and is owned by organizations that sell cloud services.

[0069] Hybrid Cloud: A cloud infrastructure is a blend of two or more clouds (private, community, or public) that remain unique entities but are brought together by standardized or proprietary technologies (e.g., cloud bursting for load balancing between clouds) that enable data and application portability.

[0070] A cloud computing environment is service oriented with a focus on statelessness, low coupling, modularity, and semantic interoperability. At the heart of cloud computing is an infrastructure comprising a network of interconnected nodes.

[0071] FIG. 5 illustrates a cloud computing environment 500 according to an embodiment of the present disclosure. As illustrated, the cloud computing environment 500 includes one or more cloud computing nodes 510, with which local computing devices used by cloud consumers, such as a personal digital assistant (PDA) or mobile phone 540A, a desktop computer 540B, a laptop computer 540C, or an automotive computer system 540N, or any combination thereof, may communicate. The computing nodes 510 may communicate with each other. The computing nodes 510 may be physically or virtually grouped into one or more networks (not shown), such as a private cloud, community cloud, public cloud, or hybrid cloud, or any combination thereof, as previously described herein. This enables the cloud computing environment 500 to provide infrastructure, platform, or software, or any combination thereof, as a service without the cloud consumer having to maintain resources on their local computing device. It is understood that the types of computing devices 540A-540N shown in FIG. 5 are intended to be illustrative only, and that the cloud computing node 510 and cloud computing environment 500 can communicate with any type of computerized device (e.g., using a web browser) over any type of network or network-addressable connection or combination thereof.

[0072] Referring now to Figure 6, there is illustrated a set of abstraction model layers (Figure 5) provided by cloud computing environment 500. It should be understood that the components, layers, and functions illustrated in Figure 6 are intended to be merely exemplary, and that embodiments of the present disclosure are not limited thereto. As illustrated, the following layers and corresponding functions are provided:

[0073] Hardware and software layer 660 includes hardware and software components. Examples of hardware components include mainframe 661, RISC (Reduced Instruction Set Computer) architecture-based servers 662, servers 663, blade servers 664, storage devices 665, and networks and networking components 666. In some embodiments, software components include network application server software 667 and database software 668.

[0074] The virtualization layer 670 provides an abstraction layer from which the following examples of virtual entities can be provided: virtual servers 671; virtual storage 672; virtual networks 673, such as those described above including virtual private networks; virtual applications and operating systems 674; and virtual clients 675.

[0075] In one example, management layer 680 may provide several functions, as described below. Resource provisioning 681 provides dynamic procurement of computing and other resources used to execute tasks within the cloud computing environment. Metering and pricing 682 provides cost tracking as resources are utilized within the cloud computing environment and billing or invoicing for the consumption of these resources. In one example, these resources may include application software licenses. Security provides identity verification for cloud consumers and tasks and protection for data and other resources. User portal 683 provides access to the cloud computing environment for consumers and system administrators. Service level management 684 provides allocation and management of cloud computing resources so that required service levels are met. Service level agreement (SLA) planning and fulfillment 685 provides pre-provisioning and procurement of cloud computing resources where future requirements are predicted according to SLAs.

[0076] Workload layer 690 provides examples of functions for which a cloud computing environment may be utilized. Examples of workloads and functions that may be provided from this layer include mapping and navigation 691; software development and lifecycle management 692; virtual classroom instruction delivery 693; data analytics processing 694; transaction processing 695; and a VM file management system 696.

[0077] The terms used herein are for the purpose of describing particular embodiments only and are not intended to be limiting. Nevertheless, certain definitions that apply throughout the specification will be set forth here.

[0078] As defined herein, the singular forms "a", "an" and "the" also include the plural forms unless the context clearly dictates otherwise.

[0079] As defined herein, "another" means at least two or more.

[0080] As defined herein, "at least one," "one or more," and "and / or" are open-ended expressions that are both conjunctive and disconnected in operation unless expressly stated otherwise. For example, each of the phrases "at least one of A, B, and C," "at least one of A, B, or C," "one or more of A, B, and C," "one or more of A, B, or C," and "A, B, and / or C" means A alone, B alone, C alone, A and B together, A and C together, B and C together, or A, B, and C together.

[0081] As defined herein, "automatically" and "dynamically" mean without user intervention.

[0082] As defined herein, "comprises," "comprising," "including," and / or "comprising" specify the presence of features, integers, steps, operations, elements or components, or combinations thereof, described herein, but do not exclude the presence or addition of one or more other features, integers, steps, operations, elements or components, or combinations thereof.

[0083] As defined herein, "when" can mean "in response to" or "in response to," depending on the context. Thus, the phrase "when determined" can be interpreted to mean "in response to determining" or "in response to determining," depending on the context. Similarly, the phrase "when [described condition or event] is detected" can be interpreted as "in response to detecting [described condition or event]" or "in response to detecting [described condition or event]" or "in response to detecting [described condition or event]," depending on the context.

[0084] As defined herein, the terms "a configuration," "a configuration," "in one or more configurations," "in a particular configuration," or similar terms mean that a particular feature, structure, or characteristic described in connection with a configuration is included in at least one configuration described within this disclosure. Thus, appearances of the foregoing phrases, or similar words, or combinations thereof, throughout this disclosure may, but do not necessarily, all refer to the same configuration.

[0085] As defined herein, "in response to" and "in reaction to" mean to respond or react readily to an action or event. Thus, when a second action is performed "in response to" and "in reaction to" a first action, there is a causal relationship between the occurrence of the first action and the occurrence of the second action. The phrases "in response to" and "in reaction to" indicate a causal relationship.

[0086] As defined herein, "substantially" means that the stated property, parameter, or value need not be achieved exactly, but that deviations or variations, including, for example, tolerances, measurement errors, limits of measurement accuracy, and other factors known to those skilled in the art, may occur in an amount that does not interfere with the effect that the property is intended to provide.

[0087] As defined herein, the terms "user," "requester," and "IT administrator" each refer to a human being.

[0088] In this specification, the terms "first," "second," etc. may be used to describe various elements. These terms are used only to distinguish one element from another, and should not be construed as limiting these elements, unless otherwise specified or clearly indicated by context.

[0089] The present invention may be a system, method, computer program product, or computer program, or any combination thereof, at any level of technical detail that may be integrated. The computer program product may include one or more computer-readable storage media having computer-readable program instructions for causing a processor to perform aspects of the present invention.

[0090] The computer-readable storage medium can be a tangible device that can hold and store instructions for use by an instruction-execution device. The computer-readable storage medium can be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. A non-exhaustive list of more specific examples of the computer-readable storage medium includes the following: a portable computer diskette 登録商標, hard disk, random access memory (RAM), read only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital versatile disk (DVD), memory stick, floppy disk, mechanically encoded device such as punch cards or raised structures in grooves in which instructions are stored, or any suitable combination thereof. As used herein, computer-readable storage medium should not be interpreted as a transitory signal per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., light pulses passing through a fiber optic cable), or electrical signals transmitted over electrical wires.

[0091] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to an individual computing device / processing device, or to an external computer or external storage device via a network, such as the Internet, a local area network, a wide area network, or a wireless network, or a combination thereof. The network may be comprised of copper transmission cables, optical fiber transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, or edge servers, or a combination thereof. A network adapter card or network interface in each computing device / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in a computer-readable storage medium within the individual computing device / processing device.

[0092] The computer-readable program instructions for carrying out the operations of the present invention may be either assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, configuration data for an integrated circuit, or source or object code written in any combination of one or more programming languages, such as object-oriented programming languages, e.g., Smalltalk, C++, etc., or conventional procedural programming languages ​​(e.g., the "C" programming language or similar programming languages). The computer-readable program instructions may be executed entirely on the user's computer, partially on the user's computer, partially on the user's computer as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any kind of network, such as a local area network (LAN) or a wide area network (WAN), or the connection may be to an external computer (e.g., over the Internet using an Internet Service Provider). In some embodiments, electronic circuits, such as programmable logic circuits, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), may execute computer-readable program instructions by utilizing state information of the computer-readable program instructions to personalize the electronic circuitry to perform aspects of the invention.

[0093] Aspects of the present invention are described herein with reference to flowchart illustrations or block diagrams, or combinations thereof, of methods, apparatus (systems), and computer program products or computer programs according to embodiments of the invention. It will be understood that each block of the flowchart illustrations or block diagrams, or combinations thereof, and combinations of blocks in the flowchart illustrations or block diagrams, or combinations thereof, can be implemented by computer-readable program instructions.

[0094] These computer-readable program instructions may be provided to a processor of a computer or other programmable data processing apparatus, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / acts specified in one or more blocks of the flowchart diagrams or the block diagrams, or a combination thereof, to produce a machine. These computer-readable program instructions may also be stored in a computer-readable storage medium that can direct a computer-programmable data processing apparatus or other device, or a combination thereof, to function in a particular manner, such that a computer-readable storage medium having stored instructions includes an article of manufacture including instructions that implement aspects of the functions / acts specified in one or more blocks of the flowchart diagrams or the block diagrams, or a combination thereof.

[0095] The computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device such that the instructions, which execute on a computer, other programmable data processing apparatus, or other device, implement the functions / acts identified in one or more blocks of the flowchart diagrams or block diagrams, or a combination thereof, causing the computer, other programmable apparatus, or other device to perform a series of operating steps to create a computer-implemented process.

[0096] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products or computer programs according to various embodiments of the present invention. In this regard, each block in the flowcharts or block diagrams may represent a module, segment, or portion of instructions, which includes one or more executable instructions for implementing one or more specified logical functions. In some alternative implementations, the functions shown in the blocks may occur out of the order shown in the figures. For example, two blocks shown in succession may actually be accomplished as a single step performed simultaneously, substantially simultaneously, partially, or fully in a time-overlapping manner, depending on the functionality involved, or the blocks may be performed in the reverse order. It should be noted that each block of the block diagrams or flowchart diagrams or combinations thereof, and combinations of multiple blocks in the block diagrams or flowchart diagrams or combinations thereof, may be implemented by a special-purpose hardware-based system that performs the specified functions or operations, or may execute a combination of special-purpose hardware and computer instructions.

[0097] The description of various configurations of the present invention has been presented for illustrative purposes and is not intended to be exhaustive or limited to the disclosed configurations. Many modifications and variations will be apparent to those skilled in the art without departing from the scope of the described configurations. The terms used in this specification have been selected to best explain the principles of embodiments, practical applications, or technical improvements over commercially available technology, or to enable others skilled in the art to understand the configurations disclosed herein.

Claims

1. 1. A computer-implemented method comprising: Detecting a user's electronic request for access to a virtual machine (VM); searching a predefined user list to determine whether the user requesting access is identified in the predefined user list; In response to identifying the user in the predefined user list, creating a file-level snapshot at a top layer of a stack before allowing the user to modify a VM file, wherein the file-level snapshot includes a user attribute indicating a role of the user for whom the file-level snapshot is created and a timestamp indicating a time when the file-level snapshot is created, and each layer of the stack includes a file-level snapshot that includes one or more VM files in their entirety; In response to user input from the user that modifies the VM file, saving the entire VM file, including the portion modified by the user, to the single file-level snapshot; and selecting a set of file-level snapshots from the stack based on user attributes of each selected file-level snapshot; and modifying the VM by merging the VM files captured by the snapshots belonging to the set of file-level snapshots. Including, The method.

2. 2. The method of claim 1, wherein each of the plurality of file-level snapshots selected for merging has a user attribute indicating that the role of the user for whom the selected one of the file-level snapshots was created is an IT administrator, and wherein modifying includes rolling back the VM by merging only latest versions of VM file changes made by one or more IT administrators and preserving all other VM files of the VM in their original, unmodified states.

3. 2. The method of claim 1, wherein the multiple file-level snapshots are multiple overlay file-level snapshots implemented with a union mount file system that combines multiple mount points to create a single directory structure containing separately sourced files and subdirectories.

4. 2. The method of claim 1, wherein the single file-level snapshot added as the top layer of the stack is the only active snapshot that supports both reading and writing data, while the lower layer file-level snapshots are read-only.

5. 2. The method of claim 1, further comprising: reclaiming data storage space associated with the VM by deleting each of the plurality of file-level snapshots in response to modifying the VM.

6. 2. The method of claim 1, further comprising: storing a timestamp indicating a time when the one file-level snapshot added as the top layer was created; and maintaining a list of the file-level snapshots stored in the stack ordered according to a timestamp associated with each stored file-level snapshot.

7. The method of claim 1 , wherein the detecting is performed by an access request monitor (ARM) integrated within a hypervisor supporting the VM.

8. 1. A system comprising: a processor configured to initiate instructions It is equipped with The instruction: Detecting a user's electronic request for access to a virtual machine (VM); searching a predefined user list to determine whether the user requesting access is identified in the predefined user list; In response to identifying the user in the predefined user list, creating a file-level snapshot at a top layer of a stack before allowing the user to modify a VM file, wherein the file-level snapshot includes a user attribute indicating a role of the user for whom the file-level snapshot is created and a timestamp indicating a time when the file-level snapshot is created, and each layer of the stack includes a file-level snapshot that includes one or more VM files in their entirety; In response to user input from the user that modifies the VM file, saving the entire VM file, including the portion modified by the user, to the single file-level snapshot; and selecting a set of file-level snapshots from the stack based on user attributes of each selected file-level snapshot; and modifying the VM by merging the VM files captured by the snapshots belonging to the set of file-level snapshots. The system comprising:

9. 9. The system of claim 8, wherein each of the plurality of file-level snapshots selected for merging has a user attribute indicating that the role of the user for whom the selected one of the file-level snapshots was created is an IT administrator, and wherein the modifying includes rolling back the VM by merging only latest versions of VM file changes made by one or more IT administrators and preserving all other VM files of the VM in their original, unmodified states.

10. 9. The system of claim 8, wherein the multiple file-level snapshots are multiple overlay file-level snapshots implemented with a union mount file system that combines multiple mount points to create a single directory structure containing separately sourced files and subdirectories.

11. 9. The system of claim 8, wherein the single file-level snapshot added as the top layer of the stack is the only active snapshot that supports both reading and writing of data, while the multiple file-level snapshots at lower layers are read-only.

12. 9. The system of claim 8, wherein the processor is configured to initiate instructions further comprising, in response to modifying the VM, reclaiming data storage space associated with the VM by deleting each of the plurality of snapshots.

13. 9. The system of claim 8, wherein the processor is configured to initiate instructions further including: storing a timestamp indicating a time when the one file-level snapshot added as the top layer was created; and maintaining a list of the file-level snapshots stored in the stack ordered according to a timestamp associated with each stored file-level snapshot.

14. A computer program comprising: Detecting a user's electronic request for access to a virtual machine (VM); searching a predefined user list to determine whether the user requesting access is identified in the predefined user list; In response to identifying the user in the predefined user list, creating a file-level snapshot at a top layer of a stack before allowing the user to modify a VM file, wherein the file-level snapshot includes a user attribute indicating a role of the user for whom the file-level snapshot is created and a timestamp indicating a time when the file-level snapshot is created, and each layer of the stack includes a file-level snapshot that includes one or more VM files in their entirety; In response to user input from the user that modifies the VM file, saving the entire VM file, including the portion modified by the user, to the single file-level snapshot; and selecting a set of file-level snapshots from the stack based on user attributes of each selected file-level snapshot; and modifying the VM by merging the VM files captured by the snapshots belonging to the set of file-level snapshots. The computer program causing a processor to execute each step of a method including the steps of:

15. 15. The computer program product of claim 14, wherein each of the plurality of file-level snapshots selected for merging has a user attribute indicating that the role of the user for whom the selected file-level snapshot was created is an IT administrator, and wherein modifying includes rolling back the VM by merging only latest versions of VM file changes made by one or more IT administrators and preserving all other VM files of the VM in their original, unmodified states.

16. 15. The computer program product of claim 14, wherein the multiple file-level snapshots are multiple overlay file-level snapshots implemented with a union mount file system that combines multiple mount points to create a single directory structure containing separately sourced files and subdirectories.

17. 15. The computer program product of claim 14, wherein the single file-level snapshot added as the top layer of the stack is the only active snapshot that supports both reading and writing of data, while the multiple file-level snapshots at lower layers are read-only.

18. 15. The computer program product of claim 14, further causing the processor to reclaim data storage space associated with the VM by deleting each of the plurality of snapshots in response to modifying the VM.

19. 15. The computer program product of claim 14, further causing the processor to: store a timestamp indicating a time when the one snapshot added as the top layer was created; and maintain a list of the snapshots stored in the stack ordered according to a timestamp associated with each stored snapshot.

20. The computer program product of claim 14 , wherein the detecting is performed by an access request monitor (ARM) integrated within a hypervisor supporting the VM.

Images