Re: [Qemu-devel] [PATCH v4 3/6] add backup related monitor commands

[Stefan Hajnoczi]

On Fri, Mar 8, 2013 at 12:01 PM, Dietmar Maurer <address@hidden> wrote:
>> > Anyways, and additional RPC layer always adds overhead, and It can be
>> completely avoided.
>> > Maybe not much, but I want to make backup as efficient as possible.
>>
>> The drawbacks outweight the performance advantage:
>
> not for me.
>
>> 1. QEMU can neither backup nor restore without help from the management
>>    tool.
>
> Backup works perfectly with the current patches. You can easily trigger a 
> backup using
> a HMP command. This is not really important, but works.

If you send me a VMA file I can't restore it without knowing your
command-line and possibly setting up the environment.  QEMU just can't
do that, it's out of scope.  That is why the backup archive is a
management tool concept.

>> This is a strong indicator that the backup archive code should
>>    live outside QEMU.  I doesn't make sense for proxmox, oVirt,
>>    OpenStack, and others to each maintain their backup archive code
>>    inside qemu.git, tied to QEMU's C codebase, release cycle, and
>>    license.
>> 2. QEMU already has interfaces to export the vmstate and block device
>>    snapshots: migration/savevm and BlockDriverState (NBD for IPC or
>>    raw/qcow2/vmdk for file).  It is not necessary to add a
>>    special-purpose interface just for backup.
>>
>> 3. The backup block job can be composed together with other QMP commands
>>    to achieve scenarios besides just VMA backup.  It's more flexible to
>>    add simple primitives that can be combined instead of adding a
>>    monolithic backup command.
>>
>> For these reasons, I'm against putting backup archive code into QEMU.
>
> That is OK for me - I already maintain the code outside of qemu.

Does this mean you will keep this patch series out-of-tree?

What I am looking for is a stripped down patch series with just a
backup block job (no backup archive writer or migration code).  That
would be easily merged and saves you front rebasing this series as
QEMU changes.

Stefan