[libvirt] New QEMU daemon for persistent reservations

[Paolo Bonzini]

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