5. Creating and Managing vApps : 5.4 vApp Deployment Readiness : 5.4.7 Relocate Existing vApps
5.4.7 Relocate Existing vApps
You can choose between two primary methods for migrating a vApp between datastores within an organization virtual datacenter:
*vCloud Director-initiated vApp relocate.
*VMware vSphere Storage vMotion®.
Choose the method that best fits your case after considering storage efficiency and provisioning time. Prerequisites
The following are prerequisites for moving a vApp between virtual datacenters:
*The target datastore and vApp must exist within the same organization virtual datacenter.
*All virtual disks for an individual virtual machine must reside within a single datastore.
NoteCapacity requirements to store a virtual machine might be affected by storage configuration policies, and this might impact fast provisioning. Use Cases
There are several potential use cases for the migration of vApps between organization virtual datacenters:
*Planned maintenance of underlying storage.
*Rebalancing storage utilization for capacity or performance management.
*Upgrading or replacing a back end storage system. Storage vMotion Procedure
Storage vMotion can be performed from the vSphere Client or through scripts that leverage vCenter procedures to complete the task. The following is a procedure for the migration process as performed from the vSphere Client.
To migrate a vApp
1. Log in to the vCloud Director portal as a System Administrator.
2. Find the organization that contains the vApp.
3. Open the organization.
4. Find and open the vApp.
5. Click the Virtual Machines tab.
6. Right-click the virtual machine to display the vApp VM Menu.
7. Select Properties.
8. Note the value of the Name in vSphere property of the virtual machine. Use this value to find the virtual machine in vSphere. The UUID portion is unique, but names might be duplicated within an environment.
NoteIf this section is not visible, the logged-in user does not have vCloud Director System Administrator privileges.
9. Using the vSphere Client, connect to the vCenter server that manages the host specified in the virtual machine properties.
10. Type the UUID of the target virtual machine in the inventory search panel.
11. Locate the virtual machine in the results list.
12. Select the virtual machine.
13. Click Inventory > Virtual Machine.
14. Select Migrate.
15. If running vSphere 5 or later, read the Warning dialog. Click Yes to continue.
16. Select the Change datastore option.
17. Click Next to continue.
18. Do not modify the currently assigned default resource pool selection.
CautionNever use the vSphere Client to modify the virtual machine resource pool. If using a vSphere version earlier than vSphere 5, you must manually select the correct resource pool. The selected resource pool must match the current resource pool that contains the virtual machine.
NoteConfigurations that have a single virtual machine using multiple virtual disks distributed over more than one datastore are not supported. All virtual disks supporting any virtual machine must be contained within a single datastore.
19. Select the target datastore from the list, and click Next to continue.
Before proceeding, confirm that the target datastore is a member of the virtual datacenter that contains the vApp within vCloud Director.
20. Click Finish to start the Storage vMotion process.
21. Continue to monitor event status for progress. After the storage migration is complete, the new datastore name is displayed in the virtual machine properties. Risks
Configuration changes at the vSphere layer do not propagate to vCloud Director. The following risks are associated with migrating vApps and virtual machines at the vSphere layer without vCloud Director involvement.
*If the virtual machine is migrated to datastores that are not assigned to the appropriate virtual datacenter management, anomalies might occur.
*If the resource pool assignment of the virtual machine is changed in the vSphere Client, abnormal behavior might result.
Changes made in vCloud Director are stored in the database. To mitigate the risks, use Representational State Transfer (REST) APIs with integrated fail-safes. Impact
The virtual machine is relocated as requested between datastores. Any services provided by the virtual machine are unavailable while it is stopped or suspended during the relocate event. The relocate process is performed as a clone operation. To minimize risk, it is followed by a delete operation.