SELinux, virtd_t, and common denials

On SELinux-enabled hosts, libvirt daemons run in controlled domains such as virtd_t. Guest resources often carry svirt_* labels so the hypervisor can touch only what the policy allows.

Why this breaks guest startup

The guest XML may be correct while SELinux blocks the disk path, firmware file, socket, or host device. That means the fix is usually labeling or policy, not a libvirt syntax change.

getenforce
ps -eZ | grep -E "virtqemud|libvirtd"
ausearch -m AVC,USER_AVC -ts recent

Triage order

Use evidence in this order before changing policy:

1. Check the AVC details and owning context.
2. Read the exact service and file labels involved in the denial.
3. Confirm whether the daemon boundary is actually the one implicated by the evidence.
4. Only then decide whether a policy adjustment is justified.

This order prevents a valid confinement decision from being mistaken for a reason to weaken SELinux. First prove what was denied, then prove which labels and process boundary own the denial, and only then decide whether the desired access should exist.

Common denial patterns

• Disk images stored in a random directory without the expected label.
• ISO files mounted from a path that the daemon domain cannot read.
• Shared folders or custom device nodes that never received the right context.

Fix pattern

ls -Z /var/lib/libvirt /var/lib/libvirt/images
restorecon -Rv /var/lib/libvirt
journalctl -t setroubleshoot -n 50

If the storage path is intentionally outside the default tree, document the labeling strategy instead of relying on ad hoc fixes.