Thu, 19 Mar 2015
Welcome to Yenya's rant about software "features". Today we will have look at libvirt in Fedora and its dependencies. But firstly let me show you a funny picture:
Anyway. I teach a seminar on Linux administration, where one of the tasks is to compile and use one's own kernel. The task for the following week is to create a virtual machine. One of my students had an interesting problem with the second task - virsh refused to start his KVM-based virtual machine with the "command timeout" message.
Digging into the issue, we discovered that it works with the distribution kernel, but not with his custom kernel. Then we found that virsh tries to do a RPC call over D-Bus, which then times out, because the D-Bus object in question was not present. This object is supposed to be provided by a daemon called systemd-machined, which describes itself with the following headline:
This is a tiny daemon that tracks locally running Virtual Machines and Containers in various ways.
This is in fact an understatement, with the real situation being that this
daemon is a core part of the virtualization subsystem, and it is not even
possible to start a libvirt-managed guest without it. We have tried to start
the daemon from the command line, but it immediately exited without a meaningful
message anywhere. The only message in the
that systemd-machined failed to start when the system was booted.
Long story short, my lucky guess was that systemd-machined could have something to do also with containers, and it might have needed a container support in the kernel. After enabling about five namespaces-related kernel config options and booting a recompiled kernel, we were able to start systemd-machined, and only then we managed to start the VM using virsh.
This spaghetti-structured unstraceable mess of interconnected daemons communicating over D-Bus and providing no meaningful error messages, which is masqueraded under a collective name "systemd", makes me sick quite often.