Today’s physical-to-virtual (P2V) conversion tools are exceptionally mature, but the deeply technical processes are slightly different in each P2V migration product.
server migration tools take an image of an OS, application and settings and convert them into a
virtual hard disk file (for Microsoft Hyper-V and Citrix Systems’ XenServer) or a virtual machine
disk format file (for VMware). Then the P2V conversion tool automatically injects virtual hardware
drivers that enable the VM to function.
Most P2V conversions are straightforward, but problems do occur occasionally. These five tips can help you master the P2V migration process.
1. Beware OEM-installed systems
When original equipment manufacturers (OEMs) install OSes on machines, they typically tag licenses to specific pieces of hardware through a processor chip ID or other mechanism. But the P2V conversion process breaks this link between OS and hardware gets, especially if you’ve migrated a VM to another piece of hardware. A new VM isn’t equipped with the same hardware markers as a physical machine, so converting OEM-installed systems often results in failure. If you have an OEM-installed system, ask your manufacturer if they have alternative licensing for virtualization.
2. Monitor before you migrate
Before you try a P2V migration, monitor your infrastructure’s key performance indicators. I usually suggest monitoring for one business cycle, so you understand how that specific system is used over the entire period of your activities. (Depending on the business, a full cycle may be a day, a week or a month.)
To prepare for a P2V conversion, you can use PerfMon or numerous other performance monitoring tools. VMware vCenter’s Guided Consolidation module, for example, monitors a server and reports its average processing and memory quantities over a specified period of time. Guided Consolidation also reports the standard deviation, or the amount of fluctuation from the average, through an easy-to-read trend line graph. Using these two metrics, you can determine how much processing power and memory to assign to VMs before you create them.
3. Don’t forget about third-party P2V products
The P2V migration functionality in vCenter or Microsoft System Center Virtual Machine Manager work just fine for converting physical machines to virtual machines. But third-party companies also have their own P2V conversion tools, many of which perform faster and provide more features.
One important consideration for P2V conversion tools is how long the conversion takes to complete. Some hypervisor vendors’ products can take hours, but some third-party products can take mere minutes. Speed isn’t a big issue if you’re converting just a couple servers. But if you’re converting a couple hundred, you’ll surely find the value in spending more money on a third-party P2V migration tool.
4. Put away the SysPrep and NewSID
When replicating systems, many IT admins are trained to use SysPrep on everything. SysPrep uses cloning to deploy an OS on multiple computers, and it assigns a unique security identifier (SID) to each destination computer. In those systems where admins don’t use SysPrep, they often change SID information with tools such as GhostWalker and NewSID. This behavior is a holdover from desktop deployment activities, where many desktops are replicated from a single golden image.
P2V conversion, unlike desktop deployment, is not a one-to-many process buta one-to-one process. The VM that ultimately gets created is intended to run as an exact copy of the original physical system would. Thus, SysPrep and SID-changing tools are unnecessary.
5. Don’t start the P and V simultaneously
With that last tip firmly in mind, you can imagine the P2V conversion problems that would ensue if you were to power on physical and virtual copies of a system at the same time. It would make two systems with the exact same domain characteristics available and communicating on the network.
You don’t want this situation, and neither does your Active Directory admin. Many P2V conversion products power down the physical instance as the VM is powered on. Never manually power on the physical and virtual machine simultaneously. If you do, you’ll end up with two identical instances of a computer without knowing which one is the right one. If you’ve ever seen those B-rate movies where the guy holding the gun doesn’t know which clone is really his father, you understand the problems this situation can create.
This was first published in March 2011