[libvirt] New QEMU daemon for persistent reservations
Daniel P. Berrange
berrange at redhat.com
Tue Oct 3 16:39:12 UTC 2017
On Tue, Oct 03, 2017 at 06:35:03PM +0200, Paolo Bonzini wrote:
> On 03/10/2017 18:17, Daniel P. Berrange wrote:
> > On Tue, Oct 03, 2017 at 06:07:53PM +0200, Paolo Bonzini wrote:
> >> Yes, but OTOH if libvirtd starts the daemon, nobody cares about the
> >> source type, so perhaps
> >>
> >> <pr driver='helper' mode='shared'>
> >> <source ... />
> >> </pr>
> >>
> >> (mandatory source) vs.
> >>
> >> <pr driver='helper' mode='private'>
> >> <path>/path/to/qemu-pr-helper</path>
> >> </pr>
> >>
> >> (optional path, default from global configuration) vs.
> >>
> >> <pr driver='passthrough'/>
> >>
> >> (no helper)?
> >
> > I tend to think we should not expose the concept of a 'helper' at all in
> > the XML. The fact that QEMU has a separate binary to do this is really an
> > internal implementation detail due to the need for privilege separation/
> > elevation.
> >
> > Libvirt should just do the right thing running the helper with a suitable
> > configuration when needed, just like we run the TAP device helper when
> > needed.
>
> I agree we don't need the helper path. I am not sure about the socket
> path, but maybe that could also be in qemu.conf. However,
> reservations='off' doesn't always make sense:
>
> 1) if you have appropriate privileges (via unpriv_sgio on distros that
> have it, or capabilities, or just because you're using the libiscsi
> driver) you will be able to access them anyway;
>
> 2) if you're on a multipath device, you need to use the helper anyway to
> get the right semantics;
>
> 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, and if
kernel were enhanced could be usable without needing a helper elsewhere
too.
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 :|
More information about the libvir-list
mailing list