Skip to end of metadata
Go to start of metadata


  • Introduction
  • Purpose
  • References
  • Branch
  • Document History
  • Glossary
  • Use case
  • Feature Specification
  • Error Handling
  • Design Description
  • API Changes
  • DB Changes
  • UI Flow 
  • Hypervisors supported


Currently, Volume Snapshots in Cloudstack take considerable amount of time to complete thereby blocking other operations on the VM. This is because, the volume snapshot operation involves 2 steps - creating a snapshot of the volume on primary storage and then backing it on secondary storage. This feature will separate the creation of snapshot on primary and its copying onto secondary.



This is a functional specification of the feature "Separate creation and backup operations for a volume snapshot".


JIRA Ticket



Document History

Harika Punna
First Revision2nd May, 2017


  • Snapshot - snapshot refers to volume snapshot if not specified specifically.

Use case

  • User wants to separate the creation and backup operation of volume snapshot.

Feature Specification

  • As part of this feature, as soon as the snapshot gets created on primary, the user gets a notification, saying that the snapshot has been successfully created on primary and the copying of it to secondary is taking place.

  • TODO- Have to check if creation of volume and template is possible from snapshot on primary.

Error Handling

  • All errors at various levels of operations will be logged in management-server.log.
  • If the creation of snapshot fails before its done on Primary, the error handling will be same as the one happening now i.e will be notified about the error that has happened.
  • If the backing up of snapshot on secondary fails, the garbage collection thread will remove the snapshot even on primary.


Design Description

This feature will only improve the experience with volume snapshots.

  • If the snapshot is successfully created on primary i.e. when the status in snapshots table is "CreatedOnPrimary", the backup process starts and the result of snapshot creation will be returned. 
  • Currently, only the deletion operation can be performed on the snapshot which is on primary.
  • The backup process if fails, runs for "backup.max.attempts", with interval between attempts "backup.retry.interval". If within these number of attempts, the creation of backup is not successful, then the snapshot will be deleted from primary even, by the garbage collector.
  • A separate thread pool will be maintained for backup task.

    Configuration parameters: 

    Param Name
    Default Value
    backup.retry.interval300 seconds


API Changes

An additional param will be added to CreateSnapshotCmd, on whose value the decision of, if to separate the snapshot and copy operations or if to continue with the existing one is decided.





DB Changes



UI Flow

A checkbox will be added to the "Create Volume Snapshot" dialog box, which when checked, snapshot and copy operations will be separated and if left unchecked the existing flow continues. By default, the check box will be checked.


Hypervisors supported

 Xenserver, KVM

  • No labels