[libvirt] [Qemu-devel] [RFC] qcow3 format in libvirt

[Kevin Wolf]

Am 04.03.2013 um 15:46 hat Daniel P. Berrange geschrieben:
> On Mon, Mar 04, 2013 at 03:38:54PM +0100, Kevin Wolf wrote:
> > Am 04.03.2013 um 15:27 hat Daniel P. Berrange geschrieben:
> > > On Mon, Mar 04, 2013 at 03:04:53PM +0100, Kevin Wolf wrote:
> > > > Am 04.03.2013 um 14:09 hat Daniel P. Berrange geschrieben:
> > > > I think it makes much more sense to deal with it the way qemu does
> > > > instead of inventing new names. This has much more of an (incompatible)
> > > > feature flag than of a different image format. So to fit it in your
> > > > proposed syntax:
> > > 
> > > The issue is that QEMU is not the only thing that implements the qcow
> > > format. There are a number of other impls out there, and we can't just
> > > assume that they will all be providing a qcow2 driver that automagically
> > > opens a qcow3 image format. Just in the same way we didn't assume that
> > > a 'qcow' (version 1) driver would open a version 2 image.
> > 
> > That's true. Other implementation actually tend to have a 'qcow' driver
> > that deals with both qcow1 and qcow2. But these two are actually
> > different enough that calling them two different formats might be
> > acceptable.
> > 
> > In contrast, version 3 images share _exactly_ the same structure with
> > version 2 images, the just have additional header fields and support
> > some new flags in some structures (that were previously reserved).
> > 
> > If you call this a different image format, then scratch that whole
> > <feature> idea, because then each newly added feature is a new image
> > format by your standards.
> 
> No, that's not what I'm saying. The version 3 image format introduces
> the ability to set a variety of features in an extensible way. Adding
> new features to that list doesn't mean the version has changed.

Why does libvirt care whether a new feature is indicated by incrementing
one header field or by setting a bit in a different header field? These
are image format internals, not external interfaces.

> > > It so happens that with QEMU if you specify format=qcow2 and give it
> > > a qcow3 image, QEMU will open it, but libvirt can't assume that, since
> > > this is a mere implementation detail. Hence libvirt must explicitly
> > > refer to 'qcow3' in the XML and map it to qcow2 if applicable when
> > > talking to QEMU.
> > 
> > If you need this information, sure, save it. I'm just requesting that
> > you don't abuse the format name for it.
> 
> The key distinction is that libvirt XML is recording an generic image
> format, while the QEMU cli args are referring to a specific driver
> implementation, which are support multiple formats. Typically these
> map 1-to-1, but there's no such requirement in general. Hence will
> refer to 'qcow3' in all its XML descriptions, and map to 'qcow2' when
> talking to QEMU, or even just to 'qcow' if talking to a different impl
> which supports all 3 versions in one driver.

I'm not talking about the QEMU cli, but about qcow2 as the format as
defined in the spec (which just happens to sit in qemu.git, but isn't
qemu specific at all)

> > > > But I guess you call all VMDKs just "vmdk", despite the fact that they
> > > > are really just a collection of different subformats. Right?
> > > 
> > > Yes, but that is really a bug in our representation of vmdk.
> > 
> > How are you going to fix it? Do you think having ten different format
> > names all starting with "vmdk" will make tools user friendly?
> 
> Well we can't really fix it now, given we've got tools relying on
> this naming, but use we ought to have numbered the vmdk formats in
> retrospect.

Do you actually support more than one subformat today that they could
rely on? It's probably only important for creating images anyway as all
backends implement all VMDK subformats using the same driver.

Anyway, just imagine that these tools didn't exist yet. I still think
that giving the user ten different "vmdk*" formats to choose from would
be the wrong way - and isn't this how it would end up if libvirt treated
it as different formats? The user should select VMDK and then get
additional options that apply to this specific format. The same way the
user should select qcow2 (or even just qcow) and then all options
that are available for it, including version 3 images.

Kevin