All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kashyap Chamarthy <kchamart@redhat.com>
To: John Snow <jsnow@redhat.com>
Cc: kwolf@redhat.com,
	Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>,
	qemu-block@nongnu.org, libvir-list@redhat.com, armbru@redhat.com,
	qemu-devel@nongnu.org, mreitz@redhat.com, pkrempa@redhat.com,
	nshirokovskiy@virtuozzo.com, den@openvz.org
Subject: Re: [PATCH] qapi: deprecate drive-backup
Date: Tue, 27 Apr 2021 14:16:47 +0200	[thread overview]
Message-ID: <20210427121647.GA3746000@paraplu.home> (raw)
In-Reply-To: <9a0e7805-c6ae-b55f-431c-4c61a1ab746e@redhat.com>

On Mon, Apr 26, 2021 at 01:34:17PM -0400, John Snow wrote:
> On 4/23/21 8:59 AM, Vladimir Sementsov-Ogievskiy wrote:
> > Modern way is using blockdev-add + blockdev-backup, which provides a
> > lot more control on how target is opened.

[...]

> 1) Let's add a sphinx reference to
> https://qemu-project.gitlab.io/qemu/interop/live-block-operations.html#live-disk-backup-drive-backup-and-blockdev-backup
> 
> 
> 2) Just a thought, not a request: We also may wish to update
> https://qemu-project.gitlab.io/qemu/interop/bitmaps.html to use the
> new, preferred method. However, this doc is a bit old and is in need
> of an overhaul anyway (Especially to add the NBD pull workflow.) Since
> the doc is in need of an overhaul anyway, can we ask Kashyap to help
> us here, if he has time?

Yes, I should be able to make time and help here; been putting it off on
the back burner.  Thanks for the reminder.  :) I'd like to update both
these:

    https://qemu-project.gitlab.io/qemu/interop/bitmaps.html
    https://qemu-project.gitlab.io/qemu/interop/live-block-operations.html

Both of them, as you know, refer to 'drive-backup'.  They also need
other adjustments / additions.  Also perhaps break the larger doc into a
couple of smaller ones.

I'll start working on it the end of this week.  First I need to tinker
with some of the recent improvements to refresh my memory and get a
sense of the modifications involved.  So please bear with me.

> 3) Let's add a small explanation here that outlines the differences in
> using these two commands. Here's a suggestion:
> 
> This change primarily separates the creation/opening process of the
> backup target with explicit, separate steps. BlockdevBackup uses
> mostly the same arguments as DriveBackup, except the "format" and
> "mode" options are removed in favor of using explicit
> "blockdev-create" and "blockdev-add" calls.
> 
> The "target" argument changes semantics. It no longer accepts
> filenames, and will now additionally accept arbitrary node names in
> addition to device names.

Yeah; this is something I had figure out by some trial-and-error when I
was playing with it in the past.

> 4) Also not a request: If we want to go above and beyond, it might be nice
> to spell out the exact steps required to transition from the old interface
> to the new one. Here's a (hasty) suggestion for how that might look:
> 
> - The MODE argument is deprecated.
>   - "existing" is replaced by using "blockdev-add" commands.
>   - "absolute-paths" is replaced by using "blockdev-add" and
>     "blockdev-create" commands.
> 
> - The FORMAT argument is deprecated.
>   - Format information is given to "blockdev-add"/"blockdev-create".
> 
> - The TARGET argument has new semantics:
>   - Filenames are no longer supported, use blockdev-add/blockdev-create
>     as necessary instead.
>   - Device targets remain supported.

Agreed; docs like these can be useful for management tools that rely on
the old behaviour and are not as up-to-date as libvirt in keeping track
of QEMU developments.

[...]

-- 
/kashyap



      parent reply	other threads:[~2021-04-27 12:22 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-23 12:59 [PATCH] qapi: deprecate drive-backup Vladimir Sementsov-Ogievskiy
2021-04-23 13:09 ` Daniel P. Berrangé
2021-04-23 13:21   ` Vladimir Sementsov-Ogievskiy
2021-04-26  7:39 ` Peter Krempa
2021-04-26 17:34 ` John Snow
2021-04-26 18:00   ` Vladimir Sementsov-Ogievskiy
2021-04-26 18:05     ` Daniel P. Berrangé
2021-04-26 18:30       ` John Snow
2021-04-26 18:41         ` Vladimir Sementsov-Ogievskiy
2021-04-26 18:45           ` John Snow
2021-04-27 12:16   ` Kashyap Chamarthy [this message]

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=20210427121647.GA3746000@paraplu.home \
    --to=kchamart@redhat.com \
    --cc=armbru@redhat.com \
    --cc=den@openvz.org \
    --cc=jsnow@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=libvir-list@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=nshirokovskiy@virtuozzo.com \
    --cc=pkrempa@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=vsementsov@virtuozzo.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.