Friday , 19 July 2019
Are P2V conversions still worth doing?

Are P2V conversions still worth doing?

 

lead image

 

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

Figure AFigure 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

Figure BFigure 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.

 

 

Leave a Reply

Your email address will not be published. Required fields are marked *

*