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:

Limitations:
– 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.

Requirements:
– 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 http://support.microsoft.com/kb/311272. Devcon.exe for i386 must be placed in the same directory as the script.
– NVSPBind.exe included in this post or available from http://archive.msdn.microsoft.com/nvspbind. 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).

Thanks!

Share Button
  1. MarshcroftMarshcroft12-20-2011

    So it is working fine but with 2 exceptions which i cannot seem to get around, it will not inject the default gateway IP and also gives an error on the DNS and WINS although WINS isnt an issue.

    Method invocation failed because [System.Boolean] doesn’t contain a method name
    d ‘Trim’.
    At C:Program Files (x86)VMwareInfrastructurevSphere PowerCLIScriptsAutoma
    tedMigration.VMxNet3.Paravirtual.ps1:35 char:73
    + $dns = $dnslog -match “d{1,3}.d{1,3}.d{1,3}.d{1,3}” | % {$_.Trim <
    <<< ()}
    + CategoryInfo : InvalidOperation: (Trim:String) [], RuntimeExcep
    tion
    + FullyQualifiedErrorId : MethodNotFound

    Cannot index into a null array.
    At C:Program Files (x86)VMwareInfrastructurevSphere PowerCLIScriptsAutoma
    tedMigration.VMxNet3.Paravirtual.ps1:36 char:17
    + $dns[0] = $dns[ <<<< 0].Split(":")[1].Trim()
    + CategoryInfo : InvalidOperation: (0:Int32) [], RuntimeException
    + FullyQualifiedErrorId : NullArray

    Method invocation failed because [System.Boolean] doesn't contain a method name
    d 'Trim'.
    At C:Program Files (x86)VMwareInfrastructurevSphere PowerCLIScriptsAutoma
    tedMigration.VMxNet3.Paravirtual.ps1:40 char:75
    + $wins = $winslog -match "d{1,3}.d{1,3}.d{1,3}.d{1,3}" | % {$_.Trim
    <<<< ()}
    + CategoryInfo : InvalidOperation: (Trim:String) [], RuntimeExcep
    tion
    + FullyQualifiedErrorId : MethodNotFound

  2. cwjkingcwjking10-26-2011

    Hey man,
    Can you make the script to where you can modify it to only do VMXNET3 or PVSCSI? We don’t want to use pvscsi for whatever reason but we are doing the conversion of VMXNET3 soon. like tomorrow lol.

    • youngtechyoungtech10-27-2011

      cwjking,

      The code is all open so you’re free to make any minor modifications like what you’re requesting. The easiest thing to do would be to remark out the following line:

      Write-Host `t(get-date -uformat %I:%M:%S) “Changing Primary SCSI controller to paravirtual” -ForegroundColor Green
      $invokeOut = Get-HardDisk -VM $vm | Select -First 1 | Get-ScsiController | Set-ScsiController -Type paravirtual

      Everything else as it relates to PVSCSI can remain in there, this is just the final “cut-over” if you will. If you remark (#) or remove this line, the script will only process VMXNET3 changes as you requested. Hope this helps!
      Thanks,
      youngtech

  3. mikemike09-07-2011

    Invalid credentials detected.”`n”Please re-run the script and provide valid credentials

    i know for sure the credentials are valid, where did it go wrong?

  4. michael khayatmichael khayat05-22-2011

    This works !
    Is ther possible to change the VM IP configuration and recreate credentials to migrate IP addresses of VMs ?

    Thanks.

    • youngtechyoungtech05-23-2011

      Not sure I quite understand. What is it you’re looking to accomplish exactly?
      Thanks,
      youngtech

  5. Jason SheaJason Shea05-18-2011

    Here’s a question,

    I’m running into issues with the script attempting to write files to the root of c: (like ipconfig.log for example) as well as c:windowstemp. Windows 2008 R2 with UAC has issues creating/writing files to these directories. Were you able to run this on Windows 2008 R2 guests? Any workarounds necessary?

    • youngtechyoungtech05-20-2011

      Jason,

      Unfortunately, UAC must be temporarily disabled in order for the migration script to work properly against 2008 and 2008 R2 VMs. As you would expect, this is by design as UAC is intended to prevent unwanted scripts (potentially malicious) from running without manual user intervention. You’re not the first to bring this up (See: http://communities.vmware.com/thread/289529), and currently there is no workaround for PowerCLI.

      UAC can be disabled rather easily through group policy or even the registry (HKLMSoftawreMicrosoftWindowsCurrentVersionPoliciesSystemEnableLUA = 0), but requires a reboot to apply. This can be done in conjunction with running the migration script since you will likely be planning an outage window to migrate the virtual machines. If this is resolved in future releases of PowerCLI, I will be sure to adjust the scripts appropriately. Sorry to be the bearer of bad news…Thanks–
      youngtech

Leave a Reply