You added a storage location in Proxmox VE months ago, and now you can't get rid of it. Maybe you typed the ID wrong the first time. Maybe you moved your NFS share to a new server and the old entry is just sitting there, greyed out and useless. Or maybe you're trying to add a storage with the name backup and Proxmox is telling you it already exists — except you're pretty sure you deleted it last week.
Here's the thing nobody tells you up front: Proxmox VE has no "rename" button for storage. Once you create a storage ID, that name is permanent unless you remove it and start over. And removing it isn't always as simple as clicking a trash icon, especially if virtual machines are still using it.
This tutorial walks through both operations properly — how to safely delete a storage definition, and the actual workaround for renaming one, without breaking any VM or container that depends on it.
What You Will Learn
- What a "storage definition" actually is in Proxmox VE, and why it's separate from your data
- Why there's no built-in rename command, and what to do instead
- How to check whether anything is still using a storage before you touch it
- The exact GUI and CLI steps to remove a storage safely
- How to move VM and container disks off a storage so you can retire it cleanly
- What the common error messages mean and how to fix each one
What Is This Feature?
When people say "storage" in Proxmox VE, they usually mean one of two things, and mixing them up is where most of the confusion starts.
The first is the physical thing: a disk, a ZFS pool, an NFS share, a directory on your root filesystem. That's where your VM disks and backup files physically live.
The second is the storage definition — a named entry in Proxmox VE that tells the cluster "here's a place to put things, here's its type, and here's what you're allowed to store on it." That definition lives in a single file: /etc/pve/storage.cfg. Every node in a cluster reads from the same file, which is why adding storage on one node makes it visible everywhere (assuming the underlying path or share is actually reachable from those nodes too).
When you click Remove on a storage in the web interface, you are editing that file. You are not touching the disk, the ZFS pool, or the NFS export behind it. This distinction matters more than it sounds like it should, and it's the source of most of the mistakes people make with this feature.
Why Would You Use It?
A few situations come up constantly:
- Typos. You named a storage
bakupinstead ofbackup, and now every automation script and mental habit expects the correct spelling. - Infrastructure changes. You replaced an old NFS server, and the storage entry pointing at its IP address is now dead weight.
- Cleanup. You tested a storage type — say, an iSCSI target — decided against it, and want the leftover entry gone so it stops showing up (and erroring out) in the storage list.
- Naming consistency. You're standardizing storage IDs across a cluster and one node's local storage doesn't match the naming pattern.
None of these are advanced, cluster-wide operations. They're the kind of small housekeeping tasks that trip people up specifically because Proxmox VE doesn't advertise how to do them anywhere obvious in the GUI.
Prerequisites
Before you start, make sure you have:
- Root or administrative access to a Proxmox VE host (this guide was tested on Proxmox VE 8.x, and the same commands work on 9.x)
- SSH access to the node, or access to the Shell button in the web console, if you want to use the command-line steps
- A list of which VMs and containers currently use the storage you're about to touch — you'll build this in the first step below if you don't already have it
You do not need to schedule downtime just to remove a storage definition. You only need downtime, or at least a maintenance window, if you're moving disks off a storage that's actively serving a busy VM — and even then, disk moves in Proxmox VE can usually run while the VM stays online.
Step-by-Step Tutorial
Step 1: Find out what's actually using the storage
Don't skip this. Removing a storage definition that a running VM depends on doesn't delete any data, but it does break that VM's ability to find its own disk.
In the web interface, click on the storage under any node in the left-hand tree, then open its VM Disks tab (for storages that host disk images) or Backups tab. That tab lists every disk image currently stored there, tagged with the VM ID it belongs to.
From the shell, you can get the same answer faster:
pvesm statusThis prints every configured storage, its type, whether it's active, and how much space is used. It won't tell you which VMs are using it, though. For that, grep the config files directly:
grep -l "oldstorage:" /etc/pve/qemu-server/*.conf /etc/pve/lxc/*.confReplace oldstorage with your actual storage ID. Any file that matches has a VM or container disk sitting on that storage.
Step 2: Move disks off the storage (if anything is using it)
If step 1 came back empty, skip to Step 3.
If it didn't, you need to relocate those disks before removing the storage — otherwise the VM will fail to start the next time it's rebooted, with an error that mentions the missing storage ID.
In the GUI, select the VM, go to its Hardware tab, click the disk, and choose Disk Action → Move Storage. Pick the destination storage and, optionally, a different disk format. Proxmox VE will copy the disk over — for a running VM this happens live, with no reboot required, though it does use disk I/O and bandwidth while it runs.
From the command line, the equivalent for a VM disk is:
qm move-disk 100 scsi0 newstorageHere, 100 is the VM ID, scsi0 is the disk you're moving, and newstorage is the destination storage ID. For an LXC container, the command is pct move-volume instead:
pct move-volume 100 rootfs newstorageRepeat for every disk on every VM or container that showed up in Step 1.
Step 3: Remove the storage definition
Once nothing references the storage anymore, removing it is quick. In the GUI, go to Datacenter → Storage, click the storage you want gone, and click Remove in the toolbar. You'll get a confirmation prompt — confirm it, and the entry disappears from every node immediately.
From the shell:
pvesm remove oldstorageThis edits /etc/pve/storage.cfg and takes effect cluster-wide right away, since that file is synced automatically across all nodes.
One thing worth repeating: this command does not touch the actual files, ZFS pool, or NFS export behind the storage. If you also want the data gone — say, you're decommissioning an old NFS server entirely — you'll need to clean that up separately, on the system that actually hosts it.
Step 4: "Rename" the storage by recreating it
Since there's no rename option, the actual process is: create a new storage entry with the name you want, move everything over, then delete the old one.
Add the new storage with the correct ID, pointing at the same physical location as the old one. For a directory-based storage, that looks like:
pvesm add dir backup-nas --path /mnt/pve/backup-nasFor an NFS share:
pvesm add nfs backup-nas --server 192.168.1.50 --export /export/backups --path /mnt/pve/backup-nasThen repeat Steps 1 and 2 above, moving every disk from the old storage ID to the new one. Once the old one is empty, remove it with pvesm remove.
Yes, this means downloading and re-uploading nothing — the disk move commands work directly between storages without round-tripping data off the server, so this is faster than it sounds. For a handful of VMs it typically takes a few minutes per disk, depending on disk size and how fast the target storage is.
Commands Explained
| Command | What it does |
|---|---|
pvesm status | Lists every configured storage, its type, and current usage. Good first command when troubleshooting anything storage-related. |
pvesm add <type> <id> [options] | Creates a new storage definition. The type (dir, nfs, zfspool, lvm, cifs, and so on) determines which options are required. |
pvesm remove <id> | Deletes a storage definition from storage.cfg. Does not delete any actual data. |
qm move-disk <vmid> <disk> <storage> | Moves a single VM disk to a different storage, live if the VM is running. |
pct move-volume <vmid> <volume> <storage> | Same idea as qm move-disk, but for LXC container volumes. |
grep -l "id:" /etc/pve/qemu-server/*.conf | Searches every VM's configuration file for references to a given storage ID, so you know what depends on it before you remove anything. |
Common Errors
"storage ID 'x' already defined" — you're trying to add a storage with a name that's already taken in storage.cfg. Check pvesm status first; the old entry is probably still there, possibly inactive.
"unable to activate storage 'x' - directory ... does not exist" — the storage definition exists, but the path, mount, or export behind it isn't reachable anymore. This is the classic sign of an entry that survived a server migration when the underlying data didn't.
VM fails to start with "unable to parse volume filename" or references a storage ID that no longer exists — this happens if you removed a storage while a VM's disk was still pointing at it. Add the storage back temporarily, move the disk properly using Step 2 above, then remove it again.
"no such logical volume" after removing an LVM-backed storage — removing the storage definition doesn't touch the underlying LVM volume group. If you also deleted the volume group manually and a VM still references it, you'll need to restore from backup, since the actual data is gone, not just the pointer to it.
Troubleshooting
If a storage won't remove through the GUI and you get a vague error, try the CLI version — pvesm remove — since it usually gives a more specific message about what's blocking it.
If you're not sure whether a storage is safe to delete, check its Summary tab in the GUI first. A "Used" value above zero means something is stored there, even if you can't immediately tell what.
For shared storage in a cluster — NFS, CIFS, iSCSI, Ceph — remember that removing the definition affects every node at once, not just the one you're logged into. Double-check no other node has a VM quietly using it before you pull the trigger.
If you accidentally remove a storage that was still in use and now have a VM that won't boot, don't panic. The data is almost always still there. Re-add the storage definition with the exact same ID and matching path or connection details, and the VM should find its disk again immediately.
Best Practices
Name storages the way you intend to keep them from day one. Renaming later is possible but tedious, and it's the kind of task that's easy to put off indefinitely once your cluster has more than two or three VMs on it.
Before removing anything, run pvesm status and take a screenshot or copy the output somewhere. It costs you ten seconds and gives you a rollback reference if something goes wrong.
Avoid hand-editing /etc/pve/storage.cfg directly unless you're confident with its syntax. It's a plain text file, so nothing stops you from opening it in an editor — but a typo there can make every node in the cluster fail to activate that storage at once, which is a worse problem than the one you started with. Stick to pvesm commands or the GUI.
If you're cleaning up a cluster with a lot of accumulated storage entries, do it one at a time and verify with pvesm status after each removal. Batch cleanups feel efficient right up until you remove the wrong one.
Frequently Asked Questions
Can I rename a storage without moving any disks?
No. The storage ID is baked into every VM and container disk reference that uses it, so there's no safe way to change the name in place without also updating those references.
Does removing a storage delete my VM disks?
No. pvesm remove only deletes the definition in storage.cfg. Your actual disk images, ZFS datasets, or files on the NFS share are untouched.
What happens if two storages point at the same physical path?
Proxmox VE will let you do this, but it's a bad idea. Both entries will report the same used space, and Proxmox has no way of knowing a disk "belongs" to one storage ID versus the other if you start creating VMs in both.
Can I remove a storage while VMs on other nodes are using it?
Technically the command will succeed, but every VM referencing that storage — on any node — will break the next time it needs to access its disk. Check across the whole cluster, not just the node you're on.
Is there a way to undo a storage removal?
Yes, as long as you remember the exact type, ID, and connection details. Re-adding a storage with the same ID pointing at the same location restores access to any data that's still sitting there.
Conclusion
Storage management in Proxmox VE is refreshingly simple once you separate the two things people usually conflate: the definition in storage.cfg, and the actual data sitting on disk somewhere. Removing a storage is safe and reversible as long as nothing is actively using it. Renaming one just means doing that removal in reverse — add the new name first, migrate what's using the old one, then clean up.
It's a five-minute job once you know the order of operations. The only real risk is skipping the check for what's still attached to the old storage, so if you take one thing from this guide, make it that first grep command.