Comment # 26 on bug 950498 from Mike Latimer

It seems as though this is a common problem on machines that are upgraded from
a previous version of SLES. I am investigating SLES11SP4 to SLES12SP2 upgrades
(which are supported) and have ran into this exact problem on multiple
machines. In every case, libvirtd.service appears to be enabled, but systemd
never attempts to start it:

xen84:~ # systemctl status libvirtd.service -l
��� libvirtd.service - Virtualization daemon
   Loaded: loaded (/usr/lib/systemd/system/libvirtd.service; enabled; vendor
preset: enabled)
   Active: inactive (dead)
     Docs: man:libvirtd(8)
           http://libvirt.org

xen84:~ # ls -l /etc/systemd/system/multi-user.target.wants/libvirtd.service
lrwxrwxrwx 1 root root 40 Jul 21 22:05
/etc/systemd/system/multi-user.target.wants/libvirtd.service ->
/usr/lib/systemd/system/libvirtd.service

xen84:~ # journalctl -axb | grep -i libvirt
<no output>

xen84:~ # systemctl status multi-user.target
��� multi-user.target - Multi-User System
   Loaded: loaded (/usr/lib/systemd/system/multi-user.target; static; vendor
preset: disabled)
   Active: active since Fri 2016-07-22 00:37:41 CEST; 24min ago
     Docs: man:systemd.special(7)

Jul 22 00:37:41 xen84 systemd[1]: Reached target Multi-User System.

xen84:~ # systemctl is-system-running
running

xen84:~ # systemctl list-dependencies --reverse libvirtd
libvirtd.service
��� ������multi-user.target
���   ������graphical.target

xen84:~ # systemctl list-dependencies multi-user.target
multi-user.target
��� ������after-local.service
��� ������auditd.service
��� ������btrfsmaintenance-refresh.service
��� ������cron.service
��� ������dbus.service
��� ������haveged.service
��� ������libvirtd.service
...

Enabling and disabling the service has no effect. apparmor-parser is not
installed (so no apparmor daemon). Manually starting libvirtd works fine -
until the next reboot, which will not start the daemon.