As described in the vCloud Director Installation and Upgrade Guide, a vCloud Director server group requires use of a shared storage volume, which is referred to as the transfer server storage. This transfer server storage must be accessible to all vCloud Director servers, the cells, in the vCloud Director server group. You can use either NFS or another type of shared-storage file system configuration, such as iSCSI and OCFS, according to what is suitable for your organization's environment. Because NFS is easier to set up and configure than other shared-storage file systems, NFS is typically chosen as the shared storage volume for this purpose.

When NFS is used for the transfer server storage, certain configuration settings must set so that each vCloud Director cell in the vCloud Director server group can mount and use the NFS-based transfer server storage. The ability for each cell to mount the NFS-based location and use it as the transfer server storage is related to the user and group permissions settings that vCloud Director uses.

How vCloud Director uses the file system permissions on the transfer server storage location

For each vCloud Director cell in the vCloud Director server group:

• In standard cloud operations such as uploading items into the catalog, the vCloud Director cell's daemon writes files to and reads those files from the transfer server storage using the vcloud user, in the vcloud group. The vcloud user writes these files with umask 0077. The vcloud user and vcloud group are created on each vCloud Director server group member when the vCloud Director installer runs and installs the vCloud Director software on that server group member, as described in the vCloud Director 5.5 Installation and Upgrade Guide.
• When running the vCloud Director log data collector script, vmware-vcd-support, with its corresponding options to collect the logs from all of your vCloud Director system's cells in one operation and bundle the logs into a single .tar.gz file, the script writes the resulting .tar.gz file to a directory in the transfer server storage location using the userid of the user invoking the script. By default, when the vCloud Director software is installed on a member of a vCloud Director server group, the owner of that script is the root user on that server group member, and is the only user who has permissions to run that script.

As a result, if you want the ability to run the vmware-vcd-support script with its multi-cell options (--all --multicell) to collect the logs from all of your vCloud Director system's cells in one operation and bundle, the root user must have the ability to write to the transfer server storage location when it is mounted on each server group member. The first time the vmware-vcd-support script with the --all and --multicell options is run on one of the cells, the script creates a directory vmware-vcd-support in the directory that is mounted as the transfer server storage location, and subsequently writes the collected diagnostic log bundle in that vmware-vcd-support directory. For more information about the vmware-vcd-support script and running it with its multi-cell options, see the VMware knowledge base article Collecting diagnostic information for VMware vCloud Director (1026312).

 

Note: If you do not use the multi-cell options when running the vmware-vcd-support script, that is, you only run it to collect logs from one cell, the script creates a file in the directory on the cell where the script is run, and not in the transfer server storage location. In this situation, the root user does not need the ability to access the transfer server storage location.

• Obtaining the .tar.gz diagnostic log bundle that is written to the transfer server storage location by the vmware-vcd-support script when run with its multi-cell options requires the permission to read from the transfer server storage using scp and the root user. Because that diagnostic log bundle is written to the vmware-vcd-support directory in the transfer server storage location by the root user on the cell where the script is run, the root user must have read permission to be able to retrieve that file if you want to use the multi-cell options to collect the logs from all of the cells at once.

Requirements on the NFS server configuration

• The export list for the NFS server must allow for each server member in your vCloud Director server group to have read-write access to the shared location that is identified in the export list. This capability allows for the vcloud user to write files to and read files from the shared location for the purposes of the transfer server storage.
• The NFS server must allow read-write access to the shared location by the root system account on each server machine in your vCloud Director server group. This capability allows for collecting the logs from all cells at once in a single bundle using the vmware-vcd-support script with its multi-cell options. This requirement can be achieved by either:
  • Setting chmod 1777 permissions on the volume on the NFS server that is the shared location that is exported in the export list, or
  • Using no_root_squash in the NFS export configuration for this shared location

If you choose the chmod 1777 permissions method to achieve this requirement, the chmod 1777 permissions must be set on the volume on the NFS server machine. If you choose the no_root_squash method, the no_root_squash is set in the NFS export configuration.

Example: Export configurations in the NFS export file

Method for allowing read-write access to the shared location for two cells named vcd-cell1-IP and vcd-cell2-IP	Example settings on the NFS server
Use chmod 1777 method	Set chmod 1777 on vCDspace directory. Add a line like the following line to the /etc/exports file, where vcd-cell1-IP and vcd-cell2-IP are the IP addresses of the cells in a two-cell vCloud Director server group. 192.168.120.7/nfs/vCDspace vcd-cell1-IP(rw,sync,no_subtree_check) vcd-cell2-IP(rw,sync,no_subtree_check)
Use no_root_squash method	Add a line like the following line to the /etc/exports file, where vcd-cell1-IP is the IP address of a cell in your vCloud Director server group. 192.168.120.7/nfs/vCDspace vcd-cell1-IP(rw,sync,no_subtree_check,no_root_squash) vcd-cell2-IP(rw,sync,no_subtree_check)

 

• Make sure there is no space between each cell IP address and its immediate following left hand parenthesis in the export line.
• Use of the sync option in the export configuration prevents data corruption in the shared location if the NFS server reboots while the cells are writing data to the shared location.
• Use of the no_subtree_check option in the export configuration improves reliability when a subdirectory of a file system is exported.

Requirements at each vCloud Director server group member (cell)

Example: Mount configuration in the /etc/fstab file on each cell

192.168.120.7:/nfs/vCDspace /opt/vmware/vcloud-director/data/transfer nfs intr 0 0

Troubleshooting tips

• Ensure that each server in the vCloud Director server group is allowed to mount the NFS share by inspecting the export list for the NFS export.
• Ensure the mount is exported by running exportfs -a to re-export all NFS shares.
• Ensure NFS daemons are running on the server (running rpcinfo -p localhost or service nfs status).
• Ensure that the /opt/vmware/vcloud-director/data and /opt/vmware/vcloud-director/data/transfer directories on the vCloud Director server members are owned by the vcloud user and vcloud group and have the permissions 750. If you create these directories for mounting before running the vCloud Director installer, the directories might have root as the owner. In this case, the log will state the transfer folder is not writable, and you can use chmod and chown to change the permissions and ownership to vcloud:vcloud 750.

 

Considerations when planning to upgrade your vCloud Director installation to a later version

During an upgrade of a vCloud Director server group, you run the installation file for the upgraded version to upgrade all of the members of the vCloud Director server group. For convenience, some organizations choose to download the installation file for the upgrade to the transfer server storage location and run it from there, because all of the cells have access to that location. Because the root user must be used to run the upgrade installation file, if you want to use the transfer server storage location for running an upgrade, ensure the root user can run the upgrade installation file when you are performing the upgrade. An alternative method is to use cp to upgrade installation bin file to /tmp or another directory outside the NFS mount.