Ctrlk

Tenant Teardown: Storage Cleanup

Overview

Deleting a tenant (project) while volumes, volume snapshots, or images backed by volumes still exist can leave orphaned storage resources that consume quota and backend capacity. In some cases, the teardown can leave the Persistent Storage Service in an inconsistent state, blocking future operations on the affected backend.

This guide describes the constraints on tenant deletion with active storage resources, and the recommended workflow for a safe, complete teardown.

In this guide, you will clean up all storage resources belonging to a tenant before deleting it, avoiding orphaned resources and backend inconsistencies.

Constraints

Before you delete a tenant, you must remove or transfer all storage resources that belong to it:

Resource Type
Constraint

Volumes in in-use state

Must be detached from all VMs before deletion. Cannot be deleted while attached.

Volumes with snapshots

All volume snapshots must be deleted before the parent volume can be deleted.

Volumes in error or error_deleting state

Require state reset before deletion.

Images backed by volumes

The image must be deleted (or deregistered) before the backing volume can be removed.

Volume snapshots

Must be deleted in reverse creation order when snapshots are chained (for backends that use CoW clones).

If you attempt to delete a tenant while these resources remain, the Identity Service will either refuse the deletion or complete the tenant deletion while leaving the storage resources orphaned (no longer accessible under any tenant but still consuming backend capacity).

Safe Teardown Workflow

Perform the following steps in order. All commands use the credentials of the tenant being torn down, or of an administrator scoped to that tenant.

Step 1 — List All Storage Resources in the Tenant

Get a complete inventory before you start:

Save the output. You will work through each resource in the subsequent steps.

Step 2 — Detach All Volumes from Running VMs

A volume cannot be deleted while it is attached to a VM. Identify attached volumes:

For each in-use volume, identify the attached VM and detach:

Wait for the volume to return to available state before proceeding:

Step 3 — Delete All Volume Snapshots

Volume snapshots must be deleted before their parent volumes. If your backend uses copy-on-write chains (NetApp FlexClone, Pure, Tintri), snapshots created later depend on earlier ones. Delete the most recently created snapshots first.

Delete each snapshot:

If a snapshot is stuck in error_deleting state, reset it and retry:

Wait for each snapshot to complete deletion before deleting the next one in a chain. If you delete a parent snapshot while a dependent snapshot still exists, the operation will fail.

Step 4 — Delete Volume-Backed Images

Images that were created from volumes or uploaded to a volume-backed backend may have a dependency on a volume. Identify and delete them:

If an image was created from a volume snapshot, deleting the image may also require that you delete the associated boot volume or snapshot first, depending on the backend.

Step 5 — Delete All Volumes

After all snapshots and image dependencies are removed, delete the volumes:

For volumes in error state, reset them first:

For volumes that fail to delete and return error_deleting, reset the state and retry, or use the force-delete flag:

Force delete and backend cleanup

--force removes the volume record from the Persistent Storage Service database but does not guarantee that the backing LUN or file was removed from the storage array. After force-deleting, verify on the storage backend that the corresponding resource was actually removed. Orphaned backend resources consume capacity silently.

Step 6 — Verify No Storage Resources Remain

Before deleting the tenant, confirm that the tenant has no remaining storage resources:

Both commands should return empty lists. If any resources remain, address them before proceeding.

Step 7 — Delete the Tenant

Once all storage resources are removed, delete the tenant through the Identity Service:

  1. Navigate to Identity > Tenants in the Private Cloud Director UI.

  2. Select the tenant and choose Delete from the Actions menu.

Or using the CLI:

Deleting a Volume Backend While Volumes Still Exist

Removing a volume backend from a cluster blueprint while volumes that were created on that backend still exist can leave those volumes inaccessible. The volume records remain in the Persistent Storage Service database but cannot be operated on because the backend that hosted them is no longer present.

Before removing a volume backend:

  1. Migrate all volumes from the backend to another backend using volume retype:

  2. Verify that each volume's os-vol-host-attr:host attribute reflects the new backend:

  3. After all volumes are migrated, remove the volume backend from the cluster blueprint.

If you remove a backend before migrating volumes, those volumes will be in error state with no backend to serve them. Contact Platform9 support for guidance on recovering volumes whose backend no longer exists.

Handling Volumes That Cannot Be Deleted

Some volumes may be undeletable because of dependencies that are not immediately visible:

Situation
Resolution

Volume has snapshots

Delete all snapshots first, then delete the volume

Volume was uploaded to an image and the image still exists

Delete the image first

Volume is a clone source for another volume (backend-managed dependency)

The backend retains the clone relationship internally; check with your storage administrator whether the backend source can be removed safely

Volume is in maintenance state from a failed migration

Reset migration status and volume state, then delete

For the last case:

Next Steps

PreviousBoot-from-Volume Provisioning and Failure RecoveryNextOverview

Last updated

Was this helpful?