We had to build a vSAN environment with witness traffic separation(WTS). We had a total of 52 host that needed this configuration. But I wasn’t completely thrilled to perform the action mentioned in the manual on every host.

Configure Network Interface for Witness Traffic (vmware.com)

So we identified the steps and start scripting; High-over we have the following steps per cluster

  1. Create a vSwitch with portgroup (those differ per datacenter and per cluster)
  2. Create VMhostNetwerk adapter
  3. Verify that the vSAN witness is reachable via the WTS interface
  4. Tag the interface for Witness traffic separation

So the first step is to create a vSwitch with the appropriate portgroups

#fetching the hosts in the cluster
$esxhosts = get-cluster VMCL01 |Get-VMHost |Sort-Object name

#setting the variables (These change per cluster)
$portgroupDC1 = "DC1-WTS-VMCL01"
$portgroupDC2 = "DC2-WTS-VMCL02"

$vlanidDC1 = "915"
$vlanidDC2 = "925"

#CreatevSwitch for hosts (Per Cluster)
foreach ($vihost in $esxhosts){
New-VirtualSwitch -VMHost $vihost -Name vSwitch1 -nic vmnic0,vmnic1 -mtu 1500
#If-Elseif statement to determine if the host is located in DC1 or DC2 and create corresponding portgroup
if ($vihost -like "pp30*")
        {
        Get-VMHost $vihost | Get-VirtualSwitch -name vSwitch1 | New-VirtualPortGroup -Name $portgroupDC1 
        }
elseif ($vihost -like "pp31*")
        {
        Get-VMHost $vihost | Get-VirtualSwitch -name vSwitch1 | New-VirtualPortGroup -Name $portgroupDC2  
        }
}

After the first steps it’s time to create the witness kernel and the appropriate route so that the vsan witness traffic gets send over the right interface. We created a CSV with al the ip adressen for the hosts in the cluster.

#create VMhostNetwork Adapter
$witnesskernels = Import-Csv -Path "H:witnesshosts-VMCL01.txt"  
foreach ($witnesskernel in $witnesskernels){
        if ($witnesskernel.Name -like "pp30*")
        {
        New-VMHostNetworkAdapter -VMhost $witnesskernel.name -Portgroup $portgroupAM4 -VirtualSwitch vSwitch1 -IP $witnesskernel.ip -SubnetMask 255.255.255.224
        New-VMHostRoute -VMHost $witnesskernel.name -Destination 10.50.28.16 -PrefixLength 28 -Gateway 10.50.110.1 -Confirm:$false

                }
        elseif ($witnesskernel.name -like "pp31*")
        {
       New-VMHostNetworkAdapter -VMhost $witnesskernel.name -Portgroup $portgroupAM2 -VirtualSwitch vSwitch1 -IP $witnesskernel.ip -SubnetMask 255.255.255.224
       New-VMHostRoute -VMHost $witnesskernel.name -Destination 10.50.28.16 -PrefixLength 28 -Gateway 10.50.120.1 -Confirm:$false
               }
}

Step 3 is to test if the WTS kernels can reach the vSAN Witness. I won’t go in detail of how to configure your vSAN Witness, there are plenty of blogs out there describing just that. What is important is that you put the right routes in the vSAN witness so the WTS traffic knows the way back.

If you combine ESXIcli with PowerCLI it’s possible to send a ping from a host through a destination to verify if there is connectivity between.

#ping witness verkeer
foreach ($vihost in $esxhosts){
$esxcli = Get-EsxCli -VMhost $vihost -V2
$params2 = $esxcli.network.diag.ping.CreateArgs()
$params2.host = '10.50.28.17'
$res = $esxcli.network.diag.ping.Invoke($params2)
Write-host "Resultaat van  $($vihost)" -ForegroundColor Green  
write-host "PacketLoss Percentage $($res.summary.PacketLost)"
}

After last step is “great succes” you can assign the witness tag tot he interface so that vSAN actually use the interface and WTS is active. I added a sleep-progress(found on the internet) because if the tags were set to fast on different host it seemed that vSAN had some issues (for example; slow response from vSAN datastore) after the timeout i didn’t see this issue.

Function Sleep-Progress($seconds) {
    $s = 0;
    Do {
        $p = [math]::Round(100 - (($seconds - $s) / $seconds * 100));
        Write-Progress -Activity "Waiting..." -Status "$p% Complete:" -SecondsRemaining ($seconds - $s) -PercentComplete $p;
        [System.Threading.Thread]::Sleep(1000)
        $s++;
    }
    While($s -lt $seconds);
    
}
#tag interface
foreach ($vihost in $esxhosts){
$esxcli = Get-EsxCli -VMhost $vihost -V2
$arguments = $esxcli.vsan.network.ip.add.CreateArgs()
$arguments.interfacename = 'vmk3'
$arguments.traffictype = 'witness'
$esxcli.vsan.network.ip.add.Invoke($arguments)
Write-Host "Completed tagging host $($vihost)" -ForegroundColor Green
Sleep-Progress 120
}

After the last part of the script and WTS finally active it’s wise validate of the vSAN Skyline Health is “green” and there are no errors left in the environment.

The original article was posted on: www.ruudharreman.nl

Related articles

  • Cloud Native
  • Implementation and Adoption
  • Platform Engineering
  • Digital Workspace
  • Hybrid Cloud
  • Private: ITTS (IT Transformation Services)
  • Private: Managed Security Operations
  • Managed Cloud Platform
  • Private: Backup & Disaster Recovery
Visit our knowledge hub
Visit our knowledge hub
Ruud Harreman Virtualization Consultant

Let's talk!

Knowledge is key for our existence. This knowledge we use for disruptive innovation and changing organizations. Are you ready for change?

"*" indicates required fields

First name*
Last name*
Hidden