Description of problem:
3.7.1 and 3.7.4 of https://access.redhat.com/documentation/en/red-hat-openstack-platform/9/paged/instances-and-images-guide/chapter-3-virtual-machine-instances state among other things:
"
If you intend to use an instance snapshot as a template to create new instances, you must ensure that the disk state is consistent. Before you create a snapshot, set the snapshot image metadata property os_require_quiesce=yes.
Compute’s libvirt driver automatically requests the QEMU Guest Agent to freeze the file systems (and applications if fsfreeze-hook is installed) during an image snapshot. Support for quiescing file systems enables scheduled, automatic snapshots at the block device level.
This feature is only valid if the QEMU Guest Agent is installed (qemu-ga) and the image metadata enables the agent (hw_qemu_guest_agent=yes)
"
With an instance which has both hw_qemu_guest_agent=yes and os_require_quiesce=yes properties set we can see from the QEMU Guest Agent log when its verbose logging is enabled that if doing something like:
# virsh qemu-agent-command instance-0000002a '{"execute":"guest-fsfreeze-freeze"}'
# virsh qemu-agent-command instance-0000002a '{"execute":"guest-fsfreeze-thaw"}'
that the guest file systems are indeed frozen/thawed as expected:
1476182654.378820: warning: disabling logging due to filesystem freeze
1476182661.412912: warning: logging re-enabled due to filesystem unfreeze
However, even if we make sure we have set disable_libvirt_livesnapshot = false in nova.conf and we're using for example a 3PAR backend, when doing:
# cinder snapshot-create --force True ...
we can see that no guest filesystem freezing ever happens, meaning that there is no guarantee that the snapshot would be consistent.
As Gorka Eguileor pointed out elsewhere, the proposal do freeze the filesystem automatically has been abandoned in upstream:
https://review.openstack.org/#/c/128112/
The documentation should be updated to reflect the current status of functionality.
Thanks.
The documentation states: "to freeze the file systems [...] during an image snapshot". So this means creating snapshots via Nova of the root disk and specifically via "nova backup" or "nova image-create".
I don't think this feature is expected to have any influence on running Cinder snapshots via "cinder snapshot-create".
Looking at the following upstream blueprints, it seems that the Nova part[1] has been implemented quite a wihle ago, while the next step to also do the same for Cinder[2] is not done.
[1] https://blueprints.launchpad.net/nova/+spec/quiesced-image-snapshots-with-qemu-guest-agent
[2] https://blueprints.launchpad.net/nova/+spec/quiesce-admin-action
But the documentation could be improved to make this clear to readers.