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 :-
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.
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