Image result for Your lab needs you

This Knowledge Base article has been updated so much.

But I wanted to share something with you guys that slipped through the net in my home lab. I recently created a new Windows 2016 template for my lab for ease of distribution, normal process and easy process to get one of these created. Once created I started deploying some new boxes around the lab to start the transition away from Windows 2012 R2 and onto the new shiny 2016 boxes.

It wasn’t until a week or so later after all backup jobs had been configured and working that I thought the throughput was looking a little low, in fact very low. But this wasn’t the case on all the VMs. I checked around and the last thing I checked was the network adapters in my nice new shiny 2016 VMs… set to E1000e.

E1000: An emulated version of the Intel 82545EM Gigabit Ethernet NIC. A driver for this NIC is not included with all guest operating systems. Typically, Linux versions 2.4.19 and later, Windows XP Professional x64 Edition and later, and Windows Server 2003 (32-bit) and later include the E1000 driver.

E1000e: This feature emulates a newer model of Intel Gigabit NIC (number 82574) in the virtual hardware. This is known as the “e1000e” vNIC. e1000e is available only on hardware version 8 (and newer) virtual machines in vSphere 5. It is the default vNIC for Windows 8 and newer (Windows) guest operating systems. For Linux guests, e1000e is not available from the UI (e1000, flexible vmxnet, enhanced vmxnet, and vmxnet3 are available for Linux). Always the default but not the preferred.

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. For information about the performance of VMXNET 3, see Performance Evaluation of VMXNET3 Virtual Network Device. Because operating system vendors do not provide built-in drivers for this card, you must install VMware Tools or open-vm-tools to have a driver for the VMXNET 3 network adapter available. This is always the preferred but not default.

Once I had found my mistake I decided I wonder how many people still have this issue? Comments below, don’t worry the first road to recovery is the admitting you have a problem.

Well if you need to change it then look no further here is some powershell to make it happen.

First you can find all VMs that are not using the VMXNET3 adapters by running this:

Get-VM | Get-NetworkAdapter | Where-object {$_.Type -ne "Vmxnet3"} | foreach ($_) {Write-Host $_.Parent.Name "("$_.Name") type:" $_.Type}

Apparently RVtools can also tell you this information. I have quite a small home lab so I was able to get by with the little powershell knowledge that I have and a little research.

Now we know the VMs that are suffering, but before we go and get these sorted please make sure you take a backup. You know Veeam have a free product that can make that happen for you –

As this process is taking the network adapter from the virtual machine and putting a new one in Windows generally doesn’t keep the configuration and settings so it is advised if you are using static IP addressing in your environment that you take note of all IP address configuration. You can do that by running the below script to capture IP addresses.

Get-VM | Select Name, @{N="IP Address";E={@($_.guest.IPAddress[0])}}

Once you have your roll back plan in the form of a backup it is then time to make some changes.

Then by taking that list you can then perform the following set of commands if the VM is powered off then the first two lines are required if you do need to power down then all the script is then required.

*NOTE that this script will preserve the MAC address of the adapter it will not preserve the IP address within the VMs

get-vm view01 | Get-NetworkAdapter
get-vm view01 | Get-NetworkAdapter | set-networkadapter -type vmxnet3 -confirm:$false
stop-vm -vm view01
get-vm view01 | Get-NetworkAdapter | set-networkadapter -type vmxnet3 -confirm:$false
Start-VM -vm view01

If you are a VMware Orchestrator user then this workflow may also be of interest, over at Jeff Greens site he has detailed the workflow steps to make this an even easier configuration change.

This isn’t a new problem and I am sure I stumbled across this problem back in 2012 at a customer site or something like that. If I can help one person then it was worth putting all of this together. Any comments please share below.

Leave a Reply

Your email address will not be published. Required fields are marked *