In order to provide connectivity to the VMs and to the ESXi Hosts, VMware offers the possibility to configure vSphere Standard Switches (vSS) (at the Host level) and Distributed Switches (vDS) (on Data Center level).
The purpose of this article is to cover the first steps about configuring vSphere Standard Switches for our home lab.
The vSphere Standard Switches operate very similarly to a physical Ethernet Switch. Each virtual NIC from the VMs and physical NICs on the Host use one “logical port” on the Standard Switch. Each logical port then is part of a single port group. Each virtual Standard Switches provide up to 4096 ports (1016 active ones) per single Host which cover the large majority of scalability scenarios including as well a great deal of flexibility including VLANs, MTUs and other Network Policies as we’ll see later in this article. For a better overview of the vSphere configuration maximums it is worth looking at this VMware document summing up all the required information.
How to setup VMware virtual switch
Before proceeding it would be a good idea to have a representation of how the vSphere Standard Switches architecture looks like so we can do a mapping with the configuration in our home lab. And here it goes a simple diagram with a quick description:
From the top we notice the Management and vMotion Traffic along with the VMs in the Test and Production groups. In a real world ideally you would like to separate the traffic depending on needs and this is exactly what you can accomplish as well by configuring different Port Groups. Port Groups can have different setting s in terms of MTU, traffic shaping and more. Ultimately Port Groups can be connected to one or more Uplink Ports which can be configured with various settings with regards to Load Balancing and and Nic Teaming scenarios. In terms of traffic separation it is possible to operate in two ways:
- By using VLANs (segmentation occurs on Layer 2)
- By creating custom TCP/IP Stacks (segmentation occurs on Layer 3)
By isolating traffic to specific devices and groups it is possible to achieve an higher level of security nonetheless a better understanding of performances for each single network service. Typically separating traffic based on its purpose it is always a good idea. In this instance for example we are considering to separate the Management Traffic from the vMotion traffic and ultimately the traffic generated by the VMs themselves by leveraging VLANs. Since all Port Groups will be part of the same vSphere Standard Switches they will be “sharing” the same Uplink Ports. For this article I will use just one VMnic. I will leave the configuration of Load Balancing and NIC Teaming for physical network cards on the Host for a separate post. Before proceeding though a quick description of the elements highlighted in this picture:
Management Traffic: responsible for carrying the configuration and management communication between the ESXi Hosts and vCenter Servers. It is created by default on the first installation of the ESXi Host. To provide redundancy it is also possible to connect additional NICs to the same VMkernel configured for Management Traffic.
vMotion Traffic: is responsible for live migration of virtual machines. It has to be enabled on the VMkernel on both source and destination Hosts. By separating this traffic to a specific Port Group using a dedicated Uplink Port performances are at their best without affecting the traffic reserved to other services.
VM: is the virtual machine that can be connected to one or multiple Port Groups by mean of multiple vNICs installed on the VM. One vNIC per Port Group. This is particularly useful when the same VM needs to “talk” to different non-routed networks (eg. DMZ).
Port Group: defines configuration option such like bandwidth limitations, VLAN tagging, network policies and more for each member part of the same group. In vSphere Standard Switches it is possible to have multiple Port Groups. Each Port Group can have it’s own predefined policies (eg. Enable Promiscuous mode helping auditing network services).
VMnic: is the default name VMware vSphere is using to identify the Physical NICs installed and recognized on the Host. By default the first VMNic is called VMNic0. The other ones usually start with VMNic32, 33, 34 and so on. In my case for my home lab based on Intel NUC I have added 3 external USB 3.0 Network adapters by following this excellent post by Jose Gomes. In case you are asking I opted for the Realtek ones! So after installing the correct drivers you should get something similar to this:
Uplink Port: is the port on the vSphere Standard Switches that is associated to physical NIC (VMnic) installed on the Host. 1 Uplink Port per VMnic. VMNics can be configured as Active, StandBy and Unused. Redundancy can be provided to the same Port Group just by adding available VMNics as per screenshot below:
At this point we are ready to create our customised vSphere Standard Switches and in particular we want to have:
- A Port Group for Management Traffic
- A port Group for vMotion Traffic
- A Port Group for Testing VMs
- A Port Group for Production VMs
- Each of the Port Groups can have specific settings
Here we go. Let’s start with the creation of our custom vSphere Standard Switches. From the vCenter let’s browse to Host and Cluster > Select the desired Host > Add Networking and from the wizard we can start with the VMkernel Network Adapter.
Let’s create a new vSphere Standard Switches.
At this point we can select the available adapters (VMnic) we want to assign as Active, Standby and Unused. This operation can be edited later on as well.
For each adapter it is possible to view the important settings. In particular it is interesting to know which network cards do support the DirectPath I/O and the SR-IOV features or simply the network speed.
Very easily we can also check the specs for the available vmnics or physical network adapters.
At this point we need to provide a name for the first Port Group which is created as part of the Standard Switch wizard. Next we can specify the VLAN ID should we want to separate the traffic for this Port Group from the other ones. In this case I do not want to use VALN tagging for this type of traffic.
We can also specify if this Port Group will use IPv4, IPv6 or both. In my case it will be a standard IPv4.
With regards to the TCP/IP stack there are 3 standard options: Default, Provisioning and vMotion. Selecting Provisioning and vMotion automatically greys out the other available network services. So in our case we can select “Default” and then make sure vMotion and Management Traffic are selected. This will ensure that on the VMkernel associated to the Standard Switch we are creating the necessary network services are available.
At this stage we can either specify the IP addresses manually or leave things automatically (providing a DHCP service is operating!).
And now a final review of the settings before committing changes.
As expected If we browse the Virtual Switches view we can find the newly created switch. Selecting the first Port Group we created is also highlighting the selected Uplink Port. All settings can be edited on the Switch and Port Group levels and in particular will be possible to change:
Switch Level:
- Properties
- MTU
- Security
- Promiscuous mode
- MAC address changes
- Forged transmits
- Traffic Shaping
- Status
- Average Bandwidth
- Peak Bandwidth
- Burst Size
- Teaming and Failover
- Load balancing
- Network failure detection
- Notify Switches
- Failback
Port Group level:
- Properties
- Network Label
- VLAN ID
- Security
- Promiscuous mode
- MAC address changes
- Forged transmits
- Traffic Shaping
- Status
- Average bandwidth
- Peak Bandwidth
- Burst Size
- Teaming and failover
- Load balancing
- Network failure detection
- Notify switches
- Failback
- Override failover order
Equally a new VMkernel associated to our “vSwitch1” has been created accordingly. From this view it is also nice to spot which services are enable on this particular VMkernel.
At this point we are ready to create the other Port Groups for vMotion, Testing VMs and Production VMs. So we can start the same wizard and select the last option as per screenshot below.
Let’s make sure we choose the intended vSwitch.
For vMotion I won’t be using a particular VLAN ID. So I will leave this set to “0” or None. In the case of Production I will use VLAN ID “10” and for Testing VLAN ID “20”.
As usual a final review before finishing the wizard..
Repeating the steps above for Production and Testing Port Groups will give a configuration similar to the one below.
Add Comment