Introduction

Standard vSwitches have been around in VMware ESX since the very earliest days – they are a robust, well-known technology and despite the advances in networking with onset of Distributed vSwitches, VMware NSX, VMware VXLAN, and vCloud Networking and Security (vCNS) – they remain very popular. Standard vSwitches reside on the VMware ESX hosts and can be managed both in stand-alone way with the vSphere Client, or via the vCenter Server using the web-client. Additionally, there are extensive PowerShell cmdlets available, together with commands on the ESX host. These commands on the ESX host itself can be very useful when used in conjunction with scripted installation for laying down the basic networking layer required for other functions and features such as access IP-based storage (NFS and iSCSI) as well as advanced features such as vMotion and Fault Tolerance.

Standard Switches are packed with features – but they are not as functional or easy to manage as the Distributed vSwitch. You may find that other technologies available from VMware strongly recommend or require the use of Distributed vSwitches. For example VMware’s vCloud Director (vCD) leans heavily on the Distributed vSwitch, and although Standard vSwitches are supported – it is substantially more effort to manage vCD without Distributed vSwitches. With that said, Standard vSwitches remain popular for environments that are mainly geared around primary compute virtualization, and this due in no small part to the Standard vSwitch being available in all distributions of vSphere, whereas the Distributed vSwitch is currently only available within the Enterprize Plus editions of the platform.

Some organizations prefer to use a combination of both Standard vSwitches and Distributed vSwitches. In this scenario they use Standard vSwitches to manage all “host” based networking, and use Distributed vSwitches to manage all “VM” Networking.

UPDATE:

I’ve since found the time to record a “Show me how” video which covers the basics of creating Standard vSwitches – it covers how to create/modify Standard vSwitches in vSphere 5.5 using the all-new Web Client – it cover vSwitches, NIC Teaming, VLAN Tagging and load-balancing MPIO for iSCSI Binding communications…

For best quality on YouTube ensure you use Full Screen, 720p HD Quality – Youtube often defaults to a lossy quality to speed up delivery.

Native Quality hosted directly on mikelaverick.com

Additionally, I did another video which covers the settings on Standard Switches and their Portgroups.

Finally, I recently recorded a “Discuss The Options” video with @chriswahl (Social media adventurer, virtualization whisperer, and global event speaker. VCDX 104. Author of http://goo.gl/C77kHn & http://goo.gl/jTBVMH). In the video Chris talks about whether you should create a standard switch for each and every type of network communication or if you should create on single “Uber” Standard Switch – and the different design considerations when using Standard Switches.

 

Network Patching of Standard vSwitches

Mode 1: Internal Standard vSwitch

In this case no physical network card (referred to as vmnic’s in VMware terminology) is mapped to the virtual switch. In this case all network communication remains within the walls of the physical server, and only systems configured to the same “internal” Standard vSwitch can communicate with each other. As such their usage remains limited to specific situations such as:

• Creating a test network within to run VMs isolated from others
• Creating a “firewall-in-a-box” scenario were one VM contains two NICs connected to two different vSwitches for purposes of being the Firewall/NAT/Router between the two networks.
• Used by VMware Site Recovery Manager to create a “bubble network” during tests to prevent network conflicts during the use of recovery plans for DR purposes

Mode 2: Basic Standard vSwitch

In this case just one vmnic is mapped to the vSwitch providing basic communication to outside the world. This could be used for network process where redundancy is not a priority. Alternatively, it maybe that a path from the host is duplicated elsewhere and redundancy is taken care of. For instance it’s not unusual to have two “management” interfaces for VMware High Availability – two provide two separate paths to validate the state of the cluster.

Mode 3: Teamed Standard vSwitch

In this case more than one physical vmnic is mapped to the Standard vSwitch. With this configuration all communication passing through the vSwitch is load-balanced and offers network redundancy. This a common configuration for traffic that needs to be highly redundant. For instance IP Storage such as NFS and iSCSI could be backed by vSwitch backed with multiple NIC to boost throughput and ensure the if a network card or physical switch, there would be an available path to the storage.

Types of Communication

Host Communication Every Standard vSwitch has portgroups as sub-component. Portgroups can be of a “vmkernel” type and hold an IP configuration (IP/Subnet Mask/Gateway). These can be enabled for different traffic including vMotion, Management and Fault-Tolerence as well as used to connect to IP storage. Portgroups supports a VLAN configuration using the 803.3q VLAN Tagging standard. As ethernet frames leave the ESX hosts, additional bytes are added to the header. This includes part that indicates the ethernet is tagged, and the VLAN ID itself.

Virtual Machine Communication Portgroups are used for virtual machine communication. When a VM is created it is patched to a portgroup on the vSwitch. Again, VLAN Tagging is supported and the VM and the guest operating system within uses the inherent load-balancing and redundancy – for this reason there is no need to configure VLAN information within the operating system, or any need to install special vendor drivers to support network teaming.

Typical Standard vSwitch Configurations

For a physical server with many network cards, it is feasible to create a Standard vSwitch for each type of traffic. This guarantees that bandwidth is dedicated to that function, and its very clear where the traffic is following. This possible with rack mounted equipment fitted with quad-port cards, or blade architectures that allow for I/0 virtualization where the management layer allows for appearance of many network adapters.

vSwitch0/vmnic0 – Management vSwitch1/vmnic1/2 – IP Storage vSwitch2/vmnic3/4 – Fault Tolerance vSwitch3/vmnic5 – vMotion vSwitch4/vmnic6 – High Availability Heartbeat vSwitch5/vmnic7/8 – Virtual Machines traffic with multiple portgroups for multiple VLANS

Typically, a host maybe more limited when it comes to the number of physical NICs

The next part of the blog takes you through a couple of typical examples of creating Standard vSwitches – including an internal vSwitch, Basic vSwitch, NIC-Teamed vSwitch, and vSwitch configuration specifically designed for meeting the requirements for load-balancing iSCSI traffic with VMware ESX own iSCSI Software Initiator.

Creating Standard vSwitch (Web-Client)

Creating an Internal Standard vSwitch

1. Open the web-client and navigate to >Host and Clusters >Select the vCenter >Select the Datacenter > Select an ESX host

2. Select the Manage tab, and the Network column

3. Select the Virtual Switches option

4. Click the Add host networking icon

5. Select Virtual Machine Portgroup for a Standard Switch and click Next

6. Select New Standard Switch

Note: New Standard vSwitches are given a serial number vSwitch0, vSwitch1 and so on.

7. Click Next to bypass the mapping of physical NICs to the Standard Switch

Click OK to the warning that you have chosen not to select a physical network adapters

8. Type a friendly name for the Portgroup. In this case the VLAN value is irrelevant as there is no communication to the physical switch where VLANs are defined

IMPORTANT: Portgroup names are case-sensitive and should be consistent from one ESX host to another.

9. Click Next and Finish to create the Internal Standard vSwitch.

The new Standard vSwitch should appear in the web-client – along side the built-in vSwitch0 which is generated during the time of installation.

Creating an Basic Standard vSwitch

Creating a basic Standard vSwitch that just has one physical vmnic connecting it to the outside world, is very similar to creating an Internal Standard vSwitch – the only difference is that you add a NIC during the configuration.

1. Open the web-client and navigate to >Host and Clusters >Select the vCenter >Select the Datacenter > Select an ESX host

2. Select the Manage tab, and the Network column

3. Select the Virtual Switches option

4. Click the Add host networking icon

5. Select Virtual Machine Portgroup for a Standard Switch and click Next

6. Select New Standard Switch

Note: New Standard vSwitches are given a serial number vSwitch0, vSwitch1 and so on.

7. Select Active Adapters, and click the green + to add a physical vmnic to the vSwitch

The web-client should refresh to indicate your selection

8. Type a friendly label for the portgroup name

9. Click Next and Finish to complete the configuration

The new Standard vSwitch should appear in the web-client – along side the built-in vSwitch0 which is generated during the time of installation.

Creating an Teamed Standard vSwitch with VLAN Tagging

In this scenario we will create a Standard vSwitch that supports multiple physical vmnic interfaces, as well as multiple tagged VLAN configurations.

1. Open the web-client and navigate to >Host and Clusters >Select the vCenter >Select the Datacenter > Select an ESX host

2. Select the Manage tab, and the Network column

3. Select the Virtual Switches option

4. Click the Add host networking icon

5. Select Virtual Machine Portgroup for a Standard Switch and click Next

6. Select New Standard Switch

Note: New Standard vSwitches are given a serial number vSwitch0, vSwitch1 and so on.

7. Select Active Adapters, and click the green + to add a physical vmnic to the vSwitch. Merely the act adding additional NICs enables load-balancing and redundancy.

8. Type a friendly label for the portgroup name, as well as the VLAN number

9. Click Next and Finish to complete the configuration

To configure additional VLANs we merely add additional portgroups to the same Standard vSwitch

10. Click the Add host networking icon

11. Select Virtual Machine Portgroup for a Standard Switch and click Next

12. Select the existing vSwitch that will host the new portgroup.

13. Click Next and Finish to complete the configuration

This workflow can be repeated for as many VLANs as need to be configured. Below vSwitch3 has three portgroups each configured for VLAN-tagging for VLAN 12, 13, and 14.

Creating an Teamed Standard vSwitch for Load-Balanced iSCSI communications

Note: In this tutorial the ESX host had insufficient NIC to create yet another Standard vSwitch to ensure the storage traffic existed on dedicated physical NICs separate from all other traffic. A compromised was reach by removing the previous examples, and mapping both vmnic0 and vmnic1 to built-in Standard vSwitch. This configuration will leave behind vmnic2/vmnic3 for use with Distributed vSwitches. This configuration change was made by selecting vSwitch0 in the web-client and clicking the “Manage the physical adapters connected to the selected switch”, and using the green + button to adding vmnic1.

VMware ESX ships with a built-in iSCSI Software Initiator used for making connections to iSCSI Storage Arrays. It supports a load-balanced configuration where two “vmkernel” ports each with their own IP configuration and fixed to separate physical NICs. As such its good example of both creating vmkernel ports, and also using the advanced functionality of the Standard vSwitch to achieve optimal performance. There two possible configurations

Option 1:

• Two Standard vSwitches with one physical vmnic each
• vmkernel portgroup on each vSwitch, with a valid IP address for the iSCSI Target

Option 2:

• One Standard vSwitch with two physical vmnics assigned
• Two vmkernel portgroups on the Standard vSwitch
• Portgroup1 would use vmnic0 as “Active” and vmnic1 as “Not in Use”
• Porgroup2 would use vmnic1 as “Active” and vmnic0 as “Not in Use”

It this second configuration that we will show here.

Step One: Create the VMkernel Portgroups

1. Select vSwitch0, and click the Add Host Networking button

2. Select VMkernel Network Adapter as the portgroup type

3. Ensure that vSwitch0 is the existing standard vSwitch

4. In the connection settings type a friendly portgroup name, and if required a VLAN tag value. In this case no special services are required

5. In most case organizations prefer a static IP configuration for something as critical as the hosts access to storage

6. Click Next and Finish.

Note: Repeat steps 1 to 6, this type specifying a different IP address for the second portgroup. This should give the Standard vSwitch two portgroups with two vmkernal ports calledd IPstorage1 and IPstorage2 each with vmkernel adatper identity of vmk1 and vmk2, with vmk0 being used as the management IP configuration.

Step Two: Reconfigure the Network Adapter Teaming on the Portgroups

Next we need to adjust the way the physical NICs are utlized on the portgroups. This is a good illustration of how flexible networking is in vSphere. Not only can we have generic teaming settings on the Standard vSwitch we can have settings which are specific to portgroups as well.

1. Select the portgroup link in the web-client, and click the Edit Setting button

2. Select the Teaming and Failover option

3. Enable the option to X Overide the default settings of the Standard vSwitch

4. Use the downward arrow to move vmnic1 to the Unused Adapters location

5. Click OK to confirm your changes

Note: Repeat steps 1 to 5 to reconfigure the second portgroup (in this case IPstorage2/vmk1) with inverse network adapter configuration with vmnic1 being active and vmnic0 set to be an “Unused Adapter”

Note: You can confirm your configuration by using the small (i) icon on the properties of a portgroup, rather opening the edit settings dialog every time…