Some time ago we had problems with the NSX Manager, had to deploy a new Manager appliance and restore a config backup. However, we were unable to manage Edge Gateways in the vCloud Director web interface after this work. Neither as Org Admin, nor as System Admins. In the Action menu the item “Edge Gateway Services” for configuring the network services was simply grayed out. Even a Re-deploy of the Edge Gateways didn’t help.
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.
VMware recently released the latest version 2.5 of the vCloud Architecture Toolkit for Service Providers (vCAT-SP). But I know that many service and cloud providers around the globe don’t know what that is and that something like that even exists.
I will therefore try to give a brief overview and introduction to this topic and hopefully show how powerful this toolkit can be for your business.
For high availability and performance reasons, it makes sense to run multiple vCloud Director cells. To do this, you can place a load balancer in front of it. And since we already use NSX for vCloud Director 9, it makes even more sense to use an edge gateway for load balancing.
However, there are a few pitfalls, for example with terminating HTTP connections, session persistence and especially with the VM Remote Console via the browser.
In my blog post I show you how to configure NSX and vCloud Director 9 and what to consider for this setup.