From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:52037)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <jtomko@redhat.com>) id 1UCUyE-0003yE-0C
	for qemu-devel@nongnu.org; Mon, 04 Mar 2013 07:58:26 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <jtomko@redhat.com>) id 1UCUy8-0003Uc-KJ
	for qemu-devel@nongnu.org; Mon, 04 Mar 2013 07:58:21 -0500
Received: from mx1.redhat.com ([209.132.183.28]:63034)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <jtomko@redhat.com>) id 1UCUy8-0003UU-D4
	for qemu-devel@nongnu.org; Mon, 04 Mar 2013 07:58:16 -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 r24CwFJt015288
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <qemu-devel@nongnu.org>; Mon, 4 Mar 2013 07:58:15 -0500
Message-ID: <51349A64.2020003@redhat.com>
Date: Mon, 04 Mar 2013 13:58:12 +0100
From: =?ISO-8859-1?Q?J=E1n_Tomko?= <jtomko@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: [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: qemu-devel@nongnu.org
Cc: libvir-list@redhat.com

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 this
sounds reasonable:

A new format named 'qcow3' would be added, along with a <features>
sub-element for target.

<volume>
  <name>qcow3test</name>
  <source>
  </source>
  <capacity unit='GiB'>8</capacity>
  <target>
    <path>/var/lib/libvirt/images/qcow3test</path>
    <format type='qcow3'/>
    <features>
      <lazy_refcounts/>
    </features>
  </target>
</volume>

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, default?).

While the qcow3 format is handled by the qcow2 driver in QEMU,
<driver name='qemu' type='qcow2'/> should be enough for domains,
but in snapshot XML we treat the driver type as the format:

<disk name='/path/to/old'>
  <driver type='qcow3'/>
  <source file='/path/to/new'/>
  <features>
    <lazy_refcounts/>
  </features>
</disk>

So I think we should allow the qcow3 driver type as well and translate
it to qcow2 for QEMU.

Jan

[1] v2 here:
https://www.redhat.com/archives/libvir-list/2013-February/msg00212.html