Re: [Qemu-devel] [PATCH 4/4] scsi: add persistent reservation manager using qemu-pr-helper

[Paolo Bonzini <pbonzini@redhat.com>]

On 19/09/2017 15:26, Daniel P. Berrange wrote:
> On Tue, Sep 19, 2017 at 03:23:09PM +0200, Paolo Bonzini wrote:
>> On 19/09/2017 15:12, Daniel P. Berrange wrote:
>>> On Tue, Sep 19, 2017 at 02:57:00PM +0200, Paolo Bonzini wrote:
>>>> On 19/09/2017 14:53, Daniel P. Berrange wrote:
>>>>>> +    /* Try to reconnect while sending the CDB.  */
>>>>>> +    for (attempts = 0; attempts < PR_MAX_RECONNECT_ATTEMPTS; attempts++) {
>>>>>
>>>>> I'm curious why you need to loop here. The helper daemon should be running
>>>>> already, as you're not spawning it on demand IIUC. So it shoudl either
>>>>> succeed first time, or fail every time.
>>>>
>>>> You're focusing on the usecase where the helper daemon is spawned per-VM
>>>> by the system libvirtd, which I agree is the most important one.
>>>> However, the other usecase is the one with a global daemon, access to
>>>> which is controlled via Unix permissions.  This is not SELinux-friendly,
>>>> but it is nicer for testing and it is also the only possibility for user
>>>> libvirtd.
>>>>
>>>> In that case, upgrading QEMU on the host could result in a "systemctl
>>>> restart qemu-pr-helper.service" (or, hopefully unlikely, a crash could
>>>> result in systemd respawning the daemon).  Reconnect is useful in that case.
>>>
>>> If using systemd socket activation and you restart the daemon, the listening
>>> socket should be preserved, so you shouldn't need to reconnect - the client
>>> should get queued until it has started again (likewise on crash).
>>
>> Oh, that's cool.  I didn't know that.  However, systemd socket
>> activation is optional, and it's only a handful of lines so I think it's
>> a bit nicer behavior (chardevs for example have options to reconnect).
> 
> The downside is that if someone forget to start the daemon, or enable
> the socket,  QEMU will spin for 5 seconds trying to reconnect, instead
> of reporting an error immediately. 

Not exactly:

- the daemon must be present at startup.  Reconnect is only tried when
sending a command.

- it's not a busy wait, pr_manager_helper_run runs in an
util/thread-pool.c worker thread (see pr_manager_execute in patch 1).

Paolo