Instant xvmotion using a private storage virtual appliance

#Benefit is claimed under 35 U.S.C. 119(a)-(d) to Foreign application Serial No. 1192/CHE/2014 filed in India entitled “INSTANT XVMOTION USING A PRIVATE STORAGE VIRTUAL APPLIANCE”, filed on Mar. 8, 2014, by VMware, Inc., which is herein incorporated in its entirety by reference for all purposes.

#“xvMotion” (also known as “Enhanced vMotion”) is a technology that allows both the execution state and the virtual disk files (VMDKs) of a virtual machine (VM) to be migrated across host systems/data stores as a single operation. This enables VM migration in environments where the host systems do not have access to shared storage (and thus rely on host-based local storage). By way of example, FIG. 1A depicts a system environment 100 that includes two host systems 102 and 104 and a virtual infrastructure (VI) server 106. Each host system 102/104 includes, in turn, a hypervisor 108/110 and a local storage component 112/114. In the example of FIG. 1A, host system 102 runs a VM 116 on hypervisor 108 that is configured to access a VMDK 118 residing on local storage component 112.

#Assume VI server 106 determines that VM 116 should be migrated from host system 102 to host system 104. In this scenario, VI server 106 can use xvMotion (as shown in FIG. 1B) to transfer both the execution state of VM 116 and its persistent data (i.e., VMDK 118) across the host systems. For instance, at step (1) of FIG. 1B (reference numeral 120), VI server 106 can cause host system 102 to background copy VMDK 118 (in the form of storage snapshots) to local storage component 114 of host system 104. Once VMDK 118 has been transferred, VI server 106 can cause host system 102 to copy the execution state (e.g., volatile memory contents) of VM 116 to host system 104 (step (2); reference numeral 122). Finally, at steps (3) and (4) (reference numerals 124 and 126), VI server 106 can halt the execution of VM 116 on host system 102 and restart VM 116 on host system 104, thereby completing the migration process.

#FIG. 1A depicts a system environment that supports xvMotion.

#FIG. 1B depicts an xvMotion workflow.

#FIG. 2A depicts a system environment that supports instant xvMotion using a hypervisor-based client/server model according to an embodiment.

#In the following description, for purposes of explanation, numerous examples and details are set forth in order to provide an understanding of various embodiments. It will be evident, however, to one skilled in the art that certain embodiments can be practiced without some of these details, or can be practiced with modifications or equivalents thereof.

#1. Overview

#The present disclosure describes an enhanced version of xvMotion (referred to herein as “instant xvMotion”) that allows VMs to be migrated across host systems that do not have access to shared storage, without transferring the VMDKs of the VMs as part of the migration process. For instance, with respect to FIG. 1B, instant xvMotion can be used to migrate VM 116 from source host system 102 to destination host system 104, while eliminating the VMDK copy operation at step (1) (reference numeral 120). At a high level, this is achieved by enabling remote file access between host systems 102 and 104—in other words, establishing a connection between the systems that allows host system 104 to remotely access VMDK 118 residing on local storage component 112 of host system 102. With this remote access connection in place, when VM 116 is restarted on host system 104, host system 104 can fulfill VM I/O requests directed to VMDK 118 by interacting with host system 102 over the connection (rather than processing the I/O requests locally). In this way, host system 104 can avoid the need to maintain a copy of VMDK 118 on local storage component 114.