To provide temporary storage for uploads, downloads, and catalog items that are published or subscribed externally, you must make an NFS or other shared storage volume accessible to all servers in a vCloud Director server group.
When NFS is used for the transfer server storage, you must configure each vCloud Director cell in the vCloud Director server group to mount and use the NFS-based transfer server storage. You need specific user and group permissions to configure each cell to mount the NFS-based location and use it as the transfer server storage.
- During transfers, uploads and downloads occupy this storage. When the transfer finishes, the uploads and downloads are removed from the storage. Transfers that make no progress for 60 minutes are marked as expired and cleaned up by the system. Because transferred images can be large, it is a good practice to allocate at least several hundred gigabytes for this use.
- Catalog items in catalogs that are published externally and for which caching of the published content is enabled, occupy this storage. Items from catalogs that are published externally but do not enable caching do not occupy this storage. If you enable organizations in your cloud to create catalogs that are published externally, you can assume that hundreds or even thousands of catalog items require space on this volume. The size of each catalog item is about the size of a virtual machine in a compressed OVF form.
How vCloud Director Uses the File System Permissions on the Transfer Server Storage Location
- In standard cloud operations such as uploading items into the catalog, the daemon of the vCloud Director cell writes files to and reads those files from the transfer server storage using the vcloud user in the vcloud group. The vcloud user writes the files with
umask 0077. When the vCloud Director installer runs and installs the vCloud Director software on a server group member, it also creates the vcloud user and vcloud group.
- The vCloud Director log data collector script
vmware-vcd-supportcan collect the logs from all your vCloud Director cells in one operation and bundle the logs into a single tar.gz file. When you run the script, it writes the resulting tar.gz file to a directory in the transfer server storage location using the user ID of the user invoking the script. By default, the only user who has permissions to run the script is the root user.
- The root user on the cell runs the script that writes the tar.gz file to the vmware-vcd-support directory in the transfer server storage location. If you want to use the multi-cell options to collect the logs from all the cells at once, the root user must have a read permission to retrieve the tar.gz diagnostic log bundle.
Requirements for Configuring the NFS Server
- 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 the vcloud user to write files to and read files from the shared location.
- The NFS server must allow read-write access to the shared location by the root system account on each server 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-supportscript with its multi-cell options. You can meet this requirement by using
no_root_squashin the NFS export configuration for this shared location.
no_root_squashmethod. You must add a line to the /etc/exports file.
192.168.120.7/nfs/vCDspace vCD_Cell1_IP_Address(rw,sync,no_subtree_check,no_root_squash) vCD_Cell2_IP_Address(rw,sync,no_subtree_check)
There must be no space between each cell IP address and its immediate following left parenthesis in the export line. If the NFS server reboots while the cells are writing data to the shared location, the use of the
sync option in the export configuration prevents data corruption in the shared location. The use of the
no_subtree_check option in the export configuration improves reliability when a subdirectory of a file system is exported.
Each server in the vCloud Director server group must be allowed to mount the NFS share by inspecting the export list for the NFS export. You export the mount by running
exportfs -a to re-export all NFS shares. NFS daemons
rpcinfo -p localhost or
service nfs status must be running on the server.
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 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 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, you must ensure that the root user can run the upgrade installation file when you are performing the upgrade. If you cannot run the upgrade as the root user, the file must be copied to another location where it can be run as the root user, for example, another directory outside the NFS mount.