****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 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. |