> > 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. > 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.
