Tools help migrate servers to virtual realm but have some room to grow
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?
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.
Next, a bootable image installs on the source system, and the server is rebooted to that image, which is identical to the image running on the destination VM. With both controllers running on the source and destination servers, the PowerConvert server steps in the middle and conducts the migration, block by block.
By running limited Windows code on both servers, PowerRecon can modify the OS parameters necessary to ensure that various hardware devices are removed from the destination VM, paving the way for a clean migration. The big downside is that the process is relatively long and requires the source server to be brought down for the entire migration.
In the lab, PowerRecon took just less than an hour to complete the migration process and bring up the newly migrated VM. During this time there was scant output from the tool other than sporadic progress messages, although the job logging provides a better view of the process.
The migration finished successfully, following several reboots of the destination server and the powering down of the source server. A little bit of a hiccup occurred here, as I couldn’t use the mouse or keyboard in the new VM’s console, but I could RDP into the server and verify that it was up and running. A short time later both input devices suddenly became active, and I was able to use the console normally. At the end of the whole process, the test domain controller was successfully migrated to a new virtual server with all services up and running.
I ran this same migration using PlateSpin’s new LiveTransfer option, which is similar to Leostream’s P>V in that it doesn’t require the source server to be taken offline prior to the conversion. Unfortunately this test didn’t end well, as the converted server booted with several broken AD services, requiring AD restore mode.
PowerRecon does offer plenty of disaster-recovery and imaging features. You may create a disk image of both a physical system or a virtual server, which can be pushed back to the hardware. PowerRecon can also migrate virtual servers to physical servers, although I didn’t test this capability.
Leostream P>V 3.0
Leostream’s solution has none of the bells and whistles of PlateSpin’s PowerConvert, and it doesn’t offer anything similar to PowerRecon, but it does handle P2V migrations well.
P>V consists of an RPM Package Manager that’s installed on a target VMware ESX Server, and an application that runs on the physical server to be migrated. When I first fired up the application on the physical test server, I was expecting to set up the app and then determine the steps necessary to migrate the server. Instead, I found a wizard, which walked me through the migration process. Within five minutes, it was moving the server to its new virtual home. That’s P>V in a nutshell — no fancy UI, just a simple P2V migration, without the reboots.
The emphasis on a quick and easy migration certainly has its benefits. If you’re migrating only a few servers, P>V’s very small footprint is hard to beat, and the lack of required reboots can be a significant benefit. It also finished its task quickly, requiring about half the time of PowerConvert to migrate my test physical server.
Leostream’s migration process relies on a Linux-based VM preparation environment, which boots immediately after the tool creates the destination VM. This Linux environment turns up the network, locates the destination disk volume, and then waits for the app running on the source server to begin the migration process.
To actually migrate the server, P>V transmits the source disk volume block-by-block to the destination server, which then writes those blocks to the VM disk. This can be done while the source server is still running but requires that the destination VM’s disk be the same size as the source. There are facilities within the tool to handle NTFS resizing, but as opposed to with PlateSpin, it’s not done on the fly. Thus, if the source server has a 50GB volume, the destination VM will be built with a 50GB disk, even if there’s only 5GB of data on the source volume, although it can be manually resized later.
In the lab, I ran P>V’s converter on the source domain controller. It created the destination VM, booted Leostream’s VM controller, and the source server began the migration. The process completed in about 20 minutes, and the new VM booted.
At this point, I saw some problems. The initial boot of the VM seemed to take much longer than it should have, which I attributed to Windows dealing with the hardware changes. After the server finally booted, I logged in — which also took quite awhile — and found what I expected: The network adapter IP information had not migrated with the server.
I remedied this, but the virtual server continued to perform poorly, even after installing the VMware server tools. I traced the problem to a probable storage driver compatibility issue in the source server, leading to invalid driver parameters being retained on the destination VM and causing significant disk I/O problems. With this in mind, I performed a migration of another physical Windows 2003 Server and had no performance issues.
These tools represent two different solutions to the P2V problem. PlateSpin’s PowerRecon and PowerConvert are thorough but heavy applications, requiring a dedicated server and several reboots to complete the P2V process. Leostream P>V is more streamlined, having a tiny footprint and no central server, but it lacks the tools and management framework of PlateSpin’s toolset.
Thus, Leostream is a very good candidate for smaller P2V projects and for constructing a development network that mirrors a physical production network. PlateSpin can do this as well but adds significant management and planning utilities that you may not need in many circumstances.
P2V tools aren’t yet a mature technology. Dealing with scores of potential hardware combinations on the source end leads to an enormous amount of “corner-case” issues when performing these migrations. P2V is still the best way to go if possible, but be prepared to rebuild a server or two the old fashioned way.
Ease of use (20.0%)
Overall Score (100%)
|Leostream P>V 3.0||8.0||7.0||7.0||9.0||7.0|
|PlateSpin PowerConvert 5.5||7.0||8.0||8.0||8.0||8.0|
Microsoft buried a Get Windows 10 ad generator inside this month's Internet Explorer security patch for...
Hot or not? From the Web to the motherboard to the training ground, get the scoop on what's in and...
Microsoft’s 'Fall Update' promised to put the finishing touches on Windows 10 -- it doesn’t
Stop procrastinating and make the switch from SHA-1 to SHA-2. You may already be getting errors -- and...
What is blindingly obvious to many is still something new to many others, reflecting the reality of how...
Cloud migrations often expose a decades-old architectural decision that can require expensive rework ...
Memcached is sometimes more efficient, but Redis is almost always the better choice