[libvirt] New QEMU daemon for persistent reservations

[Michal Privoznik]

On 11/24/2017 06:18 PM, Paolo Bonzini wrote:
> 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?

I don't know what you mean by registering. Whether libvirt can't have a
separate thread where nothing waitpid() would run? That could hardly
work - not only would libvirt need to spawn separate thread for every
helper, it would not work across restarts of libvirtd. We would have no
guarantee that PID we recorded is still the same process as it was when
we were dying.

> 
>> 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?

If qemu has to connect to the helper's socket the socket must have a
label that allows that. However, libvirt allows running qemu under
pretty much any label that users configure. So if there were just one
daemon per host (which there is not nor it will be), we wouldn't be able
to make any MCS (or at least that's how I understand it) - thus the only
thing we could do is just to allow everybody to connect.

This is more of affirmation that one helper daemon per host is a bad
idea than anything really.

Michal