[libvirt] New QEMU daemon for persistent reservations

[Paolo Bonzini]

On 24/11/2017 19:13, Michal Privoznik wrote:
> On 11/24/2017 06:18 PM, Paolo Bonzini wrote:
>> On 24/11/2017 18:07, Michal Privoznik wrote:
>>> 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?
> 
> 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.

Oh, you're right. :(  Even if libvirtd were a subreaper (see prctl(2)
manpage), the daemonized qemu-pr-helper would be reparented to init when
libvirtd restarts.

libvirtd could test whether the helper is alive by connecting to its
socket.  If that's not enough, I'll add an event.

Another thing: we have

    <reservations enable='yes'/>

which represents "one daemon per QEMU" in privileged libvirtd and
"well-known socket path" in session libvirtd.  What would the
live-domain XML look like?  Maybe:

    <!-- one daemon per QEMU, privileged libvirtd -->
    <reservations enable='yes' managed='yes'/>
      <source type='unix' path='/var/lib/libvirtd/...'
         mode='server'/>
    </reservations>

    <!-- one daemon per host, session libvirtd -->
    <reservations enable='yes' managed='no'/>
      <source type='unix' path='/var/run/qemu-pr-helper.sock'
         mode='server'/>
    </reservations>

And then, would it be an error to specify the "wrong" managed setting in
the domain-creation XML?  Or would it be possible to use a managed='no'
helper in privileged libvirtd?  I take it as a "no" given your remark below.

Thanks,

Paolo

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