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.
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.
If things go wrong in a VMware vSAN 6.x environment you may see congestion warnings and errors – usually in hybrid setups. I try to explain what congestion means in the world of vSAN, why it’s a problem and how to deal with it.
What is congestion?
In short, congestion occurs when you have a bottleneck in the lower layers of your vSAN infrastructure. Or, more concretely: The destaging process of the incoming data, from the flash cache to the capacity disks, is so heavy that one layer of vSAN cannot handle this amount of data.