- Document History
- Use case
- Feature Specification
- Error Handling
- Design Description
- API Changes
- DB Changes
- UI Flow
- Hypervisors supported
- Parallel operations that can happen during backing up of snapshot
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".
|First Revision||2nd May, 2017|
- Snapshot - snapshot refers to volume snapshot if not specified specifically.
- User wants to separate the creation and backup operation of volume snapshot.
- 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.
- 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 snapshot will move to Error state, which later will be cleaned by storage GC thread and its related entries in snapshot_store_ref table will be deleted as and when retry fails.
- In case of management server stopping, while backing up of snapshot, on the restart of server, the snapshot will be moved to Error state and then be cleaned by GC thread.
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.
- No operation will be performed on the snapshot which is on primary and is in backingup state.
- 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.
A separate thread pool will be maintained for backup task.
Configuration parameters:Param NameDefault Value
backup.max.attempts 3 backup.retry.interval 300 seconds
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.
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.
Parallel operations that can happen during backing up of snapshot
- Volume operations
- Snapshot on same volume
- Snapshot on different volume
- VM Operations
- Start VM
- Stop VM
- Destroy VM (only when data disks are backing up)
- Reboot VM
- Reinstall VM (only when data disks are backing up)
- Attach ISO
- Attach disk
- Detach disk (other than the one backing up)
- Change service offering
All the other VM/Volume operations not listed above are not supported.