Creating a virtual standard switch (vSS) using the esxcli namespace

In order to create a virtual standard switch (vSS) we can use the vSphere Web Client or alternatively we can use the esxcli namespace to achieve this. In this example I will create a single vSS by connecting to the console session of an ESXi host with the following requirements:

  • Create a vSS named vSwitch1 with 128 configured ports
  • Allow the vSS to enter promiscuousĀ mode.
  • Add uplink vmnic1
  • Add the portgroup ‘Test’ with a VLAN id of ’10’.

Firstly, we will create the vSS named ‘vSwitch 1′ with a total of ‘128′ ports and allow the vSS to enter promiscuousĀ mode.

esxcli network vswitch standard add -P 128 -v vSwitch1
esxcli network vswitch standard policy security set -p true -v vSwitch1

Now we will add the uplink ‘vmnic1‘ to the vSS.

esxcli network vswitch standard uplink add -u vmnic1 -v vSwitch1

Finally we will create a port group named ‘Test‘ and set a VLAN id of ‘10‘ for the vSS.

esxcli network vswitch standard portgroup add -p Test -v vSwitch1
esxcli network vswitch standard portgroup set -p Test -v 10

We can view the vSS we have just created by invoking ‘esxcli network vswitch standard list -v vSwitch1‘ and confirm the security policy configuration by invoking ‘esxcli network vswitch standard policy security get -v vSwitch1‘.

vSwitch1
 Name: vSwitch1
 Class: etherswitch
 Num Ports: 1536
 Used Ports: 1
 Configured Ports: 128
 MTU: 1500
 CDP Status: listen
 Beacon Enabled: false
 Beacon Interval: 1
 Beacon Threshold: 3
 Beacon Required By:
 Uplinks: vmnic1 
 Portgroups: Test
 Allow Promiscuous: true
 Allow MAC Address Change: true
 Allow Forged Transmits: true

Using the Vyatta virtual appliance in an isolated DR environment…

I was recently tasked with creating an isolated DR environment for the purpose of testing. The isolated environment in this instance was a single ESXi host with a virtual switch with no attached uplinks.

The objective of the DR test was toĀ fail overĀ to replicated virtual machines (using vRanger Pro) which existed in DMZ and internal networks and to be able to route traffic between hosts on those networks.

In order to achieve this I downloaded the virtual appliance Vyatta VC 6.0 (Final) from the Virtual Appliance (VA) marketplace (https://solutionexchange.vmware.com/store/category_groups/19).

Once the VA had been downloaded and imported to vCenter, I then configured the appliance as per my environment, excellent videos may be found here to help you along;

http://www.youtube.com/watch?v=ru6xwEg5Tlw

http://vimeo.com/10897479

Once installed and configured, I was able to communicate with hosts in the DMZ and Internal networks. However, I did seem to experience issues with network performance with virtual machines configured with the VMXNET3 virtual adapter. This is where I found the following article which explains an issue with Large Receive Offload (LRO) and the version of VMware Tools intergrated with the appliance.

There is a solution to this and a version of the VA available with integrates the latest version of VMware Tools with VA to resolve this issue. The updated VA and further information areĀ availableĀ from;

http://roggyblog.blogspot.com/2010/07/vyatta-final-60-with-updated-vmtools.html

I can confirm that the above resolved all my issues with network performance when using VMNEXT3 apadter within a virtual machine.

More information on LRO can be found at:

http://en.wikipedia.org/wiki/Large_receive_offload

http://lwn.net/Articles/243949/

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1027511