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.

Damn Small Linux as a VM for Capacity Testing a virtual managment system

Here is a little something that I did over a year ago.

My objective was to look at virtual machine management systems (such as SCVMM and Virtual Center) and to consider how many VMs they could manage.

The potential items that you can run into are many.

1) Overhead on the management system just because of the number of VMs.
2) Limits to the number of VMs on a single host.
3) Host storage

And this is without actually powering on a single VM.

Now, begin to consider performing actions on virtual machines and we get into more complexity:
1) How many VMs can a host support (the RAM implications)
2) Can we deploy more VMs than can be booted.
3) How long do the boot operations take?

And I could keep going.

When I was first challenged with this I tried to make it as simple as possible. A single VM with an operating system installed to a virtual disk (I would concern myself with PXE VMs later on). And, I only had three servers (one I needed for the management server, so I couldn't use it as a host).

I began looking at various operating systems (Windows, Linux, etc.). All failed due to the size of the virtual disk. However, I did fine one really good candidate. And there are a couple different ways that you can set it up.

This is where Damn Small Linux comes in.

By default DSL boots from an ISO, detects the hardware and runs.
The only hitch now is installing, and RAM.

In this scenario the DSL VM can be created in two different ways.

1) As many VMs sharing a common boot ISO file. (one boot ISO per host).
2) As many single VMs with unique virtual disks.

In my case I began with option 1 but later switched to option 2.

In the case of option 2, there is a special option to install DSL to the hard disk. I found that here:
http://www.damnsmalllinux.org/f/topic-3-5-18888-0.html

And, through trial and error I learned that you can set the RAM on a DSL VM as low as 24Mb of RAM and the VM would still boot. This gave me many possibilities. My requirement was that the VM was able to boot, and that it could run without crashing. The VM ran better at 36Mb of RAM and really good at 128Mb. But for density, I went to as low as I could.

What did this end up giving me?
(other than claims that - I did it!)

This gave me an environment with a virtualization manager server and 1500 virtual machines.
At the time that I did this, just the act of having that many VMs caused a great deal of overhead on the management system.

And I also learned that there was another system that only allowed 355 VMs per host (an undocumented feature) and the host would 'fall silent' as soon as you deployed VM 356 - the host didn't crash, but its internal management daemon did, and then refused to start. I rebuilt a few hosts before I narrowed down that problem.