Cloud Director requirements when using NFS for the transfer server storage

Products

• VMware Cloud Director

Issue/Introduction

As described in the Cloud Director Installation and Upgrade Guide, a Cloud 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 Cloud Director servers, the cells, in the Cloud 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 Cloud Director cell in the Cloud 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 Cloud Director uses.

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

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

• In standard cloud operations such as uploading items into the catalog, the Cloud 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 Cloud Director server group member when the Cloud Director installer runs and installs the Cloud Director software on that server group member, as described in the Cloud Director 5.5 Installation and Upgrade Guide.
• When running the Cloud Director log data collector script, vmware-vcd-support, with its corresponding options to collect the logs from all of your Cloud 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 Cloud Director software is installed on a member of a Cloud 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 Cloud 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 Generate and View the VMware Cloud Director Logs.

 

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.

Environment

VMware Cloud Director

Resolution

Requirements on the NFS server configuration

These requirements allow for the ability of the Cloud Director to write files to and read files from an NFS-based transfer server storage location for both the standard cloud operations performed by the vcloud user and the multi-cell log collection by the root user via the vmware-vcd-support script and its multi-cell options.

• The export list for the NFS server must allow for each server member in your Cloud 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 Cloud 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

Assume the NFS server has IP address 192.168.120.7, and a directory created with the name vCDspace on the NFS server, which is to be used as the Cloud Director server group's transfer space:

/nfs/vCDspace

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 Cloud 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 Cloud 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)

 

Notes:

• 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 Cloud Director server group member (cell)

Each server group member must mount the NFS shared volume at the same mount point, typically /opt/vmware/vcloud-director/data/transfer.

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

Assume the NFS server has an IP address 192.168.120.7 and the directory vCDspace has been set up appropriately in the NFS server's /etc/exports file to be used as the Cloud Director transfer server storage. Add a line to the /etc/fstab file on each cell like the following line:

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

The last two entries (0 and 0) are the dump and fsckorder, and they must be set to zero. The intr option allows NFS requests to be interrupted if the server goes down or cannot be reached.
 

Port Requirements for NFS

Please see https://ports.esp.vmware.com/home/VMware-Cloud-Director for full up-to-date details on required ports. 

Troubleshooting tips

• Ensure that each server in the Cloud 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 Cloud 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 Cloud 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 Cloud Director installation to a later version

During an upgrade of a Cloud Director server group, you run the installation file for the upgraded version to upgrade all of the members of the Cloud 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.