[libvirt] New QEMU daemon for persistent reservations
mprivozn at redhat.com
Tue Oct 3 15:59:35 UTC 2017
On 09/10/2017 11:38 AM, Paolo Bonzini wrote:
> On 28/08/2017 13:11, Michal Privoznik wrote:
>> On 08/25/2017 12:41 AM, Paolo Bonzini wrote:
>>> On 22/08/2017 18:27, Paolo Bonzini wrote:
>>>> Hi all,
>>> The XML to use the helper with a predefined socket could be:
>>> <disk ...>
>>> <pr mode='connect'>/path/to/unix.socket'</pr>
This looks okay-ish. But from future proof POV, I'd have the path as an
attribute, or as a separate sub-element of <pr/> so that we can stick
more elements into it if we need to.
>> Do we want to/need to expose the path here? I mean, is user expected to
>> do something with it? We don't expose monitor path anywhere but keep it
>> private (of course we store it in so called status XML which is a
>> persistent storage solely for purpose of reloading the internal state
>> when daemon is restarted).
> In this case, yes. This is for the case of a global daemon.
I'm thinking if we should just use virDomainChrSourceDefPtr for this. I
mean, if you take look at the vhost-user XML format it looks something
<source type='unix' path='/tmp/vhost2.sock' mode='client'/>
So we could have:
<source type='unix' path='/path/to/unix.socket' mode='client'/>
The advantage of this is that we can express other connection modes if
the pr-helper is ever going to support them (although, if you need to
pass FDs around, UNIX socket is the only way for you). Then again, I
think it follows what we have elsewhere. Also, if we go this way, we can
forbid any type='' but unix and mode='server'.
>>> while to use it with a dedicated daemon
>>> <disk ...>
>>> <pr mode='private'>/path/to/qemu-pr-helper</pr>
Ah, this breaks my design. I guess
<source type='unix' path='/path/to/qemu-pr-helper' mode='server'/>
is pure madness, isn't it?
More information about the libvir-list