I have around a week's worth of notes that haven't been cleaned up into proper writeups yet, so let's catch up a bit...
I confirmed on IRC that nobody is aware of any actual NFSv4 use out in the wild yet, and that NFSv2 is obsolete (2 gigabyte file size limit) and I can skip that.
So, next we go back to the "Laptop/KVM/busybox" test context and fire up the NFS mount at the KVM level. This should work, and it proves that the mount is making it through a non-local routing (more than one hop).
Note that I previously failed to get NFSv2 working under the busybox container, but at the time I didn't know what subsystems that involved so I didn't have a clear idea of _what_ wasn't working. Now I have two specific layers to debug, bypassing portmap, using an IPv4 number addressing to avoid DNS lookups, no locking, v3. So this time we're going to force it to fail in a way that there's some chance of figuring out WHAT doesn't work, and have the closest possible "does work" variant.
mkdir nfstest mount -t nfs -o ro,port=9999,mountport=9999,nolock,nfsvers=3,udp \ 10.1.1.1:/home/landley/test nfstest
Except that the NFS mount isn't working at the KVM level. The problem turns out to be no "nfs.mount" command for mount to hand off to.
Most mount types don't actually need one (you feed four strings to the mount system call: the driver name for the filesystem, the filesystem identifier string ala "/dev/hda1" or "188.8.131.52:/blah", the path to the directory to mount it on, and the "-o options" string of comma separated thingies. And this works fine for -t cifs (which needs a "user=blah,pass=blah" option string), and for -t p9, but of course not for NFS which is _special_. NFS needs its own special mount program that fills out structures and hands them off to the kernel. Even though you can specify everything it needs to know on the command line, and it has a whole SERVER in the kernel, it needs a special userspace program to digest that command line information into a different format than other filesystems use. Sigh.
aptitude install nfs-client
Something somewhere is apparently trying to do a reverse DNS lookup, which is a bad sign, but when it times out and fails (laptop not currently connected to the net) the mount works.
Now we try the mount from the container's root filesystem to see the failure, and it... times out? That's not the same failure I was getting last time...
Ok, back up. Let's chroot into the busybox root filesystem from the KVM context (which should work) instead of lxc-console (which shouldn't)... and the same timeout. It doesn't even work using the busybox mount command outside of the chroot. (It's a statically linked binary, I should be able to use it from anywhere. I can mount non-nfs filesystems with busybox on the KVM system, but not NFS.)
Investigate a bit, and it looks like busybox only supports NFSv2. And the server I'm using only supports NFSv3. And the funky "set up magic structures and syscall/ioctl them into the kernel" thing means that you need to re-implement the magic helper code for the new NFS version. Isn't that special?
I hate NFS.