On 03/23/2016 04:30 AM, Daniel P. Berrange wrote: > 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. Yes, it would be nice to have virDomainSnapshot and virDomainBlockCopy more integrated with one another, particularly since XML gives us the flexibility to state more details about where a backup will be created. > > 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 I'd really like us to add a notion of a default pool to the <domain> definition; if omitted, then libvirt chooses where to carve out storage for backups, snapshots, and other operations; but if present, then the user can specify a storage pool that will be used for all large-size operations that might be done on the domain. Even things like managed saves should use the per-domain storage pool rather than blindly assuming that /var/run/libvirt or /etc/libvirt/ is the right place to use. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list