VMware Open Virtualization Format (OVF)

[Technologov]

Hi All !

There is a relatively new format for meta-data about Virtual Machines, named OVF.

Open Virtualization Format - OVF:
http://www.vmware.com/appliances/learn/ovf.html

Today - while the hard disk (VMDK) is more or less supported by many vendors but there is no standard yet for the VM-specific meta-data.

This OVF is looking promising - as it contains all hardware data specific to the VM - such as CPUs, RAM, chipsets, networking configuration, ...

My main concern with OVF is that different virtualization vendors employ different virtual hardware - so even if the meta-data is standardazied - not so with virtual hardware.
So in the real-world I'm not sure how helpful this format really is... But the general idea is very good.

I presume that this OVF format implies that other vendors must match VMware in terms of virtual hardware support.

Let's look at the Virtual Machines (Hard Disk and meta-data and Hardware):

In short - for this OVF to work - different vendors Virtual Hardware must match.

Qemu:
Cirrus Logic video card, SB16, PIIX3 IDE, Realtek NIC by default
Hard disk is qcow2, and no meta-data is stored.
Qemu supports VMDK HDD and some SCSI, SMP, and VMware video card. Can emulate AMD NICs, 64-bit capable.

Parralels Workstation:
HDD Format is *.hdd, and meta-data is *pvs - both formats are proprietary.
Hardware unknown

Virtual PC 2004/2007:
Uses (*.vhd) and for meta-data formatted as *.vmc. Does not support SCSI - Audio is SB16. Video: S3 Trio. Network: AMD PCnet
Not SMP capable. Not 64-bit guests capable.

VMware Workstation 6.0:
AMD NIC + PV, Audio: SoundBlaster64 (not supported by any other vendor), video: VMware PV, IDE+SCSI, SMP-capable, 64-bit capable.
Uses VMDK for hard disks.

VirtualBox:
video: VirtualBox PV, no-SMP, IDE is PIIX3/4 capable. SCSI appeared in 2.1. Emulates AMD NICs, 64-bit capable.
Uses *.vdi for Hard Disks and *.xml for VM meta-data.
Not SMP capable.

=======================================

Even in hardware I have not checked deeply whenever the SCSI controller that Qemu and VirtualBox supports is the same SCSI controller that VMware supports - same goes for AMD PCnet NICs.
Same is true for VMDK format - that is not supported fully by Qemu & VirtualBox (snapshots, multi-volume VMDK, etc..)

Currently not all hardware from all vendors seems to match with VMware - especially in the Video PV and SoundBlaster 64 department.

What is your opinion about this?

-Technologov, 2.1.2008.

[Technologov]

Actually I see one serious flaw with the OVF:

The hardware required to run OVF-capable VMs is not specified in the OVF specification. Instead it looks like "vmware-4" capable hardware, which means that no virtualizer can claim to be 100% OVF compliant.

I think it must be more specific both regarding virtualized hardware and virtual hard disk containers to be 100% implementable by other vendors.

In short the current OVF specification (v1.0.0d) is way too abstract and it does not guarantees that one vendor makes a VM appliance compatible with OVF will run on other vendors's OVF-compatible implementation (virtualizer).

-Technologov

[vbox4me2]

A solution might be as simple that everyone implement the destroy-virtual-supported-hardware switch/tag/flipped_bit/whatever, so if a vmware guest OS and its vm drivers detect vmware isn't running it will allow VM hardware deletion, sort of like a sysprep for vmmachines.

[Technologov]

sysprep is an utility made by OS vendor, not by virtualization vendor. I'm not sure if such utility can be done at virtualization vendor level. (due to huge amount of possible guest OSes)

[vbox4me2]

Do any of you know how to read?? or other then state the bleeding obvious?

Did I actually said: lets go and use sysprep
Did I actually state: lets do this for windows guests and sodd the rest

If you bothered to read I said 'sysprep alike', for VM's you know NOT the guest OS or any frigging tools specific to a OS.

VM environments all have 1 central common issue and thats guest communication with the host via the guest additions or such tools, THIS is where you have control to envoke virtual hardware assosiations to the point you could design a sysprep alike function for VM portability that can be(come) a part of the OVF.

[Technologov]

Many low-level OS functions of proprietary OSes (read: Windows) are not documented - which means that it will not be easy to provide such a mechanism.

Having different IDE/SCSI controller for Windows guest will result in Blue Screen of Death.

This is why having equal virtual hardware is more important than writing scripts/wizards for conversion (in my opinion).

[vbox4me2]

Not really, just about anything boots when IDE drivers are used(and emulated) and ide is 99% vm backwards compatible.
Think about XML, xml is not really an endpoint product, but a means to get from A to B via xml.
Such a 'vm2vm prepare to move' tool or option would serve all vm controllers. Its not like you're talking about dozens of drivers and layers, they all hover around the same virtual techniques, enclose that endpoint and agree on it between compatitors and your done.

[Technologov]

I am happy to see that OVF I discussed here only several months ago is already implemented in VirtualBox 2.2.0

However I have not yet tried to port VMs from VirtualBox to other virtualizers.

Which other virtualizers support OVF ?
- VMware WS 6.5 ?

Qemu/KVM does not, MS Virtual PC does not, what else ? Parralels ?