A very interesting analysis… Thanks! Some feedback follows (I hope you find it useful)

I agree with you in that, currently, OVF can be seen very much “just a wrapper around proprietary virtual disk formats” although I tend to think (maybe I’m being too gullible :) that virtual disk translators could be implemented soon, because of any OVF compliant implementation shall include an “URL that refers to an unencumbered specification on how to interpret the disk format”. As a matter of fact, the VMware VMDK specification is available. Ok, it isn’t as direct yet as using the http://www.vmware.com/specifications/vmdk.html#sparse URL shown in the examples in the OVF specification document, and you have to use a suspicious form (email catcher? :), although at least it’s something… Moreover, the OVF whitepaper discussion regarding portability levels shows that, al least, they are aware of the issue.

Regarding network topology, I think that, as long as all the virtual appliance (i.e., all their virtual machines) is deployed in just one physical host, arbitrary topologies can be described (just playing with Connection tags of network adapters in the VirtualHardware sections, using the proper network names). The problem comes (as you argued with the “blue” and “red” network example) when you are considering multi-host deployment in which the physical topology impacts the virtual one. I think that OVF is (by the moment) too mono-host focused, and the multi-host deployment problem is still opened (of course, you can always split your virtual appliance in several ones, but you loss the integrity in deployment and management, that I think is the whole point of OVF). However, how to solve the “topology descriptor” issue you mention? A new (or maybe yet existing) model/language/whatever embebbed in the OVF descriptor?

You are right with your comment about XSD standalone files, DSPxxxx formatting, etc. but, well,… let’s see what happens when the official DMFT specification (1.0, not this 0.9) will be released :) What I really would like to know is when such final specification would be available… Anybody knows?

Regarding the specification itself:

I’ve found Network, OperatingSystem and InstallationSection quite naïve.

Some CIM classes (in particular, CIM_VirtualSystemSettingData and CIM_ResourceAllocationSettingData) are used to define some sections (in particular, VirtualHardwareSection) but no others (e.g., why not to use CIM_OperatingSystem in the OperatingSystem section?). I find curious this lack of homogeneity…

I think that the Environment Document Protocol idea is quite smart. However, it is currently underutilized, because of several reasons. First, it is not clear when this protocol can be used. Looking the functions that the virtual machine is supposed to implement, I guess that it is only used to help in the initial installation of virtual machines, but it is not clearly specified. If that is right, why not using it also for post-install utilization cases? For example, at virtual machine starting (i.e., booting up) time or during upgrades. Second, the transport concept (section 11.3) should be clarified… it is very obscure how the protocol will be actually implemented.

As co-founder of 3tera I’m admittedly biased, but I believe it’s too early for a standard like this. True utility computing services are less than a year old, ushered in by our own AppLogic and Amazon’s EC2. There simply hasn’t been a sufficient exploration of the possibilities to start making trade offs in the negotiation of a viable standard.

Still, if the effort to produce a standard goes forward we’ll participate as long as it looks like the output will be useful and I hope you’ll continue adding your input to the conversation.

…