Re: [Qemu-devel] [RFC 0/8] block: Live backup prototype

[Stefan Hajnoczi]

On Tue, Mar 12, 2013 at 10:18:12AM +0100, Kevin Wolf wrote:
> Am 10.03.2013 um 10:57 hat Dietmar Maurer geschrieben:
> > > The difference between this approach and Dietmar's series is that the 
> > > backup
> > > archive format is implemented outside QEMU and runs as a separate program.
> > > 
> > > This way, management tools like proxmox, oVirt, OpenStack, and others can
> > > provide their preferred backup archive formats without modifying QEMU.  
> > 
> > So you propose that everyone should use another backup format - this is a 
> > bad thing because
> > it lead to interoperability problems (vendor lock-in?)
> 
> Maybe we could consider having the backup tool inside the qemu.git tree
> and thus provide a common format that management applications can choose
> to use, but still have it implemented outside the qemu process running
> the VM.
> 
> I'm still not totally against having the VMA writer even inside the qemu
> process, but only as an option. The important part for me is being able
> to backup into _any_ BlockDriverState.

If VMA was the common backup archive format I'd be more enthusiastic
about having a writer in QEMU and letting that be the "interface" for
backups.

Writing into BlockDriverState is important is because we have the
opportunity here to provide an interface that can be used in a number of
ways beyond just writing backup archives.

Either VMA needs to have the prerequisites[1] for becoming a common
backup archive format or else we'll just be adding a new zoo of obscure
formats to QEMU.  Using the BlockDriverState interface instead is a
clear step to prevent proliferation of formats inside QEMU.

Since I'm not convinced that VMA is the going to get traction, I'd
rather we focussed on a clean interface that allowed any backup archive
format.

It's a slippery slope to put VMA into QEMU.  What will you say when
patches for OVF or some other format turn up?

[1] Prerequisites for becoming widely adopted:
 * Open specification
 * Review of VMA limitations, extensibility, and missing features
 * Packaged VMA read/write tools
 * Look into which formats existing backup solutions support (maybe
   there is already something universal, I certainly don't know)

Stefan