Difference between revisions of "Cinder/GuestAssistedSnapshotting"
< Cinder
| Line 1: | Line 1: | ||
| − | QEMU guest-assisted snapshotting | + | = QEMU guest-assisted snapshotting = |
| + | |||
| + | ==== Related blueprints ==== | ||
| + | |||
| + | * https://blueprints.launchpad.net/nova/+spec/qemu-assisted-snapshots | ||
| + | * https://blueprints.launchpad.net/cinder/+spec/qemu-assisted-snapshots | ||
| + | |||
| + | ==== Goals ==== | ||
| − | |||
1. Add snapshot support for Cinder backing stores which lack internal snapshots (NFS, Gluster, etc.) | 1. Add snapshot support for Cinder backing stores which lack internal snapshots (NFS, Gluster, etc.) | ||
| − | Prerequisites | + | ==== Prerequisites ==== |
| + | |||
* QEMU/libvirt live snapshot support | * QEMU/libvirt live snapshot support | ||
* QEMU guest agent installed (for quiescing) | * QEMU guest agent installed (for quiescing) | ||
| + | ==== Overview ==== | ||
Currently, GlusterFS + Cinder does not support snapshots. Snapshot support can be enabled by storing volume data as QCOW2 files on Cinder volumes rather than as flat raw files (as is done today), and leveraging QCOW2's snapshot functionality. | Currently, GlusterFS + Cinder does not support snapshots. Snapshot support can be enabled by storing volume data as QCOW2 files on Cinder volumes rather than as flat raw files (as is done today), and leveraging QCOW2's snapshot functionality. | ||
Revision as of 15:21, 19 June 2013
Contents
QEMU guest-assisted snapshotting
Related blueprints
- https://blueprints.launchpad.net/nova/+spec/qemu-assisted-snapshots
- https://blueprints.launchpad.net/cinder/+spec/qemu-assisted-snapshots
Goals
1. Add snapshot support for Cinder backing stores which lack internal snapshots (NFS, Gluster, etc.)
Prerequisites
- QEMU/libvirt live snapshot support
- QEMU guest agent installed (for quiescing)
Overview
Currently, GlusterFS + Cinder does not support snapshots. Snapshot support can be enabled by storing volume data as QCOW2 files on Cinder volumes rather than as flat raw files (as is done today), and leveraging QCOW2's snapshot functionality.
Creation of Snapshot:
- User calls new nova API call to executed an assisted snapshot
- Nova will quiesce guest (use existing pause functionality if guest assisted quiesce is not available)
- Nova will execute snapshot API call in Cinder
- Cinder creates snapshot
- Nova resumes VM on completion of the snapshot
The snapshot can then be managed like any other Cinder snapshot.
Changes required for Cinder QCOW2 volumes:
- Cinder code to create them (per-driver code & options)
- Cinder code to translate/process them for operations like upload-to-image, backup_create, clone
- Possibly DB information tracking type (qcow2 or raw) - if needed
