This is an automated email from the ASF dual-hosted git repository. rohit pushed a commit to branch volume-snapshot-deletion in repository https://gitbox.apache.org/repos/asf/cloudstack-documentation.git
commit 37e3cc7c29323d3932fba28a28cad4c55cdd925e Author: Rohit Yadav <[email protected]> AuthorDate: Mon Aug 14 14:57:53 2023 +0530 storage: clarify volume and snapshot deletion behaviour Signed-off-by: Rohit Yadav <[email protected]> --- source/adminguide/storage.rst | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/source/adminguide/storage.rst b/source/adminguide/storage.rst index bee232e..dfeb5b8 100644 --- a/source/adminguide/storage.rst +++ b/source/adminguide/storage.rst @@ -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
