How to securely decommission a LXD deployment¶
Follow these steps to securely decommission your LXD deployment on a standalone server, cluster member, or cluster.
Important
This process will erase all data associated with your LXD deployment. Make copies of any data that you need to preserve before proceeding. Refer to How to back up instances and How to back up custom storage volumes for relevant details.
To decommission a standalone server, proceed directly to Revoke remote access. To decommission a single member of a cluster, proceed to Remove offline cluster members or Remove an online cluster member, depending on the member’s status. To decommission an entire cluster, first delete replicators and cluster links.
Delete replicators and cluster links¶
Note
Only delete replicators and cluster links if you are decommissioning an entire cluster.
Replicators are scoped by project and must be deleted by project. First, list all projects:
lxc project list
Next, list all replicators for each project, then delete each replicator:
lxc replicator list --project <project_name>
lxc replicator delete <replicator_name> --project <project_name>
Finally, list cluster links, then delete each one:
lxc cluster link list
lxc cluster link delete <cluster_link_name>
Remove offline cluster members¶
To decommission an entire cluster or a single offline member, remove offline cluster members with the --force flag:
lxc cluster remove --force <member_name>
Important
If you are only decommissioning the offline member, update the cluster certificate on the cluster. After removing the offline member, run this command on any member of the cluster remaining in production:
lxc cluster update-certificate <cert.crt> <cert.key>
Then, to decommission the cluster member, proceed to Remove the LXD snap. To decommission the remaining cluster, proceed to Revoke remote access (you will remove online cluster members after you delete data).
Remove an online cluster member¶
To decommission a single, online cluster member, first evacuate instances from the cluster member to other members:
lxc cluster evacuate <member_name>
Instances that are not suitable for migration may remain on the cluster member. Verify that no instances remain on the cluster member:
lxc list location=<member_name> --all-projects
If instances remain on the cluster member, migrate those instances to another cluster member:
lxc move <instance_name> --target <target_member_name>
Remove the member from the cluster:
lxc cluster remove <member_name>
Then, update the cluster certificate by running this command on any member of the cluster remaining in production:
lxc cluster update-certificate <cert.crt> <cert.key>
Now proceed to Remove the LXD snap to decommission the removed member.
Revoke remote access¶
Note
To decommission an entire cluster, run the commands in this section on any cluster member.
List all identities that have access to LXD, then delete each one:
lxc auth identity list
lxc auth identity delete <type>/<name_or_identifier>
To decommission a deployment configured for single sign-on with OIDC, remove the corresponding profile from your OIDC identity provider.
Delete data¶
Important
Data deleted by LXD physically remains on disks and can be recovered by users with access to the disks. To prevent unauthorized data recovery, you must destroy and sanitize your data.
To decommission a single cluster member, run these commands after removing the member from the cluster. Do not run these commands on any member of a cluster that will remain in production.
Note
To decommission an entire cluster, run the commands in this section on any cluster member.
List projects¶
Instances, profiles, custom volumes, and buckets are scoped by project.
For deployments with more than one project, you must repeat some steps for each project, using the --project flag.
You do not need to use the --project flag to decommission deployments with only one project.
View all projects:
lxc project list
Note
You can also delete a project (except the default project) and all of its project-level entities with:
lxc project delete <project_name> --force
Stop and delete instances¶
For each project, stop all instances:
lxc stop --all --project <project_name>
Next, list the instances for each project, then delete each instance:
lxc list --project <project_name>
lxc delete <instance_name> --project <project_name>
Note
If you are unable to stop or delete an instance, use the --force flag:
lxc stop --force <instance_name> --project <project_name>
lxc delete --force <instance_name> --project <project_name>
Delete profiles¶
For each project, list all profiles, then delete every profile but the default profile:
lxc profile list --project <project_name>
lxc profile delete <profile_name> --project <project_name>
Note
The default profile cannot be deleted.
Delete custom volumes and buckets¶
You must specify storage pools to delete custom volumes or buckets. First, list all storage pools:
lxc storage list
Note
You do not need to specify a project. This command lists all storage pools across projects.
Next, list the custom volumes on each storage pool.
Use the --all-projects flag to view all custom volumes across projects:
lxc storage volume list <pool_name> type=custom --all-projects
Then, for Ceph Object pools only, list the buckets:
lxc storage bucket list <pool_name> --all-projects
Use the PROJECT column in the output to identify the project associated with each custom volume or bucket.
Finally, delete all custom volumes and buckets, specifying the storage pool and project:
lxc storage volume delete <pool_name> <volume_name> --project <project_name>
lxc storage bucket delete <pool_name> <bucket_name> --project <project_name>
Delete storage pools¶
Storage pools cannot be deleted if they are used by an instance, profile, custom volume, or bucket.
The default profile cannot be deleted; therefore, the storage pool used by the default profile cannot be deleted.
To identify this storage pool, view information about the default profile and find the pool listed under devices > root > pool:
lxc profile show default
Next, list all storage pools, then delete every pool but the one used by the default profile.
lxc storage list
lxc storage delete <pool_name>
Note
You do not need to specify a project when running these commands.
Delete monitoring data¶
Delete data from any external systems that you used to monitor events or monitor metrics, such as Loki, Prometheus, or Grafana. Refer to the documentation for those systems for details.
Remove remaining cluster members¶
To decommission an entire cluster, list all cluster members, then remove each one:
lxc cluster list
lxc cluster remove <member_name>
Note
Iterate over every cluster member name except the name of the member on which you are running the commands.
Offline cluster members should have been removed before revoking remote access. See Remove offline cluster members.
Remove the LXD snap¶
Important
Run these commands on every machine that you decommission.
Removing LXD does not erase dedicated disks/partitions, ZFS pools (zpools), LVM volume groups, or remote storage. To securely decommission LXD, you must destroy and sanitize your data.
Remove the LXD snap.
Use the --purge flag, or a snapshot of your data will be preserved:
sudo snap remove lxd --purge
Verify that the snap and associated data were removed.
The following commands should report that LXD is not installed and that the /var/snap/lxd/ directory does not exist:
snap list lxd
ls /var/snap/lxd/
Note
If you followed a different method to install LXD, use your package manager to remove LXD.
Then, delete the data in /var/lib/lxd/.
Destroy and sanitize data¶
Data deleted by LXD remains readable and can be recovered by users with access to disks used in your deployment. To prevent unauthorized recovery, you must physically overwrite the data.
Follow your data destruction policy to securely erase and destroy disks used by LXD, as well as disks on machines used to monitor LXD events or metrics. Consult storage providers for details about how to securely sanitize data on remote storage. For deployments configured for single sign-on with OIDC, consult your OIDC identity provider for the steps to remove any associated data.
Important
Sanitized data is irreversibly destroyed and cannot be recovered.