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.
What are your thoughts on a P2V today? Share your comments and
advice with fellow TechRepublic members.
