Secure, reliable operation of vCloud Director depends on a secure, reliable network that supports forward and reverse lookup of hostnames, a network time service, and other services. Your network must meet these requirements before you begin installing vCloud Director.

The network that connects vCloud Director servers, the database server, vCenter servers, and the associated vCloud Networking and Security or NSX for vSphere components, must meet several requirements:

IP addresses

Each vCloud Director server must support two different SSL endpoints. One endpoint is for the HTTP service. The other is for the console proxy service. These endpoints can be separate IP addresses, or a single IP address with two different ports. You can use IP aliases or multiple network interfaces to create these addresses. You cannot use the Linux ip addr add command to create the second address.

Console Proxy Address

The IP address configured as the console proxy endpoint must not be located behind an SSL-terminating load balancer or reverse proxy. All console proxy requests must be relayed directly to the console proxy IP address.

Network Time Service

You must use a network time service such as NTP to synchronize the clocks of all vCloud Director servers, including the database server. The maximum allowable drift between the clocks of synchronized servers is 2 seconds.

Server Time Zones

All vCloud Director servers, including the database server, must be configured to be in the same time zone.

Hostname Resolution

All host names that you specify during installation and configuration must be resolvable by DNS using forward and reverse lookup of the fully qualified domain name or the unqualified hostname. For example, for a host named vcloud.example.com, both of the following commands must succeed on a vCloud Director host:

nslookup vcloud
nslookup vcloud.example.com

In addition, if the host vcloud.example.com has the IP address 192.168.1.1, the following command must return vcloud.example.com:

nslookup 192.168.1.1

Transfer Server Storage

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, 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. See http://kb.vmware.com/kb/2086127 for details. Each member of the server group must mount this volume at the same mountpoint, typically /opt/vmware/vcloud-director/data/transfer. Space on this volume is consumed in two ways:

  • Transfers (uploads and downloads) occupy this storage for as long as the transfer is in progress, and are removed when the transfer is complete. 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 enable caching of published content occupy this storage for as long as they exist. (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, it is safe to assume that hundreds or even thousands of catalog items will need space on this volume, and that each catalog item will be the size of a virtual machine in compressed OVF form.

Note:

If possible, the volume you use for transfer server storage should be one whose capacity can be easily expanded.