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

[Kevin Wolf <kwolf@redhat.com>]

Am 04.03.2013 um 16:19 hat Daniel P. Berrange geschrieben:
> On Mon, Mar 04, 2013 at 04:05:50PM +0100, Kevin Wolf wrote:
> > 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:
> > > > > 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)
> 
> So you're saying that you consider the format name to be "qcow2" regardless
> of whether the version numer field is specified as 2 or 3.

Yes.

> So in other words, if an application came along and required libvirt to
> set  format=qcow3 on its CLI, we could justifiably refuse to do that in
> libvirt claiming this is not in compliance with the spec ?

No, you would just check which features this image uses (which, if I
understood correctly, you need to save anyway), and if a version 3
feature is among it (the basic version 3 could be represented by either
a "feature flags" or "zero clusters" feature, which are what version 3
really means), pass it the 'qcow3' command line option it wants.

Of course, I would be disappointed that the tool thought it had to
invent format names, but it's not really blocking any functionality.

Just the same way it could happen that a tool uses different drivers for
other features that we introduce. For example, imagine that we introduce
a flag that modifies the L2 table structure to allow subclusters - a
change that we've been discussing before and that would have a massive
impact on the implementation, even though it's only a feature flag that
has changed, and not the version number. Using a different driver for
this looks much more likely than a different driver for version 2 and 3,
which was really a quite small step.

So the main problem that I see is the assumption "different version =>
big change, new feature flag => small change" and as a conclusion from
that "different version => possibly new driver, new feature flag =>
definitely only old driver". This isn't true at all.

Kevin