Am 11.03.2013 um 19:03 hat Ján Tomko geschrieben: > On 03/04/2013 04:40 PM, Kevin Wolf wrote: > > 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: > >>> > >>> 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. > > > > Since libvirt needs to know the feature names, I doesn't seem to be a > problem to know what compat options they need. And the empty (but > present) <features> element could just mean compat=1.1. Sounds like an option if this isn't too much magic for you. If we ever introduced a compat=2.0, would this be represented by a specific child element of <features>? > Would we still > need to support creating compat=0.10 images with older qemu-img not > understanding this option after the default gets changed in the current > version? If you want to create images that can be read by versions < 1.1, you need it. I think it's a reasonable expectation that libvirt allows this. That said, I'm not sure when we should switch the default in qemu. It's probably too early in 1.5, but we might consider it for 1.6. > > 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 format and the driver is still 'qcow2' now, there's no need to > translate anything at the moment (apart from features->options when > creating the image). > > But if the same 'qcow2' format would need different drivers based on the > features, we need to use different set of values for driver types and > image formats, if the features would not be in the domain XML. What driver is used to deal with the format is an implementation detail, it's not something mandated by the format. This is why some tools have one driver for both qcow1 and qcow2, and others like qemu have separate ones. Kevin -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list