Take a tested backup and record the complete disk layout on the host and guest. Confirm the exact volume, current sizes, partition table, filesystem and available host capacity. This procedure concerns expansion; shrinking requires a different, often offline process and is unsupported by some filesystems.

1. Inspect the guest with read-only tools such as lsblk -f, filesystem usage and LVM reports where applicable. Map the application mount point to its actual virtual disk and record all intermediate layers.
2. Check the managing platform's supported disk-growth workflow. For panel-managed guests, use that workflow so inventory and quota remain consistent. For independent libvirt, choose the supported online block-resize or an offline image procedure appropriate to the backend.
3. Expand the host-side disk to the approved larger size. Never use qemu-img to modify an image that a running VM or another process has open. Keep the guest stopped for an offline procedure and verify its state first.
4. Inside the guest, confirm the operating system sees the new block-device size. A rescan or planned reboot may be needed before continuing. Stop if the device identity or size differs from the recorded plan.
5. Expand the relevant partition only into verified adjacent free space. If LVM is used, grow the physical-volume recognition and intended logical volume according to the actual layout. Avoid recreating a partition table from a generic example.
6. Grow the filesystem with its native supported tool. Ext4 and XFS use different procedures, and XFS growth targets a mounted filesystem. Never format the disk to make newly added capacity appear.
7. Recheck the application mount point and persistent configuration. Record the final layout and create a new recovery point after successful acceptance.

On the authorised libvirt host, list the disks attached to the intended VM and inspect the specific target. Replace VM_NAME and vda with the actual values from the listing. This reads capacity and mapping without resizing the image or guest filesystem.

sudo virsh -c qemu:///system domblklist VM_NAME --details
sudo virsh -c qemu:///system domblkinfo VM_NAME vda --human

Read the result: Match the disk target to its real source and reported capacity. The block-device capacity available to the guest differs from the size of a partition, logical volume or filesystem inside it. Thin-provisioned allocation also differs from the guest-visible capacity.

Record both host and guest layouts before the approved expansion. Use the platform's supported resize workflow when it owns the VM, then follow the guest operating system's partition and filesystem procedure. Never apply a host image-repair or resize command blindly to a disk that a running VM is actively using.

Do not assume so. Filesystem and partition constraints make shrinking a different operation, and XFS does not support an ordinary in-place shrink. Plan expansion as a lasting capacity change.

Compare the host virtual capacity, guest block-device size, partition/LVM sizes and filesystem free space. Confirm application writes succeed and existing files remain intact. Check host thin-pool capacity and alerts because larger virtual limits permit more physical consumption later.

If the filesystem still shows the old size, identify the first layer that did not grow. Do not repeat every command or apply resize tools to a different device. If partition boundaries are ambiguous, stop and obtain a layout-specific plan. A backup is the recovery route if a metadata change damages the filesystem; enlarging it again is not a repair.

• Creating and attaching a libvirt storage volume
• Taking an application-consistent backup of a KVM guest
• Understanding when a VM snapshot is not a backup
• Diagnosing CPU, memory and disk contention on a KVM host

• QEMU: Qemu Img
• libvirt: Virsh
• docs.redhat.com: Managing File Systems

• libvirt virsh reference