Minimizing P2V trouble with VMware Converter
Since P2V conversions with VMware Converter have been on my mind (and my schedule!) the last few months I figured I’d go ahead and discuss the best practices for troubleshooting failed P2V migrations of Windows physical machines to VMware virtual infrastructure. This post copies VMware KB article Best Practices using VMware Converter but with my own experience and opinions thrown in here and there.
I want all readers to understand that all of the recommendations listed are not always necessary, but instead should be systematically tried as needed when experiencing troubles. Most P2V migrations with VMware Converter “just work” without any issues. Use these steps to troubleshoot that small percentage of conversions that fail without an obvious explanation.
VMware’s KB article starts off by saying the same thing with a few reminders:
To ensure the best possible results with VMware Converter, follow as many of the steps described below as possible. If you do not follow all of the steps and a problem results, attempt another conversion and follow the steps that were missed.
Note: These steps apply only to Windows operations system sources. Using VMware Converter to virtualize a Linux operating system is experimental. If this is required, attempt a cold migration, keeping all disks and partitions at their original size.
Note: The best approach to converting a Windows operating system to a virtual machine is to perform a hot migration with VMware Converter installed locally to the source operating system. If this is not possible, a remote hot migration is the next choice. Performing a cold migration is a final choice. (This is probably the biggest catch all recommendation in this KB article. Install VMware Converter locally on each source physical server if you have to! Besides, local installs also let you use the free Standard Edition to migrate directly to ESX – a limitation of the remote method for the free version)
Note: These steps are not a recommendation against using certain features of VMware Converter in normal daily use. They are meant as troubleshooting steps to be taken that can correct a problem by eliminating variables and simplifying a conversion environment.
Before and during a conversion
- Do not plan for or try to P2V Domain controllers. It’s too easy to either create a new DC as a VM or to just demote to a member server before the P2V.
- Do not attempt to convert a Windows operating system that is currently functioning as a domain controller. Domain controllers are extremely sensitive to hardware changes and the virtual hardware presented to a virtual machine is different from the physical hardware presented to a physical machine. A virtual machine created from an active domain controller may exhibit unexpected behavior.VMware recommends removing a domain controller from its domain controller role, virtualizing it, then put the resulting virtual machine back into its domain controller role again.
- Verify that you have the latest version of VMware Converter. If you are converting an operating system that does not have the latest version of VMware Converter installed:
- Uninstall VMware Converter from the source computer.
- Reboot the source computer.
- Install the newer version of VMware Converter.
-
Install VMware Converter directly to the source operating system as a local administrator.Note:
Using a domain administrator account may not be sufficient depending on your environment, and local and group policies. Using a local administrator account removes any possible permissions issues.Note: If the source operating system is Windows NT or Windows 2000, reboot it after installing VMware Converter.
-
Confirm that the source operating system has 200 MB of free space on its system drive. (I always forget to check for the available free space!)
-
Confirm that the VMware Converter related services are started on the source operating system.(personally, I just check the Services MMC, but you can do it from the command line too as follows)
- Open a command prompt. For more information, see Opening a command or shell prompt (1003892).
- Type net start vstor2-p2v30 and press Enter.
- Type net start ufad-p2v and press Enter.
-
If the source operating system is Windows NT or Windows 2000:
- Type net start “tcp/ip netbios helper service” and press Enter.
- Type net start stcp2v30 and press Enter.
Otherwise:
- Type net start “tcp/ip netbios helper” and press Enter
- Type net start vss and press Enter.
-
If the virtual machine target host is an ESX Server, verify that ports 443 and 902 are open between the source operating system and the ESX Server host. For more information, see Testing port connectivity with the Telnet command (1003487).Note: To eliminate variables and a possible source of problems convert to an ESX Server rather than to VirtualCenter. (as simple as this sounds, it has been quite effective for me on certain stubborn migrations. In fact, it’s been a while since I pointed Converter at a VC)
-
Run the Windows System Configuration utility(msconfig) on the source operating system to eliminate all software except for Microsoft and VMware. For more information, see Using the Windows System Configuration utility (1004010).(I usually just stop the applications and services in the Services MMC and then remove the unneeded software after P2V. That way I have the exact version of the server to fall back to if the P2V just won’t work.)
-
Run VMware Converter as a local administrator.Note:
Using a domain administrator account may not be sufficient depending on your environment and local or group policies. Using a local administrator account removes any possible permissions issues. -
Do not convert unwanted disk partitions or diagnostic partitions. (They usually are very small and have a ? icon next to them in Converter)
-
Do not resize any drives or partitions. (another simple fix to unexplained failures. As much as you want to reclaim some space or give some breathing room to an application, you may have to wait until after the P2V.)
-
Use the IP address of the ESX Server host.Note: Using the host name of the ESX Server may expose issues with name resolution that can prevent the conversion from completing. (bad DNS and reverse lookup will kill you in so many ways with VI. You’ve got to get it right)
-
Authenticate to the ESX Server host as root.
-
Confirm that you are providing a unique name for the target virtual machine.
-
Leave the default number of NICs unaltered.(never had to do this myself to save a P2V)
Note: This can be changed when the conversion is successful. -
Do not install Tools during the conversion. (a good thing to try first. I’ve seen too many conversions fail at 94 to 97 percent complete, the VM still boots, and the VM tools are dragging along. Uninstall, reinstall, and a general fight ensues as the OS tries to recognize the new HAL. Can be eliminated by manually doing the VM tools install later)
-
Do not customize the virtual machine during the conversion. (is this really done? It’s a great feature, but I have never used it)
When in doubt, install VMware Converter directly on the source physical server to be migrated. Remove it after the successful P2V.
After a conversion
- If required, change the number of NICs assigned to the virtual machine.
- If the virtual machine is being hosted on an ESX Server host, remove any virtual USB ports.
- Boot the virtual machine in Safe Mode. For more information, see Booting into Safe Mode (1004011).
-
Run Device Manager and disable or uninstall all devices that show a yellow exclamation point beside them.
- Click Start>Run.
- Type devmgmt.msc and press Enter.
- Click View>Show hidden devices.
- Right-click an entry that has a yellow exclamation point beside it.
-
Click Disable or click Uninstall.
Note: Not all devices have Disable and Uninstall listed as an available option. If there is a device that does not,
click the option that is listed. If both are listed, clicking either one is sufficient. - remove hidden devices with this vmetc.com how to post too
-
Reboot the operating system.
-
If the source operating system was installed on a physical machine, uninstall any software that was specific to its physical hardware that is no longer available.
- Click Start>Run.
- Type appwiz.cpl and press Enter. (Add Remove Programs in Control Panel I assume!)
- Click on the entry for the software.
-
Click Change/Remove or Uninstall/Change depending on the version of Windows.
-
Repeat c and d for each piece of software to be removed. Do not reboot, even if prompted.
-
Reboot the operating system after all software is removed.
- Install VMware Tools.
- If the Windows System Configuration utility(msconfig) startup is still in effect on the virtual machine, switch back to a normal boot configuration and reboot.
- If required, customize the machine. This can be done by manually changing its computer name, IP address, and other required unique identification or by using the Microsoft Sysprep utility.
Conducting hot P2V migrations with VMware Converter by Eric Siebert on http://searchvmware.techtarget.com is another great referenece for troubleshooting P2V migrations.
Technorati Tags: virtualization, vmware, converter, p2v










Pingback: Minimizing P2V trouble with VMware Converter « H9Newser’s Blog