Disks end up on the wrong storage for all sorts of reasons. You built a VM on local-lvm to get it running, then added faster NVMe. A pool is filling and you need to spread VMs out. You’re retiring an old SSD and want everything off it first. Proxmox handles all of these with a single operation — moving a VM’s disk from one storage to another, often without shutting the VM down.
This guide covers moving a disk in the GUI and with qm move-disk, when a live move is safe versus an offline one, how the disk format can change depending on the target backend, and the unused-disk cleanup step people skip. It also draws the line between moving a disk and migrating a whole VM, which are easy to confuse.
Steps target Proxmox VE 8.x, where the command is qm move-disk. On PVE 7 and earlier the same command was spelled qm move_disk with an underscore — worth knowing if you’re following older notes.
Move a disk in the GUI
The GUI is the easiest path and it works whether the VM is running or stopped. Select the VM, open Hardware, click the disk you want to relocate (for example scsi0), then choose Disk Action → Move Storage.
The dialog asks for three things:
Move Storage dialog
| Target Storage | Where the disk should land — any storage on the node that accepts disk images. |
|---|---|
| Format | qcow2 or raw, when the target supports a choice. Greyed out for backends that only store raw (LVM-Thin, ZFS). |
| Delete source | Remove the original disk after the copy succeeds. Leave unchecked to keep it as an unused disk. |
Pick the target, leave Delete source unchecked for your first move, and start it. Proxmox copies the disk and, when it’s done, points the VM’s config at the new copy. The task log shows progress; large disks take a while since every block is read and written.
Move a disk from the command line
qm move-disk does the same job and is handy in scripts or over SSH. The syntax is the VMID, the disk, and the target storage:
# move scsi0 on VM 101 to the storage named "nvme-zfs"
qm move-disk 101 scsi0 nvme-zfs
# move and delete the source once the copy succeeds
qm move-disk 101 scsi0 nvme-zfs --delete
# move and force a specific target format (directory/NFS targets)
qm move-disk 101 scsi0 backup-nfs --format qcow2The --delete flag removes the original after a successful copy, the same as ticking Delete source in the GUI. Without it, the old volume is detached and kept as an unused disk.
Live moves versus offline moves
You don’t have to stop the VM to move its disk, and that’s the feature worth understanding.
A live move runs while the VM is on. Proxmox copies the disk to the new storage in the background and mirrors new writes to both copies until the copy catches up, then switches the VM to the new disk and drops the old one. The guest never notices. This is how you rebalance storage in the middle of the day without a maintenance window.
An offline move happens with the VM stopped. There’s nothing to mirror, so it’s marginally faster and simpler, but it costs you downtime. Reach for it when the VM is already off, or when you’d rather not run a live mirror on a very busy disk.
Live vs offline disk move
| Live (VM running) | No downtime. Proxmox mirrors writes during the copy, then switches over. Best for production VMs you can't stop. |
|---|---|
| Offline (VM stopped) | Simpler and slightly faster, but the VM is down for the duration. Fine for VMs already powered off. |
Format changes when you cross backends
Moving a disk can quietly change its format, because not every storage stores disks the same way. This isn’t a problem — it’s expected — but it surprises people who don’t know to look for it.
Block backends like LVM-Thin and ZFS store disks as raw volumes. File backends like a directory or NFS share can hold either qcow2 or raw files. So the move’s effect on format depends on where you’re going:
What happens to disk format on a move
| Directory/NFS to LVM-Thin or ZFS | qcow2 is converted to raw — the block backend stores raw volumes only. |
|---|---|
| LVM-Thin or ZFS to Directory/NFS | Raw volume is written out, and you can choose qcow2 or raw on the target. |
| Directory/NFS to Directory/NFS | You pick the format explicitly (qcow2 or raw) in the dialog. |
| LVM-Thin to ZFS (or vice versa) | Stays raw on both ends; no format choice to make. |
The practical takeaway: qcow2 snapshots live in the qcow2 file, so moving a qcow2 disk onto LVM-Thin or ZFS converts to raw and the snapshot capability shifts to the storage layer instead. If you depend on snapshots, know how each backend provides them — the LVM vs LVM-Thin vs ZFS comparison lays out which ones snapshot and how.
Clean up the unused disk
If you moved without --delete, the old volume is still sitting on the source storage as an unused disk. It’s not doing anything, but it’s holding space — and on a pool you were trying to free up, that defeats the point.
Find it on the VM’s Hardware tab, listed as Unused Disk 0 (or similar). Confirm the VM is running correctly on the new storage first, then select the unused disk and click Remove. From the shell:
# list disks to find the unused one (look for unused0:)
qm config 101
# detach and delete the leftover volume
qm set 101 --delete unused0Move versus migrate
It’s easy to mix these up because both relocate storage in some sense.
Move disk relocates one virtual disk to different storage while the VM stays on the same node. That’s this guide.
Migrate moves the whole VM to a different node in a cluster, optionally bringing its local disks along. You’d use qm migrate or the GUI Migrate button for that. The two overlap when you migrate a VM that has local disks — Proxmox copies those disks to the target node as part of the migration — but if the VM is staying put and you only want to change which storage a disk lives on, move-disk is the right tool.
Moving a disk, in order
- Confirm the target storage has room and accepts disk images
- Decide live (VM running) or offline (VM stopped)
- Start the move in the GUI or with qm move-disk
- Leave the source in place on the first move (no --delete)
- Boot/verify the VM works on the new storage
- Remove the leftover unused disk to reclaim space
- Don't forget EFI and TPM state disks if relocating the whole VM
Wrapping up
Moving a Proxmox disk is a low-drama operation once you know the moving parts: pick the target storage, choose live or offline, and decide whether to delete the source or keep it as a safety net. The one thing to watch is format — crossing into LVM-Thin or ZFS converts qcow2 to raw, which changes where snapshots come from. Verify the VM on its new home before deleting the old copy, and clean up the unused disk so you actually reclaim the space.
If you’re moving disks because a pool filled up, the fix for a full local-lvm covers the thin-provisioning side of that problem, and the storage backend comparison helps you pick the right target. For more walkthroughs, browse the Proxmox guides.
