Re: [Qemu-devel] [PATCH v4 0/6] Efficient VM backup for qemu

[Dietmar Maurer]

> Interesting series, the backup block job makes sense to me.  Regarding
> efficiency, I think incremental backup is a must, 

One can easily implement incremental backup on top of this patches. That is why
I introduced the BackupDriver abstraction.

> otherwise regular backups using
> this approach won't really be a win over backing files.
>
> 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.
> 
> 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.
> 
> The benefit of doing this is that the backup block job becomes a 
> general-purpose
> command and QEMU is not directly involved in capturing guest configuration.
> IMO the management tool is the correct place to orchestrate guest restore.

I am still not sure what you describe here exactly. But this looks like you 
want to have
an external backup server (NBD), and move the code out of qemu.

But NBD is not the only option. There are many backup tool/servers out there, 
and
you can easily write a BackupDriver for any of them. Using a fixed protocol 
like NBD
does not really have an advantage for me, as you can write a BackupDriver for 
that.