On Fri, Mar 8, 2013 at 6:44 PM, Dietmar Maurer <diet...@proxmox.com> wrote: >> >> 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. > > That is Patch 2/6?
Yes. I sent an RFC series that shows this approach. It is just a prototype but it demonstrates that the NBD approach works and performs reasonably well for a quick Python hack. The stripped down patch series needs: 1. (Optional) query-block virtual_size field if management tool needs to query drive size 2. Patch 2/6 with review comments addressed 3. 'block-backup' QMP command (and optionally HMP command) That's it! Stefan