Re: [libvirt] New QEMU daemon for persistent reservations
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