On Tue, Sep 20, 2016 at 04:20:49PM +0100, Daniel P. Berrange wrote: > On Tue, Sep 20, 2016 at 11:01:23AM -0400, Sean Dague wrote:
[...] > > Here is my reconstruction of the snapshot issue from what I can remember > > of the conversation. > > > > Nova defaults to live snapshots. This uses the libvirt facility which > > dumps both memory and disk. And then we throw away the memory. For large > > memory guests (especially volume backed ones that might have a fast path > > for the disk) this leads to a lot of overhead for no gain. The > > workaround got them past it. > > I think you've got it backwards there. > > Nova defaults to *not* using live snapshots: > > cfg.BoolOpt( > 'disable_libvirt_livesnapshot', > default=True, > help=""" > Disable live snapshots when using the libvirt driver. > ...""") > > > When live snapshot is disabled like this, the snapshot code is unable > to guarantee a consistent disk state. So the libvirt nova driver will > stop the guest by doing a managed save (this saves all memory to > disk), then does the disk snapshot, then restores the managed saved > (which loads all memory from disk). > > This is terrible for multiple reasons > > 1. the guest workload stops running while snapshot is taken > 2. we churn disk I/O saving & loading VM memory > 3. you can't do it at all if host PCI devices are attached to > the VM > > Enabling live snapshots by default fixes all these problems, at the > risk of hitting the live snapshot bug we saw in the gate CI but never > anywhere else. Yes, FWIW, I agree. In addition to the nice details above, enabling the live snapshots also allows you to quiesce file systems for consistent disk state, via the Glance image metadata properties 'hw_qemu_guest_agent' and 'os_require_quiesce'. (Current cold snapshot mechanism doesn't allow this.) Anyhow, Sean seems to have submitted the change to toggle the config for enabling live_snapshots: https://review.openstack.org/#/c/373430/ -- "Change disable_live_snapshot workaround" -- /kashyap __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev