Managing Storage Space in Proxmox: How to Clean Up Unused ISOs and Disks

For a long time, cleaning storage in Proxmox felt more dangerous than creating it.

That imbalance is common in a homelab.

Adding things is easy. You download another ISO because you might need it later. You import a disk because a migration experiment seemed worth trying. You move a VM to different storage, test a restore, clone something quickly, detach something temporarily, and promise yourself you will come back to the leftovers when the lab is calmer.

The lab is rarely calmer.

So storage slowly fills with polite ghosts: old installers, detached disks, abandoned experiments, and volumes that are no longer doing useful work but still occupy very real space. What made cleanup hard for me was not the commands. It was trust. I did not want to free storage by deleting something I only half understood.

What finally helped was changing the mindset. Storage cleanup is not really a deletion problem first. It is an inventory problem first.

For the technical baseline below, I use Proxmox VE documentation and separate documented platform behavior from my own placement and operating recommendations.

Cleanup feels risky because Proxmox storage is more structured than a normal folder

This is the first thing that made the whole subject easier for me.

In an ordinary filesystem, “clean up old files” usually means exactly what it sounds like. In Proxmox, storage is more layered than that. The official storage documentation is very explicit that a storage backend can hold different content types such as VM disk images, container root directories, ISO images, templates, backups, and snippets, and that not every storage supports every content type.

That matters because “storage space” is not one pile of interchangeable files.

An ISO library on a directory storage is one kind of cleanup problem.
A detached VM disk is a different kind of cleanup problem.
A thin-provisioned guest disk that still looks large on the host is another.

Once I stopped treating all of that as one generic “delete old stuff” task, the process became much calmer.

The first useful separation is this: ISO images, attached disks, and unused disks

This is the classification I wish I had much earlier.

ISO images

These are usually the easiest to reason about. On file-based storages, Proxmox stores ISO images under template/iso/, and the storage documentation even shows that directory layout directly. These are installer images, rescue media, or other bootable files. If no current workflow needs them, they are usually safe to remove after a quick sanity check.

Attached disks

These are disks still referenced by a VM or container configuration. If a disk is attached and in active use, cleanup is not about deleting it casually. It may instead be about shrinking the guest’s actual footprint, moving storage, or reclaiming thin-provisioned blocks correctly.

Unused disks

This is the category that tends to confuse people most.

The qm documentation documents unused[n] entries as references to unused volumes and explicitly says they are used internally and should not be modified manually. That alone is a helpful warning. An unused0 entry is not “imaginary metadata.” It is Proxmox telling you there is a real volume no longer attached to the VM as an active disk, but still present and referenced in the configuration.

That is cleanup gold, because it gives you a safe place to look first.

Start with storage inventory, not deletion

Before removing anything, I want three questions answered:

1. Which storages are actually full or under pressure?
2. Which content types live there?
3. Which volumes are still referenced by guests and which are just hanging around?

The first quick view is:

pvesm status

Then I like to inspect the storage more specifically.

For ISO content on a storage:

pvesm list <STORAGE_ID> --content iso

The Proxmox storage documentation gives this exact pattern as an example, and I like that because it keeps the inventory step inside Proxmox’s own storage model instead of jumping straight to manual filesystem deletion.

For the file layout itself, it is also useful to remember what the storage docs say about directory-backed storages:

• VM images live under images/<VMID>/
• ISO images live under template/iso/

That helps when you need to verify the physical path, but I still prefer starting from pvesm list because it thinks in volume IDs and content types, which is safer.

ISO cleanup is usually the least emotional win

This is often the easiest storage space to recover without touching live workloads.

Most homelabs accumulate old Debian images, Ubuntu installers, rescue ISOs, Windows media, test appliance images, and one-off downloads that made perfect sense on a specific day. Months later they are just occupying directory storage quietly.

My cleanup rule for ISOs is simple:

• keep current installers I genuinely use;
• keep rare rescue or vendor media that would be annoying to find again;
• remove duplicate old versions and one-time experiment images.

If I want to inspect the list from the CLI, I use:

pvesm list local --content iso

Or the relevant storage ID if the ISO library is not on local.

If I am deleting through the GUI, I still like to cross-check what the storage is meant to hold first. In the broader storage types article, the calmer lesson was that directory storage is often the obvious home for ISO files and templates. That also means it becomes the obvious place where forgotten media starts collecting.

Unused disks deserve more respect than old ISOs

This is where I slow down.

Proxmox can create unused[n] entries for several very normal reasons:

• you detached a disk from a VM;
• you moved a disk and kept the original as an unused disk;
• you imported a disk image as unused first;
• you restored, migrated, or reworked something and never finished the cleanup.

The qm disk move documentation makes this especially clear: by default, the original disk is kept as an unused disk after a successful copy unless you explicitly delete it. That is an excellent safety feature, but it also means storage can accumulate leftovers if you treat every move as “I will clean that up later.”

To inspect a VM config for unused disks:

qm config <VMID>

Then look for lines such as:

unused0: local-lvm:vm-101-disk-1
unused1: local:101/vm-101-disk-2.qcow2

If I want Proxmox to refresh what it sees across storages, the docs also give:

qm rescan

Or equivalently qm disk rescan, which rescans all storages and updates disk sizes and unused disk images.

That can be a very helpful “make the host tell the truth again” step before a cleanup session.

The safest cleanup sequence is verify, detach mentally, then remove

This is the emotional order that keeps me out of trouble.

Before deleting an unused disk, I want to know:

• which VM it belonged to;
• whether it is the current boot or data disk under another name;
• whether it was kept intentionally after a move or restore;
• whether a backup exists if I later regret the deletion.

Only then do I remove it.

The official qm disk unlink documentation is very useful here because it explains the behavior clearly. Without forcing physical removal, unlink removes the disk from the config and creates an unused[n] entry. But unlink of an unused[n] entry always causes physical removal.

That means a safe pattern is:

qm disk unlink <VMID> --idlist unused0

That is a much more trustworthy cleanup action than editing config files manually or deleting raw files behind Proxmox’s back.

pvesm free is powerful, which is exactly why I treat it carefully

The Proxmox storage docs document:

pvesm free <VOLUME_ID>

That is the storage-level way to free a volume by volume ID. It is useful, but I treat it as a second-step tool, not my first cleanup reflex. The reason is simple: if the host still has an easier, more contextual path through a VM config or through the GUI, I prefer to use that first.

Where pvesm free becomes especially useful is when I have already verified that a volume is truly no longer needed and I am working directly with a known Proxmox volume ID rather than with an arbitrary path on disk.

That is the difference I care about:

• deleting by trusted Proxmox identity;
• not deleting by vague filesystem feeling.

Deleting files inside the guest is not the same thing as reclaiming host storage

This is one of the most misleading parts of the whole topic.

Sometimes storage pressure is not caused by forgotten ISOs or detached disks. Sometimes the real frustration is this:

"I deleted a lot of files inside the VM. Why does the Proxmox host still show the disk as large?"

The qm documentation explains why. On thin-provisioned storage, space can be reclaimed when the guest marks blocks as unused and discard or TRIM is properly enabled through the whole path. The docs are explicit that for the guest to issue TRIM commands, discard must be enabled on the virtual disk, and the guest OS must support TRIM.

That matters a lot.

If discard is not enabled, then deleting files inside the guest may reduce guest filesystem usage without shrinking the host-side image the way you expected. That is not leftover ISO clutter. That is storage behavior.

This is also why the newer article comparing ZFS datasets and LVM-thin matters here. Cleanup decisions depend on what kind of storage backend is underneath the guest and how that backend treats space reclamation.

A small repeating cleanup habit is much better than a quarterly storage panic

This is probably the most practical lesson.

Storage cleanup is stressful when it only happens under pressure. By the time a thin pool is close to full or the directory storage is unexpectedly crowded, every deletion starts feeling loaded. That is exactly when mistakes become more tempting.

So the routine I would trust now is simple:

1. review pvesm status;
2. list ISO content on directory-backed storages;
3. inspect a few older or modified VMs for unused[n] entries;
4. confirm whether guest-side deletion is actually reclaiming host blocks where thin provisioning is involved;
5. clean small leftovers before they become a capacity story.

This is also one reason I think backups and storage hygiene belong together. If cleanup feels impossible because every old disk might secretly matter, that is often a backup confidence problem too. The day Proxmox Backup Server started feeling real to me was also the day deletion felt less superstitious.

Conclusion

Managing storage space in Proxmox becomes much safer once cleanup stops being a nervous deletion exercise and becomes a structured inventory habit. ISO images, attached disks, unused disks, and thin-provisioned guest space are not the same problem, so they should not be cleaned up the same way. The official Proxmox storage and qm tools already give a calm workflow: inspect the storage, list content types, identify unused[n] entries, rescan when needed, and remove volumes through Proxmox-aware commands rather than by improvising on the filesystem.

What changed the experience for me was not a clever one-liner.

It was finally trusting the difference between “old” and “provably unneeded.”