A Proxmox virtual machine can outgrow its first storage pool long before the rest of the host needs to change. Moving it safely means relocating every managed volume that belongs in the new pool, confirming the VM still works, and only then deciding whether the old copies can be removed.
This guide covers a storage move within Proxmox VE. It is not a node migration, a disk import from another hypervisor, or a substitute for a recoverable backup. The examples use placeholder VM and storage names. Read your own configuration before running them.
Define exactly what needs to move
Proxmox moves one virtual disk at a time. A VM may have a boot disk, one or more data disks, an EFI variables disk, a TPM state volume, and a Cloud-Init drive on different pools. Selecting one row in the Hardware panel does not relocate every volume automatically.
Open the VM’s Hardware panel and record each storage-backed entry. From the shell, qm config 104 provides the same kind of inventory for VM 104. Note the disk keys, such as scsi0 or virtio1, their current storage IDs, and any unusedN entries. Do not copy the sample VM ID into a real command.
Decide whether the goal is to move one busy data disk or to place the whole VM on the target pool. If the whole VM is moving, make a checklist for every managed volume and preserve the original bus assignment. This is also the moment to confirm whether a scheduled replication job, high-availability rule, backup selection, or storage-specific snapshot depends on the current placement.
Check the target pool before copying data
The target storage must be enabled for the current node and allow the images content type used by VM disks. Proxmox’s storage documentation also warns that marking storage as shared does not make a local pool accessible on other nodes. The flag describes storage that is already shared.
Check available capacity with the Proxmox storage view or pvesm status. Allow room for the allocated destination volume, active writes during an online move, snapshots, and ordinary growth. Thin provisioning can make the displayed virtual size different from physical use. A nearly full target is a poor migration destination because Proxmox warns that exhausted storage can send I/O errors to guests and cause filesystem inconsistency.
Compare features, not only speed. File and block backends support different image formats, snapshot behavior, cloning, sharing, and thin provisioning. A format choice is offered only where the backend supports it. If the VM currently relies on snapshots or replication, consult the current feature table for both storage types before changing placement.
The Proxmox storage planning guide can help separate durable placement from a quick capacity fix. If the source pool is already under pressure, follow the storage-full checks before starting another large write.
Create a recovery point outside both pools
Make a current backup to storage that does not depend on either pool involved in the move. Confirm the backup task completed, record its location, and make sure the restore credentials and encryption keys are available. A storage snapshot on the source pool is useful for some workflows, but it does not protect against losing that pool.
Proxmox documents three VM backup modes. Stop mode favors consistency with a short interruption. Snapshot mode minimizes downtime while accepting a small inconsistency risk; when the QEMU Guest Agent is enabled and running, Proxmox uses filesystem freeze and thaw calls to improve consistency. Choose the mode according to the workload, then verify the resulting backup rather than treating task completion as a restore test. The backup destination comparison explains why the recovery copy should remain independent of the source.
Choose an online or offline move
A running VM may be eligible for storage migration, but eligibility and impact depend on the source, target, disk, and current configuration. An online copy also competes with guest I/O. For a small home lab service with an acceptable maintenance window, an orderly shutdown reduces activity and makes application checks easier to interpret.
If the VM must stay online, choose a quiet period. Watch application latency, storage health, free space, and the Proxmox task log. Use a bandwidth limit when an unrestricted copy could crowd out production I/O. The current command reference defines the limit in KiB/s and also permits a default move limit in datacenter or storage configuration.
Do not combine this move with a Proxmox upgrade or unrelated storage repair. Apply pending platform work first, validate it, and then start the storage task. The Proxmox update checklist provides a separate maintenance sequence.
Move the first disk and keep the source copy
In the web interface, select the VM, open Hardware, select the intended disk, and choose Disk Action, then Move Storage. Select the target storage and a format only when the interface offers a meaningful choice. For the first move, leave source deletion disabled.
The current CLI form is:
qm disk move 104 scsi0 fast-zfs --delete 0The older qm move_disk spelling remains an alias. Proxmox documents --delete 0 as the default: after a successful copy, the original volume is retained as an unused disk. That consumes space on both pools, but it gives you a deliberate verification interval. The command also supports --bwlimit and a target --format where applicable.
Follow the task log until it reports completion. An interrupted browser session does not prove the server-side task failed or succeeded. Reopen the task history and inspect its final result before issuing another storage command.
Verify the VM before moving the remaining volumes
Refresh the Hardware panel and run qm config 104 again. The active disk key should point to the target storage. The retained source should appear as an unused volume rather than as the active boot or data disk. Confirm there is only one active attachment for that disk.
Start the VM if it was stopped. Check the console, boot process, guest disk inventory, filesystems, application data, and the service path users actually depend on. Review guest and host logs for I/O errors. A successful Proxmox copy verifies the storage task, not the behavior of every application inside the guest.
Move additional disks one at a time. Verify after each important volume. Review EFI, TPM, and Cloud-Init entries separately because they are easy to overlook and may have backend-specific constraints. When the placement changes a replication or high-availability assumption, confirm the job state and recovery design again before declaring the move finished.
Remove old volumes only after the evidence is clear
Keep the old unused volumes through the agreed observation period if capacity allows. Record their exact volume IDs so they are not confused with older leftovers. After the VM has passed application checks and a separate backup remains recoverable, remove only the verified source entries through Proxmox.
Avoid deleting files, logical volumes, or ZFS datasets directly underneath the storage plugin. Proxmox owns the mapping between the VM configuration and its managed volumes. Direct deletion can leave misleading configuration or erase the wrong object.
The job is complete when every intended active volume points to the target pool, the VM has passed workload checks, backup and replication policy match the new placement, and each retained source volume has an owner and removal decision. Until those conditions are recorded, the move is still maintenance in progress.
Sources
- Proxmox VE qm command reference
- Proxmox VE Storage Manager reference
- Proxmox VE Backup and Restore reference
- Proxmox VE Administration Guide
- Proxmox Virtual Environment 9.2 release notice
Primary sources were reviewed September 10, 2026 against Proxmox VE 9.2 documentation. This is a documentation-based procedure. It does not claim that LabGremlin performed, timed, or validated a storage move on a specific system.