Enabling Enhanced VMXNet

Monday, December 15, 2008 in Networking, Virtualization by slowe | 7 comments

I’ve been doing some additional digging into jumbo frames and other networking configurations, and along the way I came across references to VMware’s Enhanced VMXNet network adapters. These were apparently introduced in VMware ESX 3.5 and are necessary in order for virtual machines to take advantage of features like TCP Segmentation Offload (TSO) or jumbo frames.

The funny thing is this: even though the Enhanced VMXNet adapters are supported on both 32-bit and 64-bit versions of Windows Server 2003 and a few different flavors of Linux, the only way to be able to specify that you want to use an Enhanced VMXNet driver is if the virtual machine is configured as 64-bit Windows Server 2003 Enterprise Edition. This is outlined in this VMware KB article describing to how enable enhanced VMXNet drivers in Windows Server 2003.

Fortunately, there’s a way to also do this in the .VMX file. You’ll need to remove the VM from the VirtualCenter inventory (right-click, Remove From Inventory), then edit the .VMX file to add these entries:

ethernet0.virtualDev = "vmxnet"
ethernet0.features = “15″

Once these lines have been added—changing ethernet0 to ethernet1 or whatever the appropriate value is for the VM—you can use the Datastore Browser to add the VM back into the inventory. The NICs will now be listed as “Enhanced vmxnet”. In addition, Windows itself will now recognize greater offload functionality. The two screenshots below show the output of the command “netsh int ip show offload”; the first one is from a non-Enhanced VMXNet adapter:

Now for the output of the same command from a VM configured with an Enhanced VMXNet adapter:

This technique allows you to preserve the “integrity” of the guest OS selection by enabling Enhanced VMXNet without requiring users to change their guest OS selection to 64-bit Windows Server 2003 Enterprise Edition. Once the Enhanced VMXNet adapter is enabled, then users are free to begin working with jumbo frames and TSO. More on that in a future post…

UPDATE: I learned that in vCenter 2.5 Update 3, the option to select Enhanced VMXNet is now a selectable option for various flavors of Windows and Linux. I guess this information isn’t really needed any longer. Thanks for the information, Wade!

Tags: , , , ,

  1. Wade Holmes’s avatar

    Wade Holmes on Monday, December 15, 2008 at 6:35 pm

    Hi Scott,

    Enhanced VMXNet adapter is a vCenter selectable option for 32-bit Windows Server 2003 Enterprise Edition along with 64-bit. I have used it successfully to allow jumbo frames to 32-bit Windows 2003 Enterprise Edition VM’s.

  2. slowe’s avatar

    slowe on Monday, December 15, 2008 at 9:23 pm

    Wade,

    Thanks for the information. I’ve updated the post accordingly.

  3. NiTRo’s avatar

    NiTRo on Tuesday, December 30, 2008 at 12:33 pm

    Hi,

    Someone knows why Windows Server 2003 Enterprise Edition but not standard ?

  4. Randy Robertson’s avatar

    Randy Robertson on Saturday, January 31, 2009 at 5:39 am

    In response to the previous question, I believe it was just a matter of testing bandwidth. This should be rectified as of the latest shipping ESX3.5 updates. Advanced should be an option on all guest OSes where it would work, including Windows Server 2003 Standard.

  5. Tom’s avatar

    Tom on Thursday, March 19, 2009 at 3:27 pm

    I had to directly log in to the host via VIC to get it to let me specify enhanced vmxnet for Win2k3 Enterprise…using VIC via VC threw errors and would not let me create the VM…

  6. Tom’s avatar

    Tom on Friday, March 20, 2009 at 9:07 am

    I also discovered that this removed my existing network connection and created a new one which had to be re-configured. I know this is obvious to someone like you, but a note should be added just to be safe.

    Also for some reason after adding the vmxnet NIC I had problems with Outlook 2003 the next day.

  7. John’s avatar

    John on Friday, March 20, 2009 at 6:00 pm

    Another caveat: I also had the same problem with network connections being created, as well as: 1) the ‘old’ AMD NIC not being removed and requiring command-line configuration of Device Manager to remove the old NIC (later realized this could have been avoided by removing the NIC before taking it out of inventory but then I would not have been able to log on to it again); 2) creation of addtional IP addresses for the server(s) within DNS, causing all kinds of unexpected problems.
    Solution: This method can be used but you must plan for several extra steps and time for making sure the old NIC is removed and that your DNS doesn’t get mucked about with, you have to clean out any DNS entries that do not belong, also do this multiple times if you have more than 1 DNS server in your LAN.