From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=56692 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1OCqKu-0007iF-9A
	for qemu-devel@nongnu.org; Fri, 14 May 2010 04:33:37 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69)
	(envelope-from <kwolf@redhat.com>) id 1OCqKs-00037p-IT
	for qemu-devel@nongnu.org; Fri, 14 May 2010 04:33:36 -0400
Received: from mx1.redhat.com ([209.132.183.28]:34967)
	by eggs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <kwolf@redhat.com>) id 1OCqKs-00037h-8n
	for qemu-devel@nongnu.org; Fri, 14 May 2010 04:33:34 -0400
Message-ID: <4BED0A9A.9010608@redhat.com>
Date: Fri, 14 May 2010 10:32:26 +0200
From: Kevin Wolf <kwolf@redhat.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [RFC PATCH 0/2] Sheepdog: distributed storage system
	for QEMU
References: <1273661213-19611-1-git-send-email-morita.kazutaka@lab.ntt.co.jp>	<4BEA931A.6040309@redhat.com>	<4BEB05A6.5030305@lab.ntt.co.jp>
	<lpy6fnq4pk.wl%morita.kazutaka@lab.ntt.co.jp>
In-Reply-To: <lpy6fnq4pk.wl%morita.kazutaka@lab.ntt.co.jp>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/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: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: MORITA Kazutaka <morita.kazutaka@lab.ntt.co.jp>
Cc: aliguori@us.ibm.com, sheepdog@lists.wpkg.org, kvm@vger.kernel.org, qemu-devel@nongnu.org, avi@redhat.com, Christoph Hellwig <hch@lst.de>

Am 13.05.2010 16:03, schrieb MORITA Kazutaka:
> To support snapshot in a protocol, I'd like to call the hander of the
> protocol driver in the following functions in block.c:
> 
>     bdrv_snapshot_create
>     bdrv_snapshot_goto
>     bdrv_snapshot_delete
>     bdrv_snapshot_list
>     bdrv_save_vmstate
>     bdrv_load_vmstate
> 
> Is it okay?

Yes, I think this is the way to go.

> In the case both format and protocol drivers support snapshots, I
> think it is better to call the format driver handler.  Because qcow2
> is well known as a snapshot support format, so when users use qcow2,
> they expect to get snapshot with qcow2.

I agree.

> There is another problem to make the sheepdog driver be a protocol;
> how to deal with protocol specific create_options?
> 
> For example, sheepdog supports cloning images as a format driver:
> 
>   $ qemu-img create -f sheepdog dst -b sheepdog:src
> 
> But if the sheepdog driver is a protocol, error will occur.
> 
>   $ qemu-img create sheepdog:dst -b sheepdog:src
>   Unknown option 'backing_file'
>   qemu-img: Backing file not supported for file format 'raw'
> 
> It is because the raw format doesn't support a backing_file option.
> To support the protocol specific create_options, if the format driver
> cannot parse some of the arguments, the protocol driver need to parse
> them.

That's actually a good point. Yes, I think it makes a lot of sense to
allow parameters to be passed to the protocol driver.

Also, I've never tried to create an image over a protocol other than
file. As far as I know, raw is the only format for which it should work
right now (at least in theory). As we're going forward, I'm planning to
convert the other drivers, too.

Kevin