----- Original Message ----- > From: "Nir Soffer" <[email protected]> > To: "devel" <[email protected]> > Cc: "Eric Blake" <[email protected]>, "Daniel Erez" <[email protected]>, > "Francesco Romani" <[email protected]>, > "Adam Litke" <[email protected]>, "Federico Simoncelli" > <[email protected]>, "Yaniv Dary" <[email protected]> > Sent: Friday, June 19, 2015 11:40:23 PM > Subject: [VDSM] Live snapshot with ceph disks > > Hi all, > > For 3.6, we will not support live vm snapshot, but this is a must for the > next > release. > > It is trivial to create a disk snapshot in ceph (using cinder apis). The > snapshot > is transparent to libvirt, qmeu and the guest os. > > However, we want to create a consistent snapshot, so you can revert to the > disk > snapshot and get a consistent file system state. > > We also want to create a complete vm snapshot, including all disks and vm > memory. > Libvirt and qemu provides that when given a new disk for the active layer, > but > when using ceph disk, we don't change the active layer - we continue to use > the > same disk. > > Since 1.2.5, libvirt provides virDomainFSFreeze and virDomainFSThaw: > https://libvirt.org/hvsupport.html > > So here is possible flows (ignoring engine side stuff like locking vms and > disks) > > Disk snapshot > ------------- > > 1. Engine invoke VM.freezeFileSystems > 2. Vdsm invokes libvirt.virDomainFSFreeze > 3. Engine creates snapshot via cinder > 4. Engine invokes VM.thawFileSystems > 5. Vdsm invokes livbirt.virDomainFSThaw > > Vm snapshot > ----------- > > 1. Engine invoke VM.freezeFileSystems > 2. Vdsm invokes libvirt.virDomainFSFreeze > 3. Engine creates snapshot via cinder > 4. Engine invokes VM.snapshot > 5. Vdsm creates snapshot, skipping ceph disks > 6. Engine invokes VM.thawFileSystems > 7. Vdsm invokes livbirt.virDomainFSThaw > > API changes > ----------- > > New verbs: > - VM.freezeFileSystems - basically invokes virDomainFSFreeze > - VM.thawFileSystems - basically invokes virDomainFSThaw > > > What do you think?
OpenStack uses two different approaches for live snapshot: 1. When taking a snapshot of an instance, a new image (of the entire instance) is created on Glance in qcow2 format - orchestrated by Nova and libvirt (Snapshot xml). 2. When taking a snapshot of a single volume while the VM is running (i.e. the volume is attached to an instance), the snapshot is taken using Cinder with the relevant driver. The following message is displayed in Horizon: "This volume is currently attached to an instance. In some cases, creating a snapshot from an attached volume can result in a corrupted snapshot." (see attached screenshot) Since the current integration is directly with Cinder and VM snapshot is handled by oVirt engine, we should go with a variant of option 2... If it's too late to integrate the new verbs into 3.6, maybe we could just settle with a similar warning when creating a live snapshot? Or block the feature for now to avoid possible data inconsistency? > > Nir >
_______________________________________________ Devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/devel
