Re: [libvirt] RFC backup API

Ok, yes, there is clearly two completely separate modes of dealing with backups, externally managed and internally (to libvirt) managed. I can understand the desire to support both modes of operating backups. I was wondering what the difference is between doing a backup of the VM vs taking a snapshot of the VM. At a high level they feel pretty much the same, just no memory is snapshot for backups. IIUC though at the disk level, they pretty much inverted, a snapshot switches the running qcow2 file for the VM to point to a new qcow2 overlay, while a backup never touchs the VM disk, always using separate qcow2 images. So I can see why we'd want explicit backup support separately from snapshot support. At an API level it feels like the design of our snapshot APIs would map fairly naturally onto the new backups APIs, so getting consistency between the two is desirable IMHO.

In particular the snapshot API for creating a snapshot allows an XML document to be fed in which describes how each disk is to be snapshot. I think we would need the same kind of flexibility for backups, to avoid having to hardcode the fact that backups always use qcow2. ie if a VM is using RBD, we want mgmt apps to be able to indicate that the backup should use a particular RBD volume too. Of course it should also be possible for an RBD backed guest to be able to save its backups to local raw/qcow2 files. We should also be able to indicate that some disks should be skipped for pupose of backups. So backup creation clearly needs a high level of configurability in general. We don't have to implement the full support matrix but the API design should allow for it in the future. There's a question as to whether should have allow for some default backup location if none is specified. eg perhaps we should always just store backups in /var/spool/backups/libvirt/qemu by default if the user/app didn't provide an explicit list of target volumes to hold the backup. This would allow the backup API to have better ease of use in the simple case