Resizing a Proxmox VM disk is really two jobs that people often treat as one. First you grow the virtual disk at the Proxmox layer, which adds raw space to the block device. Then you go inside the guest and extend the partition and filesystem so the operating system actually uses that space. Skip the second step and the VM keeps reporting the old size no matter what Proxmox says.
This guide walks both halves: how to grow the disk in the GUI or with qm resize, then how to claim the new space in Linux (plain partitions and LVM) and in Windows. It also covers why shrinking is a different, riskier problem that Proxmox won’t do for you. Steps target Proxmox VE 8.x, but the workflow has been stable across recent releases.
Before anything, take a backup. A resize edits partition tables and filesystem metadata, and a mistake there can leave a guest that won’t boot. A recent vzdump backup or a storage snapshot turns a bad resize into a five-minute rollback.
Grow the virtual disk in Proxmox
The Proxmox side is the easy half. You can only grow a disk here — the field won’t accept a smaller number, by design.
In the GUI, select the VM, open Hardware, click the disk you want to enlarge (for example scsi0), then use Disk Action → Resize. Enter how much to add, not the new total. Typing 20 adds 20 GiB to whatever the disk is now.
From the shell, qm resize does the same thing and uses the same “increment” convention with a +:
# add 20 GiB to scsi0 on VM 101
qm resize 101 scsi0 +20G
# set scsi0 to an absolute size of 80 GiB (must be larger than current)
qm resize 101 scsi0 80GThe +20G form grows by 20 GiB; the bare 80G form sets the total, and it’s rejected if 80G is smaller than the current disk. Either way, Proxmox enlarges the underlying volume — an LVM-Thin volume, a ZFS zvol, a qcow2 file, whatever the storage uses.
Will the guest see it without a reboot?
In most modern setups, yes. With virtio-scsi or virtio-blk and a current Linux kernel or supported Windows build, the guest notices the new size right away and you can extend the filesystem while the VM runs.
If the guest doesn’t pick up the change, a rescan usually fixes it without a reboot. On Linux:
# rescan a SCSI disk (replace sda with your device)
echo 1 | sudo tee /sys/class/block/sda/device/rescanIf a rescan still shows the old size on an older controller, reboot the VM — that always forces a re-read of the disk geometry. On Windows, a Rescan Disks in Disk Management does the same job.
Extend the partition and filesystem in Linux
This is the half that trips people up. Proxmox gave you more block device, but the partition table and filesystem inside the guest still describe the old layout. The exact commands depend on whether the guest uses plain partitions or LVM.
Plain partition (no LVM)
Say the disk is /dev/sda, the root partition is /dev/sda1, and it’s ext4 or XFS. Use growpart to push the partition boundary out, then grow the filesystem.
# install the helper if it's missing (Debian/Ubuntu)
sudo apt install cloud-guest-utils
# grow partition 1 on /dev/sda to fill the disk
sudo growpart /dev/sda 1
# ext4: grow the filesystem to the partition
sudo resize2fs /dev/sda1
# XFS: grow the mounted filesystem instead
sudo xfs_growfs /Note the difference: resize2fs takes the partition device, while xfs_growfs takes the mount point. XFS can only grow, never shrink, which is fine here.
LVM-backed root
Many Debian and Ubuntu installs put root on LVM. Now there’s an extra layer — the physical volume and logical volume both have to grow before the filesystem does.
# grow the partition holding the PV (e.g. /dev/sda3)
sudo growpart /dev/sda 3
# tell LVM the PV is bigger now
sudo pvresize /dev/sda3
# extend the logical volume to use all free space in the VG
sudo lvextend -l +100%FREE /dev/mapper/vg-root
# grow the filesystem (ext4 shown; use xfs_growfs for XFS)
sudo resize2fs /dev/mapper/vg-rootLinux guest resize — which tool for what
| growpart | Extend a partition to fill the larger disk |
|---|---|
| pvresize | Tell LVM a physical volume grew (LVM only) |
| lvextend | Enlarge a logical volume (LVM only) |
| resize2fs | Grow an ext2/3/4 filesystem (takes the device) |
| xfs_growfs | Grow an XFS filesystem (takes the mount point) |
Extend the disk in Windows
Windows makes this straightforward once the guest sees the bigger disk. Open Disk Management (diskmgmt.msc). If the new space isn’t visible, right-click the disk and choose Rescan Disks. The added capacity shows up as Unallocated space to the right of the existing volume.
Right-click the system or data volume and choose Extend Volume. The wizard offers the unallocated space; accept it to grow the volume into the new room. There’s no reboot and no filesystem step beyond the wizard.
If you prefer the command line, diskpart does the same:
diskpart
list volume
select volume 2
extendextend with no size grabs all contiguous unallocated space following the volume.
The order that keeps your data
Resizing fails safely when you respect the layering. Growing goes from the outside in: disk, then partition, then (for LVM) PV and LV, then filesystem. Each layer can only use space the layer beneath it has already exposed.
Grow a disk, in order
- Take a backup or snapshot of the VM first
- Grow the virtual disk in Proxmox (GUI Resize or qm resize +NG)
- Confirm the guest sees the new size (rescan or reboot if needed)
- Extend the partition (growpart, or Windows Rescan)
- For LVM: pvresize then lvextend
- Grow the filesystem (resize2fs / xfs_growfs, or Windows Extend Volume)
- Verify with df -h (Linux) or Disk Management (Windows)
Why shrinking is the hard part
Proxmox won’t shrink a disk from the GUI, and qm resize rejects a smaller target. That’s intentional. To safely reduce a disk you’d have to shrink the filesystem first, then the partition, then the virtual disk — and reverse the growth order exactly. Get the sizes wrong by a single block and you cut into live data.
When you genuinely need a smaller disk, the low-risk approach is to add a new, correctly sized disk to the VM, copy the data across, then detach and delete the oversized one. It’s more steps, but nothing is ever truncated underneath a live filesystem. If the goal is reclaiming space rather than literally shrinking, see whether thin provisioning already handles it — LVM-Thin and ZFS only consume what’s actually written, and a full local-lvm is often a thin-provisioning problem rather than a disk-size one.
Wrapping up
Growing a Proxmox disk is reliable as long as you remember it’s two operations: enlarge the virtual disk in Proxmox, then extend the partition and filesystem inside the guest. The guest-side commands differ between plain partitions, LVM, and Windows, but the principle is the same — work from the disk outward to the filesystem. Shrinking is the exception; treat it as a copy-and-replace job, not a resize.
For more on what your storage backend supports, the LVM vs LVM-Thin vs ZFS guide explains how each one handles growth and snapshots. For more walkthroughs, browse the Proxmox guides.
