Virtualisation 101 – Physical to Virtual (P2V) Migrations

Following on from last month’s article on deploying brand new virtual machines Simon this month moves on to looking at how to migrate existing Physical or Virtual machines running on earlier or competing virtualisation platforms to vSphere.

What Is P2V?

P2V is the term used for creating a new virtual server containing the operating system, applications and data copied over from an existing physical server. It refers to the process and/or technology used to perform the conversion.

Why Would I Want to P2V?

The virtual infrastructure doesn’t just provide a platform for newly deployed servers – it also offers the opportunity to dramatically reduce your server room requirements by phasing out legacy hardware. Less datacentre space, reduced power consumption, not to mention less hardware to maintain and repair – all reduce costs and better for the environment.

While it is preferable to deploy fresh virtual machines and take the opportunity to upgrade to the latest OS and application versions, in some cases this would require too much effort to be feasible, or the server is undocumented and/or running out-of-support legacy applications that must be brought across “as is”.

How Does a P2V Work?

The process usually involves 3 components :-

clip_image002

The P2V market is huge, so its not surprising there are many vendors and products to choose from, each with differing capabilities, strengths and weaknesses. (Links to some of the major players are included at the end of this article.)

At a very high level a typical P2V migration would work like this :-

  • Audit the resources consumed by the source machine – CPU, memory, disk space, etc – to determine the sizing of the target server, ensuring that the virtual environment has sufficient capacity to host it.
  • Run a Migration wizard on the P2V server and work through the dialog boxes providing the information required for the job to be performed :-
    • Security credentials for the source machine and target ESX host.
    • Identify any services on the source server that needs to be stopped during conversion or disabled on the target server.
    • Resources required on the target, such as number of CPUS, amount of RAM, number of disks and NICs, plus a temporary IP address.
    • Sizing of target server hard disks – if the source server is only utilising a minority of available disk space it makes sense to save space and deploy a smaller disk.
    • When the migration should run – it can be scheduled to run out of hours if required
  • Once the migration commences it will usually install a small application on the source server, create a fresh virtual machine and power it on with a network-capable boot environment like WinPE, applying a temporary IP address. The application will then begin to transfer the data across the network to the new machine at a file, block or even byte level.

There is a degree of post-conversion tidying up to do, uninstalling applications no longer required (such as hardware agents), working through Plug & Play detection to install additional drivers and installing VMTools (though many apps do this for you).

The new virtual server can be powered on with the vNICs disconnected, allowing you to connect to the console and its check health before arranging to cut over by taking the legacy server down and bringing the new virtual server online.

Things To Consider

Admittedly this is a rather simplistic explanation for what is a very clever piece of technology, and in the Real World there are a host of things to consider :-

  • Change of Hardware – the OS of the source server communicated with the physical hardware via a set of installed drivers, which won’t work with the the target server’s new virtual hardware. The software must replace the hardware drivers during the transfer otherwise the target will just bluescreen. Another potential issue is Windows Activation, as the OS boots up and detects a whole new set of hardware.
  • Legacy Hardware and Software – as a rule of thumb the newer the server the more chance of success. Occasionally the application won’t be able to “see” the disks on the source server, or may see mirrored disks as duplicate volumes. Some applications also won’t support older operating systems such as NT4 as it lacks Plug & Play and Shadow Copy technology, which can require an alternative approach –
  • Cold Booting – converting a running server is referred to as an “online” or “hot” migration. If this isn’t supported an alternative option is a “cold” boot, whereby the server is powered up from a CD containing a network-capable boot environment. This takes the source OS out of the process, though the boot CD must be able to read the file system and have compatible network drivers.
  • Large Volumes over Slow Networks – a common problem with P2Ving is where the source server has a large amount of data to send over a slow network link, or where the source only has a 100Mb NIC, or worse trying to migrate over WAN links. It can feel like emptying a swimming pool with a spoon! For optimal speeds ensure all servers are on the same Gigabit LAN. If not possible an option here is –
  • Ferrying by NAS – plugging a cheap NAS device onto the same network as the source provides a temporary destination for the virtual machine image. The NAS can then be couriered to the target site and plugged into the same network as the virtual environment.
  • Losing Data During Conversion – when cutting over to the new server you need to be certain that no data has been lost. This means the source server should be considered “read only” during the migration, shutting down any applications and services that would write to the source.
  • Cutover & Rollback – once the migration is complete and the new server proven healthy the point comes when the old server needs taking off the network and the new one connecting. The good news is that rollback is simply a case of taking the virtual server offline and reconnecting the physical.
  • Disaster Recovery – the P2V process doesn’t have to be a one-off, complete transfer of data. Some applications expand on the idea and to maintain a DR copy of a server (virtual or physical) at another site, maintained by scheduled incremental updates.
  • *2* – The migration of servers isn’t limited to just going from physical to virtual – it’s possible to convert from physical to physical (for technology refresh projects), or virtual to virtual (if moving between virtual platforms). There will also be increasing use of Cloud as a platform, so look out for P2C and V2C!

What Product Should I Use?

There’s no clear answer to that, unfortunately. Each P2V product has its own strengths and weaknesses and costs can vary.

It is well worth trying VMware’s own Standalone Converter application first, being free, easy to use and that works well with Windows 2003 and 2008 servers, though it doesn’t do scheduled conversions.

Check with vendors whether evaluation licenses are available, and if possible get some test migrations under your belt before trying any production conversions – success rates improve as a results of lessons learnt the hard way! Most products license on a per-migration basis, so you want a high success rate.

Links:

FREE! VMware Converter: http://www.vmware.com/products/converter/

Converter Best Practices: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1004588

Novell Platespin Migrate: http://www.novell.com/products/migrate/

DoubleTake Move: http://www.visionsolutions.com/products/dt-move.aspx

Quest vConverter: http://www.quest.com/vconverter/

Ultrabac (supports NT4 P2V): http://www.ultrabac.com/products/40product-descriptions/

Techhead to the rescue! Scripted removal of HP hardware agents: http://www.techhead.co.uk/vmware-esx-removal-hp-agents-and-utilties-after-migration

2 comments

  1. Simon,

    Great article, I saw this posted on Cliff Davies blog and commented there as well.

    I wanted to ask if you could include SanXfer migration software to the list of P2V tools. It’s a full featured X2X migration tool that moves servers over SAN and IP networks, so it’s great for performing really fast P2V conversions.

    If any of your readers are interested in trying SanXfer for a P2V migration, they can email me directly and I will gladly provide a free license for them to use.

    Thanks,
    Zach (zach_hayes@inquinox.com)

    • Kate on September 27, 2011 at 2:39 am

    Great post – thanks for sharing.

    In addition one of the other key benefits of P2V technology is being able to recover a physical system in a virtual environment in the absence of deduplicate hardware. For example, your physical server suffers from a catastrophic failure, but you don’t have a spare server available let alone an identical sever to recover your data to. Plus manual system recovery is a lengthy and error prone process – the last thing you need. In this instance what do you do? The failed server was running your most critical application and it just went down. Rather than wait for a new server to be shipped to your office, P2V technology solves this problem instantly and the even better news is that Symantec has a product called Symantec System Recovery that does exactly that.

    Symantec System Recovery automatically restores an entire system to bare metal, dissimilar hardware or a virtual environment in seconds. It includes P2V, V2V and V2P technology to get your server back up and running and it also gives you the flexibility of moving systems between virtual and physical environments.

    Here are a few of the product’s highlights:

    1) Convert systems to both VMware and Hyper-V format
    2) Maintain ‘point in time’ consistency for servers or application servers with multiple volumes
    3) Ensure application servers boot and run properly post-conversion through integration with VSS
    4) Perform conversions on a ‘one time’ or scheduled/recurring basis regardless of the use case (migration, testing, disaster recovery, etc)
    5) Automatically inject the required drivers for the selected virtual platform (type of dissimilar hardware restore) ensuring converted systems boot and function properly
    6) Centrally manage the conversions of one or multiple systems using the Symantec System Recovery Management solution
    7) Convert standard or ‘hardened’ servers
    8) Store resulting virtual disk files to a disk location, or in the case of VMware upload directly to VMFS file system of an available vSphere/ESX host on the network

    If anyone has any questions about Symantec System Recovery or would like to learn more, visit: http://www.symantecsystemrecovery.com (you can download free 60-day trialware from this website) or email me at: kate_lewis@symantec.com .

    Thanks, Kate

Comments have been disabled.

%d bloggers like this: