How to Resize Virtual Disks in Proxmox and Expand Filesystems Inside the Guest OS

For a while, Proxmox disk resizing felt more misleading to me than difficult.

The hypervisor side is almost suspiciously simple. Click a disk in the hardware view, choose Resize, add a number, and the task finishes. Or run one command, such as qm resize 100 scsi0 +20G, and Proxmox is done with its part. That visual neatness creates a very tempting illusion: the job must be finished because the disk is now bigger.

That is usually the moment confusion begins.

The guest operating system often still shows the old available space, applications still complain, and the root filesystem stubbornly remains full. What finally made the whole process feel calm to me was understanding that disk growth is not one action. It is three different layers that happen in order:

1. enlarge the virtual disk in Proxmox;
2. enlarge the partition or LVM layout inside the guest if needed;
3. enlarge the filesystem that actually stores the data.

Once I stopped collapsing those layers into one mental step, disk expansion became much easier to reason about.

The first useful correction is realizing that Proxmox only enlarges the virtual disk

This was the part that organized everything for me.

Proxmox can resize a guest disk online or offline. The official wiki documents both the GUI path and the CLI path, and the command is pleasantly direct:

qm resize <vmid> <disk> <size>

For example:

qm resize 100 scsi0 +20G

The Proxmox documentation also makes a very important conceptual point: enlarging the virtual disk is like adding more physical platter capacity. The guest still has to notice the extra capacity, the partition table still has to expose it to the correct volume, and the filesystem still has to grow into it.

That is why the task so often feels half-finished. Proxmox did the virtualization layer correctly. The guest simply has more work left to do.

A bigger virtual disk only helps if the free space lands in the right place

This is where many guest-side surprises come from.

Unallocated space has to end up adjacent to the partition or logical structure you want to grow. The Proxmox wiki is very explicit about this for guest partitioning, and Microsoft says the same thing for Windows volumes: the unallocated space must be immediately after the volume being extended and on the same disk.

That detail sounds administrative until it blocks the whole task.

If the free space appears at the end of the disk but the partition you care about is not the last one, the easy online path may stop working. That is when the job becomes a partition-layout question instead of a filesystem-growth question.

This is one reason I think resize work belongs near the same operational mindset as understanding Proxmox storage types. Capacity is never just a number. It is about where the space lives and which layer is actually able to claim it.

Start with a backup because resize mistakes are boring until they are expensive

I do not think backups are interesting advice by themselves. They only become useful when tied to the shape of the risk.

Resizing a disk upward is usually calmer than people fear, but guest-side partition work is still one of those moments where a typo or wrong device name can turn routine maintenance into recovery. The more complex the guest layout is, the less I want to improvise.

Before changing anything, I would want to know:

• which virtual disk is being resized in Proxmox;
• whether the guest uses a plain partition, LVM, or Windows Disk Management;
• whether the target partition is the last relevant one on the disk;
• whether a tested restore path exists if the layout is misread.

That is why I mentally connect this task to Proxmox Backup Server more than to storage cosmetics. Resize work is not scary because it is advanced. It is scary when the rollback story is vague.

Step 1: enlarge the guest disk in Proxmox

The Proxmox side is the cleanest part.

In the GUI:

1. open the VM;
2. go to Hardware;
3. select the correct virtual disk;
4. choose Disk Action -> Resize;
5. add the extra size.

On the CLI:

qm resize 100 scsi0 +20G

The qm manual documents qm resize as an alias for qm disk resize, and the disk identifier can be something like scsi0, virtio0, sata0, or another configured disk slot.

At this point, Proxmox is finished. The rest of the work is inside the guest.

Step 2: confirm that the guest sees the larger disk

I like this checkpoint because it prevents blind trust.

Inside a Linux guest, look at the block devices first:

lsblk
sudo fdisk -l

The Proxmox wiki shows the same basic idea more explicitly with dmesg, checking whether the kernel detected the capacity change on a disk such as /dev/vda.

If the guest still does not see the larger disk size, do not jump straight into partition tools. Confirm the VM really uses the disk you resized, and consider a reboot if the guest-side storage driver does not refresh capacity live.

For Windows guests, modern setups often see the new capacity online, but Proxmox notes that this depends on the guest and drivers. The official Windows guidance then picks up from the point where Disk Management can actually see unallocated space on the disk.

Step 3A: Linux guest with a plain partition and ext4

This is one of the most common and conceptually clean cases.

If the root partition is at the end of the disk, enlarge that partition first. The Proxmox wiki demonstrates doing this with parted, for example:

sudo parted /dev/vda
(parted) print
(parted) resizepart 3 100%
(parted) quit

The exact partition number depends on the guest layout. The important part is not the number itself. The important part is that you are resizing the correct partition into the new free space.

Once the partition is larger, grow the ext filesystem. The Debian resize2fs man page is very clear on two points:

• resize2fs resizes ext2, ext3, or ext4 filesystems;
• it does not resize the partition itself, so the underlying partition must already be expanded first.

For the common “grow to fill the now-larger partition” case:

sudo resize2fs /dev/vda3

If the filesystem is mounted and supports online growth, ext4 can usually be expanded without unmounting. That is one reason this path often feels gentler than people expect once the partition boundary is correct.

Step 3B: Linux guest that uses LVM

This is the case that used to feel more mysterious than it deserved.

The Proxmox wiki breaks the process into the right layers:

1. enlarge the partition that contains the LVM physical volume;
2. run pvresize so LVM notices the new capacity;
3. enlarge the logical volume;
4. grow the filesystem living on that logical volume.

That sequence matters because LVM adds another storage boundary between the partition and the filesystem.

After the partition has been extended, grow the physical volume:

sudo pvresize /dev/vda3

Then inspect the logical volumes:

sudo lvdisplay

Now enlarge the logical volume and filesystem together. The Proxmox wiki uses lvresize --resizefs, which is one of my favorite details in the whole workflow because it makes the intent very explicit:

sudo lvresize --extents +100%FREE --resizefs /dev/<vg-name>/root

Or, if you want only a specific amount:

sudo lvresize --size +20G --resizefs /dev/<vg-name>/root

This works nicely for ext4 and XFS-backed logical volumes because LVM can enlarge the block device while the filesystem growth tool does the final step.

Step 3C: Linux guest with XFS

XFS is simple in one important way and strict in another.

The Debian xfs_growfs man page says that xfs_growfs expands an existing XFS filesystem and that the filesystem must be mounted to be grown. It is most often used with logical volumes, but it can also be used on a regular disk partition after the underlying space has been enlarged.

That means the storage layer underneath XFS still has to be bigger first:

• larger Proxmox virtual disk;
• larger partition or larger logical volume;
• then xfs_growfs.

The actual grow step usually looks like this:

sudo xfs_growfs /

Or against the mounted filesystem path that corresponds to the XFS volume you are expanding.

What I like about XFS here is that the requirement is intellectually clean. It must be mounted, and it grows outward into already-available underlying space. What it does not do is excuse you from getting the partition or LVM layer right first.

Step 3D: Windows guest

Windows is friendlier here than many beginners assume, provided the disk layout cooperates.

Microsoft documents volume extension through Disk Management and PowerShell. The core requirements are very clear:

• the free space must be immediately after the volume you want to extend;
• the free space must be on the same disk;
• the volume must use NTFS or ReFS.

In Disk Management, the normal path is:

1. right-click the target volume;
2. choose Extend Volume;
3. walk through the wizard and select the available space.

Microsoft also documents a PowerShell path:

$size = Get-PartitionSupportedSize -DriveLetter C
Resize-Partition -DriveLetter C -Size $size.SizeMax

The emotional lesson is the same as with Linux: Windows is not being stubborn if the option is unavailable. It is usually telling you that the layout is wrong for online extension, not that the new virtual disk size failed to arrive.

A quick note about LXC containers

This article is mainly about VM guests, because that is where guest operating systems own their own partition tables and filesystems.

For Proxmox containers, the model is different. The pct manual documents pct resize <vmid> <disk> <size>, and the container’s rootfs is managed as a container volume rather than a fully independent VM disk with its own virtual partition map in the same sense.

That does not mean container storage is trivial. It just means the resize story is different enough that I would not mix LXC and VM instructions casually. If a container storage problem starts feeling strange, it often belongs closer to the lessons in what I learned after my first Proxmox LXC broke than to a normal VM filesystem-expansion workflow.

What I would verify after the resize

This is the part that turns “I ran the commands” into “the job is actually done.”

Inside Linux:

lsblk
df -h

Inside an LVM-based guest:

sudo pvs
sudo vgs
sudo lvs
df -h

Inside Windows:

• confirm the larger volume size in Disk Management;
• confirm the filesystem free space in Explorer or Get-Volume.

I also like one final behavioral check: does the original low-space symptom actually disappear? A root filesystem that still reports the old size after all the “successful” steps usually means one layer was skipped or the wrong partition was grown.

The calmer way to think about the whole task

The thing that helped me most was giving up the idea that resizing a Proxmox guest disk should feel like one magical button.

It is not one button.
It is a stack.

Proxmox grows the virtual disk.
The guest exposes that growth through its partition or LVM layout.
The filesystem finally claims the space for real use.

Once that sequence is clear, the job stops feeling tricky and starts feeling procedural.

That is usually the sweet spot for good homelab work: not flashy, not mysterious, just understandable.

FAQ

Why does Proxmox show a larger disk but the guest still looks full?

Because the hypervisor only resized the virtual disk. The guest still may need a partition change, an LVM resize, and a filesystem expansion before the extra capacity becomes usable.

Can I resize a Proxmox guest disk while the VM is running?

Often yes. Proxmox documents online resizing for guest disks, and many modern Linux and Windows guests can detect the larger virtual disk without a reboot. The guest-side storage layout still determines whether the rest of the process can be completed online.

Can I shrink a virtual disk safely in Proxmox?

Not through the normal Proxmox API workflow. Proxmox explicitly documents shrinking as unsupported by the API, and it is much riskier because the filesystem and partition have to be reduced safely before the virtual disk can become smaller.

What command grows ext4 after the partition is already larger?

The usual tool is resize2fs, for example resize2fs /dev/vda3, after the correct partition has already been expanded.

What command grows XFS after the underlying space is available?

The usual tool is xfs_growfs, typically run against the mounted filesystem path, such as xfs_growfs /.