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

[Stefan Hajnoczi <stefanha@gmail.com>]

On Thu, Mar 07, 2013 at 09:28:40AM +0000, Dietmar Maurer wrote:
> > > When we run backup, we need to read such block on every write from the
> > guest.
> > > So if we increase block size we get additional delays.
> > 
> > Don't increase the bitmap block size.
> > 
> > Just let the block job do larger reads.  This is the bulk of the I/O workload.  You
> > can use large reads here independently of the bitmap block size.
> > 
> > That way guest writes still only have a 64 KB read overhead but you reduce the
> > overhead of doing so many 64 KB writes from the backup block job.
> 
> If there are many writes from the guest, you still get many 64KB block.

In the common case the backup block job does significantly more I/O than
the guest, unless your workload is dd if=/dev/vda of=/dev/null.
Remember the block job is reading the *entire* disk!

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

1. QEMU can neither backup nor restore without help from the management
   tool.  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.

If performance is key, please look into incremental backups.  Taking a
full copy of the disk image every time affects guest performance much
more than IPC overhead.  Plus there'll be less IPC if only dirty blocks
are backed up :).

Stefan