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