Expanding Virtual Machine Disk Capacity in Harvester

The Storage Expansion Gap

When a Virtual Machine (VM) in Harvester runs out of disk space, increasing the volume size in the management console is only the first half of the process. Because Harvester uses Longhorn for distributed block storage, updating the volume size expands the virtual block device, but it does not automatically resize the guest OS partition table or the filesystem. Without manual intervention inside the guest, the OS will continue to report the old capacity despite the underlying storage increase.

Prerequisites

• Administrative Access: Access to the Harvester UI or kubectl with cluster-admin permissions.
• Guest OS Support: A Linux guest utilizing the virtio-scsi driver (standard for Harvester VMs).
• Backup: A current VM snapshot. Expanding partitions carries a risk of data loss if the partition table is corrupted during the resize.

Step 1: Expand the Volume in Harvester

You can increase the disk size while the VM is running, but the guest OS may require a reboot or a SCSI rescan to see the change.

1. Navigate to the Virtual Machines tab in the Harvester UI.
2. Select the target VM and go to the Volumes section.
3. Click the Edit icon next to the volume you wish to expand.
4. Enter the new, larger size (e.g., changing 20Gi to 50Gi) and save the changes.

Step 2: Update the Guest OS Partition Table

Log into the guest VM via SSH. First, verify that the block device reflects the new size provided by Harvester.

# Run as root or with sudo
lsblk

If the disk (e.g., vda) shows the new size but the partition (e.g., vda1) remains small, you must grow the partition. The growpart utility (part of the cloud-utils package) is the most reliable tool for this.

Command Execution: Run this on the guest OS terminal.

# Syntax: growpart [device] [partition-number]
# Example: Expanding partition 1 on device /dev/vda
sudo growpart /dev/vda 1

Risk: If the disk is nearly 100% full, growpart may fail due to a lack of temporary space in /tmp. In such cases, clear logs or temporary files before proceeding.

Step 3: Resize the Filesystem

The partition is now larger, but the filesystem (the logical layer where files reside) still thinks it is the old size. The command depends on your filesystem type.

For ext4 Filesystems

# resize2fs handles online expansion for ext4
sudo resize2fs /dev/vda1

For XFS Filesystems

# xfs_growfs requires the mount point rather than the device path
sudo xfs_growfs /

Verification and Diagnostics

To confirm the operation was successful, run the following check on the guest:

df -h

The Size column for the root filesystem should now match the value configured in the Harvester UI. Additionally, check the Harvester dashboard to ensure the volume status remains Healthy.

Comparison: Online vs. Offline Expansion

Method	Pros	Cons	Requirement
Online	No downtime; immediate application.	Requires virtio-scsi and specific kernel support.	Modern Linux Kernel
Offline	Highest stability; no risk of locking.	Requires VM shutdown.	Any supported OS

Limitations and Rollback

• No Shrinking: Harvester and Longhorn do not support shrinking volumes. Reducing the size in the UI is not possible; if you need a smaller disk, you must create a new smaller volume and migrate the data manually.
• Rollback: If the partition expansion fails or corrupts the table, the only reliable recovery is to restore the VM from the snapshot taken before Step 1.