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

[Kevin Wolf <kwolf@redhat.com>]

Am 12.03.2013 um 11:50 hat Stefan Hajnoczi geschrieben:
> On Tue, Mar 12, 2013 at 10:18:12AM +0100, Kevin Wolf wrote:
> > 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.

Yes, that's why I would want to have VMA implemented as a write-only
BlockDriver. The part about saving multiple images into one VMA is a bit
tricky; it's basically the same thing as exposing several snapshots of a
qcow2 image as separate BlockDriverStates at the same time.

> 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.

We don't have a native streamable image format, so I think this is a
legitimate topic for discussion. I'm not sure if the latest proposal for
VMA is what I'd like to make qemu's native streamable format, though,
and this is something that needs to be discussed. Some comments in the
email threads made me think that it can be improved.

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

OVF isn't an image format. I would really like to produce OVA archives,
with a OVF description passed by the management tool and images in one
of our native formats. If this isn't streamable though (as I expect),
tbat would be more for storing an archive of qcow2s instead of VMAs.

Kevin

> [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