[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] New QEMU daemon for persistent reservations

On 27/11/2017 14:44, Michal Privoznik wrote:
> On 11/27/2017 12:09 PM, Paolo Bonzini wrote:
>> 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.
> Well, connecting and staying connected? Otherwise mere connect followed
> by immediate disconnect would work only when libvirtd is starting up and
> reconnecting to already running domains. Not if the helper dies some
> time after libvirt started the domain and the helper. [1]

Ok, let's add the event and state command (to QEMU 2.12 only).



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]