From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:39255) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UCXV3-0007VD-JM for qemu-devel@nongnu.org; Mon, 04 Mar 2013 10:40:29 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UCXUy-0004NT-Mx for qemu-devel@nongnu.org; Mon, 04 Mar 2013 10:40:25 -0500 Received: from mx1.redhat.com ([209.132.183.28]:22643) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UCXUy-0004NE-Fr for qemu-devel@nongnu.org; Mon, 04 Mar 2013 10:40:20 -0500 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r24FeIET014163 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 4 Mar 2013 10:40:18 -0500 Date: Mon, 4 Mar 2013 16:40:10 +0100 From: Kevin Wolf Message-ID: <20130304154010.GG3929@dhcp-200-207.str.redhat.com> References: <51349A64.2020003@redhat.com> <20130304130937.GR8123@redhat.com> <20130304140453.GD3929@dhcp-200-207.str.redhat.com> <20130304142721.GT8123@redhat.com> <20130304143854.GE3929@dhcp-200-207.str.redhat.com> <20130304144628.GV8123@redhat.com> <20130304150550.GF3929@dhcp-200-207.str.redhat.com> <20130304151922.GA8123@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130304151922.GA8123@redhat.com> Subject: Re: [Qemu-devel] [RFC] qcow3 format in libvirt List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: libvir-list@redhat.com, =?iso-8859-1?B?SuFu?= Tomko , qemu-devel@nongnu.org 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