I monitor many forums where folks are constantly dealing with problems caused by converting a physical computer to a VM or taking a VM from one hypervisor and moving it to a different hypervisor.
I have one statement for these folks: P2V is not a panacea, it is a Pandora's box. P2V brings baggage. It is this baggage that causes problems both during and after the conversion.
Now, don’t get me wrong, I totally understand why folks want to perform a P2V and I also understand why folks want free tools.
In regards to free tools – you get what you pay for. I don’t think I need to say any more. This means that there will be bad experiences, your chances of having a problem are high.
Let me back up and talk about V2V a little. In this case it all comes down to hardware. The simple example is the boot disk interface. VMware presents a SCSI disk, Hyper-V presents an IDE disk, XenServer presents what looks like an IDE during boot.
If you have ever taken a Windows Server backup (Windows 2003 or older) and then tried to apply that to new hardware you quickly learn that device drivers are the big problem. And this can be simply new SCSI arrays, let alone converting from SCSI to SATA, or IDE to SCSI.
The other big issue is hypervisor ‘tools’ that are installed into the VMs. There is a total mixed bag here. The optimum would be that the tools can be installed and they have no proble,s if that VM is moved to a different hypervisor, but that is not the case. For best results, remove the hypervisor tools BEFORE migrating the VM.
I have talked about this before:
Back to P2V.
We still have to deal with hardware changes as described above. And there are device drivers and agents as well, very similar to the ‘tools’ situation described above.
Many folks install hardware monitoring agents when an OS is installed on a physical box. These agents can cause all kinds of problems following a P2V. As with the ‘tools’ uninstall the agents prior to conversion.
Now, there are also ghost issues that will crop up over time. This is just inherent in any system when the hardware is changed. There are small device driver miss-matches, MAC address problems, application problems, etc.
It has always been the BEST case to build the entire server on the new hardware and then install the application and migrate any databases or other requirements.
Personally, I see two reasons for this: 1) you really understand your application and you can document a full rebuild for DR reasons. 2) you will get the absolute best performance of the application in the VM, no baggage.