A persistent promise of the OVFstandard has been portability of virtual system images between the various hypervisors and their associated management tools. Up to now, this has been a relatively minor concern in the market because most “cloud computing” ventures seem to leverage a single vendor for the underlying infrastructure. This has held true for projects in the enterprise data center and for the pure cloud ventures that leverage a service like the Elastic Compute Cloud at Amazon. In this context, some see image portability much like they viewed application portability: nice to have, but not essential as long as the cloud vendor maintains support for legacy deployments.

Recently, we have seen a potential shift start to occur. Increasing numbers of “cloud as a service” vendors want to supply some portion of the private data center infrastructure in the cloud. At this early stage, the offerings tends to divide into two emergent categories:

1) Disaster recovery – the customer keeps a set of critical system images ready to launch in the cloud vendor data center in the event of a catastrophic failure in their own data center.

2) Cloud burst – the customer keeps certain system images ready to launch in the cloud vendor data center to handle expected or unexpected surges in demand for capacity.

Assuming these services prove to be cost-effective, portability of images becomes more relevant. In both cases, having consistent representations of systems between the data center and in the cloud is essential. Having images that are portable between the two environments should be much more cost-effective than trying to build and rebuild systems in both environments.

As a cross-vendor method of describing virtual systems, OVF provides a potential basis for achieving this goal. At least three obstacles remain to achieving true interoperability with OVF:

1) OVF extensibility – as an emerging standard, OVF is necessarily extensible. This allows cloud infrastructure vendors to place proprietary elements in an OVF description that only their products can understand or leverage. A good example is the networking properties such as IP address. As the set of baseline properties for a virtual system becomes more defined, the vendors working in the DMTF will need to work towards a common way to represent these properties.

2) Lack of standards for hypervisors – in a closely related issue, the OVF standard is intentionally silent on the requirements for hypervisors and their management tools. An OVF description may be vendor neutral to no avail if the cloud infrastructure vendors for on-premise or off-premise clouds don’t actually consume the generic OVF.

While some advocate making the hypervisors and management tools consume all manner of exported OVF, I believe such an approach largely defeats the purpose of a standard. The resulting fragmentation of the market would raise the barrier to entry by new vendors and artificially limit competition. Instead, I think the cloud infrastructure vendors should be expected to produce and consume a sufficiently generic OVF description that is set forth as part of the standard. Such a standard does not have to eliminate proprietary extensions so long as a sufficiently inclusive set of standard properties is included.

3) OS portability – each cloud infrastructure vendor has its own restrictions on supported operating systems (usually Linux kernels) and requires its own set of drivers (usually part of the “tools” package). Given the realities of technology, this situation is unlikely to change in the immediate future. However, it does suggest that cloud infrastructure vendors need to make a concerted effort to produce kernel requirements and drivers that can peacefully coexist in a single image. We still see reports of virtual systems that pass the OVF import but subsequently fail to operate. The most common reason remains driver conflicts.

For ISV’s looking to push their products into the cloud space, the lack of OS-level compatibility among hypervisors presents some challenges. However, the larger barriers are actually in the area of licensing. That leaves us with the topic of my next post.

In the meantime, how important is portability to you? Do you have any experience trying to migrate systems from one cloud infrastructure to another? If so, is the situation improving or not? If not, have you tried Project Kensho from Citrix?