Selected host is an external witness for another vSAN Stretched cluster

As VHT readers have seen lately, I have been doing a lot of home lab work with VMware vSAN and thoroughly enjoying it.  The advancements that have been made in vSAN 6.6 and patch levels have truly made vSAN a great HCI software defined storage solution.  I really enjoy working with the home lab environment as well.  Home labs are great in that often you don’t really do things properly due to just wanting to spin things up and tear them down quickly, but in the process it makes you come up against errors that most likely you would not see in production or when you do you may not expect to see them.  Recently, I ran across another issue in the home lab that was due to not properly removing a VMware vSAN Witness host from the environment.  I wanted to reuse the same witness host with another vSAN cluster and when I attempted to use the witness host with the vSAN cluster, I received the error: “Selected host is an external witness for another vSAN Stretched cluster”.  Let’s take a look at an easy way of resolving this issue.

Selected host is an external witness for another vSAN Stretched cluster

The error presented itself when selecting the witness host in the vSAN configuration process.

As you note in the screen above, the Requirements for Witness host include:

• Not part of any vSAN enabled cluster
• Have at least one VMkernel adapter with vSAN traffic enabled
• That adapter must be connected to all hosts in the Stretched cluster

As mentioned, the witness host I wanted to use had been joined to another iteration of the vSAN cluster so it “thought” it was joined to the previous version of the vSAN cluster.  I tried to think of a way to remove the witness host from the cluster using the vSAN interface, however, it was in a “catch-22” state of not being managed by the current vSAN interface so I couldn’t really manage it to remove it and then join it or even manage the disks.   Using the command esxcli vsan cluster get I could see the host thought it was STANDALONE and could see the UUID of the previous cluster.

I wondered, was there a parameter to the esxcli vsan cluster command that would allow disjoining?  Alas there is!  Using the same command without the list parameter, I issued the esxcli vsan cluster command and there is a leave parameter that looks to do just what I had hoped.

After running the esxcli vsan cluster leave command, I then went back through to see if I could now use the vSAN witness host in the new vSAN cluster and success!  As you can see below, the Select Witness host screen now shows the Compatibility checks succeeded.

Concluding Thoughts

Most likely in production environments, you wouldn’t be building and tearing down VMware vSAN environments utilizing the same VMware vSAN Witness host.  However, in home lab environments that are volatile and constantly changing with different iterations of testing, this especially may be an error you will see if reusing the same VMware vSAN witness host in your lab environment.  As is the case often, the command line comes in for the rescue and allows leaving the previous vSAN cluster on the witness host and you can then join the new cluster without issue.