Re: New QEMU daemon for persistent reservations

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

 



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

Thanks,

Paolo

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list



[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]
  Powered by Linux