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
