Project Kensho OVF

One fo the reasons I love virtual machines is because they are mobile.  Most of them (except RDM and passthrough disks) are just files, making them easy to migrate, copy, export, and import.  But this is lmiited to the same virtualisation platform.  Changing virtualisation platforms requires a tricky V2V process that vendors have made one-way.

Citrix has unveiled a solution with the codename of Project Kensho.  It leverages the Open Virtualisation Format (OVF) standard  (developed by  Citrix, VMware, Dell, HP, IBM and Microsoft) to allow the movement of virtual machines from on virtualisation platform to another.  You can think of OVF as playing the same role as XML in business integration solutions: it’s a stepping stone.

The solution is expected to ship by Citrix in September.

What does this mean to you?  OVF gives us a standard way to V2V virtual machines between many virtualisation platforms, depending on the support offered by those platforms for OVF.

According to wikipedia:

“VirtualBox supports OVF since version 2.2.0 (April 2009).  AbiCloud Cloud Computing Platform Appliance Manager component now supports OVF since version 0.7.0 (June 2009).  Red Hat Enterprise Virtualization supports OVF since version 2.2.  VMware supports OVF in ESX 3.5, vSphere 4, Workstation 6.5, and other products using their OVF tool.  OVF version 1.1 is supported in Workstation 7.1 and VMware Player 3.1 (May 2010).  IBM supports OVF format VM images on the POWER server platform for the AIX operating system and Linux, and for Linux on z/VM on the mainframe using IBM Systems Director (via VMControl Enterprise Edition plug-in, a cross-platform VM manager”.

MS executives have confirmed in the past that VMM v.Next will include added support for XenServer management.  We know MS and Citrix are veery tight.  MS staff recommened XenDesktop as a VDI solution and Citrix are currently recommending Hyper-V for virtualisation.  It won’t surprise me to see OVF turning up in Hyper-V v.Next and VMM v.Next.  This would offer huge fleixibility:

• Private cloud made up of many platforms (as found in medium/large organisations)
• Switching seamlessly between public cloud (would require some form of broker application – there’s a startup opportunity!)
• Migrating VM’s seamlessly between any virtualisation platform in public/private clouds, e.g. develop in house on Hyper-V with VSS 2010 Lab Management and upload the final VM via OVF to the cloud service provider of choice, no matter what virtualisation solution they use.

It sounds like Nirvana!  I’m sure that there will be niggling things that will cause problems:

• Licensing: moving a VM with a MSDN license key up to a cloud environment that requires SPLA provided by the hoster will be a mess.
• Technical: Build a VM with 8 vCPUs on VMware and migrate it to Hyper-V and you’ll lose 4 vCPUs.
• Technical: VM additions or itnegration components are virtualisation platform specific.  Something will need to be done to be able to add/remove them seamlessly.

It’s going to take a while, and it might even be impossible for business reasons, to get to an automated, seamless solution.  But OVF will give us something where, with a tiny amount of admin work (product key and addition removal), we will have a format to make virtual machines even more mobile.