<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 04/26/2012 05:53 PM, Kir Kolyshkin wrote:
<blockquote cite="mid:4F996F7E.302@openvz.org" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
On 04/23/2012 12:34 PM, Björn Lindgren wrote:
<blockquote cite="mid:4F9513FC.3030207@clearit.se" type="cite">
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<tt>Hi,<br>
<br>
I'm trying to setup NFS4 in a container but are having trouble
getting the rpc.idmapd daemon process to work.<br>
<br>
At startup rpc.idmapd tries to access two proc files which are
missing in the container.<br>
<br>
/proc/net/rpc/nfs4.nametoid/channel<br>
/proc/net/rpc/nfs4.idtoname/channel<br>
<br>
They are available on the host node through kernel module
nfsd.ko<br>
<br>
How do I configure OpenVZ to get these?<br>
<br>
Running CentOS 6.2 with 042stab053.5</tt><a
moz-do-not-send="true"
href="http://wiki.openvz.org/News/updates#Kernel_RHEL6_042stab053.5_released"><span
class="toctext"></span></a><br>
</blockquote>
<br>
NFS server (and client) inside container is fully supported, for
it to work you need to<br>
(1) have kernel module nfsd loaded before starting CT<br>
(2) have feature nfsd turned on for CT<br>
<br>
Both of this is described at <a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="http://wiki.openvz.org/NFS_server_inside_container">http://wiki.openvz.org/NFS_server_inside_container</a><br>
<br>
Having said that, only NFS v2 and NFS v3 are supported inside CT.<br>
<br>
We are currently working on making NFS v4 work inside containers,
but we do it for mainline<br>
kernels rather than in RHEL6 kernel. So whenever we will port
OpenVZ to any of 3.3 kernels,<br>
it will most probably have NFS v4 support. RHEL7-based OpenVZ
kernel will have it, too.<br>
<br>
Is there any specific reason why you need NFS v4 and not v3?<br>
</blockquote>
<br>
Thanks for clarifying the status of NFSv4 support in OpenVZ.<br>
<br>
We are currently using NFSv3 and some of our applications are
dependent on the file locking feature (fcntl/fcntl64 syscall) and we
have had troubles getting remote locking to work correctly between
CT and the NFS server. Sometimes it do work, but suddenly it stop
working or stop working after a reboot of the CT. Looks like it is
related to the out-of-band communication between the CT and
rpc.lockd on the NFS server, or in the locking functionality in the
kernel space in VE or NFS server.<br>
<br>
We have found an work-around to the issue by resort to enforcing
local locking with mount option "nolock", this enables the
applications to run on top of NFSv3 in the VE.<br>
<br>
Regards,<br>
Bjorn<br>
<br>
</body>
</html>