You just added a second drive to your Proxmox box, or maybe you finally set up a NAS and want your VMs living on something better than the one spinning disk you installed on. Now you're staring at a VM's Hardware tab wondering if you have to reinstall the whole thing just to change where its disk lives. You don't. Proxmox VE can move a virtual disk to a different storage location without touching a single file inside the guest operating system.
This guide walks through exactly how that works, both from the web interface and from the command line, for VMs and for LXC containers. By the end you'll know which storage types support this, what can go wrong, and how to avoid the mistake that trips up almost everyone the first time they try it.
What You Will Learn
- What "moving a disk" actually means in Proxmox VE, and how it's different from resizing or migrating a whole VM
- How to move a VM's disk using the GUI, step by step
- How to do the same thing from the shell with
qm disk move - How to move an LXC container's root disk or mount points with
pct move-volume - Which storage backends support this, and which combinations will make it fail
- How to fix the errors you're most likely to hit along the way
What Is This Feature?
Every VM disk in Proxmox VE is really just a file or a block volume sitting on some storage backend: a directory on your boot drive, an LVM-thin pool, a ZFS pool, an NFS share, or a Ceph RBD pool if you're running a cluster. When people say "move a disk," they mean copying that underlying file or volume to a different storage location and updating the VM's configuration to point at the new copy, all without changing anything the guest OS sees. Windows or Linux inside the VM has no idea its disk just relocated.
This is not the same thing as resizing a disk, which changes how big it is but leaves it where it is. It's also not the same as VM migration, which moves an entire VM (CPU, memory, disks, the works) to a different physical node in a cluster. Moving a disk only touches storage, and it can happen on a single standalone Proxmox host with no clustering involved at all.
A quick note on the storage types you'll see in the target dropdown, since Proxmox VE supports several and the terminology trips up a lot of new users:
| Storage type | What it actually is | Typical use case |
|---|---|---|
| Directory (local) | A regular folder on the host's filesystem, storing disks as qcow2, raw, or vmdk files | The default for a single-node install; simple, but no built-in redundancy |
| LVM-thin | A thin-provisioned logical volume pool; disks only use the space they've actually written to | Fast local storage that doesn't waste space on empty disk sectors |
| ZFS | A filesystem and volume manager combined, with built-in checksums, snapshots, and optional RAID-like redundancy across multiple disks | Homelabs and small production setups that want data integrity and easy snapshots |
| NFS / CIFS | A network file share mounted from a NAS or another server | Central storage that multiple Proxmox nodes can all reach |
| Ceph RBD | A distributed block storage system spread across multiple nodes in a cluster | Clusters that need VM disks to be reachable from any node for live migration |
You don't need to understand all five deeply to follow this guide. Just know that "moving a disk" works between any of these, as long as the target storage is enabled on the node the VM is running on.
Why Would You Use It?
The most common reason is running out of space. You installed Proxmox on a single 250 GB SSD, put a few VMs on it, and now you're down to a few gigabytes free. Rather than rebuilding anything, you add a bigger drive, create new storage on it, and move the disks over one at a time.
Performance is another one. A lot of homelab builds start with everything on the same drive Proxmox itself is installed on. Once you add a dedicated NVMe drive, moving your busiest VMs onto it can make a noticeable difference, especially for things like database VMs or containers doing a lot of small random writes.
There's also the reliability angle. If you built your first pool as plain LVM and later set up a ZFS mirror for redundancy, you'll want to move your existing VM disks onto that mirror so a single failed drive doesn't take a VM down with it. And if you're decommissioning an old disk or storage box, moving disks off it before you unplug anything is a lot less stressful than restoring from backup afterward.
Honestly, this is one of those features most people don't know exists until they need it, and then they're relieved it's this simple. No downtime is required in most cases, and there's no need to touch backups, snapshots, or the guest OS at all.
Prerequisites
Before you start, make sure you have:
- A working Proxmox VE install (this guide applies to 8.x and 9.x — the commands and GUI layout haven't changed between them)
- At least one VM or LXC container with a disk you want to relocate
- A target storage already added and enabled on the same node. If you haven't created one yet, go to Datacenter → Storage → Add first and set that up before continuing
- Enough free space on the target storage to hold a full copy of the disk. Proxmox won't let the move start if there isn't room
- Root or an account with the VM.Config.Disk permission on the guest and access to the target storage
- SSH or console access to the host if you plan to use the command-line method
Step-by-Step Tutorial
Step 1: Check what storage you have available
Before moving anything, confirm the target storage is actually visible to the node. From the shell, run:
pvesm statusThis lists every storage configured on the host, along with its type, total size, and how much space is free. If the storage you want to move a disk to isn't in this list, it isn't enabled on this node yet, and the GUI won't offer it as a target either.
Step 2: Open the VM's Hardware tab
In the Proxmox web interface, click on the VM in the left-hand tree, then go to the Hardware tab. You'll see a row for each virtual disk, labeled something like Hard Disk (scsi0) or Hard Disk (virtio0), depending on the disk type you chose when the VM was created.
Step 3: Move the disk from the GUI
Click the disk row to select it, then click the Disk Action button above the hardware list and choose Move Storage. A dialog opens with a few options:
- Target Storage — a dropdown showing only storages compatible with this disk's format
- Format — you can usually leave this as-is unless you're deliberately converting between raw and qcow2
- Delete Source — check this if you want the original disk removed once the copy finishes successfully. Leave it unchecked if you want to keep the old copy around as a backup until you've confirmed everything works
Click Move disk to start. Proxmox shows a task log with a progress percentage. For a VM that's running, this happens live in the background — you don't need to shut anything down first, though the copy will take longer while the guest is actively writing to the disk.
Step 4: Move the disk from the command line
If you'd rather script this or you're managing the host over SSH, the command is:
qm disk move <vmid> <disk> <storage> --delete 1For example, to move VM 100's scsi0 disk to a storage called fast-nvme and remove the original afterward:
qm disk move 100 scsi0 fast-nvme --delete 1Drop --delete 1 (or set it to 0) if you want to keep the original disk as an unused entry instead of deleting it right away. You'll find it listed under "Unused Disk" in the Hardware tab afterward, and you can remove it manually once you're satisfied the move went fine.
Step 5: Moving a container's root disk or mount point
LXC containers work a bit differently in the GUI. Click the container, go to the Resources tab instead of Hardware, select the Root Disk or a mount point, click Volume Action, and choose Move Storage. The container needs to be stopped for this — unlike VMs, containers don't support a live storage move.
From the command line, the equivalent is:
pct move-volume <vmid> <volume> <storage> --delete 1For example, moving container 101's root filesystem to local-lvm:
pct move-volume 101 rootfs local-lvm --delete 1Step 6: Confirm everything actually worked
Once the task finishes, go back to the Hardware or Resources tab and check that the disk row now shows the new storage name. Boot the VM (or start the container) and make sure it comes up normally. If you unchecked Delete Source earlier, this is also a good time to go find that leftover unused disk and remove it once you're confident you don't need it, so it doesn't sit there wasting space.
Commands Explained
pvesm status lists every storage backend registered on the current node, its type, and how much space is used versus free. Run this any time you're not sure whether a target storage exists or has room for what you're about to copy.
qm disk move <vmid> <disk> <storage> is the core command for relocating a VM's virtual disk. The <vmid> is the numeric ID shown in the Proxmox tree (not the VM's name), <disk> is the config key like scsi0 or virtio1, and <storage> is the target storage's ID exactly as it appears in pvesm status. You'll sometimes see this written as qm move-disk or qm move_disk in older forum posts and scripts — both are accepted aliases for the same command.
The --delete flag controls whether the original disk gets removed after the copy succeeds. It defaults to off, which is the safer choice if you're not in a hurry, since it leaves you a fallback copy.
The --format flag lets you convert the disk to a different image format during the move, for example from raw to qcow2 if you're switching from LVM-thin to directory-based storage and want snapshot support along the way.
pct move-volume <vmid> <volume> <storage> does the same job for LXC containers. The <volume> argument is usually rootfs for the main container disk, or the mount point key (like mp0) for additional mounted volumes.
Common Errors
"storage does not support format 'raw'" or a similar format mismatch — this happens when you try to move a disk to a storage type that can't hold that image format. LVM and LVM-thin only store raw block volumes, so a qcow2 disk needs to be converted during the move (Proxmox usually offers this automatically, but scripted moves need --format raw explicitly).
"cannot move disk while VM has snapshots" — some storage combinations don't support moving a disk that has active snapshots attached to it. You'll need to remove the snapshots first (Snapshots tab, delete each one) before the move will proceed. This is the single most common reason a move fails on the first attempt.
"not enough space on target storage" — exactly what it says. Check pvesm status again; the target needs enough free space for the full disk size, not just the space that's actually in use, unless you're moving into another thin-provisioned backend.
"volume is locked (lock: backup)" — you tried to move a disk while a backup job was running against it. Wait for the backup to finish, or check Datacenter → Backup to see if a scheduled job is mid-run.
Troubleshooting
If the move seems to hang at a low percentage for a long time, check whether the VM is under heavy disk write load. A live move on a busy VM has to keep re-copying blocks that changed since the copy started, so it can take a while to converge on very active disks. Give it time before assuming it's stuck, and watch the task log for actual error output rather than just the percentage bar.
If the target storage doesn't show up in the dropdown at all, it usually means the storage isn't enabled for this specific node, or its content type doesn't include "Disk image." Go to Datacenter → Storage, click the storage, and check the Nodes and Content settings.
If the move finishes but the VM won't boot afterward, don't panic — the original disk is very likely still sitting there if you didn't check Delete Source. Go back into Hardware, find the unused disk entry, and you can reattach it to get back to a working state while you figure out what went wrong with the new one.
Best Practices
Leave Delete Source unchecked the first few times you do this, especially on a VM you care about. The extra copy costs you disk space temporarily, but it means a failed or interrupted move doesn't cost you the VM.
Move disks one at a time rather than kicking off several simultaneous moves, particularly if the source and target share the same physical drive. Running multiple large copies at once just makes all of them slower and makes it harder to tell which one is having trouble if something goes wrong.
Do it during a quieter period if the VM handles anything latency-sensitive, even though live moves are supported. The copy does compete for disk I/O with whatever the guest is doing.
Take a fresh backup before moving disks on anything important. This has nothing to do with the move itself being risky — it's just good practice any time you're about to change something on a production VM.
Frequently Asked Questions
Do I need to shut down the VM to move its disk?
No, for VMs this works live in most cases. LXC containers are the exception — those need to be stopped first.
Will moving a disk change its size?
No. The disk keeps its configured size unless you also resize it separately. Moving and resizing are two different operations.
Can I move a disk to a different Proxmox node, not just different storage on the same node?
Not with this command directly. qm disk move works within a single node. To relocate a disk to another node, you'd migrate the whole VM instead, which moves its disks along with it.
What happens to my snapshots if I move a disk that has some?
Snapshots often block the move outright until you remove them, depending on the source and target storage combination. Check the error message — if it mentions snapshots, that's your answer.
Does the VM's MAC address, IP, or any other config change?
No. Only the disk's storage location changes. Everything else in the VM's configuration stays exactly as it was.
Conclusion
Moving a disk between storage types is one of those Proxmox features that feels like it should be more complicated than it is. Once you've done it the first time, either through the Hardware tab or with qm disk move from the shell, it becomes a routine part of managing storage as your homelab or server grows. Keep the original disk around until you've verified the VM boots fine on its new home, watch out for lingering snapshots before you start, and you'll rarely run into trouble with it.