[libvirt] New QEMU daemon for persistent reservations

[Paolo Bonzini]

On 03/10/2017 18:17, Daniel P. Berrange wrote:
> On Tue, Oct 03, 2017 at 06:07:53PM +0200, Paolo Bonzini wrote:
>> Yes, but OTOH if libvirtd starts the daemon, nobody cares about the
>> source type, so perhaps
>>
>>    <pr driver='helper' mode='shared'>
>>      <source ... />
>>    </pr>
>>
>> (mandatory source) vs.
>>
>>    <pr driver='helper' mode='private'>
>>      <path>/path/to/qemu-pr-helper</path>
>>    </pr>
>>
>> (optional path, default from global configuration) vs.
>>
>>    <pr driver='passthrough'/>
>>
>> (no helper)?
> 
> I tend to think we should not expose the concept of a 'helper' at all in
> the XML. The fact that QEMU has a separate binary to do this is really an
> internal implementation detail due to the need for privilege separation/
> elevation.
> 
> Libvirt should just do the right thing running the helper with a suitable
> configuration when needed, just like we run the TAP device helper when
> needed.

I agree we don't need the helper path.  I am not sure about the socket
path, but maybe that could also be in qemu.conf.  However,
reservations='off' doesn't always make sense:

1) if you have appropriate privileges (via unpriv_sgio on distros that
have it, or capabilities, or just because you're using the libiscsi
driver) you will be able to access them anyway;

2) if you're on a multipath device, you need to use the helper anyway to
get the right semantics;

And later on we might have other ways to implement persistent
reservations in QEMU.  So while I'm not a big fan(*) of the
driver='helper' moniker, I don't think an attribute is enough.  Maybe
driver='external'?...

Paolo

(*) I might say, I have some reservations about it

> IOW, just be as simple as an attribute  "reservations=on|off" and we'll
> decide the UNIX socket path, daemon forking, etc ourselves
> 
> Regards,
> Daniel
>