The Ripples of OVF

I've been watching the blogosphere for reactions to OVF. This post from William Vambenepe is notable for two reasons.

First, he definitely understands the impact of OVF's ability to specify a collection of VMs as the ingredients of an appliance.  He's also correctly identified the inherent problem of network configuration and placement that this capability reveals.

The second reason for noting this post is his suggestion about how to handle the EULA that's incorporated into the OVF wrapper... a URI to a well-publicized collection of pre-approved (or at least, well vetted and understood) EULAs, so that unattended deployment of the appliance can be subject to automated policy enforcement.

William Vambenepe’s blog » Blog Archive » A review of OVF from a systems management perspective

I was very intrigued by the promise that the specification “directly supports the configuration of multi-tier applications and the composition of virtual machines to deliver composed services” but this turns out to be a bit of an overstatement. Basically, you can distribute the VMs across networks by specifying a network name for each VM. I can easily understand the simple case, where all the VMs are on the same network and talking to one another. But there is no way (that I can see) to specify the network topology that joins different networks together ...

Speaking of lawyers, the section that allows the EULA to be shipped with the virtual appliance is very simplistic. It’s just a human-readable piece of text in the OVF file. The specification somewhat naively mentions that “if unattended installs are allowed, all embedded license sections are implicitly accepted”. Great, thanks, enterprises love to implicitly accept licensing terms. I would hope that the next version will provide, at least, a way to have a URI to identify the EULA so that I can maintain a list of pre-approved EULAs for which unattended deployment is possible. Automation of IT management is supposed to makes things faster and cheaper. Having a busy and expensive lawyer read a EULA as part of my deployment process goes against both objectives. ...

Comments

[barmijo]

You and I have talked and blogged about standards for utility computing a few times, and I continue to believe it's too early for a standard.

Standards are a double edged sword - a trade-off to gain interoperability in exchange for stifling innovation. Once sufficient experimentation in an area of technology has been conducted that agreement can be negotiated between competitors on market requirements, a standard can be drafted that delivers interoperability and allows innovation at the next layer. IMHO it's way too early to make that trade-off. We haven't adequately explored the possibilities in utility computing.

For instance, the OVF is intended to provide interchange of applications between services. To my knowledge, no vendor other than 3tera has ever demonstrated this ability. Our customers do it frequently. Therefore, we can document precisely what the requirements of an interchange format are and what services are required on both ends. OVF, unfortunately, is simply insufficient. The shortcoming you note is just the most glaring.

Even if 3tera published our specification tomorrow and all parties signed on to it, that wouldn't be the end game, because transfering an application between data centers isn't the end requirement. It's merely one important step. 3tera's roadmap includes several major leaps in capabilities that will require significant extension of our current interchange format. And, as I mentioned, that's where the negative aspect of standards comes into play. To adequately explain the need for those extensions in a standard body, 3tera would be required to site use cases where they could be needed - in essence to divulge our product roadmap to our competitors.

That said, if they want input and are willing to embrace capabilities they can't yet provide, capabilities that will set the stage for years of innovation, then we'll be happy to participate.

[Rich Miller]

Bert, I agree with much of what you've said. I particularly agree that standardization efforts, when undertaken too early or too late, can be nothing but a waste of time. I've got the scars to prove it. (Ten years of working on the OSI standards for messaging and directories - X.400 and X.500.) Thus, the question is really: on what should we standardize and when in the lifecycle?

In the case of OVF, the limitations on the objective and the timing are correct. If you take a good look at OVF, the objective is little more than agreeing on the form and format of a weighbill or shipping manifest. The "language" chosen and the form are meant to be extensible, such that proprietary or specialized information can be conveyed... meaning that if the recipient has facilities that recognize and understand that part of "the recipe", it can respond appropriately. It provides a means whereby the originator of the "package" can indicate what's inside, and, within limits, what the intention of the author might be or what his recommendations might be for the recipient. ("For best results, let the package attain room temperature before cooking.")

OVF is far from an interoperability mechanism, and I'd be very surprised if the ulterior motive here was to have vendors divulge their product roadmap. The value of an OVF for use within any one virtual machine environment (VMware VI3, XenSource, 3tera or Amazon's AWS) is great enough WITHOUT any consideration of crossing the boundaries of VME interoperability. OVF should allow a vendor of software to "package" a multi-tier application comprising several server images as an "appliance" designed to be operated on, for example, XenSource. On the package, for the recipient to read should be placed enough information that the recipient can get direction as to the required resources and constraints under which the application is meant to run.

As to your last comment... OVF is now accepted under the DMTF umbrella (http://www.dmtf.org). That's an organization that's generally struck me as participatory.

[barmijo]

I agree with you that "OVF is far from an interoperability mechanism," but in their marketing launch of OVF, VMware claims:

"The Open Virtual Machine Format is a platform independent, efficient, extensible, and open packaging and distribution format for virtual machines. An OVF formatted virtual machine can be delivered to a customer who can then deploy it on the virtualization platform of their choice . . . it enables the mobility of virtual machines as well as vendor and platform independence."

[barmijo]

btw, the DMTF puts it much more plainly on their website:

" . . . machines packaged in this format can be installed on any virtualization platform that supports the standard, simplifying interoperability . . ."

[Rich Miller]

Bert, someone at VMware marketing DEFINITELY got carried away when they wrote that bit about deploying an OVF formatted VM "... on the virtualization platform of their choice." After going through the spec pretty carefully, I'd definitely agree with the much more modest DMTF description!!

[Simon Wardley]

Just back from Italy ... catching up with all the news. Good post Rich.

'Even if 3tera published our specification tomorrow and all parties signed on to it, that wouldn't be the end game,' - Agreed.

One of the main issues over adoption of UC environment is the question of lock-in and exit costs. Standards are never enough for portability, you also need multiple providers and some mechanism for client assurance.

The reason why I argued that open source is essential in this case, is that it provides an operational way of implementing a standard and removes any concerns over strategic control for future computer resource providers in this UC market.

The use of open source, can also by increasing adoption of one product, make that open source product the defacto standard in a market where no standard exists.

Well, we now have a proposed standard (equivalent to Jar files for Infrastructure).

However this is a transitional stage, where the market is just developing.

There is an opportunity for someone to disrupt this change, and release an alternative based upon an open source product with a focus on developing the future compliance / assurance industry.

That's why I agree with you - the specification isn't enough.

As for OVF - it's a step in the right direction.