Troubleshooting common P2V Conversion Failures


Conversions sometimes fail no matter how careful you are preparing the server. The failure can occur at various stages in the conversion process; these stages are based on the task bar percent and are estimated values.

1.      Creation of the target virtual machine (VM) (0%-5%)
2.      Preparing to Clone the Disk (5%-6%)
3.      Cloning (6%-95%)
4.      Post-cloning (95%-97%)
5.      Customization/Reconfig (97%-99%)
6.      Install Tools/Power On (99%-100%)

The conversion process may fail at any stage, but if it’s going to fail, it will typically fail at 97%. Converter creates a detailed log file during the conversion process which will contain exact errors pertaining to why the conversion failed.

This log file is located on the server you are converting that is running the Converter agent, and is usually named vmware-converter-0.log and is located in the C:\Windows\temp\vmware-temp directory. Open this log file and scroll towards the bottom and look for failure errors. Once the process fails, Converter will destroy the VM that it created automatically.

One clue to determine which stage it failed at is how fast it gets to 97%. If it jumps to 97% quickly and fails, this usually indicates a problem with network ports, DNS resolution or a required Windows service that is not running. Here are some things to try to resolve these types of problems.

1.      If you used a hostname to choose your VC/ESX server destination make sure you can resolve it on your source server. Also try using the FQDN of the server instead of the short name.

2. On the source server make sure the Workstation, Server, TCP/IP NetBIOS Helper and VMware Converter services are running. On Windows XP and 2003 servers make sure the Volume Shadow Copy service is not disabled, by default it should be set to Manual. This service does not need to be running for Converter to work.

3. Use telnet to see if you can connect to the required ports on the VC/ESX servers. From the source server type “telnet 902”. You should get a response back from the VC/ESX server, also do this on port 443.

4. Try rebooting the source server, this is a requirement for Windows NT and 2000 servers.

If it takes a long time to get to 97%, then typically the clone failed during the data cloning process or the post-cloning procedures. Some possible causes of these types of failures can be lost network connectivity between the servers, excessive network errors and source disk problems. Here are some steps to try to resolve these types of problems.

1.  Verify network speed/duplex settings match on your source server’s NIC and the physical switch port it is connected to.

2.  If you have OS mirroring enabled, break the mirrors.

3.      Clean-up your boot.ini file and make sure it is correct.

4.      Make sure you are using the latest version of Converter. Earlier versions fail if the source server has dynamic disks.

5.      Run chkdsk on your source server to verify file system integrity.

6.      Ensure you have at least 200 MB of free disk on the source server.

7.      If your source server has more then two serial (COM) ports, edit the registry and look for HKLM\HARDWARE\DEVICEMAP\SERIALCOM and remove any ports above serial port 2. You can export the key before you do this and re-import after the conversion is completed if needed.

Finally, if your conversion completes successfully but your server will not boot (or boots to a blue screen) you can try the following things to fix it.

1. Edit the boot.ini on the newly created VM to make sure the disks are in the proper order. Sometimes the boot disk will not be listed as the first partition. To do this, simply use a working VM as a helper and add an additional virtual hard disk. Browse to the newly created VM’s disk file.

You can then browse that disk and edit the boot.ini file. When complete, remove the disk from the helper VM. You can also try running Converter again and selecting “Configure Machine” and select your newly created VM. Run through the Wizard, and (when complete) try powering it on again.

2.  Verify you are using the proper SCSI controller for your virtual disk (BusLogic or LSI Logic).

3.  Boot the VM in safe mode to see if any hardware specific services/drivers are loading.

Enhancing performance in a new virtual machine

When your conversion completes, there are several steps you should to do clean your new VM up so it will perform better.

1. Edit the VM’s hardware. Remove all unnecessary hardware, including floppy drives and serial, parallel and USB ports. You should only give the VM as much RAM as it needs. Reduce it if you can. Most VM’s run better with one vCPU, so consider reducing the number of CPUs if you came from a SMP physical server.

2. Power on the VM, wait a few minutes to let it discover all it’s new hardware then reboot it.

3. Check the server HAL, if you came from a multiple CPU physical system and have a single CPU VM you need to go into Device Manager and edit the CPU (Computer). Select Update Driver, say No to Windows Update, select Install from List, select Don’t Search and select ACPI Uniprocessor instead of ACPI Multiprocessor.

4.      Remove any hardware specific applications and drivers.

5.      Finally, my most important tip: Remove all non-present hardware devices. These are hardware devices that were removed from the system without having been uninstalled and are a by-product of the conversion.

These devices are not physically present in the system any more, but Windows treats them as they were there and devotes system resources to them. They can also cause conflicts when trying to set your new network adapter’s IP address to the same address of the source server. The reason for this is that the old NIC still exists as non-present hardware with an IP address. There will be dozens of non-present hardware devices left after the conversion.

To remove them all simply go to a CMD prompt and type SET DEVMGR_SHOW_NONPRESENT_DEVICES=1.

Then in the same CMD window type DEVMGMT.MSC and then select Show Hidden Devices when the Device Manager window opens.

As you expand each hardware category you will see lots of non-present devices, indicated by grayed out icons. Right-click on each and select uninstall. Reboot once you have removed them all.

About Alex Hunt

Hi All I am Manish Kumar Jha aka Alex Hunt. I am currently working in VMware Software India Pvt Ltd as Operations System Engineer (vCloud Air Operations). I have around 5 Years of IT experience and have exposure on VMware vSphere, vCloud Director, RHEL and modern data center technologies like Cisco UCS and Cisco Nexus 1000v and NSX. If you find any post informational to you please press like and share it across social media and leave your comments if you want to discuss further on any post. Disclaimer: All the information on this website is published in good faith and for general information purpose only. I don’t make any warranties about the completeness, reliability and accuracy of this information. Any action you take upon the information you find on this blog is strictly at your own risk. The Views and opinions published on this blog are my own and not the opinions of my employer or any of the vendors of the product discussed.
This entry was posted in P2V, Vmware. Bookmark the permalink.

2 Responses to Troubleshooting common P2V Conversion Failures

  1. Nice post…Today I also wrote a post about “VMware P2V Converter Best Practices…Pre and Post conversion checklist” and used this post as reference…🙂

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s