One of the new features introduced in vCloud Director 5.1.2 is cell server support on the RHEL 6 Update 3 platform , cell server support on RHEL 5 Update 7 was quietly removed in the recent past – verify the version of RHEL in your environment using cat /etc/issue). When migrating your cell server(s) to RHEL 6.3, particularly from 5.x, you may run into a few issues.
The first issue is the lack of the libXdmcp package (required for vCD installation) which was once by default in RHEL 5 versions.this can be verified at the RHEL 6 CLI with the following command line:
yum search libXdmcp
or
yum list |grep libXdmcp
The package can be installed by inserting/mounting the RHEL 6 DVD or iso copying the appropriate libXdcmp file to /tmp/ and running either of the following commands:
yum install /tmp/libXdmcp-1.0.3-1.el6.x86_64.rpm
or
rpm -i /tmp/libXdmcp-1.0.3-1.el6.x86_64.rpm
Next up is the use of Windows Server 2012 (or Windows 8) as NFS for vCloud Transfer Server Storage in conjunction with the newly supported RHEL 6.3. Creating the path and directory for the Transfer Server Storage is performed during the initial deployment of vCloud Director using the command mkdir -p /opt/vmware/vcloud-director/data/transfer. When mounting the NFS export for Transfer Server Storage (either manually or via /etc/fstab f.q.d.n:/vcdtransfer/opt/vmware/vcloud-director/data/transfer nfs rw 0 0 ), the mount command fails with error message mount.nfs: mount system call failed.you can encounter this particular issue in one particular environment and my search turned up Red Hat Bugzilla – Bug 796352. In the bug documentation, the problem is identified as follows:
On Red Hat Enterprise Linux 6, mounting an NFS export from a Windows 2012 server failed due to the fact that the Windows server contains support for the minor version 1 (v4.1) of the NFS version 4 protocol only, along with support for versions 2 and 3. The lack of the minor version 0 (v4.0) support caused Red Hat Enterprise Linux 6 clients to fail instead of rolling back to version 3 as expected. This update fixes this bug and mounting an NFS export works as expected.
Further down in the article, Steve Dickson outlines the workarounds:
mount -o v3 # to use v3
or
Set the ‘Nfsvers=3′ variable in the “[ Server “Server_Name” ]”
section of the /etc/nfsmount.conf file
An Example will be:
[ Server “nfsserver.lab.local” ]
Nfsvers=3
The first option works well at the command line but doesn’t lend itself to /etc/fstab syntax so the second option which is to establish a host name and NFS version in the /etc/nfsmount.conf file seams like the better option. With this method, the mount is attempted as called for in /etc/fstab and by reading /etc/nfsmount.conf, the mount operation succeeds as desired instead of failing at negotiation.
There is a third option which would be to avoid the use of /etc/fstab and /etc/nfsmount altogether and instead establish a mount -o v3 command in /etc/rc.local which is executed at the end of each RHEL boot process. This may work, but not of the best methods.
Last but not least, install the kernel update (Red Hat reports as being fixed in kernel-2.6.32-280.el6).
