vSAN Witness Appliance and Witness traffic on the management network for 2-Node ROBO

[Thurai]

I have installed the vSAN witness appliance and put both nic ports on the management switch in order to send the witness traffic on the "management network".

By default, the VSAN appliance has two vss one for managementPG and another for WitnessPG.

I issued esxcli vsan network ip add -i vmk0 -T witness .

I noticed that vmkernel(vmk1)at the wintnessPG is still showing the VSAN check mark and vsan option on the management's vmkernel(vmk0) is not checked as below.

Should I have to tag the vSAN at the Management port-group's vmkernel vmk0?

[depping]

No, you don't need to tag the VMkernel in this case as you already tagged it for witness traffic using esxcli.

[TheBobkin]

Hello Thurai

Actually Witness should NOT be tagged with witness type traffic (yes I know, this is perhaps a little confusing) - that type of traffic only needs to be set on the data-nodes (so that they send just traffic to Witness out a specified link). Yes, the vmk0 should be tagged for traffic type 'vsan' in the UI, it should also be untagged on the default vmk1 and the 'witness' type traffic removed from vmk0.

Bob

[srodenburg]

Setting the witness-separation traffic vmk with "esxcli vsan network ip add -i vmkX -T witness" is only relevant on regular vSAN Nodes and NOT on Witness Appliances.

On witness appliances, only bind the vSAN Service to the desired single interface (either vmk0 or vmk1) via the GUI and you are done there.

In Witness Appliances where everything runs over vmk0 only, you can delete the entire witnessPG vSwitch to avoid further confusion and it looks nicely cleaned up*

*ignore this with VxRail Stretched Clusters as they use vmk1 in witnessPG (on a separate, dedicated "Witness traffic" VLAN even) so it must stay intact before you run the VxRail Deployment wizard.