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
