In conjunction with vCloud Connector, a hybrid vCloud enables vApps to move between public and private vCloud services. Prior to vCloud Director 5.1, some configurable vApp elements are not transported with the migration process. Keep track of what is and is not transported as you might need to reconfigure the vApp after the migration so that it functions properly. You can view the configuration parameters from two perspectives—from the point of view of the vApp itself or of the virtual machines contained within the vApp. With vCloud Director 5.1, lossless OVF export is provided to enable greater portability between vCloud environments.

The migration process can be carried out manually with the upload and download capabilities of the vCloud Director user interface or by programming the vCloud API. vCloud Connector simplifies vApp migrations, but is not required.

When a vApp is migrated, the vApp itself defines the virtual machine start and stop settings within the vApp. The parameters encapsulated within the vApp are:

All of these parameters are transferred with the vApp from one vCloud to another. The configuration in vCloud A remains consistent in vCloud B.

Configuration parameters are associated with virtual machines in the migrated vApp, including network segments (vApp networks) that are private to the vApp itself in the source vCloud. Some of these configuration items are maintained during a migration, while others require reconfiguration by the vApp user after migration.

vApp networks are not maintained across a vCloud migration—vApp networks that are defined in a vApp in vCloud A are not created and mapped to the virtual machines within the vApp in vCloud B. Assuming that vCloud A and vCloud B use the same network topology, after moving the application to vCloud B, the end user must complete the configuration process by recreating the vApp networks as they were defined in vCloud A.

Hard disk configuration and disk bus type are maintained across a vCloud migration. If a specific disk bus type is selected for a virtual machine’s disk, this setting is maintained when the virtual machine migrates from vCloud A to vCloud B.

Prior to vCloud Director 5.1, network interface assignments, configuration types, and network adapter types are not maintained across a vCloud migration. When the vApp is transferred, the virtual machine network interfaces revert to the default adapter type, flexible. With vCloud Director 5.1, the lossless OVF export capability preserves these settings.

IP addresses are not held across a vApp migration and must be reconfigured to the new vCloud IP addressing scheme. The end user must reconfigure all virtual machine network adapter settings for a migrated vApp.

Even if Enable Guest Customization is not selected in vCloud A, it is enabled in vCloud B when the vApp is migrated, regardless of whether the virtual machine has an installed operating system and VMware Tools™.

Most password reset parameters are maintained. When the password reset parameters are configured for the virtual machine, the settings are transferred from vCloud A to vCloud B. However, if the virtual machine configuration specifies a default local administrator password, this information is not transferred to vCloud B. The end user must re-enter the default password for the virtual machine.

Resource allocation controls set on the individual virtual machines in a vApp are maintained across a migration from vCloud A to vCloud B. However, for the settings to be used, the vApp must be deployed to a virtual datacenter that uses a Reservation Pool allocation model. Datacenters that use the Allocation Pool or Pay As You Go model do not support resource allocation controls.

The following table summarizes vApp parameters and indicates whether they are maintained across a migration.