Method for obtaining a snapshot image of a disk shared by multiple virtual machines

Methods for obtaining a snapshot of a shared virtual machine (VM) image are described herein. In response to a request for obtaining a snapshot of a first VM image stored in a storage disk accessed and shared by a plurality of VMs, a virtualization manager selects a VM from the plurality of VMs hosted within one or more hosts. First needs to notify others to prepare for the snapshot by pausing, etc. A process associated with the selected VM is configured to capture a snapshot from the first VM image, generating a second VM image to be stored in storage disk. Thereafter, the virtualization manager notifies the plurality of VMs to utilize the second image after the second VM image has been generated.

TECHNICAL FIELD

Embodiments of the present invention relate generally to network computing. More particularly, embodiments relate to techniques for obtaining a snapshot image of a disk shared by multiple virtual machines.

BACKGROUND

Generally, the concept of virtualization in information processing systems allows multiple instances of one or more operating systems to run on a single system, even though each operating system (OS) is designed to have complete, direct control over the system and its resources. Virtualization is typically implemented by using software (e.g., a virtual machine monitor, or a “VMM”) to present to each OS a “virtual machine” (“VM”) having virtual resources, including one or more virtual processors, that the OS may completely and directly control, while the VMM maintains a system environment for implementing virtualization policies such as sharing and/or allocating the physical resources among the VMs (the “virtualization environment”). Each OS, and any other software, that runs on a VM is referred to as a “guest” or as “guest software,” while a “host” or “host software” is software, such as a VMM, that runs outside of, and may or may not be aware of, the virtualization environment.

The virtualization technologies have wide applications in the computer field with the development of computer systems. For example, such virtualization technologies can be used to implement a virtual desktop application which runs within a virtual machine and can be accessed from a client over a network.

When there are multiple VMs that share the same VM image, taking a snapshot may cause certain disruptions to operations of the VMs.

DETAILED DESCRIPTION

As described above, when there are multiple VMs that share the same VM image, taking a snapshot may cause certain disruptions to operations of the VMs.

According to some embodiments, a mechanism is provided for synchronizing data among multiple VMs (e.g., distributed VMs) that share a disk supporting snapshots of VM images. The snapshots are managed by a host hosting the VMs rather than a central storage server. According to one embodiment, when a request is received to take a snapshot of a VM image stored in a storage device such as a disk shared by multiple VMs (e.g., for the backup purpose), a manager is configured to communicate and to prepare all VMs to be ready for taking the snapshot. For example, the manager may suspend some or all VMs' operations and flush any pending input and output (IO) activities to the VM image of the shared disk before taking the snapshot. In one embodiment, the manager may select one of the VMs to take a snapshot of the VM image stored in the disk, which creates a new active snapshot VM image, where the original VM image can be used as a backup copy. Once the new active snapshot VM image has been created, the manager may notify the VMs to utilize the new VM image going forward and the VMs may resume their operations respectively using the new VM image.

FIG. 1is a block diagram illustrating an example of a network configuration according to one embodiment of the invention. Referring toFIG. 1, network configuration100includes, but is not limited to, one or more clients101communicatively coupled to a remote server or a cluster of servers104over a network103. Network103may be a local area network (LAN) or a wide area network (WAN) and may be a combination of one or more networks. Client101can be any computer system in communication with server104for remote execution of applications at server104.

For example, system100may be implemented as part of a graphics remoting system. Generally, a client such as client101can be a computer system in communication with server104for remote execution of applications at server104. Thus, input data (e.g., mouse and keyboard input) representing application commands is received at the client and transferred over network103to server104. In response to client side data, an application (e.g., desktop application108) can generate output display commands (e.g., graphics commands, simply referred to herein as graphics data), which may include one or more paint and/or draw operations, for example, in the form of executable instructions. The output display commands can then be transmitted (e.g., as graphics update commands) with an optional compression back to the remote client and a remote display driver (e.g., a rendering agent116) of the remote client can collect the graphics commands and generate corresponding drawing commands for rendering at a display device of the client. Note that a desktop application is utilized herein as an example; however, any other application may also be applied.

In one embodiment, server104is configured to host one or more virtual machines (VMs)107managed by a VM manager109. Each of the VMs107may host one or more desktop applications108(e.g., desktop operating system). Desktop application108may be executed and hosted by an operating system within virtual machine107. Such an operating system in virtual machine107is also referred to as a guest operating system. Multiple guest operating systems and the associated virtual machines may be controlled by another operating system (also referred to as a host OS). Typically, a host OS represents a virtual machine monitor (VMM) (also referred to as a hypervisor) for managing the hosted virtual machines. A guest OS may be of the same or different type with respect to the host OS. For example, a guest OS may be a Windows™ operating system from Microsoft and a host OS may be a Linux operating system available from Red Hat.

Virtual machine107can be any type of virtual machines, such as, for example, hardware emulation, full virtualization, para-virtualization, and operating system-level virtualization virtual machines. Different virtual machines hosted by server104may have the same or different privilege levels for accessing different resources.

System100may be implemented as part of a server or a cluster of servers within a data center of an enterprise entity. It allows enterprises the benefit of centralized desktops without the need to change their applications or infrastructure. Enterprises benefit from an improvement in the manageability, security and policy enforcement for their desktop environment, and consequently, realize a significant reduction in the desktop TCO (total cost of ownership).

Host server104and client101may be configured and managed by a virtualization manager110of a management server102using a variety of network management protocols, such as, for example, simple network management protocol (SNMP). Configuration information (e.g., parameters) of host104and/or client101may be stored in a configuration database111. For example, in a graphics remoting application, host server104may be implemented as a VDS server while management server102may be implemented as a virtual desktop control (VDC) server.

In one embodiment, server104may be a member of a cluster of servers, where each of the member servers of the same cluster is coupled to the same network or the same segment of a network, also referred to as a logical network. In addition, all server members of a cluster may share disk storage112, for example, over a storage network. The shared disk storage112may be used to store VM images (e.g., virtual desktop images) shared by multiple VMs107. A VM image may include code base of a guest OS and guest applications, libraries, and data used by the guest OS and guest applications, etc.

According to certain embodiments, when a request is received to take a snapshot of a VM image stored in disk112and shared by multiple VMs107(e.g., for the backup purpose), manager110is configured to communicate and prepare all VMs107to be ready for taking the snapshot. For example, manager110may communicate with manager109to suspend some or all operations of VMs107and to flush any pending input and output (IO) activities to the VM image of the shared disk112before taking the snapshot. In one embodiment, manager110(e.g., in communications with manager109) may select one of the VMs107to take a snapshot of the VM image stored in disk112, which creates a new active snapshot VM image, where the original VM image can be used as a backup copy. Once the new active snapshot VM image has been created, manager110and/or manager109may notify VMs107to utilize the new VM image going forward and VMs107may resume their operations respectively using the new VM image. Note that VMs107may include multiple VMs that may reside on the same host or different hosts that share the same storage112.

FIG. 2is a block diagram illustrating an example of a virtualization system according to one embodiment of the invention. For example, hosts201A-201B may be implemented as part of a host104(e.g., VDS) and disk202may be implemented as part of storage112ofFIG. 1. Management server216may be implemented as part of management server102(e.g., VDC) ofFIG. 1. Referring toFIG. 2, system200includes one or more hosts201A-201B communicatively coupled to a storage disk202. Hosts201A-201B may host one or more VMs203-204respectively, which may be managed by VM managers205A-205B respectively, which may be a VMM or Hypervisor, or alternatively a VDSM. VMs203-204may be implemented as part of VMs107ofFIG. 1. Each VM may host one or more applications (e.g., applications206-207) such as virtual desktop applications in a graphics remoting environment.

In addition, management server216includes a host monitoring unit220and a host configuration unit219, which may be implemented as part of virtualization manager110ofFIG. 1. The host configuration unit219and host monitoring unit220are configured to configure and monitor hosts201A-201B over network215using a variety of network management protocols such as SNMP. For example, host monitoring unit220of management server216may periodically communicate with managers205A-205B of hosts201A-201B to receive certain signals (e.g., heartbeats) indicating that the respective hosts are operating correctly. The configuration information and operating statues of hosts201A-201B may be stored in database221.

In addition, a shared storage such as a disk202is coupled to hosts201A-201B. Disk202may be coupled to hosts201A-201B over a variety of storage networks or protocols, such as, for example, storage area network (SAN), network file system (NFS), Internet small computer system interface (iSCSI), and/or fibre channel, etc. Disk202may include one or more storage volumes210-211, which may be physical or logical volumes. Each volume may store one or more VM images used by VMs203-204. For example, data212may be part of virtual desktop images used by a virtual desktop application such as applications206-207. Applications206-207may access data212-213via their respective virtual IO devices such as virtual IO devices208-209. Such a virtual IO device may be a hardware emulator such as QEMU emulator in a kernel-based VM architecture. For example, virtual IO devices208-209may be virtual storage devices that are used to access data212-213stored in disk202.

According to one embodiment, when a request is received to take a snapshot of a VM image stored in disk202and shared by multiple VMs203-204(e.g., for the backup purpose), host configuration unit219is configured to communicate with managers205A-205B to prepare all VMs203-204to be ready for taking the snapshot. The request may be received from a user or administrator, or alternatively, it may be triggered by a prescheduled event (e.g., backup process event). For example, host configuration unit219may suspend some or all operations of VMs203-204and flush any pending input and output (IO) activities to the VM image of the shared disk202before taking the snapshot. In one embodiment, host configuration unit219may select one of the VMs203-204to take a snapshot of the VM image stored in disk202, which creates a new active snapshot VM image, where the original VM image may become a read-only copy. Once the new active snapshot VM image has been created, host configuration unit219may notify VMs203-204to utilize the new VM image going forward and VMs203-204may resume their operations respectively using the new VM image.

For example, for the purpose of illustration, it is assumed that applications206-207of VMs203-204are currently using VM images212stored in volume210of disk202via their respective virtual IO devices208-209. When a request for taking a snapshot of data212is received, host configuration unit219may notify (e.g., via manager205A or205B) VMs203-204to suspend some or all of the pending IO activities (e.g., read and write activities) to data212. A snapshot of data212is then taken, which creates a new image, in this example, data213. Once the new image213has been created, host configuration unit219may notify VMs203-204to utilize the new data image213and data212may become a backup copy. Suspending IO may cause problems of timeouts to the guest and its applications. So it may notify to suspend IO, but may simply notify to pause the VM entirely (which means halting the cpu as well). Suspending only IO is an option passive nodes of an active/passive cluster, only for the shared data disk being snapshot-ed.

After VMs203-204resume their operations, within a grace period of time, the original pending IO activities may continue accessing data212, while new activities may access data213. In this situation, the residual IO activities to data212may be copied to data213(e.g., via copy-on-write operations). Alternatively, all pending IO activities are flushed to data212before taking the snapshot. If there is an error occurred in any of the VMs203-204during the transition from data212to data213, which may be monitored by host monitoring unit220, all VMs203-204may roll back to a previous copy or the last known good copy of the VM image, in this example, data212.

In one embodiment, one of the VMs203-204may be selected by host configuration unit219to take the snapshot. Alternatively, the snapshot may be taken by one of managers205A-205B. A VM that performs the most IO activities to disk202may be selected to take the snapshot, which may be based on the statistics of the VMs collected over a period of time (e.g., monitored by host monitoring unit220and/or manager205A or205B). Such a VM may be the last VM to be suspended prior to taking the snapshot and such a VM may be the first one to resume thereafter. Such an optimization is useful because typically in certain types of clusters, one host is active while others are passive.

Since sometimes clusters perform multiple services using different disks, instead of suspending all VMs, according to one embodiment, host configuration unit219may instruct the corresponding virtual IO devices208-209to suspend all write operations to disk202without suspending the corresponding VMs. That is, instead of suspending the VMs which also suspends all IO activities to all disks, the system only suspends a virtual IO device corresponding to a disk in which a snapshot is to be taken. As a result, the IO activities to other disks are not disrupted.

Note that snapshots are usually related to metadata on certain data blocks such as copy-on-write (COW) blocks. Thus, there is a need to synchronize the metadata among multiple VMs (i.e., their respective QEMU processes). According to one embodiment, one VM has to receive an approval from another VM before changing or committing change of the metadata (e.g., synchronous way). Alternatively, one VM has to lock and refresh the metadata before reading the metadata (e.g., asynchronous way). Another approach is that a guest would not read data from the storage before the storage changes to an active state. The change of storage to an active state would cause a collaborative change in a virtual IO device (e.g., QEMU) to re-read the metadata and to change the state of the guest to the storage (e.g., changing a previous active state to a read-only state).

Note that some or all of the components as shown inFIG. 2may be implemented in software, hardware, or a combination of both.

FIG. 3is a flow diagram illustrating a method for obtaining snapshots of VM images according to one embodiment. Note that method300may be performed by processing logic which may include software, hardware, or a combination of both. For example, method300may be performed by host configuration unit219and/or host monitoring unit220ofFIG. 2. Referring toFIG. 3, at block301, a request is received to take a snapshot of a first VM image stored in a disk shared by multiple VMs that are hosted by one or more servers. For example, such a request may be received due to a prescheduled backup operation. In response to the request, at block302, a manager (e.g., managers110and/or manager109ofFIG. 1) suspends IO activities of some or all VMs to data representing the first VM image. Alternatively, the manager suspends the disk access activities to the first image of certain virtual IO devices of the VMs without completely suspending the VMs. At block303, the manager selects one of the VMs to take a snapshot from the first VM image and to generate a second VM image based on the snapshot to be stored in the shared disk. After the snapshot has been taken and the second VM image has been created, at block304, the manager notifies all VMs to resume operations using the second VM image. At block305, any subsequent IO activities are synchronized between the first and second VM images.

The computer system800may further include a network interface device822. The computer system800also may include a video display unit810(e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)), an alphanumeric input device812(e.g., a keyboard), a cursor control device814(e.g., a mouse), and a signal generation device820(e.g., a speaker).

The data storage device816may include a computer-accessible storage medium824(also known as a machine-readable storage medium or a computer-readable medium) on which is stored one or more sets of instructions or software (e.g., virtualization manager110) embodying any one or more of the methodologies or functions described herein. The virtualization manager110may also reside, completely or at least partially, within the main memory804and/or within the processing device802during execution thereof by the computer system800, the main memory804and the processing device802also constituting machine-accessible storage media. The virtualization manager110may further be transmitted or received over a network via the network interface device822.

The modules828, components and other features described herein can be implemented as discrete hardware components or integrated in the functionality of hardware components such as ASICS, FPGAs, DSPs or similar devices. In addition, the modules828can be implemented as firmware or functional circuitry within hardware devices. Further, the modules828can be implemented in any combination hardware devices and software components.

Embodiments of the present invention also relate to an apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes, or it may comprise a general-purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a computer readable medium. A machine-readable medium includes any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computer). For example, a machine-readable (e.g., computer-readable) medium includes a machine (e.g., a computer) readable storage medium (e.g., read only memory (“ROM”), random access memory (“RAM”), magnetic disk storage media, optical storage media, flash memory devices), etc.