online blockdev-backup, a clarification (was: Summary on new backup interfaces in QEMU)

[John Maline]

As a qemu newcomer I had a related question and confusion from reading existing 
docs. Searching qemu-block, this seemed related to my question so I’ll ask…


> On Mar 15, 2022, at 12:57 PM, Vladimir Sementsov-Ogievskiy 
> <v.sementsov-og@ya.ru> wrote:
> 
> Hi all!
> 
> Here I want to summarize new interfaces and use cases for backup in QEMU.
> 
> TODO for me: convert this into good rst documentation in docs/.

The existing docs I found at 
https://qemu.readthedocs.io/en/latest/interop/live-block-operations.html#live-disk-backup-blockdev-backup-and-the-deprecated-drive-backup
 are confusing me. This, if I’m understanding, seem clearer.


> 
> OK, let's begin.
> 
> First, note that drive-backup qmp command is deprecated.
> 
> Next, some terminology:
> 
> push backup: the whole process is inside QEMU process, also may be called 
> "internal backup"
> 
> pull backup: QEMU only exports a kind of snapshot (for example by NBD), and 
> third party software reads this export and stores it somehow, also called 
> "external backup"
> 
> copy-before-write operations: We usually do backup of active disk, guest is 
> running and may write to the disk during the process of backup. When guest 
> wants to rewrite data region which is not backed up yet, we must stop this 
> guest write, and copy original data to somewhere before continuing guest 
> write. That's a copy-before-write operation.
> 
> image-fleecing: the technique that allows to export a "snapshotted" state of 
> the active disk with help of copy-before-write operations. We create a 
> temporary image - target for copy-before-write operations, and provide an 
> interface to the user to read the "snapshotted" state. And for read, we do 
> read from temporary image the data which is already changed in original 
> active disk, and we read unchanged data directly from active disk. The 
> temporary image itself is also called "reverse delta" or "reversed delta".
> 
> 
> 
> == Simple push backup ==
> 
> Just use blockdev-backup, nothing new here. I just note some technical 
> details, that are relatively new:
> 
> 1. First, backup job inserts copy-before-write filter above source disk, to 
> do copy-before-write operation.
> 2. Created copy-before-write filter shares internal block-copy state with 
> backup job, so they work in collaboration, to not copy same things twice.

The simple case I’m aiming for matches a push backup. I’m OK w/ a snapshot.

Environment - macos 12.6 on arm processor, guest is aarch64 centos linux using 
hvf accelerator. Qemu 7.2.

I assume what you describe w/ copy-before-write is behavior in qemu 7.2. I’m 
fine if the Linux client needs to do a bit of log replay if I revert to a 
backup.

In the docs I link above it talks as if a VM shutdown is recommended after the 
job completes. Seems to ruin the whole point of an online backup. I tried 
instead finishing w/ a blockdev-del and I see the backup file closed by qemu. 
I’m guessing that’s an appropriate way to flush/complete the backup. In an 
experiment, it seemed the generated backup worked as expected.

I’m hoping for confirmation or correction on my approach.

Specifically I’m doing the following QMP commands.

{"execute": "qmp_capabilities"}

{"execute":"blockdev-add",
 "arguments":{"node-name":"backup-node", "driver":"qcow2", 
"file":{"driver":"file", "filename":"backups/backup1.img"}}
}

{"execute":"blockdev-backup",
 "arguments":{"device":"drive0", "job-id":"job0", "target":"backup-node", 
"sync":"full"}
}

... watch many job state change events ...

{"execute":"blockdev-del",
 "arguments": {"node-name":"backup-node"}
}



--
John Maline
jmaline@mac.com