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

[Stefan Hajnoczi]

On Tue, Mar 12, 2013 at 12:22 PM, Kevin Wolf <address@hidden> wrote:
> 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.

Your reply sounds like there are two separate issues here:

1. A streamable image format native to QEMU would be nice.  The killer
feature would be streamable qcow2 with the ability to run the image
and perform normal writes to it so that no conversion is necessary
when restoring the image.

I support such a feature being in QEMU.

2. Archive formats (zip/tar/OVA/VMA).  Here I'm against putting them
into QEMU since the management tool needs to put them together anyway.

Stefan