Hello Michal,
On 6/17/2025 3:44 AM, Michal Prívozník wrote:
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...@oracle.com> 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/
de...@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?
Nope, we are just researching before deploying MSFC on top of libvirt.
The libvirt source code shows there is only one pr-helper(with one
socket) running for all the managed disks. However, this looks
conflicting to the qemu
documentation(https://www.qemu.org/docs/master/interop/pr-helper.html).
This is why I bring up this topic here for clarification.
Or are you just researching the
topic.
Researching
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.
So far I haven't seen the internal mutex in qemu-pr-helper itself(maybe
I've missed something inside the socket beyond the helper?), plus what
the qemu-pr-helper document says, I suppose it is better to get
clarification on this.
I'll dig the qemu-pr-helper source code. Any thoughts are welcome :)
Again, are you experiencing any bug?
Nope, just confused about the inconsistency between the qemu
documentation and libvirt implementation.
Thanks
Annie
If so, please do file an issue so
it can be properly investigated!
https://urldefense.com/v3/__https://libvirt.org/bugs.html__;!!ACWV5N9M2RV99hQ!M_Zl7eL0ZjVWDhhJDpezXlM7vc8gNIW22WzpNtR95I4U6FUL7j3fDHtVB-u2XpTpPqXlkqgDKlc6C9E$
Michal
