Harvester volume expansion: block device size vs guest file system capacity

Question

Harvester utilizes Longhorn to provide distributed block storage for virtual machines, supporting online volume expansion to increase disk size without requiring a VM reboot.
While the Harvester UI and the underlying Longhorn engine can resize the block device, there is a technical gap between the block-level expansion and the guest operating system's recognition of that space. The Kubernetes PV/PVC layer updates the volume size, but the guest file system (such as ext4 or XFS) may not automatically expand to occupy the newly allocated capacity.
Given that shrinking volumes is unsupported and potentially destructive, it is necessary to define the expected automation boundary for this process.

Does Harvester provide a mechanism to trigger the guest file system expansion automatically?
Which guest OS distributions and file system types are natively supported for online resizing without manual intervention?

Tasadduq Burney · Answer

Direct answer
Harvester does not provide a native mechanism to automatically expand the guest file system after a Longhorn-backed PVC is resized. The platform automates the block-device layer only; the guest operating system must grow its partition and file system to consume the new capacity.

Where the automation stops
When you increase a PVC size in Harvester, the Kubernetes control plane updates the PersistentVolume spec, and the Longhorn engine resizes the underlying block device online. The virtual machine sees a larger disk, but the partition table and file system inside the guest remain at their original size. This is a well-established boundary in Kubernetes storage: the CSI driver handles the block device, not the in-guest file system.

What the guest OS can do
Whether expansion is automatic depends entirely on software inside the VM, not on Harvester itself.

Linux with cloud-init: Distributions that ship cloud-init (Ubuntu, Debian, RHEL, CentOS Stream, AlmaLinux, Rocky Linux) can automate online growth when cloud-init is configured to run the growpart and filesystem resize helpers. Common file systems such as ext4, XFS, and Btrfs support online expansion. In this case, the guest may expand automatically on reboot or via a cloud-init hook, but this is guest behavior, not a Harvester feature.
Windows: There is no built-in automatic expansion triggered by Harvester. NTFS can be extended online using Disk Management or PowerShell Resize-Partition, but this requires manual action or a guest agent/script that detects the larger disk.

Safe expansion steps
Because Longhorn does not support shrinking and a failed in-guest resize can corrupt data, take a snapshot before proceeding.

Confirm the PVC request increased:
kubectl get pvc <name> -o jsonpath='{.spec.resources.requests.storage}'

Inside the VM, verify the block device reports the new size:
lsblk
sudo fdisk -l

Grow the file system:
# ext4
sudo resize2fs /dev/vdX1

# XFS (mount point)
sudo xfs_growfs /

Confirm with df -h

Missing diagnostic
Does your guest image include cloud-init with the growpart and filesystem resize helpers enabled, or a guest agent that runs a resize script? If yes, the guest may already automate steps 2–4 after a reboot. If not, plan for the manual commands above.

Harvester volume expansion: block device size vs guest file system capacity

1 answer

Direct answer

Where the automation stops

What the guest OS can do

Safe expansion steps

Missing diagnostic

Your perspective belongs here.

0 question comments