How to Resize a Virtual Disk in Proxmox VE (Without Losing Data)

You spun up a VM in Proxmox, installed your OS, and now the 20 GB disk you picked back then is almost full. Maybe it's a Nextcloud box that's swallowed more photos than you expected, or a Windows VM that wants another 40 GB for a game server. Either way, you don't want to rebuild the VM from scratch just to get more space.

Good news: Proxmox VE lets you grow a virtual disk while the VM is still running, in most cases. The catch is that "growing the disk" and "growing the filesystem the guest OS actually sees" are two different jobs, and a lot of first-timers stop after the first one and wonder why df -h still shows the old size.

This tutorial walks through both halves of that job, on Proxmox VE 9.2, for Linux and Windows guests, using both the web GUI and the command line.

What You Will Learn

• How Proxmox VE stores virtual disks, and why that affects how resizing works
• How to grow a virtual disk from the GUI and with the qm resize command
• How to extend the partition and filesystem inside a Linux guest, with and without LVM
• How to do the equivalent on a Windows guest
• What to do when the resize option is greyed out, or the extra space just won't show up

What Is This Feature?

A virtual disk in Proxmox is a file (or, on ZFS and Ceph, a block volume) that acts like a physical hard drive from the point of view of your VM. When you created the VM, you told Proxmox how big that disk should be, and it built a container of that exact size.

Disk resizing is Proxmox's way of enlarging that container after the fact, without touching the data already on it. It's a bit like swapping a 500 GB drive for a 1 TB one but keeping every file exactly where it was. The tricky part, and the part Proxmox can't do for you automatically, is telling the guest operating system that the drive is now bigger and that it's free to use the new space.

Proxmox only supports growing disks, never shrinking them from the storage layer. If you need a smaller disk, the accepted approach is to create a new, smaller disk and migrate the data over — trying to shrink in place risks corrupting the filesystem.

Why Would You Use It?

The obvious reason is running out of space. But there are a couple of situations where planning ahead with a small disk and growing it later actually makes sense:

• Thin provisioning. If your storage uses formats like qcow2 or ZFS, a "40 GB" disk only actually consumes the space that's been written to. Starting small and growing later avoids wasting real disk space on VMs that never fill up.
• Templates. A lot of homelab users clone a small, lean template VM and then grow the disk for whichever VM ends up needing more room, rather than keeping several different-sized templates around.
• Avoiding downtime. Online resizing (with most storage types) means you don't have to shut the VM down to add capacity, which matters if it's something like a Home Assistant instance you'd rather not interrupt.

Honestly, most homelab users just do this reactively — the disk fills up, and then they go looking for how to fix it. That's a perfectly fine reason to be here.

Prerequisites

Before you start, make sure you have:

• A Proxmox VE host you can log into, either through the web interface at https://your-server-ip:8006 or over SSH
• At least one existing VM with a virtual disk attached
• Enough free space on the underlying storage (local disk, ZFS pool, Ceph cluster, or whatever you're using) to accommodate the larger virtual disk
• A recent backup of the VM, just in case — see the note below

You don't need any special permissions beyond the default Administrator role, and you don't need to install anything extra. Everything here uses tools already built into Proxmox VE and into standard Linux and Windows installations.

A quick word on backups: resizing the virtual disk itself is low-risk, since Proxmox is just extending a file or block volume. The riskier step is resizing the partition table inside the guest. It's rare for that to go wrong, but it's exactly the kind of "rare" that ruins your afternoon if it happens to you. Take a snapshot or a backup first.

Step-by-Step Tutorial

Step 1: Check How Much Space You Actually Have

Before growing a disk, confirm the underlying storage can support it. In the Proxmox GUI, click your node on the left, then Disks, or click the storage entry itself (for example local-lvm) and look at the Summary tab. If you're on ZFS, zpool list from the shell gives you the same picture faster.

Step 2: Grow the Virtual Disk from the GUI

1. Select your VM in the left-hand tree.
2. Click the Hardware tab.
3. Click the disk you want to resize (for example scsi0 or virtio0).
4. Click Disk Action at the top, then Resize.
5. In the Size increase field, type how much you want to add — not the final size. If your disk is 20 GB and you want 30 GB total, enter 10.
6. Click Resize disk.

That's the part that trips people up the most: the GUI field is an increment, not a target size. Type 30 there by mistake and you'll end up with a 50 GB disk instead of 30 GB.

Step 3: Or Grow It from the Command Line

If you'd rather use the shell (over SSH, or through the >_ Shell button in the GUI), the equivalent command is:

qm resize 100 scsi0 +10G

Here, 100 is the VM ID (check it in the GUI if you're not sure), scsi0 is the disk, and +10G adds 10 GB to whatever size it currently is. Leave off the plus sign and give a plain number, and qm resize treats it as an absolute target size instead of an increment — so qm resize 100 scsi0 30G sets the disk to exactly 30 GB, provided that's larger than its current size.

This step works while the VM is running, for most storage backends (LVM-thin, ZFS, directory storage, Ceph RBD). A few older or more exotic storage types require the VM to be stopped first — if the command errors out, try shutting the VM down and running it again.

Step 4: Tell the Guest OS About the New Space

At this point, the virtual disk is bigger, but your guest OS doesn't know that yet. Inside a Linux VM, run lsblk and you'll typically still see the old size on the partition, even though the disk itself (/dev/sda or /dev/vda) now shows the new, larger total.

How you extend the partition depends on whether the guest uses LVM. Here's the split:

Guest setup	What you run
Linux, no LVM, GPT/EFI partitioning	parted /dev/vda, then resizepart 3 100%
Linux, no LVM, MBR partitioning	parted /dev/vda, then resizepart 2 100% followed by resizepart 3 100%
Linux with LVM	pvresize /dev/vda3, then lvresize --extents +100%FREE --resizefs /dev/vg_name/root
Windows	Disk Management → Extend Volume

For a typical Debian or Ubuntu VM installed with the default guided partitioning (which uses LVM), the LVM path is the one you want. After running lvresize with --resizefs, the filesystem grows in the same step — no separate resize2fs needed.

If your guest isn't using LVM — a lot of minimal cloud images and Alpine installs skip it — extend the partition with parted first, then grow the filesystem itself:

resize2fs /dev/vda1

For an XFS filesystem (common on Rocky Linux and AlmaLinux), the equivalent command is xfs_growfs / instead of resize2fs.

Step 5: Extend a Windows Guest

On Windows Server 2012 and newer, or Windows 10/11, open Disk Management (right-click the Start button, or run diskmgmt.msc), right-click the C: partition, and choose Extend Volume. Follow the wizard, accept the default of using all available unallocated space, and you're done — no reboot needed in most cases.

Occasionally the new space shows up as "Unallocated" but sitting after a recovery partition, which blocks a direct extend. If that happens, you'll need a third-party tool like MiniTool Partition Wizard, since Windows' built-in Disk Management can only extend into space immediately to the right of the partition.

Commands Explained

• qm resize <vmid> <disk> +<size>G — grows the named virtual disk on the named VM by the given amount. Requires the plus sign for a relative increase.
• lsblk — lists block devices and their partitions, useful for confirming the new disk size actually reached the VM.
• parted /dev/vda — opens the interactive partition editor for the given disk; resizepart inside it extends a specific partition number.
• pvresize /dev/vda3 — tells LVM that the physical volume on that partition has grown and its extra space is now available to the volume group.
• lvresize --extents +100%FREE --resizefs /dev/vg/root — grows a logical volume to use all free space in its volume group, and resizes the filesystem on top of it in the same command.
• resize2fs /dev/vda1 — grows an ext4 (or ext2/ext3) filesystem to fill its partition.
• xfs_growfs / — the XFS equivalent of resize2fs; note it takes a mount point, not a device path.

Common Errors

A few messages come up often enough to call out by name.

"cfs-lock 'storage-...' error: got lock request timeout" when running qm resize usually means another storage operation (a backup, a clone) is already running against that storage. Wait for it to finish and try again.

"unable to parse volume ID" means you typed the disk name wrong. Double-check it against the Hardware tab — it's case-sensitive, and it's easy to type scsi0 when the disk is actually attached as sata0.

Resize disk option greyed out in the GUI almost always means the VM has an active snapshot. Proxmox won't let you resize a disk that has snapshots referencing it — you'll need to remove them first, under the VM's Snapshots tab.

"GPT PMBR size mismatch" shows up on Linux guests after growing the disk, when you run parted or fdisk -l. It's just parted telling you the partition table hasn't caught up with the new disk size yet — it's expected at this point, and running resizepart resolves it.

Troubleshooting

If you've resized the virtual disk but the guest still shows the old size after a resize2fs or lvresize attempt, check these in order:

1. Confirm the resize actually landed on the Proxmox side. Run qm config <vmid> and check the size listed against the disk line.
2. Reboot the guest. Some older kernels don't pick up a live block device size change until the next boot, particularly with SCSI-attached disks.
3. Make sure you resized the right partition. A VM with a separate /boot partition, or a swap partition sitting after the root partition, needs the space added at the end of the disk — if swap is last, you may need to delete and recreate the swap partition, or use the free space via LVM instead.
4. For Windows, confirm you're extending the volume that actually needs the space — a VM with a small EFI system partition and a separate data partition is easy to mix up.

If none of that gets you there, boot the VM once from a live Linux ISO (SystemRescue works well) and run parted or gparted from outside the running OS. It removes any doubt about locks or mounted filesystems getting in the way.

Best Practices

• Add more than you think you need, within reason. Growing a disk again next month is easy; doing it every other week gets tedious.
• Snapshot or back up before resizing anything you actually care about — it costs a couple of minutes and removes basically all the risk.
• If you're using thin-provisioned storage like ZFS or LVM-thin, remember that the VM disk showing "50 GB" doesn't mean 50 GB is reserved on your pool. Keep an eye on actual pool usage with zpool list or lvs so you don't get caught out by several VMs growing into space that isn't really free.
• Resize during a maintenance window if the VM runs anything important, even though online resize usually works cleanly. "Usually" is doing some work in that sentence.
• After extending a Linux guest, run df -h to confirm the filesystem, not just the partition, actually grew. It's a five-second check that saves a support forum post later.

Frequently Asked Questions

Can I shrink a Proxmox virtual disk instead of growing it?

Not directly. Proxmox doesn't support shrinking disks from the storage layer. Create a new, smaller disk, then migrate the data across and remove the old one.

Do I need to shut down the VM to resize its disk?

Usually not. Most storage backends in Proxmox VE support online resizing. A few older storage types need the VM stopped — if qm resize errors while the VM is running, shut it down and retry.

Why doesn't the extra space show up in Windows Explorer right away?

Growing the virtual disk in Proxmox only extends the underlying container. You still need to extend the volume from Disk Management inside the guest before Windows will use the new space.

I resized the disk but forgot to remove a snapshot first — what now?

Nothing's broken. Remove the snapshot from the VM's Snapshots tab, then retry the resize.

Does resizing affect my backups?

No. Your next backup will simply reflect the new disk size. Backups already taken before the resize aren't changed.

Conclusion

Resizing a virtual disk in Proxmox VE is really two small jobs stacked together: growing the container at the Proxmox level, then growing the partition and filesystem inside the guest so it actually gets to use that space. Miss the second step and you'll swear the resize "didn't work," when really it worked fine — the guest just hasn't caught up yet.

Once you've done it once, on either a Linux or Windows guest, the whole process takes a few minutes and it's not something you'll need to look up again. Take the backup first anyway.