Re: New QEMU daemon for persistent reservations

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 04/10/2017 10:28, Daniel P. Berrange wrote:
> On Tue, Oct 03, 2017 at 06:53:56PM +0200, Paolo Bonzini wrote:
>> On 03/10/2017 18:39, Daniel P. Berrange wrote:
>>> On Tue, Oct 03, 2017 at 06:35:03PM +0200, Paolo Bonzini wrote:
>>>> 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'?...
>>>
>>> Yes, if there's a choice of ways to manage reservations, we could
>>> reflect that as  'reservations=passthrough|emulated' or something
>>> like that. 
>>>
>>> I just don't think the concept of a helper program should be visible
>>> in the XML, as it is an impl detail that is totally QEMU specific and
>>> could conceivably change eg not even needed with unpriv_sgio,
>>
>> Not sure about that, the mpathpersist behavior is somewhat magic and I
>> am not really sure we should enable it by default, even with unpriv_sgio.
>>
>>> and if
>>> kernel were enhanced could be usable without needing a helper elsewhere
>>> too.
>>
>> It's an implementation detail for system mode, but not for user mode
>> (where ACLs on the socket are used to allow access to a privileged
>> operation).
>>
>> So:
>>
>>    <reservations enable='yes'/>
>>
>> (uses helper from global configuration if not a libiscsi drive) vs.
>>
>>    <reservations enable='yes'/>
>>      <source ... />
>>    </pr>
> 
> What do you mean by <source> here ?  If that's the chardev source I would
> really prefer not to have that visible.

Yes, it's the chardev source.  See above: in user mode, ACLs on the
socket are used to allow access to a privileged operation, so the source
has to be there.  It's not the most common mode, but it's the only one
that works for user mode and hardcoding a (possibly distro-specific)
socket path in libvirtd is worse IMO.

Paolo

>>
>> (for user mode) vs.
>>
>>    <reservations enable='no'>
>>
>> (fails if libiscsi || CAP_SYS_RAWIO || unpriv_sgio)?
> 
> Regards,
> Daniel
> 

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list



[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]
  Powered by Linux