Nesting VMware ESXi has become easier and easier as the years roll by. In case you don’t know “nesting” is the term used for running VMware ESXi inside a VM for development purposes. It’s the basis of VMware’s popular “Hands-on-Lab”, as well as homelabs – and in recent years “nesting” has gone to the Cloud with service like Ravello on the Oracle Infrastructure Cloud (OIC).

In years gone by there were many settings needed at the Physical and Virtual layer – that required hand-edits to configuration files to make this work. With the advent of vSphere 6.5 U1 a lot of that disappeared. HOWEVER, there’s still plenty of work that needs to be done at the physical and virtual layer to allow for networking to work properly. As well as successfully passomh some of the “health checks” around technologies like VMware VSAN that has specific networking requirements for your web-client to light up with little green ticks of happiness.

Here’s a brief check list:

Physical Switch needs:
- MTU of 9000,
- with VLAN Tagging enabled as necessary
Physical ESXi host vSwitch needs
- MTU of 9000
- vSwitch security policy of Accept, Accept, Accept
- Portgroups used by the virtual “nested ESX” enabled for 4096 to allow for VLAN tagging in the nested layer to pass-thru to the physical switch
Virtual Nested ESXi vSwitch needs
- MTU of 9000
- vSwitch security policy of Accept, Accept, Accept
- Portgroups for VMs and VMkernel enabled for VLAN Tagging as necessary

Standard Switches work well with nesting, and have the added benefit of not being tied to a vCenter to the host. This makes blowing away the nested layer after your lab period ends a breeze. It’s slower and more awkward “clean-up” process if your using DvSwitches. To use the special MacLearn VIBs that improve network performance DvSwitches are needed at the physical layer – this isn’t an option if you main physical ESXi host is stand-alone and not managed vCenter.

1. Physical Switch Needs:

In my case I have a HP ProCurve 1810G – 24 G switch – its not a bad unit, whisper quiet and simple to configure:

I have simple VLAN configuration (mainly used to demonstrate/explain the VLAN Tagging concept) but I also VLAN off my VMotion traffic.

Physical ESXi host vSwitch needs

I set my MTU and Security policy on the properties of vSwitch0, which means all the portgroups inherit those settings. Its simple quick and easy.

To do that in the context of the VMware ESXi VMKernel you could use the ESXCLI command – and these commands could be part of a kickstart install script:

## - Enabling Jumbo Frames on vSwitch0 to pass VSAN "Configuration Assistant" tests.
esxcli network vswitch standard set -m 9000 -v vSwitch0

## - Lower security on vSwitch0 to allow traffic to flow in a nested environment. 
esxcli network vswitch standard policy security set -v vSwitch0 -f=true -m=true -p=true

The VLAN configuration can be set when the portgroup is being created as is the case with VMotion being on VLAN10 like so:

esxcfg-vswitch -A "VMotion" vSwitch0
esxcfg-vswitch -v 10 -p "VMotion" vSwitch0
esxcfg-vmknic -a "VMotion" -i [VMOT_IP] -n 255.255.0.0 -p "VMotion" vSwitch0
esxcli network ip interface tag add -i vmk1 -t VMotion

Note: In this case [VMOT_IP] is variable used as part of the UDA appliance.

For an existing portgroup for example the “VM Network” the VLAN value can be set to be one that passes thru the VLAN Tagging from the nested layer to the physical layer:

esxcli network vswitch standard portgroup set -p "VM Network" --vlan-id 4095

Alternatively, if your Physical ESXi hosts are managed by vCenter – you could do this with a PowersHell for each loop like so:

1..3 | Foreach {
 $Num = "{0:00}" -f $_
 $vswitch0 = Get-VirtualSwitch -VMHost esx"$Num"nyc.corp.local -Name vSwitch0
 Set-VirtualSwitch -VirtualSwitch $vswitch0 -MTU 9000 -Confirm:$false
 }

1..3 | Foreach {
 $Num = "{0:00}" -f $_
 $vswitch0 = Get-VirtualSwitch-VMHost esx"$Num"nyc.corp.local -Name vSwitch0
 Get-VirtualSwitch -Name $vSwitch0 | Get-SecurityPolicy | Set-SecurityPolicy -MacChanges $true
 Get-VirtualSwitch -Name $vSwitch0 | Get-SecurityPolicy | Set-SecurityPolicy -ForgedTransmitsInherited $true
 Get-VirtualSwitch -Name $vSwitch0 | Get-SecurityPolicy | Set-SecurityPolicy -AllowPromiscuous $true
 }

The VLAN configuration for an existing portgroup can be updated using the following:

1..3 | Foreach {
 $Num = "{0:00}" -f $_
 $vswitch0 = Get-VirtualSwitch -VMHost esx"$Num"nyc.corp.local -Name vSwitch0
 $VMNetworkPG = Get-VirtualPortGroup -VirtualSwitch $vSwitch0 -Name "VM Network"
 Set-VirtualPortGroup -VirtualPortGroup $VMNetworkPG -VLanId 4095
 }

Virtual Nested ESXi vSwitch needs

The setting on vSwitch0 on the Nested ESXi host mirror that of the physical… so everything is aligned from vESX>pESX>pSwitch everything is MTU 9000 with weakened security. The VLANs I have from 101-104 could be added at the physical and virtual level with the esxcli command like so:

esxcli network vswitch standard portgroup add --portgroup-name=VLAN101 --vswitch-name=vSwitch0

esxcli network vswitch standard portgroup set -p VLAN101 --vlan-id 101

or if you were wanting to do this via PowersHell, you could use the following method. This approach differs from my previous examples – it merely “gets” every ESXi host in a vCenter, and creates VLAN101, 102, 103, and VLAN 104.

101..104 | Foreach { $Num = $_ 

(Get-VMHost | sort-object name) | foreach 

{New-VirtualPortGroup -VirtualSwitch (Get-VirtualSwitch -Name vSwitch0 -VMHost $_) -Name VLAN$num -VLanId $num } 

}

A very common use of nested vSphere is to create a virtual/nested vSphere VSAN cluster – this is because not everyone can afford the servers and storage to build out VSAN on a physical level (3 hosts with 1xSDD, 1xHDD). For sometime its been possible to virtualise ESXi, as well as also marking specific VMDKs as either being HHD or SSD. Inside the nested ESXi environment you will need a VMKernel portgroup enabled for VSAN. A simple thing to do would be to enable either the Management Network or the VMotion network for dual usage. Alternatively, you could setup a net-new VMKernel portgroup who’s sole and only purpose is VSAN communications. That’s what I do (even if the traffic goes over the EXACT same nics – as it makes it clear what the usage of each portgroup/vmkernel port is.

You can do this with CLI using the following commands like so:

esxcfg-vswitch -A "VSAN" vSwitch0
esxcfg-vswitch -v 0 -p "VSAN" vSwitch0
esxcfg-vmknic -a "VSAN" -i [VSAN_IP] -n 255.255.255.0 -m 9000 -p "VSAN" vSwitch0
esxcli vsan network ipv4 add -i vmk2

Note: In my case [VSAN_IP] is a variable used in my kickstart sub-template as part of the UDA. The main thing is to know the number of vmk ports – vmk0 is always the default management port – in my script the next vmk port created is for VMotion, and that therefore make the VSAN port be vmk2.

or with PowersHell:

1..3 | Foreach {
 $Num = "{0:00}" -f $_
 $vswitch0 = Get-VirtualSwitch -VMHost esx"$Num"nj.corp.local -Name vSwitch0
 New-VMHostNetworkAdapter -VMHost esx"$Num"nyc.corp.local -VirtualSwitch $vswitch0 -PortGroup VSAN -IP 10.20.33.1"$Num" -SubnetMask 255.255.255.0 -VsanTrafficEnabled $true
 }

Michelle Laverick Music

Making a little nest for your VMs

1. Physical Switch Needs:

Physical ESXi host vSwitch needs

Virtual Nested ESXi vSwitch needs

Like this:

1. Physical Switch Needs:

Physical ESXi host vSwitch needs

Virtual Nested ESXi vSwitch needs

Share this:

Like this: