Re: [libvirt] New QEMU daemon for persistent reservations

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)?