> Interesting series, the backup block job makes sense to me. Regarding > efficiency, I think incremental backup is a must, otherwise regular backups > using this approach won't really be a win over backing files.
Incremental backup is something different, not touched by this code. You can add that later if needed. > The backup writer abstraction is a special case interface somewhere > between an image format and live migration. I'd prefer it if the backup > block job stuck to BlockDriverState as the destination for backup data. > Then you could save a point-in-time copy of a disk to a raw or even > qcow2 image. backup needs to work on non-seekable pipes. > The vmstate feature looks like vmsave duplication. The problem with > vmsave is that it doesn't compose nicely with block jobs or the QMP > transaction command, which would allow you to snapshot the disks and > then capture the VM state. > > How would VMA fit in if the backup block job took a BlockDriverState > destination and vmsave worked atomically with backup block jobs? You > could have QEMU write to NBD server ports that a VMA writer process has > open. VMA would happen outside the QEMU process. We want to write to pipes, so what you suggest simply does not work?