On 24/11/2017 18:07, Michal Privoznik wrote:
On 11/24/2017 04:42 PM, Paolo Bonzini wrote:
One daemon per QEMU is nicer IMO because it lets us do MCS. Of course one daemon per QEMU can only apply to system libvirtd; session must use one daemon per host.
Agreed. One daemon per QEMU it is then. Just to make sure whether I> understand correctly - libvirtd would start it *before* exec()-ing qemu (so that qemu can connect) and kill it after qemu dies. But what should happen if the helper dies while qemu is running? Should qemu pause itself, fire up an event on the monitor so that libvirtd can spawn the helper again?
QEMU currently tries to reconnect five times every second, and then fails the I/O command. This seemed okay to me because PRs are generally used in a HA environment where the failure will be broadcast and another node will pick up the work.
The helper is going to be daemonized (for the same reason that qemu process is) => there's no SIGCHLD for libvirtd to receive.
Couldn't (or shouldn't!) libvirt register itself as a subreaper instead?
Also, I don't really expect anything special when it comes to migration, just want to make sure I'm not mislead.
No, everything is fine for migration.
One daemon per host is easy, because it's just a couple new command-line options as far as libvirtd is concerned, but we need to check that it works well with MCS.
It's very likely that it wouldn't. Users can chose arbitrary DAC/SELinux labels for their qemus. In general we will not find any intersection that the helper socket can have.
I know some of those words. :) Can you explain to an SELinux layman?
Yup. In case of a unprivileged libvirtd there'll be a system-wide helper daemon that: a) will not be managed by libvirtd b) has wide permissions so that any user can connect to it
This basically follows what we have for vhostuser. Except that vhostuser is not an implementation detail of qemu :-)
Okay, thanks. Paolo