Friday, May 22, 2009

The OVF and OVA dilemma

Here is a really good definition that I can thank my manager for of “OVF”:

OVF is a vendor- and platform-independent format to describe virtual machine metadata and create portable virtual-machine packages. These packages do not rely on a specific host platform, virtualization platform, or guest operating system. However, the virtual disk referenced by the OVF package must be compatible with the target hypervisor.

The Open Virtualization Format is a new and developing standard from the DMTF (Distributed Management Task Force). Its purpose is to form a common framework that any virtualization vendor can use to define a virtual workload. This workload can be simply a single virtual machine; this workload could also contain many virtual machines and also include complex descriptions for networking, applications, EULAs, and other entities. In theory, a single OVF could define all of the workloads within an entire enterprise and those workloads could be transported to a remote site for DR, or moved to a new datacenter. The possibilities are many.

The standard is here:

The concept seems simple enough.

When talking to IT Professionals there is always time spent describing OVF and OVA, and where each fits.

“OVF” is the acronym for the standard.

What is referred to as an “OVF Package” is the collection of the workload states, plus a description meta file, plus any other entities that are defined in the description file.

BTW – the description file is also called the OVF file, or OVF meta file or OVF descriptor. This is why this gets really confusing really fast.

Here are the two important terms that get thrown around:

OVF / OVA – these are not the same thing.

An OVF is a collection of items in a single folder. Most commonly this is a description file (*.ovf) a manifest file (*.mf), and virtual machine state files (*.vhd or *.vmdk)

An OVA is a single file. The OVA is the OVF folder contents all zipped into a single file. The purpose of the OVA is when you want to take an OVF and share it, or give it as a download. The OVA needs to be opened into the OVF before it can be consumed.

Currently there are a host of folks working on OVF, you can learn more about the companies involved at the web site:

Most commonly folks are running into OVF with Citrix (Project Kensho and XenConvert 2); VMware (VMware Workstation 6.5, Virtual Center 3 update 3, OvfTool, etc.); Sun (Virtual Box 2.2); and IBM. The big problem to date has been that the standards have been evolving during the time that these tools have been available. For example: a VMware v3 produced OVF is distinctly different than a VMware v4 OVF package. Mainly due to the state of the standards at the time the software was written. So, currently there is little cross platform between vendors.

The other problem that is happening right now is that defining a workload in an OVF is great, however, since these are virtual machine based – the operating system within the virtual machine has to deal with the fact that the virtualization hardware underneath it has been modified. Having a virtual machine as an OVF is not the same as having a virtual machine and running it through a conversion engine that repairs the operating system within the vm.

This is all evolving and will come in time.

Thursday, May 21, 2009

The layers to Linux on Hyper-V

Recently I have been seeing and getting many questions regarding the Linux Integration Components for Hyper-V virtual machines.

Through a bit of questioning, I have discovered a couple things, and distinct levels to running Linux VMs on Hyper-V.

Note: Since SuSE 10 SP2 is the ‘supported’ distribution, any instructions will be specific to it.

I am assuming that you have obtained the SuSE media and performed a ‘vanilla’ installation into a new Hyper-V virtual machine.

WARNING: Level One can lead to Level Two. And, always perform a backup / export / snapshot before proceeding. All usual disclaimers apply.

Level One – the beginning

This is a simple installation of just the Linux operating system within a Hyper-V virtual machine. The only caveat is that the VM needs a Legacy Network adapter for network connectivity.

In this case you will end up with a working Linux VM. It should auto detect an install an SMB (multi-processor) kernel and it should just work. The performance is not the best that it could be, but it should run.

Level Two – the path to enlightenment

This is the simple installation from above, with the addition of the Hyper-V Linux drivers.

This one is a bit more involved. However, the end result is that you are running the synthetic Network Adapter, and the optimized storage, and display (and other) drivers.

This optimizes drivers, but advanced integration features such as shutdown from the host (or SCVMM) is currently not available.

To obtain driver enlightenment:

a) Obtain the LinuxIC.iso

b) obtain the inputvsc.iso for the mouse driver

c) add the kernel-source and gcc-c++ packages

YaST can be used for this, either GUI or command line

Note: if an ISO was previously attached, you may need to detach, pause, then attach the desired ISO for SuSE auto-mount to pick up the change.

If that does not work, make a mount point ( mkdir /media/CDROM ) and mount /dev/hdc /media/CDROM

d) Install the linuxic drivers

a. Open a Terminal

b. attach the downloaded LinuxIC.iso through the Hyper-V manager

c. Create a folder and copy the contents to the folder

d. mkdir /tmp/linuxic

e. cp –rp /media/CDROM/* /tmp/linuxic

f. cd /tmp/linuxic

g. ./ drivers

e) Install the mouse driver

a. Attach the inputvsc.iso through the Hyper-V manager

b. Create a folder and copy the contents.

c. mkdir /tmp/inputvsc

d. cp –rp /media/CDROM/* /tmp/inputvsc

Note: you may need to mount again: mount /dev/hdc /media/CDROM

e. cd /tmp/inputvsc

f. ./

f) Power down the VM, remove the Legacy Network Adapter, add a Synthetic Network adapter, power on the VM (you could also do a shutdown now –hP)

g) Using YaST (or YaST2), configure the newly installed synthetic network adapter.