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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list