Jump to: navigation, search

Difference between revisions of "Cinder/GuestAssistedSnapshotting"

(Overview: multiple volume snaps)
Line 32: Line 32:
 
* Cinder code to translate/process them for operations like upload-to-image, backup_create, clone
 
* 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
 
* Possibly DB information tracking type (qcow2 or raw) - if needed
 +
 +
== Related Notes ==
 +
 +
* Some examples on libvirt's blockcommit and blockpull -- http://kashyapc.fedorapeople.org/virt/lc-2012/snapshots-handout.html
 +
* More notes on libvirt qcow2 based block operations -- http://kashyapc.fedorapeople.org/virt/lc-2012

Revision as of 12:13, 27 June 2013

QEMU guest-assisted snapshotting

Related blueprints

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:

  1. User calls new nova API call to executed an assisted snapshot
  2. Nova will quiesce guest (use existing pause functionality if guest assisted quiesce is not available)
  3. Nova will execute snapshot API call in Cinder for each Cinder Volume
  4. Cinder creates snapshot(s)
  5. Nova resumes VM on completion of the snapshot(s)

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

Related Notes