PlateSpin PowerConvert Part 1: Overview

 

I sat the Certified PlateSpin Analyst (CPSA) course last week, and I have been experimenting with an evaluation version of PowerConvert 7.0 in my home lab so I thought I would write up a series of posts with a step by step guide on the P2V and V2P processes so you can see what this nifty application can do, in a later part I’ll look at the Workload protection feature for disaster recovery.

Platespin PowerConvert is now owned by Novell and the key thing to understand is its principal of “Workload portability”, where a “workload” is a server/application/data combination on a server or virtual machine.

PlateSpin use the term X2X to describe what it is capable of, and indeed it’s true it can do the traditional convert from a physical machine to a virtual machine (P2V) process like VMWare’s own convertor, but it can also go the other way and convert a virtual machine into an installation on a physical server (V2P) – it can accomplish this by maintaining a database of hardware and software specific drivers which are injected into the OS image when it is transferred to the target hardware.

You can add your own drivers, and it’s very simple to use – I verified this as I added some HP BL460c drivers to the database, you simply extract the driver package from the vendor (which usually consists of .inf .sys files) and locate it via the “upload drivers” option, its then automatically imported into the database.

PowerConvert’s other party trick is V2V – where it can convert virtual machines between different hypervisors (VMWare ESX –> Xen or Microsoft Virtual Server –> ESX) this is useful if you maintain a heterogeneous environment.

All of this is achieved within the VM/OS itself; PowerConvert installs an agent inside the source and target machine or boots it from a WindowsPE/Linux boot CD (Cold Clone).

Once this process, known as “Take Control” has completed the PowerConvert server initiates a disk or file level clone of the source OS, applications and data direct from the source to the destination.

This is analogous to booting a virtual machine or physical server from a Linux/WinPE boot disk and running a disk imaging utility like Symantec Ghost, dd or ImageX – except rather than writing to an image file (although it does also support that too!) the image is written directly over the network to the disk of the target machine (virtual or physical) which is also booted into a Linux/WinPE boot disk.

During the transfer PowerConvert “injects” the appropriate hardware drivers into the OS image to support the target platform and removes the un-required drivers from the source server.

It is important to note that whilst PowerConvert can manipulate ESX servers directly to mount .ISO images to VMs it does not do anything directly with the .VMDK files; all the conversion occurs in-band within the virtual machine. This may seem a bit inefficient compared to VM Convertor but it is how it manages to achieved such flexibility in moving OS/App/Data images between so many different virtual and physical platforms.

It supports specific source/target OS’es – list here

PowerConvert and it’s sister product PowerRecon are key products in my internal cloud reference architecture as they are what enable you to be totally flexible in how you provision, change or decommission server instances by removing almost all dependencies on underlying hardware or hypervisor choices.

The next post will give a step by step guide to doing the P2V part of the conversion.