Automated Migration to VMxNet3 Network Adapters and Paravirtual SCSI Controllers for vSphere 4.x Virtual Machines

Share Button

VMware vSphere 4.x was released for general availability nearly two years ago and now vSphere 5.x is rumored for release later this year. In June 2009, virtualization master Scott Lowe wrote a blog post illustrating the roughly 16 manual steps to upgrade virtual machines to VMxNet3 adapters and Paravirtual SCSI (PVSCSI) controllers. Interestingly, two years following I still encounter larger environments that are not fully taking advantage of the performance characteristics of these two virtual machine hardware types.

The reason is simple, this 16 step process can take up to 30 minutes of downtime per virtual machine if done manually, not to mention the inevitable human error. Unfortunately, what I have most frequently heard is that the time required to manually perform these virtual machine modifications enterprise-wide does not outweigh the advantages of utilizing VMxNet3 Adapters and PVSCSI Controllers. Instead, most larger environments update and implement these enhancements in their VM templates, but leave all other vSphere migrated/legacy virtual machines configured with either Flexible/E1000 NICs and/or LSI Logic Parallel SCSI/SAS Controllers.

What if we could change all that? What if this entire process could be automated, requiring less than 5 minutes of downtime for each virtual machine? What if we could cycle through all virtual machines in a given vCenter instance and automatically perform these modifications to all virtual machines? Two years after its release VMware certainly has not demonstrated an “Update Manager” migration approach for VMxNet3 and PVSCSI. Other scripts have attempted this in the past, but typically miss the bar when it comes to the Guest Operating System configuration. Most data center virtual machines have Static IP Addresses configured on the Virtual Machines and quite frankly, this can be a chore to remove and add network adapters, ensuring the correct settings are reconfigured for the new adapters.

The script provided in this post solves that problem by dynamically recording the static address and NIC configuration prior to removal, to ensure the original configuration is set on the new adapter. From a high-level, here are the processes performed by the script:

– Obtain a list of all virtual machines to process (Accepts * to process all machines within vCenter)
-Prompts for Guest Operating System credentials to use for all virtual machines
-Bypasses machines that are not online, VMware tools not up-to-date, VMware tools not running, or already have VMxNet3 & PVSCSI
-Obtain the current network configuration by invoking ipconfig /all
-Shutdown the virtual machine
-Upgrade the VM Hardware from Version 4 to Version 7
-Obtain the network name and remove the legacy (flexible/E100) adapter
-Add a VMxNet3 adapter on the same network as the legacy adapter (VM Network, etc)
-Add a temporary hard disk on a Paravirtual SCSI controller to install the PVSCSI drivers on boot
-Start the virtual machine
-Remove Hidden Devices utilizing DevCon.exe and automated RemoveHidden.bat file (Automated process for devmgr_show_nonpresent_devices)
-Use DevCon.exe to check for hardware changes
-Rename vmxnet3 network connection to Local Area Connection
-Apply original static ip address and network configuration to the new adapter
-Shutdown the virtual machine
-Remove the temporary hard disk and secondary PVSCSI controller
-Change the primary SCSI controller to Paravirtual
-Start the virtual machine
-Ensure the virtual machine boots with PVSCSI controller before moving forward
-Cycle through this process on the remaining virtual machines
Here is a screenshot of the output after running through this process from the beginning on a sample virtual machine:

– Only execute against virtual machines with static IP addresses configured. The current revision does not programatically determine if the NIC is set to DHCP and assumes all VMs have Static IP addresses. I intend to change this in future releases.
– Only execute against virtual machines with single NIC configurations and single SCSI controllers. The current revision does not address multi-homed systems or multiple SCSI controller configurations.
– Only execute against virtual machines with up-to-date VMware tools. Other scriptsare available to update VMware Tools using PowerCLI without a reboot. Outdated machines will be bypassed.
– Only execute locally from the virtual center server. For simplicity, in Revision 1 I intend for the script to be executed from the vCenter server locally. Therefore, the above components must be installed on the server locally.
– Test the script against test/dev VMs using the “comma-seperated virtual machines” option prior to running against “*” for all virtual machines within vCenter.

– PowerShell is installed on the Virtual Center server.  Execution policy has been set to Unrestricted for the Local Machine scope (Run PowerShell command “Set-ExecutionPolicy Unrestricted -scope LocalMachine”)
– PowerCLI version 4.1.1 is installed on the Virtual Center server obtained here
– The included script (AutomatedMigration.VMxNet3.Paravirtual.ps1)
– DevCon.exe included in the zip file or available from Devcon.exe for i386 must be placed in the same directory as the script.
– NVSPBind.exe included in this post or available from NVSPBind.exe for XP (Most stable for all operating systems and forward compatible) must be placed in the same directory as the script.
– Authentication credentials for the Guest Operating System of all virtual machines. Credentials will be requested once and used throughout the process for subsequent virtual machines.
– IMPORTANT: Outage windows have been scheduled and approved for virtual machines. Two reboots will be required in this process, so do not perform during production hours! 🙂

To execute, simply unzip all files and right click the Ps1 script and select “Run with PowerShell”.  Do not execute from an existing PowerShell or PowerCLI instance. All necessary components will load automatically when you select Run with PowerShell.

Please feel free to leave a comment if you have any special requests or would like to leave feedback on results in your environment! Now that I have the framework fully laid out, I fully intend to utilize these processes to enable automated upgrades to components available in the new release of vSphere 5. Check back often for new revisions and updates on this script.

Click here to download the current version (Rev.3) along with Devcon, Devcon64 and nvspbind: AutomatedMigration.VMxNet3.Paravirtual

Updates for Revision 2:

Per Johnny Stanko’s request I have added functionality to read in the current WINS server list and assign these addresses to the new VMxNet3 adapter. Additionally, I have added functionality to remove the IPv6 component, QoS Packet Scheduler component, Link-Layer Topology Discovery Mapper component, Link-Layer Topology Discovery Responder component and enable NetBIOS over TCP/IP. To configure any of these settings, modify the Rev2 PS1 script in Notepad and change any of the variables at the top to $true before executing the script. These features required an additional command-line configuration utility NVSPBind.exe (Included in the updated Zip file).  Here’s an updated screenshot of the script post-execution:

Updates for Revision 3:

Per Ryan’s request I have added functionality to check the Guest Operating System version prior to continuing. Processing will occur for the following “supported” operating systems:
– Windows Server 2003
– Windows Server 2008
– Windows Server 2008R2
– Windows XP
– Windows Vista
– Windows 7
All other operating system versions will report “Bypassing legacy or non-Windows virtual machine”.

Additionally, I have added functionality to support Devcon hidden device removal for 64-bit Operating Systems. Devcon64.exe is now included in the attached Zip file (Obtained from the Windows Driver Kit using the procedures documented here).  The attached Zip file also includes an updated version of Devcon.exe for 32-bit systems (6.1.7600).


Share Button
  1. BastiaanBastiaan01-17-2012


    Awesome script!

    But i too have the error: Method invocation failed because [System.Boolean] doesn’t contain a method name
    d ‘Trim’.

    And no mask, dns and wins are filled. Tested on windows 2003 R2.

  2. SwapnilSwapnil01-11-2012

    Hey. Thanks for providing such a great script to the world of VM users. I want to know if we can define list of VM’s on which we want to run this script instead of doing it on all VM’s. So that we can test it on 1 or few VM’s and then go ahead with prod environment.

    • youngtechyoungtech02-12-2012


      This is not a problem, you just enter the list seperated by commas after selecting not to process all VMs in vCenter. Let me know if this works for you. Thanks!

  3. amitjamitj01-10-2012

    First off, I am running PowerCLI v 5.01 on an ESXi 5.0 environment with a full Windows vCenter5 server.

    I ran into the same issue as Marshcroft in comment #24, getting the exact same errors. The DNS and WINS info was not displayed during the initial step, and therefore, did not populate after the adapter was changed. This occurred on a Windows 2003 VM.

    I tried it on a Windows 2008R2 VM and it failed to apply the static IP, giving it all DHCP instead. It did not get the aforementioned errors, however, and did display all of the correct IP information during the initial steps of the script, it just never applied any of them. It also left the IPv6 component active and did not remove the hidden network device.

    The hard disk controller change worked great for everything, which was fantastic.

    Another point that nobody has mentioned is that this process changes the MAC address for the adapter. If you have special applications that care about the MAC address (we have a credit card billing system that is fussy over this), then make sure you record the MAC prior to the update, and then manually apply it by running Edit Settings for the VM in the vCenter GUI.

    So, there are a few issues, probably related to ESXi 5 and PowerCLI 5. I’ll check back here for a new update if you happen to get around to it. Thanks for all of your efforts.

    • youngtechyoungtech02-12-2012


      These issues all sound related to UAC being enabled within the guest operating system. This is a terrible pain and I’m going to re-evaluate if I can pre/post disable re-enable UAC within the guest. Have you tried against a VM with UAC disabled?


  4. walispeedwalispeed01-05-2012

    Hi, thanks for the script.

    I’m facing to strange issue…. with vcenter 4.1 U1 no problem …

    We updated to vCenter 5 and I’m receiving each time an invalid credentials ..

    I updated powercli to 5 version .. but problem persists ..

    Anyone can help me ? 🙂 thank you

  5. JeffJeff01-03-2012

    Outstanding! The power of Powershell never ceases to amaze me. One question, anyway to set the NIC to 1GB Full duplex?



Leave a Reply