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'?... Paolo (*) I might say, I have some reservations about it > IOW, just be as simple as an attribute "reservations=on|off" and we'll > decide the UNIX socket path, daemon forking, etc ourselves > > Regards, > Daniel > -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
