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.
Switchback
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.