vCloud Connector 2.5 Gotchas

I was recently working with vCloud Connector (vCC) 2.5 and ran into a couple of issues.  I have a support request open with VMware for both issues and engineering is looking into the issue.  If I receive a resolution, I’ll update this post.

Issue 1 – Can’t copy vApps if ESXi hosts do not have any standard switches

If your ESXi hosts only have distributed switches, copying vApps from vCloud to vCenter will fail with the error that the host did not have any virtual network defined.


As soon as you add standard switches to the hosts, the transfers work fine.  I believe the standard switches also need to have a virtual machine portgroup defined, but can’t remember if I tested this.  The switches do not have to have any uplinks or otherwise be modified.

You can also see the error on the vCloud connector node’s log file /opt/vmware/hcagent/logs/hca.log

Issue 2 – Can’t copy vApps if vCloud has the “Capture vApp Template” blocking task enabled

Having the following checked blocking task selected will cause vApp transfers to fail.


vCC will show the error “OVF export failed.  The requested operation on vApp Template “NoOS1382920933138” is not supported in its current state.


If you look at the catalog where you told vCC to store the vApp, you will see the vApp.


If the blocking task has been approved, you will still see the vApp in the catalog as the vCC operation has since failed and doesn’t perform any clean up.


In my environment the blocking task is handled by vCO, which simply updates a database, and happens very quickly.  It seems that if the vApp goes into a “pending processing” state, vCC doesn’t know how to handle it and fails.

Integrating vCloud with vCenter Orchestrator using blocking tasks – Part 1

This is the first post in a series that will show you how to integrate vCloud with vCenter Orchestrator (vCO) using blocking tasks.  Following entries in the series will show how to configure RabbitMQ, vCloud blocking tasks and vCO workflows.  The last entry in the series will show you how to resolve issues with vCloud created vCenter portgroups and etherchannel, which was a real issue in my environment.  As you may know, if you’re using etherchannel, vCenter portgroups must have a load balancing policy of “Route based on IP hash”, all uplinks connected to the etherchannel must be active and the remaining uplinks must be set to unused.  vCenter portgroups created by vCloud only have one uplink as active, which will cause intermittent issues with etherchannel.  While vCloud doesn’t modify the load balancing policy and you can modify the default vDS settings (using PowerCLI for example), we will check to make sure “Route based on IP hash” is selected.

The versions I’ll be using are 5.1 as there isn’t a 5.5 vCO plug-in for vCloud yet.

See NIC teaming using EtherChannel leads to intermittent network connectivity in ESXi for more info on etherchannel and vCenter portgroup configuration.


vCO Appliance –

AMQP plug-in –

vCloud plug-in –

Deploy the vCO Appliance

Using a vSphere client, deploy the vCO OVF into vSphere environment and give it the required info network info.  The vCO appliance will need to communicate with vCenter, vCloud, AMQP, etc.

Access vCO through the web browser.  Mine is at http://vco5.vmware.local

Select “Orchestrator Configuration”

Default credentials: vmware/vmware

Pick a new password and you will see the following screen.


Configure the vCenter plug-in

Select Plug-ins and check vCenter 5.1 then Apply changes.


Select Startup Options and Restart the vCO Server.


Re-login and select Plug-ins again.  Now the vCenter Server plug-in should be OK.


Before we can configure the vCenter server we must import its SSL certificate.  Select Network > SSL Trust Manager > Enter the URL or File to import the certificate from and select Import.  I point mine directly to the vCenter server.

You will then be presented with the certificate where you can import or decline it.


Once you import the certificate, it will be listed.


Select vCenter Server > New vCenter Server Host > Enter your vCenter details and select Apply Changes.


Install AMQP Plugin

Select Plug-ins > Install new plug-in > browse to the downloaded AMQP plug-in (o11nplugin-amqp-1.0.0-157.vmoapp) > Upload and install > Agree to the EULA.


Select Startup Options and Restart the vCO Server.


Install vCloud Director plug-in

Select Plug-ins > Install new plug-in > browse to the downloaded vCloud plug-in (o11nplugin-vcloud-5.1-538.vmoapp) > Upload and install > Agree to the EULA.


As with the vCenter server, we must import the vCloud server’s SSL cert.  Select Network > SSL Trust Manager > Import from URL > Enter vCloud host > Import > Import.


Select vCloud Director plug-in > New vCloud Director Connection.  admin user is a vCloud system administrator.


From the vCO getting started page, select Start Orchestrator client (you can download and install it as well).

The default credentials are vcoadmin / vcoadmin


Once you are in the client, you can select the Inventory tab and verify that your vCenter and vCloud plug-ins are configured successfully.  These views can provide a lot of good information on their own.  I often use them to quickly find info that I would need to find via the vCenter MOB or some other method.  It’s also nice to view how things are arranged hierarchically, which can give you insights to how things are structured that may not be apparent through the vCenter/vCloud UI.


Modifying vCloud VMs that are located on disabled datastores

I’m not sure if this is has always been this way, but in vCloud 5.1.2, if you modify a VM that’s on a datastore that has been disabled in vCloud, vCloud will will request that vCenter relocate VM to a non-disabled datastore.

I have several datastores that are disabled due to usage and this affected me when user wanted to modify the RAM on a VM.  I shut down the VM, changed the RAM and then noticed the update was taking a long time.  I jumped into vCenter to see the VM being migrated to a new datastore, and since this enviroment’s storage is very slow, the VM ended up being down for 30 minutes. 

One workaround would be to quickly re-enable the datastore, make the change and disable the datastore again.  Of course, someone could come along and provision to the datastore while you’re making the change. 

It’s not something that should be done too often, but you could also make the memory change directly in vCenter and vCloud will pick up the change. 

My change was done in a test environment so it wasn’t a big deal, but it’s useful to know in case the work is being done in a production environment where you probably have a change window that could be missed due to how long it takes to migrate the VM.