Jump to: navigation, search

Difference between revisions of "Cinder/GuestAssistedSnapshotting"

(QEMU guest-assisted snapshotting: API details)
Line 37: Line 37:
 
* Some examples on libvirt's blockcommit and blockpull -- http://kashyapc.fedorapeople.org/virt/lc-2012/snapshots-handout.html
 
* 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
 
* More notes on libvirt qcow2 based block operations -- http://kashyapc.fedorapeople.org/virt/lc-2012
 +
 +
 +
== API Details ==
 +
 +
===New APIs===
 +
 +
 +
====Cinder====
 +
new API "create-snapshot-from-metadata"
 +
- Allow creation of a snapshot by providing metadata rather than Cinder creating snapshot. (i.e. it was created by Nova)
 +
- Metadata: id (UUID)
 +
            volume_id
 +
            created_at
 +
            display_name (maybe?)
 +
            display_description (optional?)
 +
            size
 +
 +
new API "snapshot-delete-metadata"
 +
- Deletes a snapshot without performing any real storage operation
 +
- Is this needed?  Maybe not if the GlusterFS driver's snapshot-delete is smart enough.
 +
 +
 +
====Nova====
 +
  New API to create snapshots of multiple volumes
 +
  - Allow "all volumes" or a subset of volumes to be specified
 +
 +
===Snapshot creation===
 +
 +
 +
Case 1: Nova-driven snaps (attached)
 +
Nova (method 1):
 +
  Create-multiple-snapshots Nova API called, specifying which volumes, or all volumes
 +
    Determine which volumes are local files, which are iSCSI/FC-attached
 +
    Pause VM (w/ quiescing via qemu-ga)
 +
      For each local volume, create a qcow2 snapshot (libvirt: create-snapshot-as)
 +
          Create a Cinder snapshot with matching metadata  (cinder create-snapshot-from-metadata API call)
 +
    For each non-local volume, call Cinder client snapshot-create
 +
    Resume VM
 +
 +
Nova (method 2):
 +
  Create multiple-snapshots Nova API called, specifying which volumes, or all volumes
 +
    Determine which volumes are local files, which are iSCSI/FC-attached
 +
      - Fallback to method 1 if we need to snapshot other volumes through Cinder?  (Requires pause)
 +
    Call libvirt create-multiple-snapshots-with-rollback API call (does this exist?)
 +
    Create a Cinder snapshot for each snapshot created (cinder create-snapshot-from-metadata API call)
 +
  Done
 +
 +
Case 2: Cinder-driven snapshot
 +
  Only works if volume not attached
 +
  create-snapshot goes through GlusterFS driver like a typical Cinder driver snapshot
 +
  Snapshot created via qemu-img manipulation
 +
 +
 +
===Snapshot deletion===
 +
 +
Case 1: Nova-driven (attached)
 +
 +
Nova (method 1 - should work today):
 +
  Create libvirt snapshot from metadata retrieved from Cinder
 +
  Call libvirt blockpull operation (merge base into snapshot)
 +
  Rename snapshot file to previous base name (libvirt operation: ?)
 +
  Delete snapshot from Cinder (snapshot-delete-metadata, or maybe just snapshot-delete)
 +
 +
Nova (method 2 - more efficient, may not work today):
 +
  Create libvirt snapshot from metadata retrieved from Cinder
 +
  Call libvirt blockcommit operation (merge snapshot into base)
 +
    - In current (or at least recent) libvirt, live blockcommit is not supported.  Should be added in the future.
 +
  Delete snapshot from Cinder (snapshot-delete-metadata, or maybe just snapshot-delete)
 +
 +
Case 2: Cinder-driven
 +
  Only works if volume not attached
 +
  Delete via qemu-img manipulation, works like a typical Cinder driver

Revision as of 16:44, 3 July 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


API Details

New APIs

Cinder

new API "create-snapshot-from-metadata"

- Allow creation of a snapshot by providing metadata rather than Cinder creating snapshot. (i.e. it was created by Nova)
- Metadata: id (UUID)
            volume_id
            created_at
            display_name (maybe?)
            display_description (optional?)
            size

new API "snapshot-delete-metadata"

- Deletes a snapshot without performing any real storage operation
- Is this needed?  Maybe not if the GlusterFS driver's snapshot-delete is smart enough.


Nova

 New API to create snapshots of multiple volumes
  - Allow "all volumes" or a subset of volumes to be specified

Snapshot creation

Case 1: Nova-driven snaps (attached) Nova (method 1):

  Create-multiple-snapshots Nova API called, specifying which volumes, or all volumes
    Determine which volumes are local files, which are iSCSI/FC-attached
    Pause VM (w/ quiescing via qemu-ga)
      For each local volume, create a qcow2 snapshot (libvirt: create-snapshot-as)
         Create a Cinder snapshot with matching metadata  (cinder create-snapshot-from-metadata API call)
    For each non-local volume, call Cinder client snapshot-create
    Resume VM

Nova (method 2):

  Create multiple-snapshots Nova API called, specifying which volumes, or all volumes
    Determine which volumes are local files, which are iSCSI/FC-attached
      - Fallback to method 1 if we need to snapshot other volumes through Cinder?  (Requires pause)
    Call libvirt create-multiple-snapshots-with-rollback API call (does this exist?)
    Create a Cinder snapshot for each snapshot created (cinder create-snapshot-from-metadata API call)
  Done

Case 2: Cinder-driven snapshot

 Only works if volume not attached
 create-snapshot goes through GlusterFS driver like a typical Cinder driver snapshot
 Snapshot created via qemu-img manipulation


Snapshot deletion

Case 1: Nova-driven (attached)

Nova (method 1 - should work today):

 Create libvirt snapshot from metadata retrieved from Cinder
 Call libvirt blockpull operation (merge base into snapshot)
 Rename snapshot file to previous base name (libvirt operation: ?)
 Delete snapshot from Cinder (snapshot-delete-metadata, or maybe just snapshot-delete)

Nova (method 2 - more efficient, may not work today):

 Create libvirt snapshot from metadata retrieved from Cinder
 Call libvirt blockcommit operation (merge snapshot into base)
   - In current (or at least recent) libvirt, live blockcommit is not supported.  Should be added in the future.
 Delete snapshot from Cinder (snapshot-delete-metadata, or maybe just snapshot-delete)

Case 2: Cinder-driven

 Only works if volume not attached
 Delete via qemu-img manipulation, works like a typical Cinder driver