On 12/21/18 6:16 AM, Ján Tomko wrote: > On Tue, Dec 18, 2018 at 03:03:14PM -0500, John Ferlan wrote: >> Modify the generation of the command line to allow usage of a >> new XML pool source directory "mount_opts" in order to allow (for >> instance) starting an NFS pool with specific mount options. >> > > We should not try to pretend to support passing arbitrary options via XML. > > See the thread from the last time this was proposed: > https://www.redhat.com/archives/libvir-list/2014-May/msg00938.html > https://www.redhat.com/archives/libvir-list/2014-June/msg00188.html > > Jano sigh... But in a way we already do allow passing arbitrary options via XML in the form of <os> {<initarg>, <initenv>, and/or <cmdline>} </os> and/or <bootloader_args>. There's also a free form <lease> <lockspace> and/or <key> although that's a bit different. In Daniel's response: https://www.redhat.com/archives/libvir-list/2014-June/msg00188.html "... The only way I'd support passthrough is if it were done in he same way as QEMU passthrough where it used a separate XML namespace which was clearly marked "use at your own risk, unsupported if it breaks". " the "unsupported" part would seem to be 'undesirable' at least w/r/t what's being asked for from the (private) bz. The request is "Shouldn't the security options for nodev,nosuid or even noexec be available via KVM?" (as it relates to the 'mount ... -o <options>' command). So if we say unsupported, then for those customers that desire perhaps higher security I would think/believe that they would want something that is supported. TBH: The XML namespace option used by QEMU commandline args and for LXC sharenet, shareipc, & shareuts options would seem to be a bit of overkill for what amounts to a more "bounded" operation trying to add free form (to a degree) options for a specific storage backend command. This isn't some new option that we haven't had the time to implement in libvirt for QEMU domains - it's arguments to an OS command. I'll dig a little more on this, but figured I'd throw this out there as something to consider. I guess I'm not seeing the overall value of adding yards of code. Then there's the quandary of this really is for storage source, but following the domain model I think it'd look odd to have it as the same level as target too. How would it be handled if someone wanted some sort of name/value for <target>? Right now there's two known consumers - netfs for the mount -o args and rbd to allow changing the defaults of (currently) 3 name/value config arguments. Plus perhaps a bunch of debugging uses that weren't defined. John -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
