Tag - vCloud Director

I had a customer upgrade their vCloud Director environment from v8.20 to v9.5. The upgrade itself went fine, however some tenants were now unable to login. Interestingly, the affected tenants were authenticating against their own LDAP server over LDAPS. All other tenants were authenticating against the Service Provider managed LDAP server. For this particular service provider customer and their tenant, the LDAP server was specified using an IP address instead of a FQDN.

With the release of vCloud Director 9.5 I’ve gone ahead and upgraded my test environment from 9.1 (specifically 9.1.0.1) to 9.5. Straight away I notice in the release notes that having a mix of vCloud Director appliances and Linux servers (with vCD installed) is not supported. There is also no supported migration method to move from Linux servers to the appliance. So, in place upgrade it is! I won’t go over the entire experience of using the HTML5 UI, only things I’ve noticed that are new in 9.

VMware has released vCloud Director 9.5! If you go to the My VMware downloads section you won’t find it. You need to change the URL so it has “9_5” on the end: vCloud Director 9.5 Download Assuming you have the right entitlements, you’ll be able to start downloading the upgrade bin’s and the OVA. To find out what’s new, VMware have released a PDF highlighting all the new features: What’s new with vCloud Director 9.

I’ve been working on some more automation lately for vCloud Director using vRealize Orchestrator. One of my use cases was to retrieve the SDK Connection scripting object for the linked vCenter Server. My starting point was an Org vDC, and from there I wanted to get the backing vCenter Server. Let’s start by getting the Provider vDC vCloud Reference object from the Org vDC scripting object (orgVDC): var providerRef = orgVDC.

I’ve been working on some automation that will create metadata against objects in vCloud Director using vRealize Orchestrator. If you’ve ever had to do this before you’ll know how painful it can be to get your head around all of the objects/transformations you need to make before you can even set the metadata to the object. First you take the metadata value (in this case a string) and create a new VclMetadataStringValue object.

Recently I spent some time configuring vCloud Director metrics and storing them in a Cassandra cluster. If you have ever stepped outside of the default metrics and tried to provide your own via a Groovy file, you may have hit the following error in the cell-management-tool.log log: Invalid column name **metric** because it conflicts with an existing column If your Groovy file contains the metric listed in the error message and you’ve only listed it once, you’re probably thinking “where on earth is this duplicate coming from?

One of the core pre-requisites for vCloud Availability for vCloud Director 2.0 is CassandraDB. This database service stores replication state and storage information and is used by the HCS (vSphere Replication Cloud Service) appliance. As part of my strained vCloud Availability deployment I needed to build a simple CassandraDB server. VMware Docs and the vCloud Architecture blog have some great information to get you started: vCloud Architecture blog - Deploying CassandraDB VMware Docs - vCloud Availability for vCloud Director Installation Guide Symptom I built the CassandraDB server as described in the blog post and Docs pages above, but when I would try to connect to the database using the Cassandra shell (cqlsh {ip-address} 9042) I would get the following error:

After a short break over Christmas and New Year’s I threw myself into the latest version of vCloud Availability for vCloud Director (2.0). The installation of vCloud Availability for vCloud Director (vCAv) is all done through an “installer appliance”, a CLI and a configuration file called a ‘registry’. I opted for the ‘automated’ installation using a registry file and had all of my configuration and VM deployment specs in there.

Hello again! Today’s adventures drove me a little wild… Some background first. In my test environment, I have a full vCloud Director v8.10.1 deployment, load balanced with an F5 LTM. The certificates are loaded on the F5 so that traffic is terminated and re-encrypted on it’s way to the vCloud cells. Since deployment, both the http and console FQDNs functioned as expected. This all changed just a few months ago…

While trying to troubleshoot another problem, we tried Refreshing vCloud to vCenter which includes registering/updating the extension. This is when we hit a beauty we’d never seen before: Alright, calm down. Probably something with the network, right? And if it’s not the network then it’s probably DNS. Right? Oh how I wish that were so. I dug around in the vCenter MOB and found the vCloud Director extension. As expected it already had a “vCloud Director-1” named extension.