Upgrade e1000 to vmxnet3

Folks, I have about 200 VM's that need their NIC's upgraded. Keeping in mind the number of VM's that need to be worked on, what's the best way to do this job? Removing the old NIC, adding the new one and configuring it is the only way to go or is there a line I can inject into the VM's .vmx files? Anyone have any tricks? Methinks I'm in for a long, repetitive task...

EDIT: Okay, I found out that I need to upgrade the disk controller drivers too on all VM's! These are mostly 2008 R2 VM's, some Windows 7 and a few Linux ones.

Find more posts tagged with

Comments

QHalo

Here's a link to a powercli script that will do it. My guess is with a little tweaking and pulling together of scripts you could do an entire list. You're going to have to power them down as well to make the change.

Robert's Blog » PowerCLI

jibbajabba

Essendon wrote: »

Folks, I have about 200 VM's that need their NIC's upgraded. Keeping in mind the number of VM's that need to be worked on, what's the best way to do this job? Removing the old NIC, adding the new one and configuring it is the only way to go or is there a line I can inject into the VM's .vmx files? Anyone have any tricks? Methinks I'm in for a long, repetitive task...

EDIT: Okay, I found out that I need to upgrade the disk controller drivers too on all VM's! These are mostly 2008 R2 VM's, some Windows 7 and a few Linux ones.

Personally I'd just take the hit and take it one by one .. I had the fun once myself and there is ALWAYS something going wrong with one or another VM. I had to upgrade the e1000 to vmnx3 myself - some windows server needed VMWare Tools reinstalled for the driver to be applied. Or at least manually added via the device manager (c:\program files\common files\vmware\driver etc.). On Linux you likely end up with new nic scripts (ifcfg-eth0 becomes ifcfg-eth0.bak) and you have to change them again manually. You also likely to have to re-run the vmware tools configure script to make sure the proper kernel module is loaded.

On Windows Server you can sometimes end up with Ghost Nics when you remove / upgrade the old nics.

If you do all this automated and you run into multiple (vm) issues, you might end up with more than just one guy screaming at you that the server is down.

As for storage controller - easy on Linux - you shut down, change controller to whatever you need and boot up. Windows isn't so forgiving, which however depends on the new controller to be used. I just take a guess here - if you are using the paravirtualized one then Windows would require a driver which isn't included in the OS.

You are likely end up with Bluescreens unless you make sure the driver are part of the OS - best way to do this is adding an additional storage controller, install the driver, **** down and swap the main controller over.

As always - test it .. I'd just grab a clone of a VM in question (obviously make sure the NICs are disabled) and see what happens so your backside is covered, but even more importantly you see what IS actually required so you can do the proper ones quickly.

jibbajabba

jibbajabba wrote: »

install the driver, **** down and swap the main controller over.

Err whoops ...

odysseyelite

I tried doing this with powercli in the past. The problem was it destroyed the e1000 nic and created a new nic. The IP did not save, and the Mac addresses changed. If anyone comes up with a solution, I'd like to hear about it.

scott28tt

It's no surprise the MAC address would change, it's a whole new NIC.

Essendon

I'll try a bunch of VM's in my test lab first with the script. I've asked some of my team to help out with the upgrade, they seem willing and this may not be a huge task after all if everyone agrees to do 40 odd VM's each. I'll post back on how I go. Thank you for the info gents, much appreciated!

astorrs

You can do the same thing for the disk controllers on the VMs using Get-/Set-ScsiController in place of Get-/Set-NetworkAdapter in the previously linked article.

kgottleib

Check it out: #Get-VM -location $MeditechCluster | get-networkAdapter | Where { $_.Type -eq "e1000"} | set-NetworkAdapter -Type "vmxnet3" -NetworkName $VMNetworkName. This is the script I used to swap out the adapters, and did it live without any downtime. I tested this out again and again, and it never failed, never created a new adapter with a new connection #, and never reverted the IP to DHCP. However, when I ran this script live at a customer site, it created issues days later according to the customer. customer reported that there were 2 adapters instead of 1, and that the e1000 still had the IP while the new vmxnet3 was DHCP. I am going to continue testing till I solve this issue once and for all.

ja_panynj

I also have a large amount of machines to migrate the vNIC to VMXNET3 from older versions...
I tried the above command and it worked great, except it didnt update the hardware inside the OS. I tried a re-scan in the device manager, but no luck.

Is there an additional command to make sure this hardware change gets followed through into the Guest OS?

higherho

Hello all,

I did not want to creat eanother thread for this issue but in my test enviroment. I removed the VMXNet3 adapter on one of my VM's and wanted to use the e1000 instead (Red hat linux guest OS). Now of course eth0 doesn't work and I was curious what extra steps are needed within the guest OS or something I missed to complete to bring up the adapter? I checked eth0's configuration on the linux OS and everything seems to be fine. Thoughts?

QHalo

Try reinstalling VMware tools.

MentholMoose

higherho wrote: »

Hello all,

I did not want to creat eanother thread for this issue but in my test enviroment. I removed the VMXNet3 adapter on one of my VM's and wanted to use the e1000 instead (Red hat linux guest OS). Now of course eth0 doesn't work and I was curious what extra steps are needed within the guest OS or something I missed to complete to bring up the adapter? I checked eth0's configuration on the linux OS and everything seems to be fine. Thoughts?

Is the new NIC actually detected as eth0? It is probably eth1 so the eth0 configuration won't apply. You can update the configuration to point to eth1 instead of eth0, or wipe out the udev rules and reboot to get the new NIC detected as eth0 (but you may still need to update the eth0 config, e.g. change the MAC address).

higherho

Hi Menthol,

yes thats the first thing I did was edit the udev config and make sure eth0 was being reconized as the new NIC and then went back to if-cfgeth0 to make sure the HDWARR was also correct.