Re: Question about managed/unmanaged persistent reservation disks

On 6/12/25 17:01, Annie Li wrote: > Hello Michal, > > On 6/12/2025 9:18 AM, Michal Prívozník wrote: >> On 6/10/25 19:15, Simon Coter wrote: >>> Adding users DL to possibly reach out a wider audience. >>> >>> Simon >>> >> Dropping devel list as this is users list material. >> >>>> On Jun 9, 2025, at 7:28 PM, Annie Li <annie.li(a)oracle.com&gt; wrote: >>>> >>>> Hello, >>>> >>>> I've been looking at source code related to persistent reservation and >>>> got confused a little bit about managed persistent reservation disks. >>>> For disk configured with 'managed=yes' as the following, >>>> >>>> <reservations managed='yes'> >>>>            <source type='unix' path='/var/lib/libvirt/qemu/domain-7- >>>> brml10g19-iscsi-rese/pr-helper0.sock' mode='client'/> >>>> </reservations> >>>> >>>> libvirt is responsible for starting a pr-helper program with a >>>> specific associated socket file. The following source code shows that >>>> there is only one pr-helper and socket file associated with the >>>> managed disks for one VM. >>>> >>>> const char * >>>> qemuDomainGetManagedPRAlias(void) >>>> { >>>>      return "pr-helper0"; >>>> } >>>> char * >>>> qemuDomainGetManagedPRSocketPath(qemuDomainObjPrivate *priv) >>>> { >>>>      return g_strdup_printf("%s/%s.sock", priv->libDir, >>>>                             qemuDomainGetManagedPRAlias()); >>>> } >>>> >>>> So if the VM is booted with multiple disks configured with >>>> 'managed=yes' for reservation, I suppose these multiple disks share >>>> the this managed pr-helper and socket file. However, per the qemu >>>> document, https://urldefense.com/v3/__https://www.qemu.org/docs/ >>>> master/interop/pr-helper.html__;!!ACWV5N9M2RV99hQ! >>>> KTvTQA7YxW75PM9pKbPZ3lG5cV- >>>> QT0MDZfDkL1XZmT6gQ3chMSfk63La0TUAg4ZvMk2FCh_zn2p4HnY$ >>>> <https://urldefense.com/v3/__https://www.qemu.org/docs/master/ >>>> interop/pr-helper.html__;!!ACWV5N9M2RV99hQ! >>>> KTvTQA7YxW75PM9pKbPZ3lG5cV- >>>> QT0MDZfDkL1XZmT6gQ3chMSfk63La0TUAg4ZvMk2FCh_zn2p4HnY$ > >>>> "It is invalid to send multiple commands concurrently on the same >>>> socket. It is however possible to connect multiple sockets to the >>>> helper and send multiple commands to the helper for one or more file >>>> descriptors." >>>> >> This certainly did not use to be the case. IIRC this was discussed in >> this very old thread: >> >> https://urldefense.com/v3/__https://lists.libvirt.org/archives/list/ >> devel(a)lists.libvirt.org/thread/UUL3B7ZLAW4WPVUBX2R76GZTOS24Z2SD/__;!! >> ACWV5N9M2RV99hQ!KTvTQA7YxW75PM9pKbPZ3lG5cV- >> QT0MDZfDkL1XZmT6gQ3chMSfk63La0TUAg4ZvMk2FCh_zeWt4DWY$ > Thanks for the info. > This thread talks about the socket connection/access, but doesn't touch > the topic of multiple socket. > My understanding of the qemu document is that it's OK to run one helper > per QEMU or even per host, but multiple disks shouldn't share the same > socket since it is possible that multiple commands may be sent > concurrently. >> Maybe QEMU has some internal lock that does the right thing and >> serializes requests? Are you actually seeing any problems?

Or are you just researching the topic.

What is happening is - libvirt starts one pr-helper per guest, and all disks within the guest share the same pr-helper process. QEMU needs just one connection for that and per Paolo's reply later in this thread it has internal mutex that serializes multiple accesses onto the socket.

> I'll dig the qemu-pr-helper source code. Any thoughts are welcome :) Again, are you experiencing any bug?