Are P2V conversions still worth doing?

Physical-to-virtual conversions have a few gotchas, but they may be the best option when a proper application, data, and configuration migration isn't possible.

 

 

A colleague recently asked me if performing a physical-to-virtual (P2V) conversion was still a valid task to do today. After all, I am the one who encourages everyone to virtualize like it's 2014! When the question was raised, I wasn’t immediately familiar with the state of the tools. The gold standard in free tools is VMware Converter Standalone, but I hadn’t used it for a good two or three years. The current version is 5.0.1, which was released in October 2012. Good thing, as anyone deploying a physical server before then would need to answer to me directly. Depending on the situation, I generally advise people to migrate applications and data to a new virtual machine compared to doing a P2V conversion. That’s the academic approach. But what is good practical advice for P2V tasks today?

When I inquired a bit more with my colleague about the P2V candidate, the idea of migrating it to a new VM sounded like a nearly impossible task due to the lack of real ownership and knowledge of the system and applications on this system — a Small Business Server 2011 (SBS) system. SBS solved a great need for companies to have basic file, print, email, and application platforms leveraging Microsoft technologies. After a quick few minutes identifying the scope of a proper migration to a new VM from an application and data perspective, the P2V approach sounded easier and less risky.

Still, a P2V conversion does incur risk. For one thing, it doesn’t remove any application or system configuration problems that occurred when the system was a physical server. There are plenty of potential gotchas associated with P2Vs as well. Here are some of the tips I recommend based on things that caught me over the past year. I shared them with my colleague (who successfully performed a P2V of the SBS server).

Avoiding the gotchas

• Identify anything tied to an interface or IP address. Exchange, IIS, and other applications are notorious for specific IP addresses or interfaces being configured for a specific task. Figure A  shows Exchange specifying a specific interface to permit outbound mail transport. While Exchange is usually a clear-cut migration application, SBS systems are not. In Figure A, the Exchange application wants to communicate to the former interface, which post-P2V is nonexistent. This option will prevent outbound mail to be sent if there are large queues of mail failing for DNS reasons.

Figure A

 

• Uninstall any hardware driver and associated software. Sometimes they can prevent a VM from starting at all. I’ve had some packages fail to start when on a VM that caused everything else to fail. For Windows systems, the trick is to go into Safe Mode and uninstall the hardware packages there. You don’t want to uninstall them on the physical system in case you need to revert back.

• Make sure you address all of your disk geometry bad decisions. Why did we used to make C:\ drives 25, 127, or 50 GB? Who knows, but let’s change it to our newest preference.

• Always check for the latest version of VMware Converter. I’m guilty of overlooking this, and it caught me once a few years ago. When the major versions are released (4, 5, etc.) of ESXi, chances are a new version of Converter is around the corner. Don’t get stuck using an obsolete package.

• Know what applications to make quiet during the conversion. Life is a lot easier if there is no question of what data exists in what point; just ensure that the applications are stopped.

• Make sure OEM hardware licensing isn’t in use. If you used to fancy purchasing Windows from the hardware OEM, reactivating on a VM may not work. See the next tip….

• Do a dry run! If you haven’t done a P2V in a while, ensure that this VM converts okay and you test out all critical applications off the network before you take the plunge. Figure B shows the simple step to put a VM of the network so it won’t interfere with production. The dry run also gives you a good approximation of the time required, so make sure you include the post conversion tasks, such as installing VMware Tools and a few reboots. The takeaway here is that you can be viewed as a pro when you make an estimate and deliver as advertised.

Figure B

• Use Hardware Version 9 as a target VM. VMware Converter allows creating VMs in Hardware Version 10 (the latest version with ESXi 5.5). Note that when this happens, some changes can be made only with the vSphere Web Client. In the interest of saving time, consider using Hardware Version 9 as a target so you can make tweaks in the Windows vSphere Client.

• Document the entire IP configuration. And don’t forget DNS! Nothing will break everything quicker than bad DNS configuration or the wrong subnet. The VM will likely have an entirely new interface and need to be configured the same as the source VM.

• Don’t create an obsolete operating system museum. While a P2V may solve a need, don’t set yourself up for running an obsolete operating system forever. Start the conversation, including the budget part, to get a system retired or migrated to the correct platform.

The benefits

The art of the P2V is indeed alive and well here in 2014. While a P2V has its own catch points, the benefits of virtualizing another system outweigh the risk of keeping one or more physical systems around. In my opinion, P2V is a great option when a proper application, data, and configuration migration simply isn't possible.