[INFO] How a vCloud Director Export Actually Works

The question of “How does a vCloud Director Export Actually work?” came up yesterday from a fellow VCDX, Mark Achtemichuk.  I was pretty sure I had the right answer based on the work I did around the vCloud clone/copy process a couple of months back.  However, I did inquire with an engineering contact who not only verified my assumptions, but also provided a little more depth to the process.  I wanted to share this with you all since it can affect how you address your designs in a similar way the clone wars series did.  Below is the step by step process that happens when you initiate a vCloud Export.  What you will see is it does align with my findings previously but it also has a few other points of interest.

1. vCloud Director invokes an OVF export in vCenter Server
2. vCenter Server returns a lease which contains a bunch of http urls (basically disks, ovf descriptor, etc..) + an authorization token. The URLs point to the ESX host (it’s really opaque to vCloud Director). There could be multiple ESX hosts that are available (based on connection to the datastore). It is unknown to me what strategy is used to choose one of these ESX urls.  My guess is it will be the one that has the virtual machine registered to it.
3. vCloud Director downloads these files to its transfer directory, and a lease is associated with these files. The download happens through http as a transport protocol, and session management is done through NFC, VMware’s network file copy protocol).
4. vCloud Director exposes a http download link that the user can use to download the files, this is http served by Jetty web endpoint.
5. When the transfer lease expires, vCloud Director deletes the files from the transfer directory.

The key to this, and what I thought was true, is that vCloud Director export is always a two-step process, from ESXi host directly to the cell and then from the cell to the end user.  This is the case regardless if the export is invoked through the UI, API, PowerCLI, or vCenter Orchestrator.  The reason this came up is that the customer noticed that an export in vCenter was happening almost twice as fast, and that is in fact correct!  That process does not move the data to any “Transfer” space it is moved directly from Host to the end-user through the vCenter Client.  Therefore, vCloud Director exports will take longer, but there are places you can check to see if there is a way to increase the copy.

My original design considerations around interfaces and traffic flows should absolutely be considered since you are moving data from a host, to a shared folder, then out to a user or to another vCenter in the case of a copy between vDCs.  Understanding the underlying nuts and bolts about how operations are performed by both vCloud Director and vSphere is extremely important to not only design but troubleshooting possible bottlenecks.

It is worth noting that this is the process used by vCloud Connector on the initial Export as well only instead of the CLIENT as the endpoint the vCloud Connector Node becomes the end point for the second step.  Then this process is also repeated for an import back into another vCloud Director location.  The files are moved back into that cloud’s transfer directory, then into the catalog location, and finally into the cloud itself.