libvirtd Segfault – Start request repeated too quickly for libvirtd.service (Solved)

Today I came across the following issue after an upgrade of libvirtd:

[root@karma ~]# service libvirtd start

Oct 19 17:48:43 karma kernel: libvirtd[4469]: segfault at 0 ip 00007f38f342ccf7 sp 00007f38efb5cf88 error 4 in libvirt_driver_qemu.so[7f38f33c3000+133000]
Oct 19 17:48:43 karma systemd: libvirtd.service: main process exited, code=killed, status=11/SEGV
Oct 19 17:48:43 karma systemd: Unit libvirtd.service entered failed state.
Oct 19 17:48:43 karma systemd: libvirtd.service failed.
Oct 19 17:48:43 karma systemd: libvirtd.service holdoff time over, scheduling restart.
Oct 19 17:48:43 karma systemd: start request repeated too quickly for libvirtd.service
Oct 19 17:48:43 karma systemd: Failed to start Virtualization daemon.
Oct 19 17:48:43 karma systemd: Unit libvirtd.service entered failed state.
Oct 19 17:48:43 karma systemd: libvirtd.service failed.

It looks like libvirtd is segfaulting immediately, leading to systemd restarting it over and over, eventually failing due to it failing so quickly.

Loading up gdb, it looks like the problem is in qemuDomainMachineIsI440FX:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffdaecc700 (LWP 8709)]
0x00007fffde79acf7 in qemuDomainMachineIsI440FX () from /usr/lib64/libvirt/connection-driver/libvirt_driver_qemu.so
(gdb) bt
#0  0x00007fffde79acf7 in qemuDomainMachineIsI440FX () from /usr/lib64/libvirt/connection-driver/libvirt_driver_qemu.so
#1  0x00007fffde777f10 in qemuAssignDeviceControllerAlias () from /usr/lib64/libvirt/connection-driver/libvirt_driver_qemu.so
#2  0x00007fffde7787c3 in qemuAssignDeviceAliases () from /usr/lib64/libvirt/connection-driver/libvirt_driver_qemu.so
#3  0x00007fffde7b545f in qemuProcessStart () from /usr/lib64/libvirt/connection-driver/libvirt_driver_qemu.so
#4  0x00007fffde814585 in qemuDomainObjStart () from /usr/lib64/libvirt/connection-driver/libvirt_driver_qemu.so
#5  0x00007fffde814c3b in qemuAutostartDomain () from /usr/lib64/libvirt/connection-driver/libvirt_driver_qemu.so
#6  0x00007ffff735c5da in virDomainObjListHelper () from /lib64/libvirt.so.0
#7  0x00007ffff731035c in virHashForEach () from /lib64/libvirt.so.0
#8  0x00007ffff737a1e1 in virDomainObjListForEach () from /lib64/libvirt.so.0
#9  0x00007fffde7eb70a in qemuStateAutoStart () from /usr/lib64/libvirt/connection-driver/libvirt_driver_qemu.so
#10 0x00007ffff73d6e56 in virStateInitialize () from /lib64/libvirt.so.0
#11 0x0000555555569f1b in daemonRunStateInit ()
#12 0x00007ffff7349182 in virThreadHelper () from /lib64/libvirt.so.0
#13 0x00007ffff49b2dc5 in start_thread () from /lib64/libpthread.so.0
#14 0x00007ffff46dfced in clone () from /lib64/libc.so.6
(gdb)

After looking at the source, it looks like a bug was introduced when qemu-kvm was upgraded to 1.5.3. This is the problem line:

    return (STREQ(def->os.machine, "pc") || 

The segfault occurs when os.machine points to nothing. Looking at the config for one of the virtual machines, we can see why:

[root@karma qemu]# cat /etc/libvirt/qemu/autostart/bishop.xml
<domain type='kvm'>
  <name>bishop</name>
  <uuid><!--omitted--></uuid>
  <memory>262144</memory>
  <vcpu>1</vcpu>
  <os>
    <type arch="x86_64">hvm</type>
    <boot dev='hd'/>

There’s no machine parameter in the os -> type node. The fix is very simple. Simply add machine=”pc”:

    <type arch="x86_64" machine="pc">hvm</type>

Libvirt now starts without complaint. This really should have been caught by the XML config parser. Simply segfaulting is not nice behaviour!