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.
The topics “How do I get root access to the different NSX components” or “How can I find the root password” comes up quite often. For some components it’s already widely documented (for example NSX Manager) and for other components it’s rarely described (for example the NSX controllers). I also haven’t yet found a complete overview of how to get root access to the underlying Linux layer on all components. So I thought I’d put this information together here for the NSX versions 6.3 and 6.4.
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.