4.5 Migrate (fully-stopped) VMs from one cloud-provider to another

****WORKING DOCUMENT****

4.5      Migrate (fully-stopped) VMs from one cloud-provider to another

Actors:  cloud-subscriber, cloud-provider-1, cloud-provider-2, cloud-management-broker

Goals:  Seamlessly migrate an arbitrarily designated stopped virtual machine from cloud-provider-1 to cloud-provider-2.

Assumptions: Includes the Use cases "Open An Account", "VM Control: Manage Virtual Machine Instance State", "VM Control: Allocate VM Instance".Both cloud-providers are using para-virtualized devices, or are using identical hardware.

Success Scenario (migrate instance, IaaS):  The cloud-subscriber issues commands to halt the source VM instance on cloud-provider-1.

Cloud-provider-1 generates a configuration file for the halted VM.  The configuration file includes an abstract description of the virtual hardware provided by cloud-provider-1 as well as a description of the storage devices needed for the VM to operate.  Candidate fields for the configuration file include:

The number of virtual CPUs
The amount of memory used/assumed by the VM
The unique hostname and IP address
The Domain Name System resolver configuration used by the VM
The list of virtual network interfaces used/assumed by the VM
The subnet mask and identifier for each subnet attached to the VM
The MAC address assigned to the VM
The list of virtual block devices the VM assumes
The list of attached storage devices (local or network-accessed file systems)

The configuration file may take advantage of the OVF format or the Mirage Image Format, or others.

The cloud-subscriber submits the configuration file to cloud-provider-2 and requests a translation into cloud-provider-2's environment.

Cloud-provider-2 returns a list of the fields in the configuration file that have reliable translations in cloud-provider-2's environment.

The cloud-subscriber identifies any missing translations in the configuration file.  If the cloud-subscriber cannot supply missing translations, the migration is cancelled.

Otherwise, the cloud-subscriber substitutes cloud-provider-2's translations in the configuration file, and, if the VM's root storage device is persistent, copies the data object representing the VM's root storage device to cloud-provider-2 (See Use Case "Copy Data Objects Between Clouds").

If non-root storage devices are network accessible from outside of cloud-provider-1's infrastructure, the cloud-subscriber may choose to leave the data at cloud-provider-1 and access them remotely; however access latencies may limit the availability of this approach.

If non-root storage devices are not network accessible, or if the cloud-subscriber determines that the performance of remote access storage devices would not be sufficient, the cloud-subscriber copies the data objects containing the attached devices from cloud-provider-1 to cloud-provider-2.  (Note that this can be a large operation and the cloud-subscriber may choose to reconfigure the VM to avoid some of the copying.)

The cloud-subscriber issues VM management commands for cloud-subscriber-2 to initialize a new VM in cloud-subscriber-2 that is based on the information transferred from cloud-provider-1 (See Use case "VM Control: Allocate VM Instances").

The new VM can now be managed at cloud-provider-1 (See Use case "VM Control: Manage Virtual Machine Instance State").

Failure Conditions (migrate instance): Necessary translations in the VM's configuration file are missing for cloud-provider-2.

Failure Handling (migrate instance): There is no recovery except to choose a different cloud-provider as cloud-provider-2.

Credit: Success Scenario 2: Amazon AMI images.  "Open Virtualization Format Specification" the DMTF.;  "Opening Black Boxes: Using Semantic Information to Combat Virtual Machine Image Sprawl", D. Reimer et al, VEE '08 March 5-7, 2008, Seattle, Washington.