On Fri, Mar 8, 2013 at 12:01 PM, Dietmar Maurer <diet...@proxmox.com> 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
