Tips for a Successful Vmware Converter Operation

For the ones making P2V operations using Vmware Converter plug-in, sometimes it is a nightmare to troubleshoot why the agent fails to proceed. I've tried to compile my experiences on the Vmware Converter plug-in for a successful import without facing any errors.

1. First of all make sure you read and open the ports necessary if there is firewall(s) between vc, hosts and guests. you can find the official link to the article below;
   http://kb.vmware.com/kb/1010056/
2. Before you launch the plug-in, make sure the guest resolves both the vc and host with their fqdn. If necessary, enter the fqdns in the host file.
3. Always reboot the guest after the agent is installed (even the vmware says a reboot is not necessary)
4. Make sure the admin$ of the guest is reachable from vc (in order to install agent).
5. And finally if all of the above are true and you still see face an error while importing, you can find a verbose log named vmware-converter-agent-0.log (increments if a file size threshold exceeds) under the client's below directory;
   
   %allusersprofile%\Application Data\VMware\VMware Converter Enterprise\Logs

VMware Converter Fails at 99%

Last week, I was migrating some physical servers to VMware Server images with VMware Converter tool. I was using the latest and improved version of VMware Converter (v3.0.3 - Build 89816). I had two servers to migrate: one SBS 2003 server and one Windows 2003 based Terminal Server. I had to run the converter on a third piece of hardware while the servers were up and running, installing the converter agent service on them (AKA "hot clone"). SBS server had two volumes, and the total used disk space was around 40GB. Terminal Server had two volumes and used disk space was around 25GB. 

First P2V migration session ran approximately for 6 hours on the SBS server and completed without any problems. I started the second session on the Terminal Server and checked the status every hour. 

If you are familiar with the P2V process, you probably know that the tool initially creates the vmdk files, then fills them in with the files from the source machine (Cloning Phase). When all files are transferred to the virtual disks (vmdk files), then final step is called "conversion". At this stage, the storage, HAL and network specific driver files and their configuration gets modified. This step is necessary, otherwise the virtual disk will not be able to boot. 

Anyhow, after running for 3 hours and 30 minutes, my Terminal Server P2V migration session failed at 99% with "Unknown Error"! A quick Google search revealed that the 97% and 99% range belongs to Customization/Reconfig phase, meaning that it failed at the "conversion" step. VMware converter has the ability to manually run the "conversion". I selected the newly created virtual machine as the source, and ran the "Conversion Wizard", but the process failed again. This time, I decided to examine the log files to see what's wrong. Converter creates log files in two locations: Converter Console log files reside in user's profile folder (in my Vista laptop, they are located at: "%userprofile%\AppData\Local\Temp"). Converter Agent log files reside in "Windows\Temp" folder. After a quick review, I realized that the log files in the profile folder did not provide the detail level I needed. Then after going through the log files in "Windows\Temp" (vmware-converter-n.log) I found what I was looking for:

[#2] [2008-08-23 07:33:53.707 'App' 3932 verbose] [registryUpdate,73] Applying registry update S_SYMMPI
[#2] [2008-08-23 07:33:53.708 'App' 3932 verbose] [registryHiveProxy,176] Saving registry key ControlSet001\Services\symmpi to \\.\vstor2-p2v30-B4BDB4BD007E00000000000003000000\WINDOWS\$Reconfig$\ControlSet001-Services-symmpi-reg
[#2] [2008-08-23 07:33:54.174 'App' 3932 verbose] [registryHiveProxy,152] Restoring registry key ControlSet001\Services\symmpi from C:\Program Files\VMware\VMware Converter\data\52-S_SYMMPI
[#2] [2008-08-23 07:33:54.202 'App' 3932 verbose] [fileUpdate,69] Update File system32\drivers\symmpi.sys
[#2] [2008-08-23 07:33:54.202 'App' 3932 verbose] [volumeProxy,95] Checking if WINDOWS\system32\drivers\symmpi.sys exists...
[#2] [2008-08-23 07:33:54.205 'App' 3932 verbose] [volumeProxy,102] WINDOWS\system32\drivers\symmpi.sys does not exist!
[#2] [2008-08-23 07:33:54.223 'App' 3932 error] [fileUpdate,120] Unable to find symmpi.sys in the specified CAB files
[#2] [2008-08-23 07:33:54.250 'App' 3932 info] [imageProcessingTaskStep,194] UfaSysReconfig::task{1}::task{2} step "applying reconfigurations" destroyed

The Converter was failing at a specific file, symmpi.sys! Because it was looking for the file in "WINDOWS\system32\drivers" folder, failing to find it there, then aborting the process. Another Google search revealed that this was the LSI Logic Miniport Driver file. Luckily, I found the same file in one of my other virtual machines, in the "WINDOWS\system32\drivers" folder. To copy the file to my failing virtual Terminal Server, I connected its C:\ drive as an additional disk to my old virtual machine. After this, I could easily add a drive letter to the drive and was able copy the file.

I shutdown my old virtual machine, removed the drive connection. Then I ran the "conversion Wizard" one more time selecting the new virtual Terminal Server as the source. The "Conversion Wizard" only ran for a couple of minutes, then completed successfully. After this step, I was able to verify that I could successfully boot my new virtual Terminal Server.

My Google searches during this troubleshooting period showed me that this is a very common error. I spent about 2 hours and 30 minutes to find the solution and I hope this post can speed up your troubleshooting process. Please use the comments link below if you have any questions.

MS Virtual Server to VMware ESX Migration Issue

Last week, I was trying to migrate some virtual guest servers from MS Virtual Server 2005 environment to VMware ESX. I had to run the "import" task three times to achieve a successful migration, and had to spend 4-5 hours for a simple migration operation. Hope the tips here will save you some time.
At my first attempt, the process seemed to halt at 22%. There was no activity in the Virtual Center and there were no log file entries at the VMware side. I examined the event viewer logs of the Virtual Server 2005 guest machine and found that the following error was logged:
Log Name: System
Source: msvmscsi
Date: 5/15/2008 5:14:45 PM
Event ID: 9
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: xxx-xxx.xxx.xxx
Description:The device, \Device\Scsi\msvmscsi1, did not respond within the timeout period.

A quick Google search directed me to this link:
http://www.eventid.net/display.asp?eventid=9&eventno=9355&source=vmscsi&phase=1
Before my second attempt I created the following value as described in the above link, and rebooted the guest server:
Key: HKEY_LOCAL_MACHINE/System/CurrentControlSet/Services/Disk
Sub Key: TimeOutValue
Data Type: REG_DWORD
Value: 03c hex (or 60 decimal)

The import process ran up to 97% in my second attempt, then halted there. Same error messages were displayed in the event log of the guest machine.
Before the third attempt, I decided to increase the same registry key value as follows and rebooted the guest server:
Key: HKEY_LOCAL_MACHINE/System/CurrentControlSet/Services/Disk
Sub Key: TimeOutValue
Data Type: REG_DWORD
Value: 05a hex (or 90 decimal)
After this final change and reboot, third import attempt ran successfully. As a final step, I removed the registry setting at the ESX guest machine since it is no longer needed.