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:
- http://itproctology.blogspot.com/2009/04/migrating-vms-between-hypervisors_10.html
- http://itproctology.blogspot.com/2008/12/you-want-to-convert-machine-to-vhd.html
- http://itproctology.blogspot.com/2009/02/do-you-know-where-your-vm-has-been.html
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.
2 comments:
Interesting post, Brian. The rebuild argument certainly has its merits. It might be the best solution overall. The problem is that I suspect that most will not want to do a rebuild of servers in the midst of a large and complex virtualization project. They want results as quickly as possible with as little disruption as possible.
Maybe the best solution is a mix: rebuild the machines with out of of or near out of support OS's (where app-support allows it, rebuild the unstable ones, and convert the rest of the candidates that the assessment identified?
Aidan Finn.
I was first all starry eye'd by P2V 6 years ago. PlateSpin was pretty much the only game in town, and it worked.
Unfortunately, the gotchas then are the same gotchas today.
However, the expectations are different. Back then we expected problems, and we used P2V as a band-aid until we had time to re-build - not as a solution.
Many folks today consider a P2V a done deal and walk away, never to revisit the workload until they have some performance problem. And generally the performance problems are 'baggage' related.
I can also say that a software company can never test all of the possible combinations that can and do happen. Only a best effort can be done. Therefore any conversion tool is always of beta quality at best or they focus on one sinlge conversion path.
I also take assessments with a grain of salt. They are useful as guidelines, but they should not be taken as absolutes. That is a different post.
Post a Comment