Virtualization Strategies for the CIOToday’s physical-to-virtual (P2V) conversion tools are exceptionally mature, but the deeply technical processes are slightly different in each P2V migration product.
Requires Free Membership to View
When you register, my team of editors will also send you the latest expert resources covering all areas of server virtualization, such as platforms, architectures and strategies, server hardware, managing virtual environments, application issues and more.
Margie Semilof, Editorial Director
Virtual
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
Join the conversationComment
Share
Comments
Results
Contribute to the conversation