My Dell KVM/Libvirt host runs multiple VM’s but some fail to start with the error:
virsh start autobuild
error: Failed to start domain 'autobuild'
error: internal error: Failed to start QEMU binary /usr/bin/qemu-system-x86_64 for probing: qemu-system-x86_64: fatal: could not load module for type 'tcg-accel-ops'
The eventual fix was to update the VM definition:
virsh dumpxml autobuild > /tmp/autobuild-repair.xml
vi /tmp/autobuild-repair.xml
<os>
<type arch='x86_64' machine='q35'>hvm</type>
<devices>
<emulator>/usr/libexec/qemu-kvm</emulator>
rm -rf /var/cache/libvirt/qemu/capabilities/*
rm -rf /run/libvirt/qemu/capabilities/*
virsh define /tmp/autobuild-repair.xml
Is this something that will be fixed by Rocky/RedHat?
virt-manager also fails when trying to create a new VM.
I used chatgpt and Google aI to further diagnose the issue:
virsh dumpxml docker | grep -A2 ‘’
<emulator>/usr/libexec/qemu-kvm</emulator>
<disk type='file' device='disk'>
<driver name='qemu' type='qcow2'/>
# grep -R "emulator" /etc/libvirt/qemu.conf /etc/libvirt/*.conf 2>/dev/null
/etc/libvirt/qemu.conf:# its process title, so the complete QEMU command (emulator and
/etc/libvirt/qemu.conf:# emulator threads and helper processes remain outside of the group
/etc/libvirt/qemu.conf:# "emulator" - only QEMU and its threads (emulator + vCPUs) are placed into
/etc/libvirt/qemu.conf:clear_emulator_capabilities = 1
/etc/libvirt/qemu.conf:emulator = "/usr/libexec/qemu-kvm"
/etc/libvirt/qemu.conf:# its process title, so the complete QEMU command (emulator and
/etc/libvirt/qemu.conf:# emulator threads and helper processes remain outside of the group
/etc/libvirt/qemu.conf:# "emulator" - only QEMU and its threads (emulator + vCPUs) are placed into
/etc/libvirt/qemu.conf:clear_emulator_capabilities = 1
/etc/libvirt/qemu.conf:emulator = "/usr/libexec/qemu-kvm"
The problem was the stale, unowned binary:
/usr/bin/qemu-system-x86_64
which was:
QEMU emulator version 9.1.0 (qemu-kvm-9.1.0-29.el9_7.6)
After moving it aside:
mv /usr/bin/qemu-system-x86_64 /usr/bin/qemu-system-x86_64.old
libvirt correctly discovered:
<path>/usr/libexec/qemu-kvm</path>
and capability probing now works.The problem was the stale, unowned binary:
/usr/bin/qemu-system-x86_64
which was:
QEMU emulator version 9.1.0 (qemu-kvm-9.1.0-29.el9_7.6)
After moving it aside:
mv /usr/bin/qemu-system-x86_64 /usr/bin/qemu-system-x86_64.old
libvirt correctly discovered:
<path>/usr/libexec/qemu-kvm</path>
and capability probing now works.
It seems that the dnf update is not cleaning-up the previous version 9.x qemu-kvm binaries when updating to version 10.x
I checked on a RHEL9 system that still shows all qemu versions and there are no packages that own /usr/bin/qemu-system-x86_64. If it’s not owned by a package, then dnf cannot clean it up.
The real question is why that existed when no package owns it? Perhaps it was a symlink under /usr/bin? Or something configured with alternatives.
Hi Ian,
It’s very strange because I built my hypervisor from scratch on Rocky-9 and it has been running (patched and rebooted) for about six months without any issue, then the latest dnf update broke it?
I have not done any special patching or tailoring.
It could well be that previous packages used alternatives or update-alternatives in pre/post scripts to create that file. It could well be that later packages didn’t include anything in pre/post to clean that up. It’s the only thing I can think of from the system-side of things.
By using alternatives would explain why dnf doesn’t clean up a file that doesn’t belong to a package since it’s dealt with in a different way.
The only real way of verifying that would be to replicate and install the same version of Rocky 9 and qemu/kvm packages that were initially installed and then update after that.
If nothing else was done from the user side of things, eg: manually creating symlink or alternatives configuration, then it could only be something similar to my suggestion above.
Main thing is, you got it fixed anyway 
I don’t see that file at all on my Rocky 9.x
Hi Ian,
I don’t know if this helps but this is how I built my cluster:
Transaction ID : 4
Begin time : Fri 20 Mar 2026 10:17:01 AM CET
Begin rpmdb : 8a25791ba6cfa3456f2ed80f9c552284b16c9ac8fe58127d7a0f3841c9cd23d2
End time : Fri 20 Mar 2026 10:17:42 AM CET (41 seconds)
End rpmdb : 616d7df68a0d45fa5c717df405d437ade357ecff3a44f6c1cf140219539a0a25
User : root <root>
Return-Code : Success
Releasever : 9
Command Line : install -y bridge-utils virt-top libguestfs-tools bridge-utils virt-viewer qemu-kvm libvirt virt-manager virt-install
Persistence : Persist
Not really. The above shows what packages were installed, but we don’t know the version numbers to then be able to replicate it. We only see releasever but that is the version of Rocky - and it’ll show that even if we installed Rocky 9.0 or any other point release.
Even the date/time of the transaction doesn’t necessarily help, although it could give an idea. Assuming it was downloading packages from the internet, then it would be easy enough to know that the released version at that time was 9.7.
The versions (and source repo) would show in the Packages Altered part of the transaction info.
An examble:
...
Packages Altered:
...
Install slirp4netns-1.2.0-3.el9.x86_64 @appstream
Install python3-backoff-2.2.1-1.el9.noarch @epel
Upgrade mock-5.0-1.el9.noarch @epel
Upgraded mock-4.1-1.el9.noarch @@System
I saw a thread (dated 2020) about CentOS 8.0, where it was noted that
el8 had already /usr/libexec/qemu-kvm
while el7 had /usr/bin/qemu-system-x86_64 (or something).
That obviously does not tell what el9 has.
(If I were psychic, I still could not see /usr/bin/qemu-system* in CentOS 7 either.)
Why not virsh edit autobuild here?
Edit fails when you try to save no matter what you update as it has somehow been cached.
That’s too bad. I didn’t have an issue when I last ran libvirt - 6 mo ago - but I may have used a different editor or something. I’ve since converted to PVE after some agonising over its compostion, and I have no more libvirt. Sorry I couldn’t help.
Up to el9_7 the /usr/bin/vi was a script that did start vim if that was installed. If not, actual vi (from libexec) did start.
In el9_8 the /usr/bin/vi is the real vi binary and you need to run vim explicitly.
The change was due to some security issue.
Various tools do default to “vi” for edits (a thing you can control with EDITOR and/or VISUAL envvars). Hence 6 mo ago one got vim and now vi.
That’s really strange, there are now two binaries (double the attack vector), but it’s good for security. The editors come from different packages, vim-minimal in base-os and vim-enhanced in appstream.
