Life of a Geek Admin

The Daily adventures of a true geek administrator

Life of a Geek Admin - The Daily adventures of a true geek administrator

Optimal Network Adaptor Settings for VMXNET3 and Windows 2008 R2

There is an ongoing debate between many admins on what are the best settings for the VMXNET3 driver on Windows 2008 R2 settings and I suppose there will be many more. In this postI will attempt to point out some of the options and recommended settings for the VMXNET3 adaptor.

 Global Settings

Receive Side Scaling (RSS)

Receive-Side Scaling (RSS) resolves the single-processor bottleneck by allowing the receive side network load from a network adapter to be shared across multiple processors. RSS enables packet receive-processing to scale with the number of available processors. This allows the Windows Networking subsystem to take advantage of multi-core and many core processor architectures.

By default RSS is set to enabled. To disable RSS you must open a command prompt and type:

netsh int tcp set global rss=disabled

There is also a second RSS settings that is in the VMXNET3 adaptor properties under the Advanced tab, which is disabled by default. Enable it by selecting from the dropdown.

This is a beneficial setting if you have multiple vCPU’s on the server. If this is a single vCPU then you will receive no benefit.

If you have multiple vCPU’s it is recommended to have RSS enabled.

netsh int tcp set global rss=enabled

References

http://technet.microsoft.com/en-us/network/dd277646.aspx

TCP Chimney Offload

TCP Chimney Offload is a networking technology that helps transfer the workload from the CPU to a network adapter during network data transfer. In Windows Server 2008, TCP Chimney Offload enables the Windows networking subsystem to offload the processing of a TCP/IP connection to a network adapter that includes special support for TCP/IP offload processing.

For VMXNET3 on ESXi 4.x, 5.0 and 5.1 TCP Chimney Offload is not supported; turning this off or on has no affect. This is discussed in several places.

References

http://www-01.ibm.com/support/docview.wss?uid=isg3T1012648

http://support.microsoft.com/kb/951037

The Microsoft KB951037 article is of interest because it includes a table that shows how TCP Chimney interacts with programs and services and gives insight to where you can gain the most from this feature. By default this setting is enabled.

As for the use of TCP Chimney Offload is to disable as it is not recognized by VMXNET3. To disable do the following.

Open a command prompt with administrative credentials.

At the command prompt, type the following command, and then press ENTER:

netsh int tcp set global chimney=disabled

To validate or view TCP Chimney

netsh int tcp show global

Recommended setting: disabled

 NetDMA State

NetDMA provides operating system support for direct memory access (DMA) offload. TCP/IP uses NetDMA to relieve the CPU from copying received data into application buffers, reducing CPU load.

Requirements for NetDMA

  • NetDMA must be enabled in BIOS
  • CPU must support Intel I/O Acceleration Technology (I/OAT)

You cannot use TCP Chimney Offload and NetDMA together.

Recommended setting: disabled

TCP Receive Windows Auto-Tuning Level

This feature determines the optimal receive window size by measuring the BDP and the application retrieve rate and adapting the window size for ongoing transmission path and application conditions.

Receive Window Auto-Tuning enables TCP window scaling by default, allowing up to a 16MB maximum receive window size. As the data flows over the connection, it monitors the connection, measures its current BDP and application retrieve rate, and adjusts the receive window size to optimize throughput. This replaces the TCPWindowSize registry value.

Receive Window Auto-Tuning has a number of benefits. It automatically determines the optimal receive window size on a per-connection basis. In Windows XP, the TCPWindowSize registry value applies to all connections. Applications no longer need to specify TCP window sizes through Windows Sockets options. And IT administrators no longer need to manually configure a TCP receive window size for specific computers.

By default this setting is enabled, to disable it open a command prompt with administrative permission and type:

netsh int tcp set global autotuninglevel=disabled

Recommended setting: disabled

References

http://technet.microsoft.com/en-us/magazine/2007.01.cableguy.aspx

Add-On Congestion Control Provider

The traditional slow-start and congestion avoidance algorithms in TCP help avoid network congestion by gradually increasing the TCP window at the beginning of transfers until the TCP Receive Window boundary is reached, or packet loss occurs. For broadband internet connections that combine high TCP Window with higher latency (high BDP), these algorithms do not increase the TCP windows fast enough to fully utilize the bandwidth of the connection.

Compound TCP, CTCP increases the TCP send window more aggressively for broadband connections (with large RWIN and BDP). CTCP attempts to maximize throughput by monitoring delay variations and packet loss. It also ensures that its behavior does not impact other TCP connections negatively.

By default, it is on by default under Server 2008. Turning this option on can significantly increase throughput and packet loss recovery.

To enable CTCP, in elevated command prompt type:

netsh int tcp set global congestionprovider=ctcp

To disable CTCP:

netsh int tcp set global congestionprovider=none

Possible options are:  ctcp, none, default (restores the system default value).

Recommended setting: ctcp

ECN Capability

ECN (Explicit Congestion Notification) is a mechanism that provides routers with an alternate method of communicating network congestion. It is aimed to decrease retransmissions. In essence, ECN assumes that the cause of any packet loss is router congestion. It allows routers experiencing congestion to mark packets and allow clients to automatically lower their transfer rate to prevent further packet loss. Traditionally, TCP/IP networks signal congestion by dropping packets. When ECN is successfully negotiated, an ECN-aware router may set a bit in the IP header (in the DiffServ field) instead of dropping a packet in order to signal congestion. The receiver echoes the congestion indication to the sender, which must react as though a packet drop were detected.

ECN is disabled by default, as it is possible that it may cause problems with some outdated routers that drop packets with the ECN bit set, rather than ignoring the bit.

To change ECN, in elevated command prompt type:

netsh int tcp set global ecncapability=default

Possible settings are: enabled, disabled, default (restores the state to the system default).

The default state is: disabled

ECN is only effective in combination with AQM (Active Queue Management) router policy. It has more noticeable effect on performance with interactive connections and HTTP requests, in the presence of router congestion/packet loss. Its effect on bulk throughput with large TCP Window is less clear.

Currently, it is not recommended enabling this setting, as it has negative impact on throughput.

Recommended setting is disabled

netsh int tcp set global ecncapability=disabled

Direct Cache Access (DCA)

Direct Cache Access (DCA) allows a capable I/O device, such as a network controller, to deliver data directly into a CPU cache. The objective of DCA is to reduce memory latency and the memory bandwidth requirement in high bandwidth (Gigabit) environments. DCA requires support from the I/O device, system chipset, and CPUs.

To enable DCA:

netsh int tcp set global dca=enabled

Available states are: enabled, disabled.

Default state: disabled

Recommended setting is disabled

To disable DCA:

netsh int tcp set global dca=disable

These are just settings that I have used successfully in the VMware environment and work well. You can pick and choose the settings that work best for your environment.

How To Fix VMware Error IP address already assigned to another adapter

There has been times when you have deleted a NIC in VMware and to the eye it looks like it is gone but really it is still there and it rears it’s ugly head when you try to re-add it to a Windows VM. You will receive errors similar to the following.

The IP address XXX.XXX.XXX.XXX you have entered for this network adapter is 
already assigned to another adapter Name of adapter. Name of adapter is hidden 
from the network and Dial-up Connections folder because it is not physically in
 the computer or is a legacy adapter that is not working. If the same address is 
assigned to both adapters and they become active, only one of them will use this address. 
This may result in incorrect system configuration. Do you want to enter a different 
IP address for this adapter in the list of IP addresses in the advanced dialog box?

XXX.XXX.XXX.XXX is usually the IP address of the system you are working on. According to VMware support this error can occur also if

  • You have upgraded VMware virtual network adapters (for example, when you migrate a virtual machine from an older to a new version of VMware software).
  • You have added and removed network adapters multiple times.
  • You may see this if you recently performed a P2V and the resulting virtual machine still has the physical NICs and drivers for those NICs present. These ghost NICs have the old IP address and the virtual NIC cannot be assigned the same IP address.

This issue occurs if a network adapter with the same IP address is in the Windows registry but is hidden in the Device Manager (My Computer > Properties > Hardware > Device Manager). This hidden adapter is called a ghosted network adapter.

Using the Show hidden devices option in the Device Manager (View > Show hidden devices) does not always show the ghosted adapter to which that IP Address is assigned.

So how do we fix it? First make the ghosted network adapter visible in the Device Manager and uninstall the ghosted network adapter from the registry:

  1. Click Start > Run.
  2. Type cmd and press Enter.
  3. At the command prompt, run this command:
set devmgr_show_nonpresent_devices=1

Note: If this command does not work (a possibility in Windows Server 2000 and 2003), you may need to add the parameter to Windows and set its value:

a. Right-click the My Computer desktop icon and choose Properties.
b. Click the Advanced tab and select Environment Variables.
c.  In the System variables section, click New.
d.  Set the Variable name to devmgr_show_nonpresent_devices and set the Variable value to 1 to enable the parameter.
e.  Click OK to add the variable to Windows.

4. Start the Device Manager by running this command from the same command prompt:

start devmgmt.msc

5. Click View > Show Hidden Devices.
6. Expand the Network Adapters tree (click the plus sign next to the Network adapters entry).
7. Right-click the dimmed network adapter, then click Uninstall.
8. Once all of the grayed out NICs are uninstalled, assign the IP address to the virtual NIC.

Note: To assign the IP address to the virtual NIC on the command line, run the command:

netsh interface ip set address "Local Area Connection #" static IP_Address Subnet_Mask Default_Gateway

For example:

netsh interface ip set address "Local Area Connection 2" static 192.168.1.101 255.255.255.0 192.168.1.1

9. Close the Device Manager.

That should fix the issue stopping you from adding a new NIC in your VM.

Network performance with VMXNET3 on Windows Server 2008 R2

Recently we ran into issues when using the VMXNET3 driver and Windows Server 2008 R2, according to VMWare you may experience issues similar to:

•Poor performance
•Packet loss
•Network latency
•Slow data transfer

The issue may be caused by Windows TCP Stack offloading the usage of the network interface to the CPU.

To resolve this issue, disable the TCP Checksum Offload feature, as well enable  RSS on the VMXNET3 driver.
Open the command prompt as administrator and run these commands:

netsh int tcp set global chimney=Disabled
netsh int tcp set global autotuninglevel=Disabled
netsh int tcp set global congestionprovider=None
netsh int tcp set global ecncapability=Disabled
netsh int ip set global taskoffload=disabled
netsh int tcp set global timestamps=Disabled

To validate type:

netsh int tcp show global

Next we will need to turn on RSS feature on the VMXNET3 driver. To do this open the network connections and adapter settings. Open Control Panel > Network and Internet > Network Connections. Right click on your adapter and select properties.

vmxnet3_4

Click on the Advanced tab and scroll down to find the RSS setting, you will see by default it is set to disabled. Set the drop down to enabled and click ok to save the settings.

vmxnet3_3

 

If you find there is no change just reset to default.

To reset to default type:

netsh int tcp set global chimney=Enabled
netsh int tcp set global autotuninglevel=normal
netsh int tcp set global congestionprovider=ctcp
netsh int tcp set global ecncapability=Enabled
netsh int ip set global taskoffload=Enabled
netsh int tcp set global timestamps=Enabled

How to determine whether TCP Chimney Offload is working
When TCP Chimney Offload is enabled in the operating system and in the network adapter, the TCP/IP stack tries to offload suitable TCP connections to the network adapter. To find out which of the currently established TCP connections on the system are offloaded, follow these steps:

Use administrative credentials to open a command prompt.
Type the following command, and then press ENTER:

netstat –t

You receive output that resembles the following:

Active Connections
Proto  Local Address          Foreign Address        State           Offload State
TCP    127.0.0.1:52613        computer_name:52614    ESTABLISHED     InHost
TCP    192.168.1.103:52614    computer_name:52613    ESTABLISHED     Offloaded

In this output, the second connection is offloaded.

How to Install VMWare Workstation 8.0.4 on Fedora 17

Recently ran into an issue were I was receiving VMWare module compilation errors when installing VMWare Workstation 8.0.4. The error I was receiving was it couldn’t execute and find the kernel-headers which were installed but not where VMWare was looking for them.

Download and install latest licensed version 8.0.4 from http://www.vmware.com/support

$ chmod +x VMware-Workstation-Full-8.0.4-744019.x86_64.bundle
$ sudo ./VMware-Workstation-Full-8.0.4-744019.x86_64.bundle

Install needed modules for module compilation

$ sudo yum install automake autoconf gcc kernel-devel kernel-headers

Now to fix the compilation error. Thanks to Weltall’s Blog (http://weltall.heliohost.org/wordpress) we have a patch. Download and install patch for module compilation error from

http://weltall.heliohost.org/wordpress/2012/04/01/vmware-workstation-8-0-2player-4-0-2-and-7-1-x3-1-x-fix-for-linux-kernel-3-4-0/

Extract the tarball and edit patch-modules_3.4.0.sh

$ vi patch-modules_3.4.0.sh

We need to make the change because the script is looking for 8.0.2 and we have 8.0.4.

Change:

vmreqver=8.0.2
plreqver=4.0.2

to

vmreqver=8.0.4
plreqver=4.0.4

Run the patch as root

$ sudo ./patch-modules_3.4.0.sh

Now we are ready to fire up VMWare Workstation 8.0.4 and start virtualizing.

Updating VMWare ESXi Hypervisor 5

Recently I built a VMWare ESXi Hypervisor 5 server for testing and learning purposes. As a good admin you must always patch and VMWare is no exception.

First download and install VMWare vCLI from http://www.vmware.com/support/developer/vcli/. You must have an account on VMWare to download the products, the account is free. I will be using vCLI installed on Windows 7 x64 Professional, so the path maybe different on your installation.

Now Download the latest patch from http://www.vmware.com/patchmgr/findPatch.portal. The current patch is ESXi500-201204001.zip. Once you have downloaded the latest patch copy it to a datastore on the ESXi 5 server or a place the server to patch has access to, for this post I am using /vmfs/volumes1/datastore2/updates. Download the zip file and do not extract it. Open vCLI session.

First we need to see if the server needs to be in Maintenance Mode for the patch, issue the following command:

esxcli --server=192.168.1.80 --username=root software sources vib get -d /vmfs/volumes/datastore2/updates/ESXi500-201204001.zip | grep "Maintenance Mode Required: True"

If grep returns a True then lets put it in maintenance mode, issue the following command:

"C:\Program Files (x86)\VMware\VMware vSphere CLI\Perl\bin\perl" vicfg-hostops.pl --server 192.168.1.80 --operation enter

Verify the host is in maintenance mode,issue the following command:

"C:\Program Files (x86)\VMware\VMware vSphere CLI\Perl\bin\perl" vicfg-hostops.pl --server=192.168.1.80 --operation info

Verify what vib’s are installed, issue the following command:

esxcli --server=192.168.1.80 --username=root software vib list | more

To find out which VIBs are available in the depot (the downloaded .zip file), issue the following command:

esxcli --server=192.168.1.80 --username=root software sources vib list --depot=/vmfs/volumes/datastore2/updates/ESXi500-201204001.zip | more

To update the ESXi 5 host with the VIBs included in the depot, issue the following command:

esxcli --server=192.168.1.80 --username=root software vib update --depot=/vmfs/volumes/datastore2/updates/ESXi500-201204001.zip

When the update is complete, verify the information presented. If prompted, reboot the ESXi 5 host by issuing the following command:

"C:\Program Files (x86)\VMware\VMware vSphere CLI\Perl\bin\perl" vicfg-hostops.pl --server 192.168.1.80 --operation reboot

Verify the patch bundle was installed, by issuing the following command:

esxcli --server=192.168.1.80 --username=root software vib list | more

If applicable, take the ESXi 5 host out of maintenance mode using the vSphere Client or with the following command:

"C:\Program Files (x86)\VMware\VMware vSphere CLI\Perl\bin\perl" vicfg-hostops.pl --server 192.168.1.80 --operation exit

If the operation  exit command fails just open vSphere client and remove the server from Maintenance mode and un-pause the vm’s on the server.

Note: All of this can be done from a Linux system as well. VMWare provides a Linux vCLI download as well. The difference in the commands is that the perl preface used for Windows can be omitted as well as the .pl on the end of the command.

Installing and updating ESXi 5 VMtools with OSP

Recently I had the pleasure of building n ESXi Hypervisor 5 server. Server sprawl has taken over and the time has come to consolidate. The first VM’s to create are my web and database servers. After the build I was needing to install VMtools to get the full functionality on my CentOS / SL / RHEL 6 servers.

There are several ways to do this but a way to add a repo and have it install updates when I update the servers is a better way, so that lead me to OSP (Operating System Specific Packages).

Checking the internet I found Operating System Specific Packages pdf that describes the process here.

The process I used here is for CentOS 6.2 / RHEL 6.2 and SL (Scientific Linux) 6.2. First I downloaded and imported the RSA and DSA certificates.

# wget http://packages.vmware.com/tools/keys/VMWARE-PACKAGING-GPG-DSA-KEY.pub
# wget http://packages.vmware.com/tools/keys/VMWARE-PACKAGING-GPG-RSA-KEY.pub
# rpm --import VMWARE-PACKAGING-GPG-RSA-KEY.pub
# rpm --import VMWARE-PACKAGING-GPG-DSA-KEY.pub

Now lets create the repo file. Name it vmwaretools.repo in /etc/yum.repos.d directory with the following contents.

[vmware-tools]
name=VMware Tools
baseurl=http://packages.vmware.com/tools/esx/5.0/rhel6/x86_64
enabled=1
gpgcheck=1

Save the file and type:

# yum update

And let the repository populate the information you need. Now we need to install the correct tools. Since I am using ESXi Hypervisor 5 I am limited to 1 CPU so I really don’t need to look and see if I have PAE enabled kernels. If I did, we would need to check using uname -r and look for the PAE designation in the kernel release.

# yum install vmware-tools-esx-kmods vmware-tools-esx

Once the tools have been downloaded and installed all that is needed is a reboot.

 

 

Switch to our mobile site