virtual grind thoughts from the virtual world


vCloud Director Does Not Show Storage Policies

I have been experiencing this a lot lately with vCloud Director versions 5.x. What happens is that you will add tags in the web client and then apply to them to the appropriate datastores. After performing a "Refresh Storage Policies" in vCloud Director, your newly created polices do not show up.

I have found that this is a bug and does not clear unless you empty some tables in your vCloud Director database. The script below simply empties some inventory tables and when the services are restarted, re-syncs them from vCenter.

I will say that I always gracefully stop all cells, backup my vCloud database, then run this script. Please note that this script is not intrusive to any static data.


delete from task;
update jobs set status = 3 where status = 1;
update last_jobs set status = 3 where status = 1;
delete from busy_object;
delete from QRTZ_CALENDARS;
delete from QRTZ_TRIGGERS;
delete from QRTZ_JOB_DETAILS;
delete from compute_resource_inv;
delete from custom_field_manager_inv;
delete from cluster_compute_resource_inv;
delete from datacenter_inv;
delete from datacenter_network_inv;
delete from datastore_inv;
delete from dv_portgroup_inv;
delete from dv_switch_inv;
delete from folder_inv;
delete from managed_server_inv;
delete from managed_server_datastore_inv;
delete from managed_server_network_inv;
delete from network_inv;
delete from resource_pool_inv;
delete from storage_pod_inv;
delete from task_inv;
delete from vm_inv;
delete from property_map;


Manually Remove vCloud Director Agent From Hosts

I recently ran in to an issue in a lab where I had to manually remove the vCD agent from an ESXi host. The command to manually do this on an ESXi5 host is:

esxcli software vib remove -n vcloud-agent

Note that this is vCloud Director 1.5.


Restarting vShield Manager Web Interface

Sometimes vCD cells lose connectivity to vShield Manager. Instead of rebooting the vShield Manager virtual machine, the web service of vShield Manager can simply be restarted.

To accomplish this, you can open the console of your vShield Manager virtual machine, log in, and enter enable mode. From there, enter configure mode and issue the command "no web-manager" and then "web-manager".

manager# configure terminal
manager(config)# no web-manager
manager(config)# web-manager

This will restart the web and hopefully clear any web service connectivity issues.


vCloud Director 1.0.1 Upgrade Fails with “cpio: chown failed – Operation not permitted”

VMware requires that the vCloud Director installation .bin file is executed as root. This file is run to perform a new installation or upgrade to an existing vCloud Director cell. I have recently run into an issue with NFS's "root squashing" feature, which prevents the upgrade from completing.

As the NFS Sourceforge page states:

Default NFS server behavior is to prevent root on client machines from having privileged access to exported files. Servers do this by mapping the "root" user to some unprivileged user (usually the user "nobody") on the server side. This is known as root squashing. Most servers, including the Linux NFS server, provide an export option to disable this behaviour and allow root on selected clients to enjoy full root privileges on exported file systems.

Unfortunately, an NFS client has no way to determine that a server is squashing root. Thus the Linux client uses NFS Version 3 ACCESS operations when an application is running on a client as root. If an application runs as a normal user, a client uses it's own authentication checking, and doesn't bother to contact the server.

If you are not using the "no_root_squash" option on your NFS exports on your NFS server, you will receive the error "cpio: chown failed - Operation not permitted". This option is needed since the /opt/vmware/cloud-director/data/transfer directory on the vCloud Director cell is actually mounted to your NFS server.

Once you enable the no_root_squash option on your NFS exports, such as:

/export/dir hostname(rw,no_root_squash) will be able to write to the directory as root and the upgrade will complete.