Hypervisor assisted single instance data access by multiple virtual machines

A data instance to be shared by multiple virtual machines is stored at a hypervisor level. A file system driver is provided to each virtual machine. Each virtual machine mounts a file system backed by the data instance, and thus has read access to the data through its mounted file system. A virtual machine is suspended. A copy of the data instance is saved as part of the stored image of the suspended virtual machine. The suspended virtual machine is subsequently restored from the stored image, and the copy of the data instance is present in the restored virtual machine. The copy of the data instance is detected at a hypervisor level, and the restored virtual machine is provided with read access to the data instance through its mounted filed system.

TECHNICAL FIELD

This disclosure pertains generally to sharing data between multiple virtual computing devices, and more specifically to sharing a single instance of data between multiple virtual machines with support for virtual machine suspension, resumption and migration.

BACKGROUND

In the world of virtual computing, multiple virtual machines (VMs or guests) can be instantiated at a software level on a single physical computer (host computer). In various virtualization scenarios, a software component often called a hypervisor can act as an interface between the guests and the host operating system for some or all of the functions of the guests. In other virtualization implementations, there is no underlying host operating system running on the physical, host computer. In those situations, the hypervisor acts as an interface between the guests and the hardware of the host computer. Even where a host operating system is present, the hypervisor sometimes interfaces directly with the hardware for certain services. In some virtualization scenarios, the host itself is in the form of a guest (i.e., a virtual host) running on another host. The services described herein as being performed by a hypervisor are, under certain virtualization scenarios, performed by a component with a different name, such as “supervisor virtual machine,” “virtual machine manager (VMM),” “service partition,” or “domain 0 (dom0).” The name used to denote the component(s) performing specific functionality is not important.

The operation of individual virtual machines can be suspended and subsequently resumed. When a virtual machine is suspended, an image of the virtual machine, is stored in a format such as Open Virtualization Format (OVF). The OVF image of a virtual machine can later be used to resume the virtual machine on the host. Virtual machines can also be migrated between hosts, essentially by suspending the virtual machine on a first host and subsequently resuming it on a second host. Various optimizations exist to simulate the instantaneous or “live” migration of a running virtual machine from one host to another, for example by building as much of the virtual machine image on the second host in advance as possible, suspending the virtual machine on the first host, very quickly transmitting the active memory and precise execution state of the virtual machine to the second host, and then activating the virtual machine on the second host as quickly as possible. The suspend and restore can thus be done in sufficiently rapid succession to appear instantaneous to a user.

Sometimes it would be desirable for multiple virtual machines to be able to share the same data, in order to enable the group of virtual machines to be able access a single, large data set without each virtual machine having to store a copy. For example, it would be desirable for a group of virtual machines with a common hypervisor to share a single copy of a set virus definitions (100+ megabytes of information) to use for scanning files to detect malicious code, rather than require each separate virtual machine to store its own 100+ megabyte copy. This same concern is true for other types of large data sets.

However, if a group of virtual machines were sharing a single data set and an individual virtual machine of the group were suspended for subsequent restoration or migration, the shared data would become out of synchronization with either the suspended virtual machine or the non-suspended virtual machines. Because a suspended virtual machine must be restored into the exact state from which it was suspended, the shared data set would have to be frozen at the time of suspension to stay in synchronization with the suspended virtual machine. But, if other virtual machines sharing the data set were not suspended, the shared data set would have to remain active in order to stay in synchronization with them. However, if the shared data set were to become out of synchronization with any of the multiple virtual machines sharing the data, an error condition would result.

It would be desirable to address these issues.

SUMMARY

With hypervisor level assistance, shared access to a single data instance is provided to multiple virtual machines. The single data instance to be shared by a plurality of virtual machines is stored at a hypervisor level. In some embodiments, the single data instance is stored at a hypervisor level as a formatted disk image file which is internally treated as a series of blocks, although other storage formats are used in other embodiments. A file system driver is provided from a hypervisor level to each virtual machine of the plurality that is to share the single data instance. In some embodiments, the provided file system driver is in the form of a block driver. Each virtual machine of the plurality that is to share the single data instance mounts a file system backed by the hypervisor level single data instance, such that each virtual machine has read level access to the single data instance through its mounted file system. In some embodiments, mounting a file system backed by the hypervisor level single data instance further comprises mapping a formatted disk image file comprising the single data instance into each virtual machine of the plurality, such that the formatted disk image file appears to be a file system volume to each virtual machine. In such embodiments, read level access requests on each virtual machine for data from the shared data instance are filtered and relayed to the hypervisor by the block device driver via a hypervisor/virtual machine communication channel. The requested data from the shared data instance is then returned from the hypervisor to the block device driver on the requesting virtual machine via this channel.

Virtual machines with read level access to the single data instance can be suspended at a hypervisor level. When this occurs, an image of the suspended virtual machine is stored at a hypervisor level, and a copy of the single data instance is saved as part of the stored image of the suspended virtual machine, such that a subsequent restoration of the suspended virtual machine from the stored image comprises the saved copy of the single data instance being present in the restored virtual machine. Later, a suspended virtual machine is restored from a stored image containing a saved copy of the single data instance, such that the saved copy of the single data instance is present in the restored virtual machine. The saved copy of the single data instance in the restored virtual machine is detected at a hypervisor level. The restored virtual machine is provided with read level access to the single data instance through its mounted filed system, and the saved copy of the single data instance in the restored virtual machine is deleted.

In some embodiments, a count of a number of virtual machines with read level access to the single data instance is maintained at a hypervisor level. In response to one of the virtual machines with read level access of the single data instance being suspended, the count of the number of virtual machines with read level access to the single data instance is decrementing. In response to one of the virtual machines with read level access of the single data instance being restored, the count of the number of virtual machines with read level access to the single data instance is incremented.

In some embodiments, one or more additional single data instance(s) can be stored at a hypervisor level, and shared access to these additional single data instances can be provided to other pluralities of virtual machines.

DETAILED DESCRIPTION

FIG. 1is a block diagram illustrating an exemplary network architecture100in which a single instance data sharing system101can be implemented. The illustrated network architecture100comprises multiple clients103A,103B and103N, as well as multiple servers105A and105N. InFIG. 1, the single instance data sharing system101is illustrated as residing on client103A. It is to be understood that this is an example only, and in various embodiments various functionalities of this system101can be instantiated on a client103, a server105or can be distributed between multiple clients103and/or servers105.

Clients103and servers105can be implemented using computer systems210such as the one illustrated inFIG. 2and described below. The clients103and servers105are communicatively coupled to a network107, for example via a network interface248or modem247as described below in conjunction withFIG. 2. Clients103are able to access applicants and/or data on servers105using, for example, a web browser or other client software (not shown).

AlthoughFIG. 1illustrates three clients and two servers as an example, in practice many more (or fewer) clients103and/or servers105can be deployed. In one embodiment, the network107is in the form of the Internet. Other networks107or network-based environments can be used in other embodiments.

FIG. 2is a block diagram of a computer system210suitable for implementing a single instance data sharing system101. Both clients103and servers105can be implemented in the form of such computer systems210. As illustrated, one component of the computer system210is a bus212. The bus212communicatively couples other components of the computer system210, such as at least one processor214, system memory217(e.g., random access memory (RAM), read-only memory (ROM), flash memory), an input/output (I/O) controller218, an audio output interface222communicatively coupled to an external audio device such as a speaker system220, a display adapter226communicatively coupled to an external video output device such as a display screen224, one or more interfaces such as serial ports230, Universal Serial Bus (USB) receptacles230, parallel ports (not illustrated), etc., a keyboard controller233communicatively coupled to a keyboard232, a storage interface234communicatively coupled to at least one hard disk244(or other form(s) of magnetic media), a floppy disk drive237configured to receive a floppy disk238, a host bus adapter (HBA) interface card235A configured to connect with a Fibre Channel (FC) network290, an HBA interface card235B configured to connect to a SCSI bus239, an optical disk drive240configured to receive an optical disk242, a mouse246(or other pointing device) coupled to the bus212e.g., via a USB receptacle228, a modem247coupled to bus212, e.g., via a serial port230, and a network interface248coupled, e.g., directly to bus212.

Other components (not illustrated) may be connected in a similar manner (e.g., document scanners, digital cameras, printers, etc.). Conversely, all of the components illustrated inFIG. 2need not be present. The components can be interconnected in different ways from that shown inFIG. 2.

The bus212allows data communication between the processor214and system memory217, which, as noted above may include ROM and/or flash memory as well as RAM. The RAM is typically the main memory into which the operating system and application programs are loaded. The ROM and/or flash memory can contain, among other code, the Basic Input-Output system (BIOS) which controls certain basic hardware operations. Application programs can be stored on a local computer readable medium (e.g., hard disk244, optical disk242) and loaded into system memory217and executed by the processor214. Application programs can also be loaded into system memory217from a remote location (i.e., a remotely located computer system210), for example via the network interface248or modem247. InFIG. 2, the single instance data sharing system101is illustrated as residing in system memory217. The workings of the single instance data sharing system101are explained in greater detail below in conjunction withFIG. 3.

The storage interface234is coupled to one or more hard disks244(and/or other standard storage media). The hard disk(s)244may be a part of computer system210, or may be physically separate and accessed through other interface systems.

The network interface248and or modem247can be directly or indirectly communicatively coupled to a network107such as the Internet. Such coupling can be wired or wireless.

FIG. 3illustrates the operation of a single instance data sharing system101residing in the system memory217of a client computer103, according to some embodiments. As described above, the functionalities of the single instance data sharing system101can reside on a client103, a server105, or be distributed between multiple computer systems210, including within a cloud-based computing environment in which the functionality of the single instance data sharing system101is provided as a service over a network107. It is to be understood that although the single instance data sharing system101is illustrated inFIG. 3as a single entity, the illustrated single instance data sharing system101represents a collection of functionalities, which can be instantiated as a single or multiple modules as desired (an instantiation of specific, multiple modules of the single instance data sharing system101is illustrated inFIG. 3). It is to be understood that the modules of the single instance data sharing system101can be instantiated (for example as object code or executable images) within the system memory217(e.g., RAM, ROM, flash memory) of any computer system210, such that when the processor214of the computer system210processes a module, the computer system210executes the associated functionality. As used herein, the terms “computer system,” “computer,” “client,” “client computer,” “server,” “server computer” and “computing device” mean one or more computers configured and/or programmed to execute the described functionality. Additionally, program code to implement the functionalities of the single instance data sharing system101can be stored on computer-readable storage media. Any form of tangible computer readable storage medium can be used in this context, such as magnetic or optical storage media. As used herein, the term “computer readable storage medium” does not mean an electrical signal separate from an underlying physical medium.

As illustrated inFIG. 3, a single instance data sharing system101runs mostly at hypervisor305level with certain components running on the virtual machine303side. The single instance data sharing system101provides hypervisor305directed shared access of a single instance of data301to multiple virtual machines303. As illustrated, multiple virtual machines303and a hypervisor305run in the computer memory217of a host210, which can be in the form of a physical computer210, for example of the type illustrated inFIG. 2. InFIG. 3, only three virtual machines303are shown for illustrative purposes, but in practice many more can be deployed. With the shared access, each virtual machine303has what appears to be a unique view of the single data instance301, without requiring each virtual machine303to have its own copy thereof. For example, suppose the data instance301is in the form of 100 MB of shared virus definitions and there are fifteen virtual machines303sharing the data instance301. In the scenario, only 100 MB of storage in the hypervisor305would be used for the shared data instance301, as opposed to 100 MB in each virtual machine303for a total of 1.5 GB, as would required in a conventional system.

A storing module307of the single instance data sharing system101running at a hypervisor305level stores the single instance of data301to be shared by the virtual machines303. A providing module313of the single instance data sharing system101prepares the data instance301on the hypervisor305side (in physical or logical form) such that it can be provided to the virtual machines303that will have shared access thereto. More specifically, the data instance301is provided in the form of a file system309in each virtual machine303sharing the data instance301. Each virtual machine303accessing the shared instance of data301runs a file system driver311which serves the file system309backed by the data instance301into the virtual machine303environment. These file system drivers311can be thought of as virtual machine303side file system309driving modules of the single instance data sharing system101. The file system drivers311can be installed on the virtual machines303, or injected thereon by the hypervisor305side providing module313. The file system drivers311running on the virtual machines303can be instantiated in various forms, such as an actual file system, a block device (on top of which a file system is loaded), or a mini-filter which redirects certain virtual machine303side input/output requests to the single instance data sharing system101on the hypervisor305.

In one embodiment, a file system driver311is implemented as a block device driver, which emulates a device that consists of a series of readable blocks which comprise the shared data instance301. In this embodiment, the shared data instance301can be implemented on the hypervisor305side as a formatted disk image file which is internally treated as a series of blocks which (when mapped into a virtual machine303) appears to be a file system309volume. Read level access requests (e.g., read, open, etc.) on a virtual machine303for data from the shared data instance301are relayed by the file system driver311(e.g., the block device driver in this embodiment) to the providing module313on hypervisor305via a hypervisor/virtual machine communication channel. In response to these requests, the providing module313returns the requested shared data301to the file system driver311on the requesting virtual machine303via this channel.

While the above-described embodiment uses a block device driver on the virtual machines303and a formatted disk image file on the hypervisor305to share the data instance301, it is to be understood that this is simply an example of a specific instantiation of this functionality. Although this specific implementation example is used to describe the functionality of sharing a hypervisor305side data instance301among multiple virtual machines303in conjunction withFIG. 3, it is to be understood that what specific implementation details to use to instantiate this functionality is a design choice. More specifically, this functionality can be implemented in the form of any valid file system309usable by the virtual machines303, or any file system309filtering method which allows the intercepting of file enumeration/open/read operations on the virtual machines303.

It is also to be understood that each virtual machine303can mount and manage multiple shared data instances301. The example illustrated inFIG. 3describes the mounting and managing of a single shared data instance301by three virtual machines303. The same protocol can be repeated for each additional data instance301being shared by any number of virtual machines303.

It is the hypervisor305side single instance data sharing system101that determines which virtual machines303are to have access to any given shared data instance301. The hypervisor305side providing module313of the single instance data sharing system101notifies each of these virtual machines303to mount the file system309. In response, the file system driver311on each notified virtual machine303introduces a new device instance into the virtual machine's operating system. The virtual machine's operating system sniffs the block device (or other device instantiation) and automatically loads the correct file system driver311, thus creating a new volume (or other file system image) in the virtual machine303backed by the shared data instance301on the hypervisor305. This occurs in each virtual machine303notified to mount the file system309, at which point each such virtual machine303is sharing a read-only view of the same backing data instance301.

A hypervisor305side counting module317of the single instance data sharing system101maintains a count319of the number of active virtual machines303with access to a particular data instance301. When a new virtual machine303mounts the corresponding file system309as described above, the counting module317increments this usage count319. When a virtual machine dismounts the file system309or shuts down, the counting module317decrements the usage count319. When there are no remaining virtual machines with access to a given data instance301(i.e., the count319equals zero), a hypervisor305side cleanup module315of the single instance data sharing system101can delete the now unneeded backing data instance301(either immediately or as part of a subsequent cleanup cycle).

Turning now toFIG. 4, complexity is introduced by two virtualization features, the ability to arbitrarily suspend a virtual machine303, and the ability to migrate a running virtual machine303to another host. Since these operations are not supported by the operating system but are instead controlled by the hypervisor305, it is critical that when a suspended virtual machine303is restored, it is returned to the exact state from which it was suspended. Where a single data instance301is shared between multiple virtual machines303as described herein, the operating system of a specific virtual machine303may, at the time of suspension, have open and in-use file handles to data in the shared instance301. Where this is the case, the shared data instance301must be guaranteed to still be available and consistent to the suspended virtual machine301when it is restored. A virtual machine303can remain suspended indefinitely (for seconds, minutes, hours, days, months, years, or possibly forever), and yet the single instance data sharing system101must still immediately provide a consistent data instance301from the time of suspension to a restored virtual machine303. The migration of a running virtual machine303from one hypervisor305to another presents similar issues, and can be conceived of as a suspend on one host immediately followed by a resume on another.

To address these issues, when a virtual machine303with access to a shared data instances301is suspended, a data saving module401of the of the single instance data sharing system101saves a copy of the shared data instance301in the OVF image403(or image in another format where applicable) describing the suspended virtual machine303. In some embodiments, the saved copy of the data instance301is in the form of a link to the data (e.g., a file system hard link) as opposed to a copy of the data itself (under hypervisors305that support this feature), so as not increase the storage requirements. When a virtual machine303is suspended, the counting module317decrements the usage count319of virtual machines303sharing the data instance301, just as if the suspended virtual machine303dismounted the data instance301or shut down.

If a suspended virtual machine303is later restored, because the stored image403includes the copy of the data instance301, so too does the restored virtual machine303which is built from the stored image403. Because this copy of the data instance301is in the exact state of the data instance301at the time the virtual machine303was suspended, the restored virtual machine303has access to a consistent data instance301as required.

A detecting module405of the single instance data sharing system101detects the copy of data store301in the restored virtual machine303, and takes ownership thereof, by providing the virtual machine303with access to the data instance301as a file system309as described above. Once the virtual machine303is accessing the data instance301via the above-described functionality provided by the single instance data sharing system101, the cleanup module315deletes the virtual machine's copy of the data instance301, the counting module317increments the usage count319, and the single instance data sharing system101manages the virtual machine's access of the data instance301as if it had done so the entire time. Because migrating a virtual machine303is functionally equivalent to a suspend and a restore, this functionality works for migrated virtual machines303as well.

The above-described functionality of the single instance data sharing system101guarantees that virtual machines303have self consistent access to a shared single data instance301, and can be safely resumed after suspension at any time. The counting and cleaning up functionality further ensures that data is not orphaned if a suspended virtual machine303is never restored.

FIG. 5illustrates steps of the operation of the single instance data sharing system101(FIG. 1), according to some embodiments. A storing module307(FIG. 3) stores501the single data instance (FIG. 3) to be shared by a plurality of virtual machines303(FIG. 3) at a hypervisor305(FIG. 3) level. A providing module313(FIG. 3) provides503a file system driver311(FIG. 3) from a hypervisor305(FIG. 3) level to each virtual machine303(FIG. 3) that is to share the single data instance301(FIG. 3). Each virtual machine303(FIG. 3) that is to share the single data instance301(FIG. 3) mounts505a file system309(FIG. 3) backed by the hypervisor305(FIG. 3) level single data instance301(FIG. 3), such that each virtual machine303(FIG. 3) has read level access to the single data instance301(FIG. 3) through its mounted file system309(FIG. 3). A counting module317(FIG. 3) maintains507a count319(FIG. 3) of the number of virtual machines303(FIG. 3) with read level access to the single data instance301(FIG. 3).

A virtual machine303(FIG. 3) with read level access to the single data instance301(FIG. 3) is suspended509at a hypervisor305(FIG. 3) level. A saving module401(FIG. 4) saves511a copy of the single data instance301(FIG. 3) in an image403(FIG. 3) of the suspended virtual machine303(FIG. 3) which is stored at a hypervisor305(FIG. 3) level. In response to the virtual machine303(FIG. 3) with read level access of the single data instance301(FIG. 3) being suspended, the counting module317(FIG. 3) decrements513the count319(FIG. 3) of the number of virtual machines303(FIG. 3). Subsequently, the suspended virtual machine303(FIG. 3) is restored515from the stored image403(FIG. 4) containing the saved copy of the single data instance301(FIG. 3), such that the saved copy of the single data instance301(FIG. 3) is present in the restored virtual machine303(FIG. 3). A detecting module405(FIG. 4) detects517the saved copy of the single data instance301(FIG. 3) in the restored virtual machine303(FIG. 3). The providing module313(FIG. 3) provides519the restored virtual machine303(FIG. 3) with read level access to the single data instance301(FIG. 3) through its mounted filed system309(FIG. 3). The cleanup module315(FIG. 3) deletes521the saved copy of the single data instance301(FIG. 3) in the restored virtual machine303(FIG. 3). In response to the virtual machine303(FIG. 3) with read level access of the single data instance301(FIG. 3) being restored, the counting module317(FIG. 3) increments523the count319(FIG. 3).

As will be understood by those familiar with the art, the invention may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. Likewise, the particular naming and division of the portions, modules, agents, managers, components, functions, procedures, actions, layers, features, attributes, methodologies, data structures and other aspects are not mandatory or significant, and the mechanisms that implement the invention or its features may have different names, divisions and/or formats. The foregoing description, for purpose of explanation, has been described with reference to specific embodiments. However, the illustrative discussions above are not intended to be exhaustive or limiting to the precise forms disclosed. Many modifications and variations are possible in view of the above teachings. The embodiments were chosen and described in order to best explain relevant principles and their practical applications, to thereby enable others skilled in the art to best utilize various embodiments with or without various modifications as may be suited to the particular use contemplated.