qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
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>
Subject: Re: [Qemu-devel] [PATCH RESEND 01/17] docs: incremental backup documentation
Date: Wed, 4 Mar 2015 11:39:55 +0100	[thread overview]
Message-ID: <20150304103955.GF3465@noname.str.redhat.com> (raw)
In-Reply-To: <54F4A2BF.8090304@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

  parent reply	other threads:[~2015-03-04 10:40 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-28  0:47 [Qemu-devel] [PATCH RESEND 00/17] block: transactionless incremental backup series John Snow
2015-02-28  0:47 ` [Qemu-devel] [PATCH RESEND 01/17] docs: incremental backup documentation John Snow
2015-03-02 17:49   ` Max Reitz
2015-03-02 18:48     ` John Snow
2015-03-02 19:07       ` Max Reitz
2015-03-02 21:27         ` Max Reitz
2015-03-04 10:39     ` Kevin Wolf [this message]
2015-02-28  0:47 ` [Qemu-devel] [PATCH RESEND 02/17] qapi: Add optional field "name" to block dirty bitmap John Snow
2015-02-28  0:47 ` [Qemu-devel] [PATCH RESEND 03/17] qmp: Ensure consistent granularity type John Snow
2015-02-28  0:47 ` [Qemu-devel] [PATCH RESEND 04/17] qmp: Add block-dirty-bitmap-add and block-dirty-bitmap-remove John Snow
2015-02-28  0:47 ` [Qemu-devel] [PATCH RESEND 05/17] block: Introduce bdrv_dirty_bitmap_granularity() John Snow
2015-02-28  0:47 ` [Qemu-devel] [PATCH RESEND 06/17] hbitmap: add hbitmap_merge John Snow
2015-02-28  0:47 ` [Qemu-devel] [PATCH RESEND 07/17] block: Add bitmap disabled status John Snow
2015-03-02 17:08   ` Max Reitz
2015-02-28  0:47 ` [Qemu-devel] [PATCH RESEND 08/17] block: Add bitmap successors John Snow
2015-02-28  0:47 ` [Qemu-devel] [PATCH RESEND 09/17] qmp: Add support of "dirty-bitmap" sync mode for drive-backup John Snow
2015-02-28  0:47 ` [Qemu-devel] [PATCH RESEND 10/17] qmp: add block-dirty-bitmap-clear John Snow
2015-02-28  0:47 ` [Qemu-devel] [PATCH RESEND 11/17] qmp: Add dirty bitmap status fields in query-block John Snow
2015-02-28  0:47 ` [Qemu-devel] [PATCH RESEND 12/17] block: add BdrvDirtyBitmap documentation John Snow
2015-02-28  0:47 ` [Qemu-devel] [PATCH RESEND 13/17] block: Ensure consistent bitmap function prototypes John Snow
2015-02-28  0:47 ` [Qemu-devel] [PATCH RESEND 14/17] block: Resize bitmaps on bdrv_truncate John Snow
2015-03-02 17:17   ` Max Reitz
2015-02-28  0:47 ` [Qemu-devel] [PATCH RESEND 15/17] iotests: add invalid input incremental backup tests John Snow
2015-02-28  0:47 ` [Qemu-devel] [PATCH RESEND 16/17] iotests: add simple incremental backup case John Snow
2015-02-28  0:47 ` [Qemu-devel] [PATCH RESEND 17/17] iotests: add incremental backup failure recovery test John Snow

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150304103955.GF3465@noname.str.redhat.com \
    --to=kwolf@redhat.com \
    --cc=armbru@redhat.com \
    --cc=famz@redhat.com \
    --cc=jsnow@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    --cc=vsementsov@parallels.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).