[libvirt] New QEMU daemon for persistent reservations

[Daniel P. Berrange]

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.

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

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|