[libvirt] New QEMU daemon for persistent reservations

Paolo Bonzini pbonzini at redhat.com
Tue Oct 3 16:53:56 UTC 2017


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>

(for user mode) vs.

   <reservations enable='no'>

(fails if libiscsi || CAP_SYS_RAWIO || unpriv_sgio)?

Paolo




More information about the libvir-list mailing list