Re: [libvirt] [Qemu-devel] [RFC] qcow3 format in libvirt
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