vSAN Deletion Process

8 min

Block-Level Architecture Foundation

KorGrid's vSAN operates on a block-level architecture where:

VM and Tenant disks are divided into multiple blocks

Each block receives a unique cryptographic hash

Blocks are distributed across nodes using hash-based algorithms

Both primary and redundant copies are maintained

Tenants operate as LXC containers with their own storage allocations within the parent vSAN

How Deletion Works

Reference Counting System

When you delete a VM, drive, or tenant:

The system doesn't immediately delete the actual data blocks

Instead, it removes the references to those blocks from the hash map

Each block maintains reference counts tracking how many objects use it

Tenant storage follows the same reference counting as individual VMs, but operates within LXC container boundaries

Deduplication Impact

Since KorGrid uses block-level deduplication:

Multiple VMs may share identical blocks (same hash)

Tenant storage can share blocks with parent system or other tenants

Deleting one VM or tenant only decrements the reference count

Blocks are only marked for deletion when reference count reaches zero

Garbage Collection Process

The actual deletion happens through background processes:

vSAN Walk: The system periodically scans for unreferenced blocks

Blocks with zero references are marked for reclamation

Physical storage space is then freed and made available

Tenant deletions trigger the same garbage collection as VM deletions

Immediate vs. Actual Reclamation

Immediate: UI shows space as "freed" immediately

Actual: Physical space reclamation happens during background vSAN operations

This is why you might not see storage space decrease immediately after deletion.

Drive / VM Deletion

When you delete a VM or drive:

References are removed from the system

Hash map entries are updated

Background processes handle actual block cleanup

Snapshots and Deletion

Deleting a VM also deletes its VM snapshots

However, the VM remains in system snapshots taken while it existed

Tenant Deletion Scenarios

When deleting a Tenant:

All tenant VMs, drives, and metadata references are removed

Tenant storage tiers are dereferenced from the parent vSAN

LXC container filesystem and allocated storage are cleaned up

Hash map entries for all tenant blocks are updated

Background processes handle block cleanup across all tenant data

Key Considerations

VM/Drive Deletion Within Tenants

When deleting VMs or drives inside a tenant:

References are removed from tenant's local hash map

Parent vSAN hash map entries are also updated

Background processes handle actual block cleanup

Tenant vs. Parent vSAN Relationship

Tenants operate as LXC containers within the parent vSAN - they don't have separate vSANs

Tenant storage is allocated from parent vSAN tiers through container filesystem layers

Block deduplication works across tenant boundaries and between containers

Parent system manages all physical storage cleanup for tenant containers

Snapshots and Tenant Deletion

Deleting a tenant also deletes its local VM snapshots

Tenant remains in parent system snapshots taken while it existed

System snapshots can prevent immediate storage reclamation

Tenant can be restored from system snapshots even after deletion

Shared Objects and File Sharing

Files shared between parent and tenant may maintain references

Shared VM snapshots can prevent complete storage cleanup

Files provided to tenants create additional block references

Consider shared objects when estimating storage reclamation

When a tenant is deleted, associated network resources are automatically cleaned up

IP addresses assigned to tenant VMs and networks are released back to the pool

Network blocks (subnets) allocated to the tenant are unassigned and returned to available inventory

Network interfaces and routing configurations are automatically removed

DNS entries and network policies associated with the tenant are cleaned up

Advanced Scenarios

Nested Tenant Deletion

For tenants that host their own sub-tenants:

Sub-tenants operate as nested LXC containers

Sub-tenant deletion follows same reference counting within container hierarchy

Parent tenant container manages sub-tenant storage cleanup

Multiple layers of containerization and reference counting may apply

Cleanup processes work from innermost to outermost container

Tenant Restore Impact on Deletion

Restoring deleted tenants from system snapshots recreates references

Previously "deleted" blocks may become active again

Storage usage may increase when restoring tenants

Background cleanup processes adapt to restored references

Monitoring

Parent System Monitoring

Storage dashboard for overall tier utilization

vSAN diagnostics for background operation status

System logs for tenant deletion and cleanup details

Tenant statistics showing storage consumption trends

Tenant-Level Monitoring (before deletion)

Tenant dashboard for internal storage usage

Tenant history for consumption statistics

Internal vSAN statistics within tenant environment

Post-Deletion Verification

Storage tier utilization should decrease over time

vSAN walk statistics show cleanup progress

Reference count verification through vSAN diagnostics