[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.

5 comments

  1. So as an ISV we don’t allow our customers to do this. But if internal access was setup for our own users in vCloud director they could actually do all this themselves.  Of course I don’t think anyone would seriously download an 800GB VM or much less a 5GB one honestly.  I am just thinking in the context of internal support staff and so on how this could be potentially more beneficial.  Then of course why would one do that if they are internal if they could just do it within vCenter? Perhaps it could just be a more secure way?  I have yet to use vCloud Connected so that is something I am going to have look at playing with here soon. ALso the network file copy, is that done over the Management interface?  Thanks again for a great post.

    • Yes the file copy will most likely happen over the ESXi management interface, and depending on the Cell setup it will most likely use the HTTP interface.  That is unless you have designed the cell with multiple interfaces to contend with this per the Clone Wars recommendations.  As far as doing things in vSphere vs vCD…..I think you know my stance on that.   Although the first step is an OVF export, you are ONLY getting the VM is you use vCenter where in vCD you are getting additional vApp data potentially.

      • Thanks, Chris for the reply!  I can see the indications of why DESIGN is clearly important and in some way critical to what the requirements are. Do you think in impelementations of 10GB FCoE (Cisco UCS) that seperating that traffic or what not may not be as important because of the amount of bandwidrh you have? Then again QOS or something like that may be important, as I think you emphasized, as well. Sorry just thinking out loud. I am ofcourse reviewing some designs and things like that. 🙂

        • Just remember the data transfer between ESX and Cell going to be network copy, so I am not sure if FCoE will really help on that layer of the data transfer.  That would exist between host and storage.  Most likely Cell to Transfer is NFS though so there is multiple layers of consideration knowing how the data is being moved.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

Scroll To Top
%d bloggers like this: