Conversion applications move a working host into its new virtual environment along with its stored application images in tow.
Unless VM guests are installed from 'bare metal' operating systems and application media, guest instances are converted from an existing stable VM that has a specific foot print that regards its memory needs, disk displacement plus future storage needs, network I/O requirements and settings, and needs for raw CPU power.
Converting that stable platform requires preserving many characteristics, including operating system-specific files, settings, and user and group attributes. On top of that, the servers must maintain access to external resources, such as DNS servers, certificate authorities, directory services, external databases, and the links that are components/resources to a working server.
PlateSpin's PowerConvert aims to be an egalitarian provisioning product that seemingly doesn't care which virtual host platform you are working with. Its main goal is to help move a server process from point A to point B. In PlateSpin's realm, these points could exist in either the virtual or physical worlds, or have a foot in both. PlateSpin supports P2V, V2V, V2P, P2P conversions, P2I (physical to image), V2I, I2V and I2P deployment.
The key to PlateSpin's proposition is that it uses a procedure of conversion that's designed to provide at most, a single re-boot. This is obviously a beneficial trait in any conversion product because it minimizes server downtime. Likewise PlateSpin's product assists in hot failover and disaster recovery scenarios as essential services and other mission-critical systems can be mirrored in live or standby modes on physical or virtual backup resources. Of course, the one reboot claim comes with the caveat that you'd likely have to run several test conversions before attempting one on a live, mission-critical server.
PowerConvert analyzes candidate servers to take an inventory code and correlate services running on them. Once the systems are fully understood, the task of dragging a working system that may consist of just a few files and service profiles, or very many can proceed in various ways. The server's workload can be consolidated onto a larger server, converted in its entirety to a candidate virtual or physical resource that can serve as its replacement or run as a standby backup or archived into a image repository for backup or other purposes.
Installation of the PowerConvert server components requires the Microsoft .Net 2.0 framework running on the Windows 2003 Enterprise Server platform, which isn't included in the distribution. We had Windows 2003 running on a VM in our lab, but had to manually upgrade the system with thee required .Net components. We used both a CentOS 5 and Windows 2003 Enterprise Server to produce image archives, gold masters or build-groups of server/client operating systems that were typical configurations for running production servers, which we wanted to convert with the PlateSpin product.
We tested PowerConvert on both Virtual Iron and VMware virtualization platforms. It analyzed software running on both platforms quite well and understood the small differences in formatting between the two platforms perfectly.
The conversion process, whether scheduled or live, proceeds through a detailed step-by-step checklist that helps to pinpoint exactly where any conversion may have failed. If, during the conversion processes, there is a failure at any step, a helpful error code is registered. PlateSpin provides a searchable knowledge base of possible errors that can occur during any conversion and provides guidelines to remediate the issue.
We used PowerConvert to run the gamut of migrations, checking P2V (Windows and Linux) as well as V2V, I2V and V2I images of running platforms on the target platform. Processes included in these images are DNS, file/print services, networking configurations, and in the case of Linux, sendmail/procmail. The only glitch we encountered was occasionally, and not repeatedly, PowerConvert would be unable to stop services on Windows servers during P2V conversions.
However, simply fixing the error and restarting the process where it left off never worked for us; instead, we had to restart any failed conversion from the beginning, a measure that resulted in a complete conversion. An administrator needs to monitor and shepherd the process closely as SMTP alerts are the only method of knowing something's gone wrong in an unattended conversion. An upside is that the conversion(s) can be scheduled to run during quiet network time if the conversion process has been stabilized.