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