4.3.4.1 vCloud Connector ODT Customer Steps
To make the ODT process as smooth as possible, VMware recommends choosing and testing one or more Network Attached Storage (NAS) devices that support NFS. In this way, you can prepare the device so that it supports only the NFS mount at the customer data center with very specific instructions on how to mount and copy data. From the customer premises vCloud Connector Node run the following command:
mount -t nfs NFSDeviceIP:/nfs/ODT /data/ODT -o nolock
As shown in Figure 15, the available VMs, vApps and templates from the associated vCenter Server (more on configuring that in the following section) are displayed. After the Offline Data Transfer is initiated, the data is written to the mounted share. The data that is written to the file system is encrypted for security and the encryption key along with other credentials are stored (also encrypted) in the service provider vCloud Connector instance. The following snapshots illustrate this process.
Figure 17. NFS Mount Path Relative to vCloud Connector Node
This NFS mount information does not impact the service provider mount or import process and can be decided by the customer. It is important that the NFS share be exported with read and write permission for EVERYONE.
Figure 18. VMware Cloud Provider vCloud Director Tenant Org URL and Credentials
The credential must be an Organization Admin. This information is encrypted before being stored. The ODT Node URL comes from the VMware Cloud Provider.
Figure 19. VMware Cloud Provider vCloud Director VDC and Catalog
Caution Do not use the Public Catalog. Use the customer-specific Organization Catalog instead. If you use the Public Catalog all tenants will be able to download a copy of your VMs.
Figure 20. VMware Cloud Provider vCloud Director Network Pairing and Power State
Note Any vApps that are exported without the Deploy check box selected are imported as multiple separate vApp templates, one for each VM that was part of the vApp. They are named SourcevAppName_RandomSequence_1, SourcevAppName_RandomSequence_2, and so on. ODT by design appends random numbers to the vApps and vApp templates names to avoid naming conflicts during the import process.
To avoid possible undesired situations on guest operating systems with non-present networks, the recommendation is to perform the following steps:
1. Before starting the export, create a copy (clone) of the VMs.
2. Disable and remove the vNICs from the cloned VMs guests and from vSphere.
3. Perform the export.
4. Re-create the networking to consume what is provided by vCloud Director.
Alternatively, creating a default vSphere port group such as “VM Network” on the target ESXi hosts in the target provider SDDC allows for a clean match.
If you choose to keep the template in the catalog by selecting the Keep Catalog check box, you are prompted with a warning that the template will consume disk space in the catalog. You can click Next to continue.
Figure 21. Keep Catalog Warning
Figure 22. Confirmation of Details
Figure 23. Export Progress
Figure 24. Export Completion
Figure 25. Export Verification on vCloud Connector Node NFS Mount
