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

[Stefan Hajnoczi]

On Sun, Mar 10, 2013 at 10:57 AM, Dietmar Maurer <address@hidden> wrote:
>> 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?)

No, they can use a common format (OVF?).  It's up to them.

>> This has many advantages:
>>
>>  * 'block-backup' composes with 'migration' and other commands, unlike the
>>    monolithic 'backup' command designed just for writing backup archives
>
> Yes, but you can add that easily on top of my patches.

True, it can be added on top but it's simpler to have just the key
primitive rather than adding it on top.

>>  * Backup code can be updated or added outside the QEMU release cycle
>>
>>  * Choice of language, coding style, and license for backup code
>>
>>  * Less QEMU code to test and maintain
>
> The question is why you would want to write and maintain your own backup 
> solution?
> This is an disadvantage, not an advantage. If we have working code inside 
> qemu, everybody
> can use it. This will lead to better testing, more stable code, and finally 
> we can even try
> to make backup/restore work across different management frameworks.
>
> So while you have "Less QEMU code to test and maintain", it will lead to more 
> code
> you have to test and maintain - not inside qemu, but outside qemu ;-)

QEMU is not the only component that can be shared.  If you want to put
VMA into a common component, try libvirt.

QEMU does not have enough information to create a full backup archive
or restore it.  Therefore QEMU is the wrong place for backup archive
code.

Stefan