Troubleshooting failed VMware Converter P2V migrations
A failed VMware Converter physical-to-virtual migration has numerous sources of potential failure, and even your best-laid plans may not prevent a problem. But this tip offers detailed troubleshooting to identify the problem.
After you've used VMware Converter for a physical-to-virtual migration, what comes next? What happens if a conversion...
Continue Reading This Article
Enjoy this article as well as all of our content, including E-Guides, news, tips and more.
fails, or something else goes awry?
In part two of this series, we talked about preparation steps to ensure a successful conversion and also the process of running the conversion wizard. In this article in our series we will continue by discussing some post-conversion steps and tips for troubleshooting and resolving failed conversions.
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.
- Creation of the target virtual machine (VM) (0%-5%)
- Preparing to Clone the Disk (5%-6%)
- Cloning (6%-95%)
- Post-cloning (95%-97%)
- Customization/Reconfig (97%-99%)
- 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.
- 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.
- 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.
- 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.
- 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.
- Verify network speed/duplex settings match on your source server's NIC and the physical switch port it is connected to.
- If you have OS mirroring enabled, break the mirrors.
- Clean-up your boot.ini file and make sure it is correct.
- Make sure you are using the latest version of Converter. Earlier versions fail if the source server has dynamic disks.
- Run chkdsk on your source server to verify file system integrity.
- Ensure you have at least 200 MB of free disk on the source server.
- 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.
- 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.
- Verify you are using the proper SCSI controller for your virtual disk (BusLogic or LSI Logic).
- 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.
- 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.
- Power on the VM, wait a few minutes to let it discover all it's new hardware then reboot it.
- 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.
- Remove any hardware specific applications and drivers.
- 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 anymore, 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.
That concludes this series of articles on using VMware Converter. Hopefully the information in these articles will help you in converting your physical servers to virtual ones.
ABOUT THE AUTHOR: Eric Siebert is a 25-year IT veteran with experience in programming, networking, telecom and systems administration. He is a guru-status moderator on the VMware community VMTN forums and maintains VMware-land.com, a VI3 information site.