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