From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:55191)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kwolf@redhat.com>) id 1YT6il-0008Jp-OA
	for qemu-devel@nongnu.org; Wed, 04 Mar 2015 05:40:08 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <kwolf@redhat.com>) id 1YT6ih-0005lU-SI
	for qemu-devel@nongnu.org; Wed, 04 Mar 2015 05:40:07 -0500
Date: Wed, 4 Mar 2015 11:39:55 +0100
From: Kevin Wolf <kwolf@redhat.com>
Message-ID: <20150304103955.GF3465@noname.str.redhat.com>
References: <1425084477-31602-1-git-send-email-jsnow@redhat.com>
	<1425084477-31602-2-git-send-email-jsnow@redhat.com>
	<54F4A2BF.8090304@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <54F4A2BF.8090304@redhat.com>
Subject: Re: [Qemu-devel] [PATCH RESEND 01/17] docs: incremental backup
	documentation
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: Max Reitz <mreitz@redhat.com>
Cc: famz@redhat.com, qemu-block@nongnu.org, qemu-devel@nongnu.org, armbru@redhat.com, vsementsov@parallels.com, stefanha@redhat.com, John Snow <jsnow@redhat.com>

Am 02.03.2015 um 18:49 hat Max Reitz geschrieben:
> >+2. Create a destination image for the incremental backup that utilizes the
> >+full backup as a backing image.
> >+
> >+    * Let's assume it is named 'incremental.0.img'.
> >+
> >+    ```sh
> >+    # qemu-img create -f qcow2 incremental.0.img -b full_backup.img -F qcow2
> >+    ```
> 
> Aha, using .img for qcow2. *g*
> 
> Also, we really do need some sort of image-create for QMP at some
> point in time, I guess...

Not really necessary on its own, because in practice management
applications can (and do) just call qemu-img, but it implies
QAPIfication of the image creation and I believe that is something that
we do want. With features like specifying separate options for protocols
and formats, perhaps even including filters during image creation.
Essentially "blockdev" work for create instead of open.

The QMP command would then just happen to fall out of that work
naturally.

Kevin