From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:55288)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <berrange@redhat.com>) id 1UCV9I-0000be-Lh
	for qemu-devel@nongnu.org; Mon, 04 Mar 2013 08:09:53 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <berrange@redhat.com>) id 1UCV9C-0006sD-8r
	for qemu-devel@nongnu.org; Mon, 04 Mar 2013 08:09:48 -0500
Received: from mx1.redhat.com ([209.132.183.28]:47047)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <berrange@redhat.com>) id 1UCV9C-0006s5-01
	for qemu-devel@nongnu.org; Mon, 04 Mar 2013 08:09:42 -0500
Received: from int-mx12.intmail.prod.int.phx2.redhat.com
	(int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r24D9f2A020448
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <qemu-devel@nongnu.org>; Mon, 4 Mar 2013 08:09:41 -0500
Date: Mon, 4 Mar 2013 13:09:37 +0000
From: "Daniel P. Berrange" <berrange@redhat.com>
Message-ID: <20130304130937.GR8123@redhat.com>
References: <51349A64.2020003@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <51349A64.2020003@redhat.com>
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Qemu-devel] [RFC] qcow3 format in libvirt
Reply-To: "Daniel P. Berrange" <berrange@redhat.com>
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: =?utf-8?Q?J=C3=A1n?= Tomko <jtomko@redhat.com>
Cc: libvir-list@redhat.com, qemu-devel@nongnu.org

On Mon, Mar 04, 2013 at 01:58:12PM +0100, J=C3=A1n 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 thi=
s
> 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, defau=
lt?).
>=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,

We should use qcow3 everywhere IMHO, regardless of whether qcow2
technically works in this context.

> but in snapshot XML we treat the driver type as the format:
>=20
> <disk name=3D'/path/to/old'>
>   <driver type=3D'qcow3'/>
>   <source file=3D'/path/to/new'/>
>   <features>
>     <lazy_refcounts/>
>   </features>
> </disk>
>=20
> So I think we should allow the qcow3 driver type as well and translate
> it to qcow2 for QEMU.
>=20
> Jan
>=20
> [1] v2 here:
> https://www.redhat.com/archives/libvir-list/2013-February/msg00212.html
>=20

Daniel
--=20
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange=
/ :|
|: http://libvirt.org              -o-             http://virt-manager.or=
g :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr=
/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vn=
c :|