Category Archives: Vcenter

VMware Validated Designs does not exclude Stretched Cluster in general

Working as an architect in the VMware space you will sooner or later come across the VMware Validated Designs (VVD). Just a few weeks ago the latest version 4.0 was released to make adjustments for vSphere 6.5. It can be found here:

VMware Validate Designs Documentation

The designs are a great source for building your own architectures or building architectures for customers. The incorporated component architectures are natively built for availability, reliability and scalability. These are exactly the main goals I try to put in the designs I create for customers. The VVDs show up a good practise for a detailed setup that can be used for several use cases like Private Cloud or VDI deployments. VMware Cloud Foundation also makes use of the VVDs for its implementations.

But apart from this I also like to treat them as a framework which gives me the chance to keep the setup supported by VMware but also adjust it to the customer needs and make it fit like a second skin based on customers requirements.

Across their history they mainly relied/rely on a two region concept with one primary and fail-over region. This is a quite common architecture for U.S. setups. In the European space and especially in Germany customers often stick their existing architectures based a two datacenters setup working as an active/active pair. If you see this also as a two region setup or you would aggregate this into one region like me, is up to you. I prefer one region because the datacenters are in a short distance because of their synchronous replication/mirroring and so they build up a logical domain because for their active/active style.  This is why I split the region down to two physical availability zones (AWS term) and one virtual across two datacenters. This does not need to be undestand now, it will get clearer in later chapter.

In my understanding the VVD framework needs some extension in regards to Stretched Clusters and this is why I like to set up a series which guides through a forked version of the VVDs I personally use for customer designs:

  1. General thoughts
  2. Additions/Changes to physical architecture
  3. Additions/Changes to virtual architecture
  4. Additions/Changes to cloud management architecture
  5. Additions/Changes to operations management architecture
  6. Additions/Changes to business continuity architecture

Stay tuned!






Set up vCenter HA in advanced mode with different heartbeat networks

Setting up vCenter HA in basic mode is pretty straight forward.

Doing the same in advanced mode is a little bit more tricky. But first, why I need to go with the advanced vCenter HA mode?

  • the VCSA is managed by another vCenter (for example if the setup is according to the VMware Validated Design 3.0)
  • the heartbeat vNICs are not in the same IP subnet

Luckily I to cater with both in a project.

I don’t want to create much content by copying from VMware documentation, so I only like to give some hints and describe some pitfalls you might get into, when setting this up and last but not least describe what VMware missed in there official documentation:

Preparation pitfalls

DNS reverse lookup

Basics, basics, basics. Ensure that you have a proper DNS reverse lookup implemented. Also take care of the exact writing of the host names. Don’t maintain a hostname entry in the DNS system with capital letters and use a non-capital or mixed one in your VCSA. This basically does not work, because the self-lockup fails. The GUI won’t tell you that, but if you run the preparing with prepare-vcha cmd line interface I will show up some more info.


Procedure pitfalls

When have you clicked through the first step in GUI, the next step is to clone the VCSA two times, once for the passive node and second one for the witness node. Very important is, that you don’t clone before the first step has finished. Otherwise the communication between the appliances won’t work because they use the wrong SSH keys. This is also valid, if you try to use the same cloned appliances for setting this up a second time – this won’t work. You need to throw them away and clone new ones at the right point in time.


The official documentation does not describe the customization stuff in much detail. Maybe that is not necessary, but if something is not totally clear to you, here some hints:

Passive node: documentation is clear, but really, you need to configure the first NIC (NIC 0) with the same IP config like the primary vNIC of your original VCSA. The adapter gets automatically shut down while first boot, so there is no IP conflict in your network – or better only for a short moment. NIC 1 set to the heartbeat network info you have prepared. Ensure that you really don’t set a gateway on this adapter.

Witness node: the documentation stated here to also leave the gateway out for the required heartbeat NIC. I have not done this, as I set the first adapter unused or shut it down. The second one I set to the heartbeat IP and used also a gateway. The gotcha was, that the witness had an IP in a totally different subnet than the active and the passive VCSAs. Static routes might also do the job, but I had some trouble with that.

First start

Start up the appliances. The IP conflict resolves as described above. Before to click the next step in the GUI, ensure that you do the following:

Go to both active and passive VCSA and add a static route so they can reach the witness via the heartbeat interface:

Edit /etc/systemd/network/ and add the following lines at the end:


The destination can be limited to the heartbeat IP of the witness VM. The gateway must be the gateway of the IP subnet used for the heartbeat in the local VCSA appliance. Repeat this on the passive appliance (best is to SSH to it via the active one).

Now and only now hit “Finish” in the GUI and all should go well. You can check the log /var/log/vmware/vcha/vcha.log for further info.