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.