Moving all disks to new storage in Proxmox is not one command. It’s a loop over your VMs and containers, and the order matters if you don’t want to lock yourself out mid-move. Here’s the safe sequence.
Move VM disks first
For each VM, use qm move_disk. The syntax is simple:
qm move_disk <vmid> <disk> <target_storage> --deleteThe --delete flag removes the original disk after the move. If you want to keep it as a backup, drop that flag. But if you’re moving to new storage because the old one is dying, you probably want it gone.
To move all disks for a VM, you can loop over them. Get the disk names with qm config <vmid> and look for lines starting with virtio, scsi, sata, or ide. Then run the move for each. Or just do it in the web UI: select the VM, go to Hardware, select the disk, click Disk Action > Move Storage. It’s slower but you see progress.
Move container mounts next
LXC containers use pct move-volume. The syntax is similar:
pct move-volume <ctid> <volume> <target_storage> --deleteAgain, get the volume names from pct config <ctid>. Look for rootfs and any mp0, mp1 entries. Move each one.
One thing that trips people: if the container is running, the move will fail. Stop it first with pct stop <ctid>. Same for VMs — shut them down before moving disks. You can move a running VM’s disk with --online but it’s slower and riskier. Just shut it down.
Verify the move
After moving, check that the old storage is empty. Run pvesm list <old_storage> and see if any disks remain. If there are, you missed something. Also check each VM and container boots. A quick qm start <vmid> and pct start <ctid> is enough. If it boots, the move worked.
One more thing: if you’re moving to a ZFS pool, the target storage name is the pool name. If you’re moving to LVM-thin, it’s the thin pool name. Don’t mix them up or you’ll get an error about the storage not supporting the disk type. The error message is useless, but the fix is to check your storage type.
If you’re moving a lot of VMs, consider doing it in batches. Move a few, verify, then continue. It’s slower but you won’t end up with a half-moved cluster and no idea what went wrong. And if you’re moving to a new node entirely, check out the manual failover post for the full sequence.
