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