Skip to content

storage: clarify volume and snapshot deletion behaviour #340

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
yadvr merged 1 commit into from
Aug 14, 2023
Merged

storage: clarify volume and snapshot deletion behaviour #340

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 10 additions & 2 deletions source/adminguide/storage.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -711,10 +711,18 @@ Volume Deletion and Garbage Collection
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The deletion of a volume does not delete the snapshots that have been
created from the volume
created from the volume.

When a VM is destroyed, data disk volumes that are attached to the VM
are not deleted.
are not deleted unless specified.

In managed storage systems such as Solidfire and others, the volume snapshots
are linked entities in the volumes wherein deletion of the volume would delete
those snapshots. In such managed storage systems, the volume snapshots exist on
the primary storage and may not be backed up to the secondary storages. For a
volume deleted in CloudStack, it will not be deleted on the managed storage
(such as Solidfire and others) until all the volume snapshots are deleted in
CloudStack.

Volumes are permanently destroyed using a garbage collection process.
The global configuration variables expunge.delay and expunge.interval
Expand Down