Re: [libvirt] New QEMU daemon for persistent reservations
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>
>> </disk>
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
like this:
<interface type='vhostuser'>
<mac address='52:54:00:3b:83:1b'/>
<source type='unix' path='/tmp/vhost2.sock'
mode='client'/>
<model type='virtio'/>
<driver queues='5'/>
</interface>
http://libvirt.org/formatdomain.html#elementVhostuser
So we could have:
<disk>
<pr>
<source type='unix' path='/path/to/unix.socket'
mode='client'/>
</pr>
</disk>
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>
>> </disk>
Ah, this breaks my design. I guess
<disk>
<pr>
<source type='unix' path='/path/to/qemu-pr-helper'
mode='server'/>
</pr>
</disk>
is pure madness, isn't it?
Michal