A KVM guest paused. Follow the I/O trail.

A virtual machine becomes unavailable. SSH stops responding. The console shows little activity. Before blaming CPU or memory, determine whether libvirt has placed the guest in a paused state and whether QEMU has reported a block I/O error.

The guest's visible symptoms do not identify the cause. The host, storage network, backing file, and capacity layers all matter.

1. Capture the guest state#

virsh list --all
virsh domstate VM_NAME --reason
virsh domblkerror VM_NAME
virsh domblklist VM_NAME --details

Replace VM_NAME with the domain name. Record the reported reason and disk target. virsh domblkerror can help identify block-device errors reported for the domain. Treat a specific I/O error as evidence to investigate, rather than as a complete root-cause diagnosis.

2. Trace the backing storage#

Inspect the guest's storage definition:

virsh dumpxml VM_NAME

Identify the disk target and its backing path or volume. If the backing file is a QCOW2 image on a remote filesystem or LVM-backed storage, map all the intermediate layers.

lsblk -f
df -hT
pvs
vgs
lvs -a -o +devices

Check both block capacity and filesystem capacity. A full host filesystem can interrupt writes even if an underlying NVMe namespace has free space elsewhere.

3. Inspect the host kernel and services#

journalctl -k -b -p warning --no-pager
journalctl -u virtqemud -b --no-pager

The libvirt service name can differ by RHEL release and configuration. Some hosts use libvirtd. Inspect the actual running service and its logs.

Look for I/O errors, namespace resets, transport reconnects, filesystem errors, and thin-pool or capacity warnings near the incident timestamp.

4. Check NVMe/TCP when applicable#

If the virtual disk ultimately depends on NVMe/TCP, inspect the host's NVMe state:

nvme list
nvme list-subsys

Look at network health and storage array alerts at the same timestamp. Correlated errors are more useful than a single message without context.

5. Recover in a controlled way#

If capacity exhaustion caused the pause, correct the affected storage layer and verify free space before considering guest recovery. For transport or device failures, establish stable I/O access first.

An unpause command such as virsh resume VM_NAME should follow root-cause checks. Resuming repeatedly while the backing storage remains unavailable can produce another pause and obscure evidence.

Make the next incident faster#

Record five facts: the domain state and reason, disk target, backing storage path, host error timestamp, and storage health at the same time. That small dataset makes repeat incidents much easier to compare.

Reference: libvirt virsh command reference.