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.
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.
Upgrading NIOC from version 2 to 3 is no big deal. But I’m writing this blog post because the official VMware documentation says that the upgrade to NIOC v3 is disruptive and that worried me.
We have only one dvSwitch in our virtual infrastructure and use vSAN and NSX. If this upgrade is really disruptive, we need to shut down all virtual machines before the upgrade process starts. And that would be a big deal for us and our customers.