2009 
   

Standard vSwitch 
setup 
Creating a Super vSwitch 
 
In this document we examine different strategies for setting a vSwitch up with 
multiple NIC’s to achieve optimum load balancing and best failover detection. 
 

John Borhek 
VMsources 
10/9/2009 
 October 9, 2009  [STANDARD VSWITCH SETUP] 
 
Standard vSwitch Configuration 
Figure 1 demonstrates a fairly standard vSwitch setup. It is, in fact, based on VMware documentation, except we have 
chosen to start with a minimum of six NIC’s as a more realistic production norm.

 
Figure 1 

Figure 1 accomplishes all of the recommended minimum thresholds for virtual networking: 

 Management Network and Service Console separation from production VM Networking 
 Gigabit on all uplinks (NIC’s) 
 Redundancy for all vSwitches 
 Additional Service Console redundancy 

There are, however, numerous ways to improve the reliability and throughput of our production Port Groups and 
Vmkernel connection without adding additional NIC’s. 

PCI Device Redundancy 
The first recommendation is to make sure that no one vSwitch is operating on a single PCI adapter (no matter how many 
NIC’s or ports that adapter has) In many server configurations with 6 NIC’s total, there will be 2 ports onboard and 4 
ports on a single add‐on PCI device. Since there will only be 2 PCI devices in total, make sure that the Service Console is 

2  Standard vSwitch Configuration | VMsources 
 
 [STANDARD VSWITCH SETUP] October 9, 2009 
 
served with one of the onboard Ethernet ports and at least one add‐ins so that it cannot be wiped out by a single PCI 
device failure. Use the second onboard Ethernet port to ensure PCI device redundancy for one of the other vSwitches. 
Figures 2 and 3 demonstrate how to determine PCI bus location. 

   
Figure 2 

 
Figure 3 

The Super vSwitch 
In the examples, we assume a total of 6 NIC’s on at least 2 PCI adapters. While the example in Figure 1 does satisfy 
minimum requirements for redundancy, it does not allow much room for load balancing. Furthermore, when all NIC’s 
are active in three teams (2 NIC’s per team), as represented in Figure 4,  failover detection can be accomplished only 

VMsources | The Super vSwitch  3 
 
 October 9, 2009  [STANDARD VSWITCH SETUP] 
 
with the default policy “Link Status only” because the alternate Failover Detection Policy “Beacon Probing” requires at 
least three NIC’s in a team to function correctly. Because Beacon Probing uses broadcast packets transmitted and 
received by each NIC associated with a vSwitch, with fewer than three NIC’s, it is impossible to determine if a packet is 
making a round‐trip or merely being transmitted and received by the same NIC. 

 
Figure 4 

One way to achieve both more flexibility in load balancing and be able to opt for the preferred failover detection 
method is to create a “Super vSwitch.” A Super vSwitch relies on VLAN’s to separate traffic over the wire to trunked 
ports on a managed switch elsewhere. By using VLAN’s, we can combine multiple vSwitches together, maintain security, 
improve failover detection and increase load balancing potential.  

In the examples below, Figure 5 represents a “traditional” use of 6 NIC’s. The vSwitch0, with no VLAN assigned is an “air 
gap” network. vSwitch1 and vSwitch2 already use VLAN’s to segregate network traffic, so when we combine the Port 
Groups Service Console 2 (VLAN 10) and VMkernel (VLAN 10) with Production Public (VLAN 30) and Production Private 
(VLAN 40), we can re‐distribute the available NIC’s however we see fit. 

4  The Super vSwitch | VMsources 
 
 [STANDARD VSWITCH SETUP] October 9, 2009 
 

 
Figure 5 

In Figure 6, we have chosen to distribute the NIC’s with three for each remaining vSwitch, thereby allowing us to select 
Beacon Probing as our failover detection method on both vSwitches (Figure 7). In Figure 6  vmnic0 and vmnic1 are the 
onboard Broadcom NIC’s and vmnic2 thru vmnic5 are an Intel add‐on PCI device. Notice that we have assigned one 
onboard and two add‐on NIC’s to each vSwitch, preventing any one PCI device failure from taking either of the vSwitches 
down.  

VMsources | The Super vSwitch  5 
 
 October 9, 2009  [STANDARD VSWITCH SETUP] 
 

 
Figure 6 

 
Figure 7 

Given that vSwitch0 is likely to have very little traffic overall, and that we have a redundant Service Console anyway, 
splitting our NIC’s three and three may not be the best overall use of resources. With a redundant Service Console, two 
NIC’s for vSwitch0 and four for vSwitch1 ought to exceed all the recommendations for standard vSwitch configuration: 

6  The Super vSwitch | VMsources 
 
 [STANDARD VSWITCH SETUP] October 9, 2009 
 
 Redundant NIC’s for each vSwitch 
 Redundant Service Console connection 
 Adequate bandwidth 
 Separation of Service Console and Virtual Machine networking 

While providing increased bandwidth availability for the VMkernel Port Group and the Virtual Machine port Groups. 

 
Figure 8 

 
 

VMsources | The Super vSwitch  7 
 
 October 9, 2009  [STANDARD VSWITCH SETUP] 
 

8  The Super vSwitch | VMsources 
 
 [STANDARD VSWITCH SETUP] October 9, 2009 
 

VMsources | The Super vSwitch  9