From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:40861)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kwolf@redhat.com>) id 1UCW0g-0007rW-Gu
	for qemu-devel@nongnu.org; Mon, 04 Mar 2013 09:05:02 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <kwolf@redhat.com>) id 1UCW0e-0006gE-81
	for qemu-devel@nongnu.org; Mon, 04 Mar 2013 09:04:58 -0500
Received: from mx1.redhat.com ([209.132.183.28]:38976)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kwolf@redhat.com>) id 1UCW0d-0006ep-V7
	for qemu-devel@nongnu.org; Mon, 04 Mar 2013 09:04:56 -0500
Received: from int-mx09.intmail.prod.int.phx2.redhat.com
	(int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r24E4tWQ030316
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <qemu-devel@nongnu.org>; Mon, 4 Mar 2013 09:04:55 -0500
Date: Mon, 4 Mar 2013 15:04:53 +0100
From: Kevin Wolf <kwolf@redhat.com>
Message-ID: <20130304140453.GD3929@dhcp-200-207.str.redhat.com>
References: <51349A64.2020003@redhat.com>
 <20130304130937.GR8123@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
In-Reply-To: <20130304130937.GR8123@redhat.com>
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Qemu-devel] [RFC] qcow3 format in libvirt
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: "Daniel P. Berrange" <berrange@redhat.com>
Cc: libvir-list@redhat.com, =?iso-8859-1?B?SuFu?= Tomko <jtomko@redhat.com>, qemu-devel@nongnu.org

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 add
> > support for the new qcow format to libvirt, I would like to know if t=
his
> > sounds reasonable:
> >=20
> > A new format named 'qcow3' would be added, along with a <features>
> > sub-element for target.
> >=20
> > <volume>
> >   <name>qcow3test</name>
> >   <source>
> >   </source>
> >   <capacity unit=3D'GiB'>8</capacity>
> >   <target>
> >     <path>/var/lib/libvirt/images/qcow3test</path>
> >     <format type=3D'qcow3'/>
> >     <features>
> >       <lazy_refcounts/>
> >     </features>
> >   </target>
> > </volume>
> >=20
> > I think that libvirt shouldn't care if the features are compatible 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, def=
ault?).
> >=20
> > While the qcow3 format is handled by the qcow2 driver in QEMU,
> > <driver name=3D'qemu' type=3D'qcow2'/> should be enough for domains,
>=20
> We should use qcow3 everywhere IMHO, regardless of whether qcow2
> technically works in this context.

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 (incompatible)
feature flag than of a different image format. So to fit it in your
proposed syntax:

<target>
  <path>/var/lib/libvirt/images/qcow3test</path>
  <format type=3D'qcow2'/>
  <features>
    <compat version=3D"1.1" />
    <lazy_refcounts/>
  </features>
</target>

Or if you really think that you should refer to the inner workings of
qcow2, you can make it <version>3</version>.

But I guess you call all VMDKs just "vmdk", despite the fact that they
are really just a collection of different subformats. Right?

Kevin