Bug 1385748 - Document that consistent snapshots are not supported
Document that consistent snapshots are not supported
Status: NEW
Product: Red Hat OpenStack
Classification: Red Hat
Component: documentation (Show other bugs)
9.0 (Mitaka)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: 12.0 (Pike)
Assigned To: RHOS Documentation Team
RHOS Documentation Team
: Documentation
Depends On: 1378063
Blocks:
  Show dependency treegraph
 
Reported: 2016-10-17 11:50 EDT by Marko Myllynen
Modified: 2017-04-26 11:45 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Marko Myllynen 2016-10-17 11:50:13 EDT
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.
Comment 2 Marko Myllynen 2016-10-18 01:02:59 EDT
See also:

https://bugzilla.redhat.com/show_bug.cgi?id=1378063
Comment 4 David Gurtner 2017-03-03 10:11:33 EST
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.

Note You need to log in before you can comment on or make changes to this bug.