To P2V or Not to P2V? The rules of the road for virtual migration

Physical-to-virtual migration is sometimes touted as a turnkey event. But without understanding your server environment, P2V tasks are hardly seamless.

In the move from physical to virtual infrastructure, organizations face numerous challenges: getting appropriate decisional support, planning and implementing the right hardware components, even choosing the right hypervisor. But one of the most complicated processes that organizations encounter is determining how to move current physical workloads into virtual machines (VMs). Virtualization providers often tout their physical-to-virtual (P2V) migration tools as the cure-all for this complex process. But when your IT infrastructure is at the core of business operations, you want to ensure that your approach provides the best results. After all, when you put all your eggs in one basket, the basket better be as tough and resilient as you can make it.

So what does a physical-to-virtual migration entail, and why can it be problematic? In simple terms, the virtual hardware presented by a virtual machine is always different from the physical hardware on the original server. A conversion process is thus required to accommodate these differences. During the conversion process, existing physical drivers are replaced with the drivers supported by the virtual platform and the machine is adapted to the hypervisor. The P2V conversion process decouples and migrates a physical server’s operating system, applications and data from its physical container to a virtual machine guest hosted on a virtualization platform, transforming physical disk drives into virtual disk drive files.

But this process isn’t always seamless. That’s why, when you move workloads into new virtual machines, you should use the workload’s own migration process whenever possible. This way, you won’t transfer the issues that can arise from the conversion process. Ideally, therefore, you should rely on P2V only for special workloads—those that do not support an internal migration process of their own—and you should choose a P2V tool with care by ensuring that it supports all the operating systems you run and has a perfect record for driver conversion.

But you can’t make these determinations about which workloads are P2V candidates and proceed with a migration approach until you understand your computing environment: You need to determine which items you need to migrate, and in which order. To do so, you need to scan your network resources over a significant period of time to determine what each workload runs, how it runs, which resources it requires, when its lows and peaks occur, and so on. Once you intuitively understand the dynamics of your environment, you can progress to the next stage: categorizing resources by differentiating between simpler and more complex workloads. After you complete these evaluation stages, you can then progress to the migration stage.

This article offers guidance in understanding your environment, categorizing its elements and mapping out a physical to-virtual migration process step by step so that you migrate with success and without wasted effort and error along the way.

Inventory and categorization challenges

When organizations attempt to migrate to virtual machines without first assessing their environment, the likelihood of failure, snafus and rework increases. It’s amazing how many organizations lack ongoing inventories for their IT infrastructure. The perception is that the machines just run, so collecting an inventory doesn’t seem necessary. But when you migrate from a physical to a virtual infrastructure, you need a list of the servers in your network and the workloads these servers run. Otherwise you can’t properly size the virtual machines you create to run the same workloads.

That’s right. You should not rely on a one-to-one resource correlation between physical systems and virtual machines: The reason you perform physical server consolidation projects—projects that reduce the number of physical servers by turning workloads into virtual machines—is because traditional physical workloads do not use the full system resources that are available to them. After all, if your physical server runs at 10% utilization, you shouldn’t waste virtual resources by giving a VM the same configuration as its physical host. But you should be aware of peaks and heavy resource utilization periods for the workload. And when you assign resources to a VM, you must account for this additional demand. That’s why your network and resource analysis must run for long periods of time—enough time, in fact, to capture variations in the workloads you run. In the end, you’ll most likely discover that if a physical machine has 2 GB of RAM assigned to it, you can often have the corresponding workload run at 1 GB of RAM. Monitor your resources, and if more is required, simply change the VM’s configuration. It is a lot easier to add resources to a VM than to a physical server.

Different workloads, different migration needs

Once you identify your workloads, you’ll find that you can designate them for the most appropriate server type. The simplest categories include three different types of workloads.

  • Simple workloads. This category includes single-purpose servers, servers with low input and output (I/O) rates, and servers that run only one network interface card (NIC).
  • Advanced workloads. More advanced workloads include applications that are configured for high availability through server load balancing or failover clustering, servers with ongoing high I/O, or multi homed computers that use multiple NICs to route traffic.
  • Special workloads. Special workloads include applications that use multiple tiers (N-tiered), applications that span multiple sites, applications that require custom hardware or dongles to work, or applications over which you have no ownership. The latter often requires you to launch a negotiation with an application’s “owners,” which may include other business units, departments, groups in different locations or even other groups within IT.

Obviously, you want to begin a migration process with the most basic applications and, once you gain experience with the process, then progress to more complex workloads. Further, when ownership is in question, your special workloads may require a lot of negotiation with other departments and their stakeholders. So this sometimes lengthy administrative process should begin as soon as possible.

VM provision approaches

Nearly everyone knows that an upgrade leaves behind a ton of garbage and can destabilize a server. So the best machine is a clean machine, one that was cleanly installed and to which the workload has been newly applied. In IT, this caveat has proven itself time and time again. When organizations face an operating system migration, especially a server OS migration, they rarely opt for an upgrade and most often choose to create a pristine installation of the new OS and migrate the workload to that new OS image. The same applies to your new virtual machines.

Still, the bottom line is that moving to a virtual infrastructure is supposed to be a simple process that should remove— not add—overhead to administrative processes. This move should not add a massive workload to your overstressed administrative staff. That’s why most virtual infrastructure manufacturers— VMware Inc., Microsoft Corp., Citrix Systems Inc. and others—offer a P2V conversion tool to facilitate this process.

These tools target a physical server and convert its disks into virtual disk drives. The key to this process is driver injection. Because physical machines rely on custom drivers—drivers that are specific to the hardware platform—these drivers must be converted to the generic drivers that are used in the virtualization platform you have selected for your virtual infrastructure (see Figure 1). The P2V engine must be able to properly replace hardware drivers with the virtualization drivers you need to use. If this process does not work or does not work completely, you’ll confront broken systems and unstable servers.
For this reason, organizations must test P2V processes in a laboratory environment before moving them into production. Of course, P2V tool manufacturers promise that with practice you can move machines from physical to virtual and sometimes back to physical environments during their operation without encountering failure. Some even promise the ability to do so while a machine runs. While this might work for simpler workloads, it is unlikely to be effective for all your workloads, especially complex or special ones.

In the end, your P2V process consists of three approaches, each of which offers benefits and poses risks

Manual P2V: The first approach involves the creation of a brand-new virtual machine running a stable OS configuration. This VM serves as the seed machine for all workload migrations. If you have multiple OSes in your data center, you may require more than one seed machine, but keep the number to a minimum. To duplicate this seed machine, use a re-branding or a provisioning process as required. Citrix XenServer 5, for example, provisions any number of virtual machines on the fly when you point it to a specific seed machine. Other hypervisors also support the process of generating new machines from seed VMs. Once a new machine has been provisioned, you use the workload’s internal migration capability to move the service from the physical to the new virtual machine. While this process can be more time-consuming than other methods, it provides excellent results and ensures a more stable system.

Semi-automated P2V: The second approach consists of using a free or offline P2V conversion tool to move the workload as is and convert the operating system from one contained in a physical machine to one contained in a VM.

While this process can be riskier than the first approach, it’s sometimes necessary when a workload lacks a migration capability of its own. This is often the case for legacy or custom in-house code. Because the tools offer offline conversion—where the source machine is taken offline during the conversion process—some manual operations may be required once the conversion is complete. This method relies on tools such as Microsoft System Center’s Virtual Machine Manager or VMware Converter (that is, the downloadable version) to move servers from a physical state to a virtual machine. And as with manual processes, this process is time consuming because of the manual operations required to fix conversion problems that can arise from an inadequate plug-and-play process during driver conversion.

Fully automated P2V: Fully automated conversions execute while a physical system runs, copying disk drive contents to virtual disk drives and then booting a VM to replace a physical server’s workload. For this method, use a tool that migrates a server over a network without user interaction. There are several such tools on the market, such as those from PlateSpin Ltd. and Vizioncore Inc. that support VMware, Citrix and Microsoft platforms as well as corresponding tools from each vendor. These tools are often expensive but usually work well for your most common workloads.

P2V preparation

Cleaning up your environment: Before you begin the P2V process, you need to clean up your server environment. You don’t want to find yourself amid a massive file server conversion only to discover that 90% of the files on the server haven’t been accessed in months and are ready for archiving. Use your network analysis to determine which machines should be migrated first. To do so, rely on metrics such as hardware requirements, software dependencies, licensing requirements and current resource utilization ratios.

Minimizing downtime: Because migration copies the contents of physical disk drives to virtual ones, the process relies heavily on the network to move data from one machine to another. As a result, the process of migration can involve downtime. And while several technologies support live conversion from physical to virtual machines, you’ll generally perform these conversions offline and during maintenance periods. So IT needs to schedule downtime—and possibly even a special migration period —and negotiate with its stakeholders to pre-empt migration issues.

When machines have redundant services, downtime risks decrease considerably. If you migrate a service running on a server load-balancing cluster, for example, you shouldn’t experience downtime. As a migration takes place, you enable another node to take on the load. Note, however, that this strategy does not work for all-in-one servers such as Windows Small Business Server (SBS). In such cases, all server roles run on the same machine, so virtualizing technologies like SBS will most certainly involve downtime.

Storage considerations: Also make sure you are prepared for the migration process. Do you have enough storage to virtualize all the machines you’ve targeted? You should use storage virtualization with thin provisioning and target the creation of dynamically expanding virtual disks in order to minimize the required amount of storage. During the conversion, can your network sustain the load? If you are at peak performance today, adding a conversion workload may overly stress your network.

Support: Determine whether providers support virtualizing these applications. Over the past 10 years, vendors that do not support virtualization have become far rarer, but you should always check on proper application support. Oracle Corp., for example, supports the virtualization of its applications only on its own virtualization platform. Organizations virtualizing Oracle on different hypervisors must return workloads to physical machines to obtain support.

In other cases, vendors offer a “best effort support policy”: that is, they will try to help solve issues, but if they can’t find a solution, you may have to revert the workload to a physical system. Microsoft, for example, offers such a policy for the support of its applications within non-Microsoft virtualization environments unless the virtualization platform has been validated by the Microsoft Server Virtualization Validation program. Both Citrix and Vmware hypervisors have been approved by this program. And others, like Oracle, may request that you convert the workload back to a physical platform in order to provide support for special problems. As you select a P2V tool, keep these support issues in mind. Because of these considerations, you should also consider integrating the backup tool you select with the ability to convert machines from one state to another; backup tools actually store the contents of each machine in a separate container before moving the contents to a VM.

Number of conversions required: The number of conversions you need to make is a factor in determining which tools to use. If you run a basic network with workloads that are classified as simple, you may be able to rely solely on a manual conversion. If you have several legacy workloads and can take them offline during a migration, you can rely on free or integrated conversion tools. If you have a high volume of workloads to migrate, you’ll most likely want to use both the manual and the fully automated method. In this case, you’ll also want the ability to convert virtual machines to physical ones. These reverse conversions may be required to obtain support from certain application vendors. While over time the need for these reverse conversions will decrease and possibly disappear, they are still necessary in the early stages of a hypervisor implementation.

In large data centers, you may need a tool that can perform not only P2V conversions but also V2P conversions because large data centers run a wider variety of workloads than do their small or medium-sized counterparts. If you operate a large data center, the best strategy may be to combine the requirements for backup and restoration with the requirements for machine conversions.

Drivers and the backup process: When you think about it, a P2V conversion is really nothing more than a backup of physical drives. Ideally, you can use a tool that backs up any machine—physical or virtual—then stores this backup in a central location. In this case, disk image backups are often the best. When the time comes to restore a machine, you can then move the image from this central backup location to any physical or virtual target.

But central here is the ability to update OS drivers when the restoration process runs. Many such tools can point to a central driver store to first obtain them and then inject them into the image as it is restored. From this point forward, the tool can support backups, restorations and conversions from any machine— whether that machine resides in the resource pool or in virtual service offerings.
Several tools on the market offer support for this. Consider disk imaging vendors such as Acronis Inc., which offers the True Image line of products, or backup vendors such as Symantec Corp., which offers a comprehensive line of backup products to evaluate the best tool for your needs.

A P2V Checklist

Once you’re ready to perform the actual P2V operation, you should use the following approach:

  1. Determine the validity of the candidate for migration.
  2. Clarify provider support for the virtual workload.
  3. Consider licensing costs, and if necessary, make adjustments.
  4. Identify the appropriate host for the virtual machine.
  5. Identify CPU and memory requirements for the virtual machine.
  6. Identify the storage location for the virtual machine’s files.
  7. Identify network requirements and ensure that the appropriate virtual NICs are available on the host.
  8. Identify a failover strategy for this VM.
  9. Use a standard naming strategy to differentiate the new virtual service offering from the physical host that used to run the workload.
  10. Schedule downtime in support of the migration. You may not need it, but if you do, it is safer to have it ready.
  11. Prepare your testing plan for the new VM. First run the virtual machine in a lab to ensure that it’s stable.
  12. Prepare a go-live plan for the VM once it passes all tests. This go-live plan should include the decommissioning of the physical host.

A safety-net strategy. In order of importance, select appropriate migration candidates. Your migration strategy should first tackle low-risk, non- business critical workloads such as the test and development environments you run. This enables you to master the P2V process without incurring the costs of missteps. Web servers are also often good candidates for initial conversion. If your website is properly set up, you may already have redundant Web servers running through technologies such as Microsoft’s Network Load Balancing service. Having redundant services reduces the risk, especially for your first P2V experiments. Then move on to low-use systems that host less-critical applications. Next, work on higher-use systems that are not critical. Such candidates could include application-specific servers or routing and virtual private networking servers. Migrate servers running critical workloads last. At this point, you should be familiar with the process and ready for any eventuality.

Finally, remember to build on your successes. P2V migrations are often onetime procedures and once machines have been properly migrated, you will rarely need to touch their workloads again. In some instances, of course, odd workloads need to move back and forth should support issues arise. Be ready, become familiar with your tools and have a fallback strategy for each conversion.

About the Authors

Danielle Ruest and Nelson Ruest are IT professionals who focus on technology futures. Both are passionate about virtualization and continuous service delivery. They are the authors of multiple books, including Windows Server 2008: The Complete Reference published by McGraw-Hill Osborne, which explores building virtual workloads with this powerful new OS. They are currently writing Virtualization, A Beginner’s Guide for McGraw-Hill Osborne. They are also performing a multi-city U.S. tour on virtualization. If you have comments or suggestions, contact the authors at [email protected]

Dig Deeper on Virtualized test and development environments