A few days after upgrading from vCloud Director 9.1 to 9.5, I encountered a strange issue. If someone was trying to launch a vApp or VM or trying to reconfigure existing VMs or vApps, it wasn’t possible. In the logs I could see the error message “Total available resources could not be determined for reservation” in combination with a long Java stack trace.
vCloud Director has been adding an Auto Discovery feature for VMs in version 8.20 and it’s available for some time now. It’s a cool feature that can simplify migrations, but in practice there are some pitfalls that can make things difficult. To be more concrete: It only works under certain conditions. Tom Fojta has written an article about this feature some time ago (Thanks, Tom). But I think some details are missing and that inspired me to post this.
In previous vCloud Director versions (5.x, 8.x, 9.0 and 9.1) importing OVA files was difficult and sometimes impossible. Depending on the type of appliance, many OVA files allow you to configure additional settings during deployment. These can be network settings, passwords, license keys or something else. Whether these options exist, are optionally configurable or required depends on the OVF manifest defined by the manufacturer of this OVA. If these fields were necessary for starting the appliance (e.g. license information), it was previously not possible for customers to import and use these appliances themselves in vCloud Director.
With vCloud Director version 9.0, performance metrics of virtual machines can be directly displayed in the new HTML5 Tenant portal for customers. All it takes is a Cassandra database cluster and a few small configurations on the vCloud Director side. Sounds simple, doesn’t it? That’s it, too, if you consider a few pitfalls.
With vCloud Director 9.5 it is possible to display performance metrics for VMs, such as CPU or memory usage, directly in the new Tenant Portal. However, this requires a Cassandra database cluster to store these performance metrics.
There are already guides out there on how to set up a Cassandra database cluster for vCloud Director, but the instructions I found were partly outdated or lacked information or were not suitable for CentOS 7, which I want to use as the base operating system. So I decided to create my own blogpost. And the VMware documentation about installing Cassandra for vCloud Director 9.5 doesn’t give a lot here and serves only as a rough orientation.
A vCloud Director setup consists of several components. At least required are vCD cells, a database and an NFS server. Depending on the features, additional components may be necessary, for example the AMQP Broker or a Cassandra database. In order to make this setup completely high available, each of these components must therefore be redundant. So, it’s useful to take a look at some basic HA considerations for the individual components.
With the release of vCloud Director 9.5 it became known that only Postgres will be supported in the future as database backend. MS SQL was flagged as deprecated and Oracle is no longer supported with vCD 9.5 onwards. In addition vCloud Director has also been released as an appliance based on PhotonOS. Therefore, I would like to explain how you can switch to the new appliances and the database backend in a few steps.
Since September 2018, VMware has a special Cloud Verified Logo for partners who meet specific requirements for their cloud infrastructure. As my company was the first in Switzerland to receive this logo, I would like to briefly explain what this designation means and which requirements apply.
Since upgrading to NSX 6.4, I get warnings for certain ESXi hosts because there is a VLAN and MTU mismatch. So I checked the vDS healthchecks and found the following error: VLAN 0 is not supported. But since we didn’t remove or add VLANs on the physical switches, I was very surprised. And VLAN 0 shouldn’t exist anyway. So, what is it about and why does the error suddenly occur?
We have recently upgraded from NSX-v 6.3.3 to NSX-v 6.4.3. The upgrade went well so far, but after the upgrade we noticed that the list of logical switches was no longer loaded correctly.
Depending on how we sorted the list, the list was either empty and the error message “Internal server error has occurred” was displayed or it happened while scrolling. In any case we couldn’t use the list with the logical switches anymore. And unfortunately the error message is quite useless.
So we went through the logs of the NSX Manager and found what we were looking for in the vsm.log.