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.