e1000 vNIC’s Hate Me – How To Find And Change vNic Types With The VI ToolKit

Posted on by

Well, this being the third time I’m trying to write this post (some issues with my Wwindows 7 VM, something to be said for autosave).

VMware recently released a white paper showing a performance comparison between the e1000 and enhanced vmxnet drivers. In most cases the vmxnet driver outperformed and used less CPU overall than the e1000 vNIC. This isn’t the only reason to use it however. Remember a few weeks back, the PSOD we talked about? Do you? Here it is incase you need to read it again. Well in that situation, the hypervisor was taken out, due to a funky packet being sent and processed by the e1000 vNIC.

So how do we find these evil things? Using my favorite VI automation tool, the VI Toolkit for Windows! Hint: It’s a one liner:

get-vm | get-networkadapter |  where { $_.Type -like "e1000"}

So how do you change this? Well, doing that programmatically, that is to say, with the VI Toolkit, can get messy, lets take a look at the steps involved:

  1. Power down VM
  2. Add a new adapter of desired type (vmexnet)
  3. Remove old adapter
  4. Power VM on
  5. Assign IP’s as needed

Now, all of these can be done programmatically, but there are other things to consider here. You MAC address will change. Which means, any licensing based on MAC address, will break. Scheduling an outage across a few hundred VM’s belonging to different business units and customers will also not be pleasant. Further, what if the VM’s have more than 1 NIC?

6 thoughts on “e1000 vNIC’s Hate Me – How To Find And Change vNic Types With The VI ToolKit”

  • just having been assigned to the VM team in my organization, I'm finding your blog most informative, thanks!
    As to this problem; would not successive passes catch and change multiple nics were you to this programmatically using your search command as input? Not as elegant as a single-pass solution perhaps, but seems it would work logically.

  • I've sat and thought some more on it, and with the right amount of logic in the script, and using the Invoke-VM cmdlet to change the ip's within the VM's it could be done. Was just more than I could do in a single sitting. If there is some demand, I can spit one out however.

  • VM, stands for virtual machine ? isn't it… I could hardly keep up with his technical stuff, all I know is java has its own virtual machine, separate kernel over the kernel default.

Comments are closed.