On Mon, Oct 19, 2015 at 5:13 PM, John Spray <jspray@xxxxxxxxxx> wrote: >> If you try this, send feedback. >> OK, got this up and running. I've shared the kernel/qemu/nfsutils packages I built here: https://copr.fedoraproject.org/coprs/jspray/vsock-nfs/builds/ (at time of writing the kernel one is still building, and I'm running with ganesha out of a source tree) Observations: * Running VM as qemu user gives EPERM opening vsock device, even after changing permissions on the device node (for which I guess we'll want udev rules at some stage) -- is there a particular capability that we need to grant the qemu user? Was looking into this to make it convenient to run inside libvirt. * NFS writes from the guest are lagging for like a minute before completing, my hunch is that this is something in the NFS client recovery stuff (in ganesha) that's not coping with vsock, the operations seem to complete at the point where the server declares itself "NOT IN GRACE". * For those (like myself) unaccustomed to running ganesha, do not run it straight out of a source tree and expect everything to work, by default even VFS exports won't work that way (mounts work but clients see an empty tree) because it can't find the built FSAL .so. You can write a config file that works, but it's easier just to make install it. * (Anecdotal, seen while messing with other stuff) client mount seems to hang if I kill ganesha and then start it again, not sure if this is a ganesha issue or a general vsock issue. Cheers, John -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
