Bug 1385748 - Document that consistent snapshots are not supported
Summary: Document that consistent snapshots are not supported
Keywords:
Status: CLOSED EOL
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: documentation
Version: 9.0 (Mitaka)
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: ---
Assignee: RHOS Documentation Team
QA Contact: RHOS Documentation Team
URL:
Whiteboard:
Depends On: 1378063
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-10-17 15:50 UTC by Marko Myllynen
Modified: 2023-11-21 17:32 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-07-06 11:04:58 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker OSP-5848 0 None None None 2022-08-11 12:09:30 UTC

Description Marko Myllynen 2016-10-17 15:50:13 UTC
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 05:02:59 UTC
See also:

https://bugzilla.redhat.com/show_bug.cgi?id=1378063

Comment 4 David Gurtner 2017-03-03 15:11:33 UTC
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.

Comment 5 Lucy Bopf 2017-07-27 02:12:22 UTC
Clearing target release pending docs triage.


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