You hit "No space left on device" inside a VM
You are running a Fedora VM for development or a service. You try to install a package and dnf aborts with No space left on device. The VM disk is full. You need to add storage without wiping the guest or losing data. The fix involves expanding the image file on the host and then telling the guest to use the new space.
A botched resize can corrupt the partition table or filesystem. Snapshot the VM before you start. If the resize fails, you can revert to the snapshot and try again.
What's actually happening
A virtual disk has three layers. The outer layer is the image file on the host, usually qcow2. The middle layer is the partition table inside that image. The inner layer is the filesystem, like ext4 or xfs.
Think of the image as a cardboard box. The partition is a shelf inside the box. The filesystem is the stack of books on the shelf. If you replace the box with a larger one, the shelf does not automatically grow. The books do not spread out to fill the new space. You must extend the shelf and then rearrange the books.
Expanding the image file only makes the outer container bigger. The partition table still points to the old end-of-disk. The filesystem still thinks it ends where it always did. You must expand the image, then extend the partition, then resize the filesystem. Skip a layer and the extra space sits unused. Force a layer out of order and you risk data corruption.
Prepare the host environment
Identify the disk path before you touch the VM. Libvirt manages disk paths, and guessing the filename leads to errors.
Here's how to find the exact source path for your VM's disk.
virsh domblklist <vm-name>
# WHY: Lists block devices and their source paths. You need the source path to resize the image.
# WHY: The target is the device name inside the VM, like vda. The source is the file on the host.
Check the image format. qemu-img resize works on qcow2 and raw images. It fails on images with backing files or complex chains.
Here's how to inspect the image metadata.
qemu-img info /var/lib/libvirt/images/<disk>.qcow2
# WHY: Shows format, virtual size, and backing file status.
# WHY: If "backing file" is not "null", you cannot resize directly. Merge the chain first.
If the image uses a backing file, you must merge it before resizing. Use qemu-img convert to create a standalone copy, resize that, and update the VM config. Backing file chains break when the top layer changes size.
Expand the disk image
Stop the VM before resizing. Resizing while the guest writes to the disk risks corruption. A clean shutdown ensures all buffers are flushed.
Here's how to stop the VM and expand the image.
virsh shutdown <vm-name>
# WHY: Stops the VM cleanly. Wait for the process to exit before proceeding.
# WHY: Use 'virsh destroy' only if the guest is hung. A hard power-off risks filesystem journal corruption.
qemu-img resize /var/lib/libvirt/images/<disk>.qcow2 +10G
# WHY: Adds 10GB to the virtual capacity. The + prefix adds to current size.
# WHY: Omit the + to set an absolute size. For example, 20G sets the disk to exactly 20GB.
The qemu-img resize command updates the image header. The file size on the host may not grow immediately if the image is thin-provisioned. The virtual capacity increases, which is what matters.
Resize the partition and filesystem
Boot the VM. The guest kernel sees the larger disk, but the partition table and filesystem remain at their old sizes. You need tools inside the guest to claim the new space.
Here's how to extend the partition and filesystem inside the VM.
sudo growpart /dev/vda 1
# WHY: Expands partition number 1 to fill the disk. growpart handles partition table math safely.
# WHY: The syntax is device then partition number. Do not use /dev/vda1 as the first argument.
sudo resize2fs /dev/vda1
# WHY: Resizes the ext4 filesystem to fill the partition.
# WHY: If you use xfs, run 'xfs_growfs /mount/point' instead. xfs_growfs requires a mount point.
growpart is safer than fdisk for this task. fdisk requires deleting and recreating the partition, which can shift start sectors and break bootloaders. growpart preserves the start sector and only moves the end.
If the VM uses LVM, growpart expands the physical volume partition. You then need pvresize and lvextend to propagate the space to logical volumes. The filesystem resize step remains the same.
Verify the changes
Confirm the space is available before you declare the job done. Check both the partition geometry and the filesystem usage.
Here's how to verify the resize worked.
lsblk
# WHY: Shows block device hierarchy and sizes. Confirm the partition size matches the disk size.
df -h
# WHY: Shows filesystem usage. Confirm the available space increased.
# WHY: If df shows the old size, the filesystem resize failed. Check journalctl for errors.
Run journalctl -xe inside the VM if resize2fs or xfs_growfs reported errors. The journal often contains the specific reason a resize failed, such as a read-only filesystem or a corrupted superblock.
Common pitfalls and error messages
Resizing fails for predictable reasons. Recognizing the error saves time.
qemu-img: Could not open '/path': Could not open backing file
This error means the disk uses a backing chain. You cannot resize the top image without breaking the reference to the base. Merge the images with qemu-img convert -O qcow2 source.qcow2 merged.qcow2, then resize the merged file. Update the VM XML to point to the new file.
growpart: unable to extend partition
This error usually means the partition is not the last one on the disk. growpart only works on the final partition. If you have a swap partition at the end, you must move or delete swap first. Create a new swap partition in the expanded space and update /etc/fstab with the new UUID.
resize2fs: Bad magic number in super-block
This error means you pointed resize2fs at a partition that does not contain an ext filesystem. Check lsblk -f to verify the filesystem type. If the partition is LVM, you must resize the logical volume first. If the partition is xfs, use xfs_growfs.
xfs_growfs: /dev/vda1 is not a mounted xfs filesystem
xfs_growfs requires a mount point, not a device path. Run xfs_growfs / if the root filesystem is xfs. XFS can only grow online. You cannot shrink xfs. Plan your sizes carefully.
When to use this vs alternatives
Use qemu-img resize followed by growpart when you need a reliable, scriptable resize for simple partition layouts. Use virt-manager disk settings when you prefer a GUI and are managing a single VM interactively. Use virt-resize from libguestfs-tools when you need to resize partitions and filesystems automatically without booting the guest. Use a raw disk format when you plan to resize frequently and want to avoid qcow2 overhead or backing file complexity. Stay on qcow2 when you need snapshots or thin provisioning for storage efficiency.
virt-resize is a powerful offline tool. It can resize disks, add partitions, and even convert between formats in one command. It requires the VM to be off and loads the disk image into a temporary appliance. It is safer for complex layouts with multiple partitions or LVM, but slower for simple single-partition VMs.
Run journalctl -xe first. Read the actual error before guessing. A failed resize is usually a configuration mismatch, not a bug.