In ESX 4, we released VMXNET 3 as another high performance paravirtualized adapter for use with VMs. This increases the choices …or perhaps the level of confusion. Which adapter do you choose?

Fortunately, there is help at hand. One of our engineers recently updated a knowledge base (KB) article on this very topic. You can see the full text at the site (KB #1001805), but I’ve copied the meat of it here…

The adapter choices are as follows …

  • Vlance — An emulated version of the AMD 79C970 PCnet32 LANCE NIC, an older 10 Mbps NIC with drivers available in most 32-bit guest operating systems except Windows Vista and later. A virtual machine configured with this network adapter can use its network immediately.
  • VMXNET — The VMXNET virtual network adapter has no physical counterpart. VMXNET is optimized for performance in a virtual machine. Because operating system vendors do not provide built-in drivers for this card, you must install VMware Tools to have a driver for the VMXNET network adapter available.
  • Flexible — The Flexible network adapter identifies itself as a Vlance adapter when a virtual machine boots, but initializes itself and functions as either a Vlance or a VMXNET adapter, depending on which driver initializes it. With VMware Tools installed, the VMXNET driver changes the Vlance adapter to the higher performance VMXNET adapter.
  • E1000 — An emulated version of the Intel 82545EM Gigabit Ethernet NIC, with drivers available in most newer guest operating systems, including Windows XP and later and Linux versions 2.4.19 and later.
  • VMXNET 2 (Enhanced) — The VMXNET 2 adapter is based on the VMXNET adapter but provides some high-performance features commonly used on modern networks, such as jumbo frames and hardware offloads. This virtual network adapter is available only for some guest operating systems on ESX/ESXi 3.5 and later.
    VMXNET 2 is supported only for a limited set of guest operating systems:
    • 32- and 64-bit versions of Microsoft Windows 2003 (Enterprise and Datacenter Editions). You can use enhanced VMXNET adapters with other versions of the Microsoft Windows 2003 operating system, but a workaround is required to enable the option in the VI Client or vSphere Client. See if Enhanced vmxnet is not offered as an option.
    • 32-bit version of Microsoft Windows XP Professional
    • 32- and 64-bit versions of Red Hat Enterprise Linux 5.0
    • 32- and 64-bit versions of SUSE Linux Enterprise Server 10
    • 64-bit versions of Red Hat Enterprise Linux 4.0
    • 64-bit versions of Ubuntu Linux
  • VMXNET 3 — The VMXNET 3 adapter is the next generation of a paravirtualized NIC designed for performance, and is not related to VMXNET or VMXNET 2. It offers all the features available in VMXNET 2, and adds several new features like multiqueue support (also known as Receive Side Scaling in Windows), IPv6 offloads, and MSI/MSI-X interrupt delivery. 
    VMXNET 3 is supported only for virtual machines version 7 and later, with a limited set of guest operating systems:
    • 32- and 64-bit versions of Microsoft Windows XP and later
    • 32- and 64-bit versions of Red Hat Enterprise Linux 5.0 and later
    • 32- and 64-bit versions of SUSE Linux Enterprise Server 10 and later
    • 32- and 64-bit versions of Asianux 3 and later
    • 32- and 64-bit versions of Debian 4/Ubuntu and later
    • 32/64-bit versions of Sun Solaris 10 U4 and later

VM Upgrades … 

Now, a word about upgrades… if you upgrade a VM to Version 7 hardware support (to take advantage of VMXNET3), it’s a one-way upgrade. i.e. you cannot go back.

Scott Lowe posted some good information about the virtual machine upgrade process on his blog. It’s worth a look

David Oslager, from our own field, added some great info about capturing the interface information from a Windows VM for later reapplication after the upgrade. This is his process…

As per Scott’s blog, you have to save the IP info from the old NIC and replace the IP info on the “new” VMXNET 3 adapter.

Dump the IP info to a text file and then reapply it on Windows

To dump the IP config using netsh from a command line:

netsh interface ip dump > c:ipconfig.txt

Since Windows will most likely see the new NIC as “Local Area Connection 2” (or something similar) you have to modify the above text file and change the NIC name to match the new NIC’s name. Or change the new NIC’s name on the host to match what’s in the file above. Either way works.

To re-import it:

netsh -c interface –f c:ipconfig.txt

This really comes in handy when you have a lot of DNS servers, WINS servers, etc and/or multiple IPs on the same NIC.