Three scenarios when it's worth paying for third-party P2V tools

Third-party P2V tools are expensive, but there are some important use cases that make a robust P2V migration product well worth the expense.

Moving a handful of physical workloads to virtual hosts -- or what's commonly referred to as a physical to virtual (P2V) migration -- can be a pretty trivial task. Each major hypervisor provides the P2V tools you need to take a beige box running your favorite version of Windows or Linux and add it to the many virtual workloads running in your virtualization cluster. VMware Converter and Hyper-V Virtual Machine Manager (VMM) both have decent features for moving basic workloads. With VMware Converter coupled with vCenter, you can even schedule when you want a P2V migration to take place.

But what happens when you need to move a couple hundred or even a couple thousand workloads, need to convert workloads with hundreds of gigabytes or terabytes of data, or even need to roll back from virtual to physical after encountering post-migration problems? In these cases, VMware converter or VMM just won't cut it, especially if you need to minimize downtime between conversions. There are few things more frustrating than returning from the weekend to find that a scheduled migration failed or didn't finish during the conversion window.

This is when it may be time to start looking at third-party P2V tools that offer more robust features. These products are not cheap, however. Before you shell out good money for a third-party tool, consider the use cases for when third-party P2V tools are worth the expense.

Use case No. 1: Migrating large VMs

The typical maximum virtual disk file size is 2 TB, but virtual disks that large are rare because migrating a disk that large from volume to volume can be problematic. However, even if you wanted to migrate 2 TB of data from a physical machine to a virtual machine (VM), the chances of the copy failing over a 1 Gigabit Ethernet or 10 GbE network are fairly high. The chances are even higher over a WAN link. The other challenge is that there's a good chance that the data transfer will carry over into production hours, which may affect the user experience for other network applications. Another annoying challenge is dealing with files changed by users during the copy process or after the copy process is complete, forcing you to manually copy files post-migration.

Third-party products, such as NetIQ PlateSpin Migrate, allow you to perform differential data syncs similar to the way backup products allow you to perform "synthetic full backups." The concept is familiar to those of us who have the pleasure of managing backups. Once an initial sync is performed, you can schedule a migration to occur with only the delta being transferred; reducing the downtime associated with migrating large volumes.

Some of these tools even allow you to schedule the automatic shutdown of the target machine and start the VM, which allows a smooth cutover. Ideally, you could perform an initial sync one weekend, then schedule a final sync and cutover the next weekend. The end users would only have a short downtime during the time it takes to do the final sync and boot the virtual server.

Use case No. 2: P2V migration over a WAN

There are a couple of challenges with performing a P2V migration over a WAN connection. Sometimes the data set can be too large to migrate over a slower connection, and large migrations can consume a lot of bandwidth. Third-party products often have a couple of methods to overcome these challenges. The first is the ability to migrate the data in scheduled windows and perform delta-based replication.

Some third-party tools also allow you to throttle bandwidth. But in practice, this isn't a magic solution. It's similar to when you perform backups using a throttling setting; There is still a direct relationship between the size of the network connection and the amount of data you need to migrate. This is no magic solution for migrating a 100-GB image over a T1 connection. It's meant as a feature to balance migrating small office workloads over decent connections without affecting user traffic during production hours.

Use case No. 3: V2P and P2P migrations

The third scenario is when you need to revert a VM back to a physical machine (V2P) after an extended time in production. Unfortunately, after the change window has passed, it's never as simple as implementing your fallback plan. I've run into situations where workloads functioned perfectly fine as VMs but they were just not economical for a cluster. For example, a database server that needs 32 GB of RAM (or as much as you can throw at it) to perform optimally isn't a good choice in a cluster where each host only has 32 GB of RAM. You may ultimately find moving the workload to a physical host is a better use of resources.

Another scenario is when you need to move workloads from one physical platform to another (P2P). A couple of cases that are great examples would be moving a workload from one physical location to another, or needing to move a workload to more (or less) capable hardware.

There are a couple of critical features to look for that help with P2P and V2P migrations. One of the largest challenges in moving to different hardware platforms is getting the copied image to boot on new hardware. This can be a challenge even when you're moving between hardware from the same vendor within the same model and generation. For example, if you tried to move a Windows 2008 R2 64-bit image from a HP DL 360 G6 to another HP DL 360 G6, but with a different RAID controller, there's a good chance you'd get a blue screen of death. Another example is taking a virtual Red Hat Linux workload and moving it to a physical hardware platform. Will the server boot?

Some of the more mature products will allow you to slip drivers into the migrated OS or disable incompatible drivers and software prior to booting on the new platform. This can save hours of troubleshooting on the new target platform and makes going back and forth between physical and virtual a realistic option.

Options for third-party P2V tools

NetIQ PlateSpin Migrate -- I've used PlateSpin in the past to do a large-scale migration. It's a robust product but has a steep learning curve. I found NetIQ's support to be good when Novell owned it directly. I haven't had much experience with the product since Attachmate purchased Novell.

Doubletake Move -- I've used Doubletake's traditional tools to protect physical workloads by replicating the system from one hardware product to another. They've leveraged their expertise to provide a combined P2V tool and virtual-to-virtual tool. I've found their replication technology to be solid in the past.

Quest vConverter -- I have the least experience with Dell's Quest software. However, Quest has been a respectable name in virtualization management tools for years. At one point prior to Dell's purchase of Quest, vConverter was a standalone product. Now it seems as if you can \ purchase it only as an option with vEssentials.

Putting it all together

These third-party P2V tools are what actually make full P2V data center migrations, consolidations and transformations possible. The right tool can allow you to migrate hundreds or thousands of workloads to hosts located a few hundred miles away just as easily as migrating workloads a couple racks away. Even if you aren't looking to migrate a large number of VMs, these tools provide some extremely flexible options for tricky workload migrations. However, I've found that the learning curve to get these products up and running is steep. As I've mentioned, many of their features are similar to those in robust backup products. The effort to implement and support these products is a little greater than installing a similar backup product. For example, PlateSpin requires an entire SQL back end to manage and track migration jobs, similar to a full-scale backup tool.

I'd like to hear from you about whether you've tackled large migrations or consolidations, and what tools and features you've found indispensable during them.

Dig Deeper on P2V, V2V and V2P migration