From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:51110) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UCWXb-0006yN-Ix for qemu-devel@nongnu.org; Mon, 04 Mar 2013 09:39:01 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UCWXZ-0000q8-Rq for qemu-devel@nongnu.org; Mon, 04 Mar 2013 09:38:59 -0500 Received: from mx1.redhat.com ([209.132.183.28]:27131) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UCWXZ-0000q0-KS for qemu-devel@nongnu.org; Mon, 04 Mar 2013 09:38:57 -0500 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r24EcumN014581 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 4 Mar 2013 09:38:56 -0500 Date: Mon, 4 Mar 2013 15:38:54 +0100 From: Kevin Wolf Message-ID: <20130304143854.GE3929@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> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20130304142721.GT8123@redhat.com> Content-Transfer-Encoding: quoted-printable 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 15:27 hat Daniel P. Berrange geschrieben: > On Mon, Mar 04, 2013 at 03:04:53PM +0100, Kevin Wolf wrote: > > Am 04.03.2013 um 14:09 hat Daniel P. Berrange geschrieben: > > > On Mon, Mar 04, 2013 at 01:58:12PM +0100, J=E1n Tomko wrote: > > > > Before posting another version of my patches [1], attempting to a= dd > > > > support for the new qcow format to libvirt, I would like to know = if this > > > > sounds reasonable: > > > >=20 > > > > A new format named 'qcow3' would be added, along with a > > > > sub-element for target. > > > >=20 > > > > > > > > qcow3test > > > > > > > > > > > > 8 > > > > > > > > /var/lib/libvirt/images/qcow3test > > > > > > > > > > > > > > > > > > > > > > > > > > > >=20 > > > > I think that libvirt shouldn't care if the features are compatibl= e or > > > > incompatible, as we don't know what features are supported by the > > > > hypervisor. Would the features be any good as tri-state (on, off,= default?). > > > >=20 > > > > While the qcow3 format is handled by the qcow2 driver in QEMU, > > > > should be enough for domai= ns, > > >=20 > > > We should use qcow3 everywhere IMHO, regardless of whether qcow2 > > > technically works in this context. > >=20 > > I think it makes much more sense to deal with it the way qemu does > > instead of inventing new names. This has much more of an (incompatibl= e) > > feature flag than of a different image format. So to fit it in your > > proposed syntax: >=20 > The issue is that QEMU is not the only thing that implements the qcow > format. There are a number of other impls out there, and we can't just > assume that they will all be providing a qcow2 driver that automagicall= y > opens a qcow3 image format. Just in the same way we didn't assume that > a 'qcow' (version 1) driver would open a version 2 image. That's true. Other implementation actually tend to have a 'qcow' driver that deals with both qcow1 and qcow2. But these two are actually different enough that calling them two different formats might be acceptable. In contrast, version 3 images share _exactly_ the same structure with version 2 images, the just have additional header fields and support some new flags in some structures (that were previously reserved). If you call this a different image format, then scratch that whole idea, because then each newly added feature is a new image format by your standards. > It so happens that with QEMU if you specify format=3Dqcow2 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. > > But I guess you call all VMDKs just "vmdk", despite the fact that the= y > > are really just a collection of different subformats. Right? >=20 > Yes, but that is really a bug in our representation of vmdk. How are you going to fix it? Do you think having ten different format names all starting with "vmdk" will make tools user friendly? Kevin