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