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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
