The "No space left on device" error in QEMU typically occurs when the host filesystem lacks free blocks, the virtual disk image has reached its maximum allocated size, or permissions prevent writing to the storage path. Resolving this requires verifying host disk usage, expanding the virtual disk capacity using qemu-img, and ensuring correct file ownership for the QEMU process.
Understanding the Error Context
When QEMU reports that there is no space left on the device, it is usually a direct reflection of the underlying storage subsystem's state rather than a bug within the hypervisor itself. This error can manifest during VM creation, snapshot operations, or normal runtime writes if the backing store is full. It is critical to distinguish between a host-level storage exhaustion and a guest-level file system limit, although the former is the most common cause in virtualization environments.
Before attempting complex fixes, you must confirm that the error originates from the host operating system's inability to write data to the disk where the virtual machine files are stored. If the host has ample free space, the issue may lie with specific quotas, inode exhaustion, or permission errors that mimic a full disk condition. Understanding this distinction prevents unnecessary troubleshooting steps that do not address the root cause.
Check virt-manager with QEMU and KVM provides additional context on managing storage backends effectively, which can help in diagnosing similar issues when using higher-level management tools.Verifying Host Disk Space and Inodes
The first diagnostic step is to check the available space on the host partition hosting your virtual disk images. Use the df -h command to view human-readable disk usage statistics. Look specifically at the Use% column for the mount point containing your .qcow2 or .raw files. If the percentage is 100%, you must free up space by removing unnecessary files or expanding the logical volume.
Additionally, check for inode exhaustion using the df -i command. Inode limits are often overlooked but can trigger "No space left on device" errors even when megabytes of free space remain. This situation commonly arises in directories with millions of small files. If inodes are exhausted, you cannot create new files regardless of available block space.
df -h /path/to/vm/storage
df -i /path/to/vm/storageIf you find that the host disk is indeed full, identify large files using the du -sh command on subdirectories. Cleaning up old snapshots, logs, or unused disk images will restore write capabilities to the QEMU instance.
Expanding Virtual Disk Images
Even if the host has space, the virtual disk image itself might have reached its configured maximum size. QEMU disk images, particularly those in qcow2 format, can be dynamically allocated but still have a virtual size limit defined at creation. You can expand this limit using the qemu-img resize command.
To increase the size of a virtual disk by 10 gigabytes, run the following command:
qemu-img resize /path/to/disk.img +10GThis command modifies the metadata of the image file to allow for more data allocation. However, resizing the container does not automatically extend the file system inside the guest OS. After resizing the image, you must boot the guest and use tools like fdisk, parted, or lvextend to utilize the new unallocated space within the guest's partition table.
If you are running QEMU in a nested virtualization environment, such as Ubuntu via VMware, ensure that the outer virtualization layer also has sufficient storage overhead. Refer to Run QEMU in virtualized UBUNTU via VMWARE for insights into managing storage layers in complex setups.
Checking Permissions and Ownership
Permission errors can sometimes masquerade as disk space errors. If the user running the QEMU process does not have write access to the directory or the image file, the kernel may return an I/O error that appears similar to a full disk. Verify ownership using ls -l on the storage directory.
ls -l /path/to/vm/storage/Ensure that the current user or the libvirt/qemu group has read-write permissions. If necessary, change ownership using chown or adjust permissions with chmod. Incorrect SELinux contexts on Linux systems can also block write access, so check audit logs with ausearch -m avc if standard permissions appear correct.
Managing Snapshots and Backing Files
Snapshots can consume significant disk space over time, especially if they are not merged regularly. Each snapshot delta adds to the total storage footprint. Use qemu-img info to inspect the chain of backing files and snapshot sizes. If a snapshot chain is bloated, consider merging it to reclaim space and improve performance.
Regular maintenance of virtual disk images helps prevent sudden space exhaustion. Tools like qemu-img check can verify integrity, while qemu-img convert can optimize storage formats. For users dealing with corrupted data due to sudden power loss or space issues, understanding recovery methods is crucial.
Frequently Asked Questions
Why does QEMU say no space left when df shows free space?
This discrepancy usually indicates inode exhaustion rather than block space shortage. Check inode usage with df -i to see if the file system has run out of directory entry slots. Additionally, verify that you are checking the correct mount point where the VM files reside.
Can I shrink a qcow2 virtual disk to save space?
Yes, you can reduce the virtual size of a qcow2 image using qemu-img resize with a negative value, but only after ensuring the guest file system does not need the extra space. Shrinking too aggressively can corrupt the guest OS if partitions are expanded beyond the original boundaries.
Does the guest OS file system fill up affect the host?
No, the guest OS filling its own internal drive does not impact the host's physical disk space directly, as dynamic images grow incrementally. However, if the guest writes heavily, the host disk will eventually fill up as the image file expands to accommodate the guest's data.
How do I fix permission denied errors that look like no space?
Ensure the QEMU process user owns the disk image and directory. Use chown to transfer ownership to the current user or libvirt service account. On SELinux-enabled systems, reset security contexts with restorecon if permissions are correct but access is still blocked.
What causes rapid disk growth in QEMU snapshots?
Every write operation inside the guest creates a delta in the active snapshot file. If snapshots are taken frequently without merging, the delta files grow continuously. Regularly merge snapshots using qemu-img commit to consolidate changes and stop the growth.