Open Stack

2011/12/2 Donal Lafferty <donal.lafferty at citrix.com>:
> The key in my email was to ask whether MIME-like specialisations were
> appropriate either for combining characteristics of an image into a
> single property.
>
> E.g. <container_type>/<image_type>.  The example I provided was
> <image_type>/<vendor-specific-format>
>
> That second example came from observing that a VHD produced by
> VHDTOOL.exe as posted on MSDN produced a file that could not be
> understood by XenServer.  In contrast, Ken Bell's 'DiscUtils' as
> posted on Codeplex produced a VHD that worked fine.  When I spoke to
> Ken, he mentioned he'd noticed that VHDTOOL.exe generated a slightly
> different format.  Now, I doubt Microsoft would host a tool that
> didn’t support their format.  Therefore, there seems to be a
> difference of opinion as to what constitutes a VHD.

I understand there might be differences in implementations of the
various formats. Sometimes, this is due to bugs (common if the format
was reverse-engineered) or perhaps different (incompatible) versions of
the same format. I don't think the correct way to encode these
differences is making it "vendor" specific.

As an example, vmdk's generated by QEmu are different from vmdk's
generated by VirtualBox, and both of those are different that vmdk's
generated by VMWare (which again generates different vmdk's depending on
its version), but the compatibility matrix is complicated. I think all
vmdk's from QEMu will work in VirtualBox and VMWare, but VMWare and
VirtualBox can certainly both generate vmdk's that QEMu doesn't
understand.  Some of these differences are due to different versions of
the vmdk format being used, and some are due to incomplete
implementations of the formats.

I simply don't think adding a vendor part to the container type string
is going to be a very good way to encode this.

-- 
Soren Hansen        | http://linux2go.dk/
Ubuntu Developer    | http://www.ubuntu.com/
OpenStack Developer | http://www.openstack.org/