Introduction

Currently CloudStack supports volume snapshots but User has to wait for whole backup to copy to secondary storage before performing any operation on VM. These waits can be long and frustrating. Also currently in CloudStack,  VM snapshots and volume snapshots cannot exist together. If user has taken VM snapshots then he cannot take volume snapshots on volume of VM and vice versa. With latter limitation user tries to create volume snapshots frequently. Volume snapshots are not meant to be taken frequently. For frequent purposes user are supposed to take VM snapshots. But they cannot do so because of limitation.

This document describes the feature which will ease the above operations by deferring the backup snapshot for later and by allowing VM snapshots and volume snapshots to exist together. 

Purpose

This is a functional specification for feature ‘snapshot Improvements’.

References

JIRA Ticket

Unable to render Jira issues macro, execution error.

Branch

master

Document History

Glossary

Snapshot : snapshot refers to volume snapshot if not specified specifically

Feature specifications

• Split volume snapshot process into two parts i.e. take volume snapshot and backup volume snapshot.
• After taking volume snapshot user should be able to perform basic operations like stop start on VM.
• Remove VM snapshot cannot be taken if volume snapshots already exists and vice-versa restriction.
• Post this feature Users should be able to perform all operations on snapshots as earlier.
• User should get the response quicker in case of volume snapshots.
  
  

Quality risks involved (test guidelines)

• User should be able to perform all operation volume snapshots as they were able to do earlier
• Volume snapshot should not be corrupted in long run
• Volume snapshots of large volumes (which were timing out in customers setup) should behave as expected
• VM snapshots and volume snapshots created in any order should work as expected
• VM and volume snapshots related operation should be performed with at least 3-4 levels of both type of snapshots.

Error handling

• In case backup snapshot process fails then user will be provided with alert that backup of snapshot fails.
• All errors at various levels of operations will be logged in management-server.log
  
  

Use case

• User has to wait for long durations for snapshot backup and during this time he cannot perform any operation on VM.
• Because of volume and VM snapshots not existing together user tries to take volume snapshots frequently which is time consuming

Design description

We already support volume snapshot for hypervisors like VmWare, XenServer and KVM. This feature will only improve the experience with volume snapshots and VM snapshots.

• Volume snapshot creation will be divided into two part process.
  • Snapshot creation on primary storage. This part varies with hypervisors.
  • Backup of snapshot created on primary to secondary storage.
• A separate thread pool will be maintained for backup task.
• Once the snapshot creation on primary is done, we will add the backup snapshot task to thread pool and return the response to user immediately.
• After getting response user can perform some basic operations on VM.
• Backup Snapshot task will be scheduled in background.
• Snapshots which are not backed up will remain in transitional state to specify that they are not yet backed up.

Hypervisor specific for split snapshot

Vmware:

• We will take the full clone of VM for volume snapshot as thin clone will affect operations on VM till the snapshot is backed up to secondary.

All Volume and VM snapshots to exist together  

• Remove the restriction that VM and volume snapshots cannot exist together.
• Fix the issues related to these operations.

Limitations

Split Snapshot can be taken only if we take full clone of snapshotted VM in VmWare.

API Changes

NA

DB Changes

No

UI Flow

NA

Upgrade