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