[...]
For the general nosuid, nodev flags, I think we can do something like we have for the <features/> element in the domain XML.
So that means to me that every option currently possible in mount would need to be listed. Doesn't that feel excessive? Not that mount changes that often, but I would think it's awfully painful to take that route. Especially for some of the "more complicated" mount options.
The mount command options are a tiny, trivial set compared to QEMU command line options. The goal here is not to have simple libvirt code, rather is to have portable & simple application code. Libvirt exists to provide an abstraction layer over OS specific commands line "mount" which can have different syntax on each OS. eg FreeBSD mount command options may differ from Linux mount command options.
And this last line is the biggest concern over providing or "by default" adding "-o nosuid,nodev,noexec" for NFS mount command line. Secondary to that is the "what if" by doing so we break some existing configuration for some reason that was making use of a pool volume in some really strange manner that we didn't expect just because one of those mount options wasn't set by default. Not that it seems the 3 mentioned ones would cause such pain, but the precedence of adding options by default in general.
I'm not suggesting implementing support for every single mount option though. Only those that we actually have a compelling reason to support, just as we've not implemented every single QEMU arg.
Understood. Of course as soon a couple are implemented, someone else's favorite is desired, etc. It's the picking and choosing which are compelling enough to support vs. just allowing or even providing a supportable mechanism to allow arbitrary command options vs. implementing "some" and leaving the rest to be added via namespace. Right now the "some" are: nfsvers='n' [add only if new XML exists] nosuid nodev noexec and maybe additionally 'ro' if [new] <readonly/> was set. Just trying to get all the "parameters" set before starting a v3... John [...]