P2V is not a panacea it is a Pandora's box

I monitor many forums where folks are constantly dealing with problems caused by converting a physical computer to a VM or taking a VM from one hypervisor and moving it to a different hypervisor.

I have one statement for these folks:  P2V is not a panacea, it is a Pandora's box.  P2V brings baggage.  It is this baggage that causes problems both during and after the conversion.

Now, don’t get me wrong, I totally understand why folks want to perform a P2V and I also understand why folks want free tools.

In regards to free tools – you get what you pay for.  I don’t think I need to say any more.  This means that there will be bad experiences, your chances of having a problem are high.

Let me back up and talk about V2V a little.  In this case it all comes down to hardware.  The simple example is the boot disk interface.  VMware presents a SCSI disk, Hyper-V presents an IDE disk, XenServer presents what looks like an IDE during boot.

If you have ever taken a Windows Server backup (Windows 2003 or older) and then tried to apply that to new hardware you quickly learn that device drivers are the big problem.  And this can be simply new SCSI arrays, let alone converting from SCSI to SATA, or IDE to SCSI.

The other big issue is hypervisor ‘tools’ that are installed into the VMs.  There is a total mixed bag here.  The optimum would be that the tools can be installed and they have no proble,s if that VM is moved to a different hypervisor, but that is not the case.  For best results, remove the hypervisor tools BEFORE migrating the VM.

I have talked about this before:

• http://itproctology.blogspot.com/2009/04/migrating-vms-between-hypervisors_10.html
• http://itproctology.blogspot.com/2008/12/you-want-to-convert-machine-to-vhd.html
• http://itproctology.blogspot.com/2009/02/do-you-know-where-your-vm-has-been.html

Back to P2V.

We still have to deal with hardware changes as described above.  And there are device drivers and agents as well, very similar to the ‘tools’ situation described above.

Many folks install hardware monitoring agents when an OS is installed on a physical box.  These agents can cause all kinds of problems following a P2V.  As with the ‘tools’ uninstall the agents prior to conversion.

Now, there are also ghost issues that will crop up over time.  This is just inherent in any system when the hardware is changed.  There are small device driver miss-matches, MAC address problems, application problems, etc.

It has always been the BEST case to build the entire server on the new hardware and then install the application and migrate any databases or other requirements.

Personally, I see two reasons for this:  1) you really understand your application and you can document a full rebuild for DR reasons.  2) you will get the absolute best performance of the application in the VM, no baggage.

OVF vs OVA the saga continues

It has been over two years since I began working with the OVF standard from the DMTF.

Repeatedly during this process I have had to educate folks about what an OVF package is, and quite frequently what an OVA is and when to use it.  Just yesterday I corrected a person in a conference call as this is still a relatively new thing to most folks.

In very simple terms, an OVA is a single file.  It is a TAR archive of an OVF.  It simply has the file extension “.ova” to give some indication that it is an OVF.  Otherwise it would be just any other “.tar”

The OVF is the real important part that the DMTF keeps defining and expanding upon.

The OVF package is basically two things. 

1. It is an XML file that describes the virtual environment (vCPU, vRAM, vNetwork config, and it lists references to any other parts of the OVF package).
2. It is a collection of files.  Virtual disks of virtual machines, .ISO installation media, any other file attachments that a person could dream up.

Use OVA when you need to take an OVF package somewhere.  Or want to give it to someone as a download.

Use an OVF for all of your internal purposes.

Is OVF a promise that an appliance can be imported to and run on any hypervisor?  Absolutely not.

OVF is NOT a way to convert workload from one platform to another – no reason why it could not be used that way (it makes sense) – but that is not why it exists.  Eventually I see companies implement conversions around OVF packages.  The closest thing I know of today is the “fixup” that is in the Citrix Kensho implementation.

There are two reasons why:  The OS installed in the VM and its built in driver support and that different hypervisors present virtual hardware in different ways. 

To a lesser extent there is a third reason: proprietary VM tools.  The tools from vendor A can prevent a VM from running on a different hypervisor (or at least make it really difficult) or they can cause the performance of the VM to be very poor on the new hypervisor.

So, the moral of the story:  Use OVA appropriately and don’t expect an OVF package build on one hypervisor to “just work” on a different hypervisor.  And be wary of VM tools installed within the VM.

PowerShell DateTime to CIM_DateTime

Obviously no one that is using PowerShell is using WSMAN against a remote Linux system.  Everything assumes WMI, simple enough.

Use WSMAN against Linux and you enter into a insane land of XML and properly formatting your XML.

Take for example the simple act to send an XML string that queries a time period.

In PowerShell you type Get-Date and you get a nice, human friendly value back: Wednesday, May 05, 2010 10:24:14 AM

Now, try to send that to a CIM provider of any type (in my case a CIM provider that sits behind a WSMAN interface) and you immediately get a value invalid error.

off to Bing-land.. searching, searching, searching – absolutely nothing.  Wait, there are a couple useful things…

on MSDN the Scripting API Objects, the SWbemDateTime Object.  The what?  you say.  Isn’t it obvious? (I didn’t think so).

Here is the kicker, the CIM_DateTime format.  It expects this really strange format that looks like this:  yyyymmddHHMMSS.mmmmmmsUUU

So how do I take this:  Wednesday, May 05, 2010 10:24:14 AM and turn it into this: 20100505102415.000000-420

I have to play with objects in PowerShell, here is my script part:

$startTimeWindow = ((Get-Date) - $9Minutes)
$objScriptTime = New-Object -ComObject WbemScripting.SWbemDateTime
$objScriptTime.SetVarDate($startTimeWindow)
$startTime = $objScriptTime.Value

I first set my time window to begin 9 minutes before ‘now’.  I then create a SWbemDateTime object from the Wbem.Scripting class.  I then take the start of my time window and set this friendly formatted time to the object.  Then I retrieve the value of the object and I have a CIM_DateTime to send off to my Linux system CIM interface (through WSMAN).