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

[Stefan Hajnoczi]

On Thu, Feb 21, 2013 at 06:53:24AM +0000, Dietmar Maurer wrote:
> > 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.

There is more discussion on this in the patch where a VM configuration
file gets saved.

I posted more concrete explanations of how it works and why it's a good
idea.

Stefan