PlateSpin, Leostream ease the move to virtual datacenters
Tools help migrate servers to virtual realm but have some room to growFollow @pvenezia
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.