The vCloud Director user interface allows importing vSphere virtual machines as a vApp to an organization Virtual Data Center. Once imported configuration changes are required to have these VMs operating such as connecting them to the appropriate networks. This process involves several steps for each VM. In the private cloud context importing a large number of VMs in a short time is not possible without providing some automation.
The following workflows implementation allows processing a large number of imports and configuration with:
- Selecting a vCenter resource pool or resource pool containing virtual machines
- Creating vCloud Director external networks and Organization Virtual Data Center networks required for the VMs it contains
- Importing each VM as a vApp, configure the VM network cards with a network directly connected to the created Organization VDC network. Power on the vApp
The import package is leveraging the following components:
- vSphere Server & vCloud Director 5.1 installed and configured
- vCenter Orchestrator 5.1 server & client installed and configured
- vCloud Director plug-in 5.1 for vCenter Orchestrator installed and configured
- vSphere 5.1 Server (Optional – User interface)
vCloud Director must be configured as follows:
- The vCenter managing the VMs to be imported must be attached (and be attached only to the vCloud Host in which the VMs will be imported).
- A Provider VDC must be created in the same vCenter to insure VMs can be reconnected to their original networks. This provider VDC should be linked to a resource pool from the same cluster as the one where the VMs are hosted to avoid cluster-to-cluster migrations and insure networks consistency. It should also preferably use a storage profile containing the datastores used by the VMs to avoid datastore to datastore migrations.
- An organization and its organization VDC partitioned from the created provider VDC
The organization VDC may have Organization VDC networks of type “Direct” connected to external networks using the same vCenter networks and Distributed Virtual Portgroups as the one connected to the VMs.
Since these workflows can potentially be used on a very large number of Virtual machines it is recommended to perform import tests on small number of test VMs to:
- Insure the import process is successful
- Tune the parameters
For example moving the VMs may improve the process time dramatically if the VMs do not require to be migrated but will mitigate recoverability. The optimum number for the concurrent imports will change depending on the vSphere infrastructure.
The implementation of the workflows is documented in the vCAT 3.0 Workflow Examples Document.
Disclaimer: These samples workflows are provided AS IS and are not considered production quality and are not officially Supported. Use at your own risk. Feel free to modify and expand and share your contributions.