PlateSpin, Leostream ease the move to virtual datacenters

When planning a datacenter migration from P2V (physical to virtual), rebuilding servers in the virtual realm to take over for their physical counterparts is a task that must be accomplished manually — a complex, arduous, and money-burning effort. So what could be simpler than running a few apps on the target physical servers and magically watching them boot in the virtual realm?

Free IT resource TechNet: More ways to know it, share it, and keep it running. Sponsored by Microsoft Free IT resource Attend the SOA Executive Forum: Breaking SOA Bottlenecks SOAExecForum.com/may2007 Sponsored by InfoWorld

Arguably, P2V migration is significantly easier on Linux than on Windows. Most enterprise-level Linux servers run with kernels that can handle abrupt hardware changes with aplomb. Windows Server 2003 is much better at handling hardware changes than previous iterations, but substantial hardware layout changes are still likely to result in an unbootable system or to cause odd, unexplainable problems with normal server function.

PlateSpin and Leostream’s P2V tools address these core difficulties. Leostream P>V supports Windows NT and Windows Server 2000 and 2003; whereas PlateSpin’s PowerConvert tool can handle several Linux distributions as well as the major Windows server platforms on the source side. Both can migrate to virtual servers hosted by VMware GSX and ESX Server, and Microsoft’s VirtualServer virtualization platforms.

To test these two P2V solutions, I built a few physical servers to be used as migration guinea pigs and deployed a fresh installation of VMware ESX Server 2.5.3 on a target VM host system. As with any virtualization platform, they needed plenty of memory, and Corsair came through with 8GB of DDR400 RAM.

I tasked both tools with one of the more worrisome Windows server migrations — migrating an active Windows 2003 SP1 Active Directory DC (domain controller). In the lab, I built a fresh DC on a Dell PowerEdge 2600 server with two NICs, a 50GB RAID5 volume running on the Dell PowerEdge Expandable RAID Controller, and 4GB of RAM. I then ran each conversion utility on the server to migrate it into a new virtual server running on an IBM Server x3550 running VMware ESX Server 2.5.3.

PlateSpin PowerRecon and PowerConvert

PlateSpin’s VM offerings are split into two distinct products: PowerRecon and PowerConvert. Both are decidedly Microsoft-based, requiring IIS and the .Net 2.0 framework; both are built on this Web app foundation and generally require a dedicated server.

Aptly named, PowerRecon’s sole mission is to analyze physical production servers for resource utilization and to develop a migration strategy to move them to the virtual realm. To do so, it inspects each server’s CPU, RAM, disk, and network I/O utilization on a set polling interval. For Windows servers, these data points are collected via WMI; on Linux servers, the procedure involves SSH sessions and text parsing of command output. PowerConvert handles the actual P2V migrations.

Armed with the collected data, PowerRecon creates scenarios that lay out a suitable virtual infrastructure to accommodate the same service load. The creation of these scenarios involves more than simply trying to fit workloads into virtual space; PowerRecon can create scenarios based on hardware profiles developed by admins.

Such profiles can provide useful information, but I found that getting the real data out of the application was somewhat of a hassle. Oddly, PlateSpin’s offerings don’t support RHEL (RedHat Enterprise Linux) 4, which was released well over a year ago. PlateSpin does plan to include support for RHEL 4 by the end of 2006, and I hope that happens soon.

I installed each application on a virtual Windows 2003 Server, with PowerRecon running on a VMware GSX server installation and PowerConvert running on another virtual Windows 2003 Server on an ESX host server. The applications performed well as long as their respective virtual servers were granted the resources required.

PlateSpin’s take on P2V differs greatly from Leostream’s method. All  migration steps are handled by the central server, much the way tape backups are. Jobs can be scheduled, saved, and replayed, and multiple jobs can be run simultaneously.

The process begins by creating a new VM on the destination server with the appropriate configuration as specified by the migration control panel in the UI. This portion of the process dictates the RAM, CPU, and disk resources to be granted to the resulting virtual server, and it allows for dynamic resizing of NTFS volumes on the fly.

After it has been created, the new VM boots with an ISO image that runs a thin version of Windows XP with no other purpose than to bring up the network, find the local disk volume, and download the controller code from the migration server. When this process is complete, the server has control over the VM.