Datamation puts their angle on the big three virtualization vendors

Datamation has put their spin and opinion into the world of virtualization and the virtualization engines and offerings in this comparison of Citrix (XenServer), Microsoft (Hyper-V, SCVMM), and VMware (ESX, vCenter).

Mind you, this is a judgment article – But it mentions Kensho – a project very near to my personal efforts, and DocFinder – another product I was involved in the infancy of.

You can find the article here:

http://itmanagement.earthweb.com/features/article.php/12297_3853716_1/Virtual-Server-Comparison-Xen-vs-Microsoft-vs-VMware-2010.htm

Importing Kensho OVF to ESX

My main focus has been in taking OVF content from other vendors and consuming that with Citrix Kensho (the OVF Tool or XenConvert 2.x) – however lets turn the tables.
OVF is a format that describes virtual appliances; these could be single or multiple machine.  In doing so, OVF describes the virtual hardware and physical requirements of each machine.
In the spirit of supporting the development of interoperability between vendors I also consider how other vendors consume OVF appliances.
I have my personal opinion of how things should work, but the DMTF VMAN is a committee, therefore there are many opinions.
At the same time, the promise of interoperability is as much in the hand of the consume of an appliance as it is in the creator, as it is in the operating system of the machine in the appliance.
Lets look at using VMware Products (as released today 10/9/2009) to consume a Citrix Kensho created OVF appliance. 
Well, I am going to be honest – at this time VMware does not translate other vendors hardware descriptions into VMware equivalents – therefore VMware cannot import OVF content that does not adhere to the VMware way of describing the hardware of a virtual machine.
So, knowing that, is there a workaround?  Yes, there is.
In my example I am going to use XenConvert to create an OVF Appliance from a XenServer XVA (that is an export of a XenServer VM), modify that using a VMware created OVF, and then import to ESX.
Mind you, this is not for the easily sickened, nor is it something you want to do every day.
First of all, I begin by downloading the Citrix Merchandising Server virtual appliance. I also use XML Notepad, ESX, and VMware Converter.  (Please note that following this process will NOT magically make the Merchandising Server work on ESX - you need to use the appliance built for VMware)
[1] Expand the Merchandizing bz2 zip archive. (WinRAR can do this, and others as well)
[2] Use Citrix XenConvert 2.x to convert from “Xen Virtual Appliance” to “Open Virtualization Format (OVF) Package”

Do not create an OVA, just an OVF.

[3] Using the VMware Client:

a. Create a shell VM using Linux / RedHat Enterprise Linux 5 (32-bit)
b. Select the VM that was created and export it to an OVF appliance
· VI3 = Select VM, File, Virtual Appliance, Export
· vSphere4 = Select VM, Export

[4] Open both folders containing the OVF appliance from XenConvert and the OVF appliance from VMware.
Note that both folders contain common items: a virtual disk file, and a .ovf metafile that describes the settings of the appliance.

[5] Copy the VHD from the XenConvert created appliance to the folder of the VMware created appliance

[6] Open the .ovf XML metafile from both appliances using XML Notepad
[7] Open the two references to the virtual disk
There are two important sections that need to be modified in the VMware OVF so that it will properly ‘see’ the VHD. The ‘name’ of the virtual disk and the ‘format’.

[8] Copy the disk reference sections from the XenConvert created appliance to the VMware created appliance.

[9] Save the changes
[10]If the VMware appliance folder contains a file ending in .mf – delete it
[11]Using VMware Converter import the modified VMware OVF appliance.
Only VMware Converter can both consume the OVF and convert the VHD to VMDK.

a. Open VMware Converter
b. Select Convert Machine
c. Choose virtual appliance, browse to the modified OVF
d. Select Next
e. Complete the import wizard

The preceding steps converted the Merchandising Server XVA based appliance to OVF and then used a VMware derived OVF to import the appliance to VMware. The operating system within the appliance still needs to be repaired to allow the machine to boot and run.
Hopefully, I will have a solution for that in the near future.  As there are currently many challenges inherent within the operating system of the machines themselves that prevent true interoperability.

Thinking in Workloads with OVF

Many of you realize that I am pretty close to the Citrix Project Kensho OVF Tool.

Frankly, I find it as a very useful tool with some very useful features.

First of all – let me mention a bit about OVF again.  OVF is NOT a method of converting virtual machines.  OVF is a way to describe a virtual appliance using standardized XML tags, so that various platforms can consume and use that virtual appliance as it was defined.

A virtual appliance has traditionally been though of as a single virtual machine (thank you VMware).  However, a virtual appliance is actually a “workload.”

Many of you might realize that an enterprise application is rarely a simple single .exe file that simply runs on a desktop.  A very simple reporting application might be an executable, a SQL database, and even a document archiving system.  All of these entities grouped together is the workload.

It takes all of these pieces working together for the application to be fully functional and feature rich.  The Application Workload would be a better way to describe this.

In the same light there is a component that might participate in multiple workloads – the SQL server can serve databases to multiple front-end and back-end applications.  It would have the most complex relationship in this example.

This brings me pack to the virtual appliance – the OVF is a description of the workload.  This example has that defined as two servers and one client.

If you are the person creating the package, you might leave the client out of the package, or only deliver the client executable as a component of the package, but it is not imported to a virtualization host as a virtual machine.

Some might call this creative thinking, but really it is just taking what the OVF allows and applying that to real situations.

The OVF standard (VMAN at the DMTF) is still evolving and changing.  And vendors are still working on compatibility and pushing those standards to ever complex designs.

It is because of this that not all vendors support each other.  They have to choose to allow for consumption of other implementations of the OVF standard.  Yes, this gets very complex and interwoven and creates a bummer for some folks that see OVF as the answer to virtual machine portability – when that portability has far more to do with the applications and operating systems within the virtual appliance themselves than it does in the depths of an XML file.