Configuring BOSH Director on vSphere

This topic describes how you can configure the BOSH Director tile for VMware vSphere.

You can also perform the procedures in this topic using the Tanzu Operations Manager API. For more information, see Using the Tanzu Operations Manager API.

If you are installing VMware Tanzu Kubernetes Grid Integrated Edition (TKGI) on vSphere with NSX-T integration, follow the instructions in Configuring BOSH Director with NSX-T for TKGI instead of performing the procedure described in this topic.

After you complete this procedure, follow the configuration instructions for the runtime that you choose to install:

To install VMware Tanzu Application Service for VMs (TAS for VMs), see the TAS for VMs documentation.
To install TKGI, see the TKGI documentation.

For more information about VMware Tanzu Operations Manager runtimes, see Installing Runtimes.

Prerequisite

Before you begin this procedure, you must complete all steps in Deploying Tanzu Operations Manager to vSphere.

Step 1: Log into Tanzu Operations Manager

In a web browser, navigate to the fully qualified domain of your Tanzu Operations Manager.
Log in to Tanzu Operations Manager. To log in, see Log In to Tanzu Operations Manager for the first time.

Step 2: Configure vCenter

Click the BOSH Director for vSphere tile.
Click vCenter Config. Configure the one or more vCenters that host your Tanzu Operations Manager foundation, as described in the following steps.
Complete the following fields on the vCenter Config pane:
- Name: A name that you provide for your vCenter configuration. This field is used to identify the datacenter configuration in Tanzu Operations Manager if you are configuring multiple datacenters.
- vCenter Host: The hostname of the vCenter that manages ESXi/vSphere.
- vCenter Username: A vCenter username with create and delete privileges for virtual machines (VMs) and folders.
- vCenter Password: The password for the vCenter user specified above.
- Datacenter Name: The name of the datacenter as it appears in vCenter.
- Virtual Disk Type: The Virtual Disk Type to provision for all VMs. For guidance on selecting a virtual disk type, see vSphere virtual disk types.
  
  Datastores do not support whitespace characters in their names. Including whitespace characters in datastore names causes an error.
- Ephemeral Datastore Names (comma delimited): The names of the datastores that store ephemeral VM disks deployed by Tanzu Operations Manager.
- Ephemeral Datastore Cluster Names (comma delimited): The names of the datastore clusters that store ephemeral VM disks deployed by Tanzu Operations Manager. If Datastore Names and Datastore Clusters are specified, both are considered for disk placement. If you deactivate Storage DRS for a datastore cluster, the BOSH CPI ignores the cluster. For more information, see Activate and deactivate storage DRS. As of Tanzu Operations Manager v3.0.11+LTS-T, datastore clusters located in folders can be referenced using the full path to the datastore cluster. Folder names must be followed by a forward slash character.
- Persistent Datastore Names (comma delimited): The names of the datastores that store persistent VM disks deployed by Tanzu Operations Manager.
- Persistent Datastore Cluster Names (comma delimited): The names of the datastore clusters that store persistent VM disks deployed by Tanzu Operations Manager. If Datastore Names and Datastore Clusters are specified, both are considered for disk placement. If you deactivate Storage DRS for a datastore cluster, the BOSH CPI ignores the cluster. For more information, see Activate and deactivate storage DRS. As of Tanzu Operations Manager v3.0.11+LTS-T, datastore clusters located in folders can be referenced using the full path to the datastore cluster. Folder names must be followed by a forward slash character.
  
  A datastore cluster is a collection of datastores with shared resources and a shared management interface.
To configure networking, complete the vCenter Config fields described below:
- Standard vCenter Networking: This is the default option when upgrading Tanzu Operations Manager. If you select this option, you do not need to configure the NSX-T Networking fields below.
  
  If you intend to deploy TKGI using Flannel as the CNI, select this option to configure the BOSH Director. Do not choose NSX-T Networking. When you configure the TKGI tile later on, you configure Flannel as the container network interface (CNI).
  
  If you intend to deploy TKGI with NSX-T, see the TKGI documentation.
  
  When deploying on VMC (vSphere on AWS), you must select Standard vCenter Networking. NSX-T Networking does not work with VMC.
- NSX-T Networking: Select this option to allow NSX-T network virtualization for non-TKGI products such as TAS for VMs. This virtualization allows you to configure component load balancing and security in the Resource Config pane of the BOSH Director tile. For more information, see Step 10: Resource Config pane.
  
  Configure NSX networking by entering the following information:
  - NSX Mode: Select either NSX-V or NSX-T.
  - Use NSX-T Policy API: Select whether to use the NSX-T Policy API instead of the Manager API when placing VMs in NSX-T groups and server pools. You can use NSX-T groups or server pools to designate VMs as load balancer back ends. This feature requires NSX-T Data Center v3.0 or later.
  - Use NSX-T Policy API Migration Mode: Activate this check box to activate migration mode on the CPI. This allows you to transition infrastructure created with the Management API over to the Policy API.
    
    Note The NSX-T Policy API is no longer experimental as of Tanzu Operations Manager v2.10.17. Do not select the NSX-T Policy API option if you are using an earlier Tanzu Operations Manager version.
  - NSX Address: The address of the NSX Manager.
  - NSX-T Authentication: Select how BOSH Director authenticates to the NSX Manager:
    - Local User Authentication authenticates with a username and password.
      - For this option, fill in the NSX Username and NSX Password fields. Specify an NSX user with Enterprise Administrator privileges.
    - Certificate Authentication authenticates with a certificate and private key.
      - For this option, fill in the NSX Manager Principal Identity Certificate and NSX Manager Principal Identity Private Key fields.
      Note Certificate Authentication for the NSX-T Policy API was added in Tanzu Operations Manager v2.10.40. You must use Local User Authentication if you are using an earlier Tanzu Operations Manager version.
  - NSX CA Cert: A CA certificate in PEM format that establishes a secure connection to the NSX server before the BOSH Director authenticates to the NSX Manager. If the NSX Manager generated a self-signed certificate, use the following command to retrieve the CA certificate using OpenSSL:
```
openssl s_client -showcerts -connect NSX-MANAGER-ADDRESS:443 < /dev/null 2> /dev/null | openssl x509
```
    Where NSX-MANAGER-ADDRESS is the address of the NSX manager.
Configure the following folder names:
- VM Folder: The vSphere datacenter folder where Tanzu Operations Manager places VMs. Enter [YOUR-DEPLOYMENT]_vms where YOUR-DEPLOYMENT corresponds to a descriptive name for your deployment. For example, my_pcf_vms.
- Template Folder: The vSphere datacenter folder where Tanzu Operations Manager places templates. Enter [YOUR-DEPLOYMENT]_templates. For example, my_pcf_templates.
- Disk path Folder: The vSphere datastore folder where Tanzu Operations Manager creates attached disk images. You must not nest this folder. Enter [YOUR-DEPLOYMENT]_disk. For example, my_pcf_disk.
After initial deployment, you cannot edit folder names.
Click Save.
(Optional) Click Add vCenter Config toward the top of the form to configure additional vCenters. Once you click Save, your multiple vCenter Configs are listed in the vCenter Configs pane. For more information about multiple vCenter configs, see Managing multiple data centers.

Step 3: Director Config pane

To configure the Director Config pane:

Click Director Config.
Enter one or more NTP servers in the NTP Servers (comma delimited) text box. For example, us.pool.ntp.org.
- The NTP server configuration updates only after VM recreation. If you modify the value of this field, select the Recreate VMs deployed by the BOSH Director check box to re-create your BOSH Director-deployed VMs and update the NTP server configuration. If you have any service tiles installed, ensure that the Recreate All Service Instances errand runs for each service tile.
Leave the Bosh HM Forwarder IP Address text box blank. BOSH-reported component metrics are available in Loggregator Firehose by default. If you continue to use the BOSH HM Forwarder to consume these component metrics, you might receive duplicate data.
Select the Enable VM Resurrector Plugin check box to enable the BOSH Resurrector functionality and increase your runtime availability. If you intend to install TAS for VMs, see Using the BOSH Resurrector for more information about the Resurrector plug-in.
If you want to collect detailed metrics from BOSH-managed VMs, select the Enable System Metrics check box. For a list of metrics that the System Metrics Agent collects from BOSH-managed VMs, see System Metrics Agent on GitHub. When you select this check box, ensure that the System Metrics Scraper is able to connect on port 53035 to all BOSH-managed VMs.
Select Enable Post Deploy Scripts to run a post deployment script after deployment. This script allows the job to execute additional commands against a deployment.

If you intend to install VMware Tanzu Kubernetes Grid Integrated Edition (TKGI), you must enable post-deploy scripts.

Click Recreate VMs deployed by the BOSH Director to force BOSH to recreate BOSH-deployed VMs on the next deployment. This process does not recreate the BOSH Director VM or destroy any persistent disk data. This check box is cleared automatically after a successful redeployment.
Select Recreate BOSH Director VMs to force the BOSH Director VM to be recreated on the next deploy. This process does not destroy any persistent disk data. This check box is cleared automatically after a successful redeployment.
Select Recreate All Persistent Disks to force BOSH to migrate and recreate persistent disks for the BOSH Director and all tiles. This process does not destroy any persistent disk data. This check box is cleared automatically after a successful redeployment.
Select Enable bosh deploy retries to instruct Tanzu Operations Manager to retry failed BOSH operations up to five times.
Select Skip Director Drain Lifecycle to prevent drain scripts from running when the BOSH Director is recreated.
Select Store BOSH Job Credentials on tmpfs (beta) to store credentials for BOSH jobs on temporary file storage (tmpfs) memory, rather than on disk. You must re-create all BOSH-deployed VMs for this setting to take effect.
Select Keep Unreachable Director VMs to preserve BOSH Director VMs after a failed deployment for troubleshooting purposes.
(Optional) Modify the Director Workers value, which sets the number of workers available to run BOSH Director tasks. The value in this text box defaults to 5.
(Optional) Max Threads sets the maximum number of threads that the BOSH Director can run simultaneously. VMware recommends that you leave the text box blank to use the default value, unless doing so results in rate limiting or errors on your IaaS.
(Optional) To add a custom URL for your BOSH Director, enter a valid hostname in the Director Hostname text box. You can also use this text box to configure a load balancer in front of your BOSH Director. For more information, see How to set up a Load Balancer in front of Tanzu Operations Manager Director.
(Optional) To set a custom banner that users see when you log in to the BOSH Director using SSH, enter text in the Custom SSH Banner text box.
(Optional) Enter your comma-separated custom Identification Tags. For example, iaas:foundation1, hello:world. You can use the tags to identify your foundation when viewing VMs or disks from your IaaS.
For Certificate Duration Overrides, you can choose whether certificates generated within Tanzu Operations Manager and CredHub use the default duration specified for the certificate, or a custom duration value that you specify.
- Off: Use this option to use default duration for certificates created by all products.
- On: Use this option to set a value to override the duration for certificates created by all products. If a product creates a certificate with a longer duration than the value you set, the longer duration is used.
  1. CA Certificate Duration (days): Enter the number of days for which CA certificates are valid.
  2. Leaf Certificate Duration (days): Enter the number of days for which leaf certificates are valid. This value must be less than or equal to the CA certificate duration.
  After you set a certificate duration override, you must take additional steps to apply the setting to all certificates. For more information, see Overriding Duration for Certificates.
Select HM Pager Duty Plugin to enable Health Monitor integration with PagerDuty.
- Service Key: Enter your API service key from PagerDuty.
- HTTP Proxy: Enter an HTTP proxy for use with PagerDuty.
Select HM Email Plugin to enable Health Monitor integration with email.
- Host: Enter your email host name.
- Port: Enter your email port number.
- Domain: Enter your domain.
- From: Enter the address for the sender.
- Recipients: Enter a comma-separated list of addresses of intended recipients.
- Username: Enter the user name for your email server.
- Password: Enter the password for your email server.
- Enable TLS: Select this check box to enable Transport Layer Security to the email host.
For CredHub Encryption Provider, you can choose whether BOSH CredHub stores its encryption key internally on the BOSH Director and CredHub VM, or in an external hardware security module (HSM). The HSM option is more secure.

Before configuring an HSM encryption provider in the Director Config pane, you must follow the procedures and collect information described in Preparing CredHub HSMs for configuration.

After you deploy Tanzu Operations Manager with an HSM encryption provider, you cannot change BOSH CredHub to store encryption keys internally.
- Internal: Use this option for internal CredHub key storage. This option is selected by default and requires no additional configuration.
- Luna HSM: Use this option to use a SafeNet Luna HSM as your permanent CredHub encryption provider, and fill in the following fields:
  
  If you use multiple HSM hosts, you must use the Tanzu Operations Manager API to set or update the HSM configuration. For more information, see Updating a staged director's properties in the Tanzu Operations Manager API documentation.
  1. Encryption Key Name: Any name to identify the key that the HSM uses to encrypt and decrypt the CredHub data. Changing this key name after you deploy Tanzu Operations Manager can cause service downtime.
  2. Provider Partition: The partition that stores your encryption key. Changing this partition after you deploy Tanzu Operations Manager could cause service downtime. For this value and the ones that follow, use values gathered in Preparing CredHub HSMs for configuration.
  3. Provider Partition Password
  4. Partition Serial Number
  5. Provider Client Certificate: The certificate that validates the identity of the HSM when CredHub connects as a client.
  6. Provider Client Certificate Private Key
  7. HSM Host Address
  8. HSM Port Address: If you do not know your port address, enter 1792.
  9. HSM Certificate: The certificate that the HSM presents to CredHub to establish a two-way mTLS connection.
Click Blobstore Location to configure the blobstore as either an internal server or an external endpoint.

After you deploy the BOSH Director, only Tanzu Operations Manager users in Advanced Mode can change the blobstore location. For more information, see Tanzu Operations Manager Fields That Lock On Deploy.
- Internal: Use this option for an internal blobstore. No additional configuration is required.
- S3 Compatible Blobstore: Use this option for an external S3-compatible endpoint. To create an S3 bucket, follow the procedures in Sign up for Amazon S3 and Creating a Bucket in the AWS documentation. When you have created an S3 bucket, configure the following fields:
  1. S3 Endpoint:
    1. If you are using a public S3 endpoint:
      1. Locate the endpoint for your region. To find the endpoint, see the Amazon Simple Storage Service (S3) table in Regions and Endpoints in the AWS documentation.
      2. Construct a URL using your region’s endpoint. For example, if you are using the us-west-2 region, the URL you create would be https://s3.us-west-2.amazonaws.com. Enter this URL into the S3 Endpoint field.
    2. If you are using a non-public S3-compatible endpoint (Tanzu Operations Manager v2.10.19 or earlier):
      1. Enter the URL for the non-public endpoint.
      2. SSH into the Tanzu Operations Manager VM by running:
        
        ssh ubuntu@OPS-MANAGER-FQDN
        
        Where OPS-MANAGER-FQDN is the fully-qualified domain name (FQDN) of your Tanzu Operations Manager deployment.
      3. Copy the custom public CA certificate you used to sign the S3 endpoint into the /etc/ssl/certs directory on the Tanzu Operations Manager VM.
      4. On the Tanzu Operations Manager VM, import the custom CA certificate into the Tanzu Operations Manager VM truststore by running:
        
        sudo update-ca-certificates -f -v
      5. Add this custom CA certificate into the Trusted Certificates field in the Security page. For instructions, see Security Page.
    3. If you are using a non-public S3-compatible endpoint (Tanzu Operations Manager v2.10.20 or later:
      1. Enter the URL for the non-public endpoint.
      2. Add the custom public CA certificate you used to sign the S3 endpoint to the Trusted Certificates field on the Director Config page.
  2. Bucket Name: Enter the name of the S3 bucket.
  3. URL Style: Click either path-style or domain-style to specify the URL style for the S3-compatible blobstore. By default, the blobstore uses domain-style URLs.
    AWS ends support for path-style URLs for all S3 buckets created after September 30, 2020. For more information, see Support for Virtual-Hosted-Style URLs for AWS S3 Blobstores.
  4. Access Key and Secret Key: Enter the keys you generated when creating your S3 bucket.
  5. Enable signed URLs: Select this check box to configure BOSH VMs to generate short lived, pre-signed URLs for communication between the BOSH Agent and blobstore. If you enable this feature, BOSH Agents do not use credentials to communicate with the blobstore, and VM disks do not store blobstore credentials. This feature is only available for BOSH VMs that use Xenial stemcell line 621 or later.
  6. Select V2 Signature or V4 Signature. If you select V4 Signature, enter your Region. AWS recommends using Signature Version 4 (V4). For more information about AWS S3 Signatures, see Authenticating Requests in the AWS documentation.
  7. S3 Backup Strategy: To configure whether and how to back up the BOSH Director’s S3 blobstore, select one of the following options:
    - No backups
    - Use a versioned bucket: This option uses blobstore bucket versioning to save backups. It requires an S3 blobstore that supports versioning.
    - Copy into an additional bucket: This option saves blobstore backups to a separate bucket, which is useful with blobstores that do not support versioning. This option requires you to configure the Backup Bucket Region and Backup Bucket Name fields.
- GCS Blobstore: Use this option for an external Google Cloud Storage (GCS) endpoint.
  
  To create a GCS bucket, follow the procedures in Creating Storage Buckets in the GCS documentation. To create a GCS bucket, you must have a GCS account. When you have created a GCS bucket, configure the following fields:
  1. Bucket Name: Enter the name of your GCS bucket.
  2. Storage Class: Use this storage class for your GCS bucket. For more information, see Storage Classes in the GCP documentation.
  3. Service Account Key: Follow the steps in Set up IAM Service Accounts in Preparing to Deploy Tanzu Operations Manager on GCP to download a JSON file with a private key. Enter the contents of the JSON file into the text box.
  4. GCS Backup Strategy: To configure whether and how to back up the BOSH Director’s GCS blobstore, click one of the following options:
    - No backups
    - Copy into an additional bucket: This option saves blobstore backups to a bucket separate from the blobstore itself, and requires you to configure the Backup Bucket Region and Backup Bucket Name text boxes.
Click Database Location. By default, Tanzu Operations Manager deploys and manages an Internal database for you. If you choose to use an External MySQL Database, complete the associated fields with information obtained from your external MySQL Database provider: Host, Port, Username, Password, and Database.

Note Use of an External MySQL Database applies only to the BOSH Director. UAA and CredHub do not use these settings and continue to use the Postgres database co-located with the BOSH Director.

After you deploy the BOSH Director, you cannot change the Database Location from an External MySQL Database to an Internal database or from an Internal database to an External MySQL Database.

In addition, if you selected the Enable TLS for Director Database check box, you can complete the following optional fields:
- Enable TLS: Select this check box to enable TLS communication between the BOSH Director and the database.
- TLS CA: Enter the Certificate Authority for the TLS Certificate.
- TLS Certificate: Enter the client certificate for mutual TLS connections to the database.
- TLS Private Key: Enter the client private key for mutual TLS connections to the database.
- Advanced DB Connection Options: This text box accepts a JSON-formatted options string. It can be left blank unless directed by Broadcom Support.
Click Save.

Step 4: Create Availability Zones pane

Tanzu Operations Manager Availability Zones (AZs) correspond to your vCenter clusters, resource pools or host groups.

Multiple AZs allow you to provide high availability and load balancing to your applications. When you run more than one instance of an application, Tanzu Operations Manager balances those instances across all of the AZs assigned to the application.

VMware recommends that you use at least three AZs for a highly available installation of your chosen runtime.

For more information about AZs and high availability in vSphere, see Compute and HA considerations in vSphere Reference architecture.

Select Create Availability Zones.
Use the following steps to create the first AZ.
- Click Add.
- Enter a unique Name for the AZ.
- Select a vCenter config name from the IaaS Configuration dropdown to associate your AZ with a vCenter. If you have only one vCenter config, or if you are creating your first AZ, IaaS Configuration defaults to the first vCenter and cannot be configured.
- Enter the name of the vCenter Cluster where you deployed Tanzu Operations Manager. You created this cluster in the Prepare vSphere step of Deploying Tanzu Operations Manager to vSphere. For example, Cluster1.
- Enter the name of the Resource Pool that you created in the Prepare vSphere step of Deploying Tanzu Operations Manager to vSphere to organize management components like BOSH Director. For example, RP-MGMT. The jobs running in this AZ share the CPU and memory resources defined by the pool. You only need to specify this resource group in one AZ.
- (Optional) Enter the name of a Host Group for the AZ to use. The host group must be within the cluster you designated in the Clusters field. You created host groups in the Prepare vSphere step of Deploying Tanzu Operations Manager to vSphere. For more information about using host groups, see Host groups in vSphere.
- (Optional) In the VM-Host Affinity Rule drop-down menu, select SHOULD. Selecting SHOULD allows vSphere to restart VMs in another host group in the event of an AZ failure. For more information, see DRS host-affinity rules and stretched clusters in Host Groups in vSphere.
  The value for VM-Host Affinity Rule only applies if you are using Host Groups. If you do not specify a Host Group for the cluster, then any changes you make to VM-Host Affinity Rule are ignored.
- (Optional) Click Add Cluster to add more clusters to the AZ as required by your installation size and high availability requirements.
(Optional) Use the following steps to create additional AZs.
- Click Add.
- Specify Cluster and optionally, a Resource Pool or a Host Group with a VM-Host Affinity Rule. Typically you specify either a resource pool or a host group for an AZ, but not both. For more information about the difference between host groups and resource pools, see Host Groups in vSphere.
- Click Add Cluster to assign more clusters to the AZ as necessary for high availability. Click the trash icon to delete a cluster. The first cluster cannot be deleted.
Click Save.

Step 5: Create Networks pane

Select Create Networks.
Select Enable ICMP checks to enable ICMP on your networks. Tanzu Operations Manager uses ICMP checks to confirm that components within your network are reachable.

Depending on the runtime that you are deploying, do one of the following:

For TAS for VMs, click Add Network and create the following networks:

infrastructure: This network is for Tanzu Operations Manager and the BOSH Director.
pas: This network is for all the TAS for VMs VMs including Gorouter, Diego cells, and Cloud Controller.

services: This network is for any service tiles to be deployed alongside TAS for VMs.

Use the values from the following table as a guide when you create each network, replacing the IP addresses with ranges that are available in your vSphere environment:

Infrastructure Network	Field	Configuration Example
	Name	`infrastructure`
	vSphere Network Name ^*	`pcf-virt-net/infrastructure`
	CIDR	`192.168.101.0/24`
	Reserved IP Ranges ^†	`192.168.101.1-192.168.101.9`
	DNS	`192.168.101.2`
	Gateway	`192.168.101.1`
Deployment Network	Field	Configuration Example
	Name	`pas`
	vSphere Network Name ^*	`pcf-virt-net/pcf-pas-subnet`
	CIDR	`192.168.16.0/24`
	Reserved IP Ranges ^†	`192.168.16.1-192.168.16.9`
	DNS	`192.168.16.2`
	Gateway	`192.168.16.1`
Services Network	Field	Configuration Example
	Name	`services`
	vSphere Network Name ^*	`pcf-virt-net/pcf-services-subnet`
	CIDR	`192.168.20.0/24`
	Reserved IP Ranges ^†	`192.168.20.1-192.168.20.9`
	DNS	`192.168.20.2`
	Gateway	`192.168.20.1`

^* In vSphere Network Name, enter the full path of the network as it displays in vCenter. For example, enter YOUR-DIRECTORY-NAME/YOUR-NETWORK-NAME. If your vSphere Network Name contains a forward slash character, replace the forward slash with the URL-encoded forward slash character %2f.

^† For Reserved IP Ranges, enter any IP addresses from the CIDR that you do not want BOSH to use in your installation. Tanzu Operations Manager will not deploy VMs to any address in this range.

For TKGI, click Add Network and create the following networks:

infrastructure: This network is for Tanzu Operations Manager, the BOSH Director, the TKGI broker, and the TKGI API.
pks: If you have a large deployment with multiple tiles, you can choose to deploy the TKGI broker and TKGI API to a separate network named pks. For more information, see the table below for more information.

services: Network for creating the master and worker VMs for Kubernetes clusters. The CIDR should not conflict with the pod overlay network 10.200.0.0/16 or the reserved Kubernetes services CIDR of 10.100.200.0/24.

Multiple networks allow you to place vCenter on a private network and the rest of your deployment on a public network. Isolating vCenter in this manner denies access to it from outside sources and reduces possible security vulnerabilities.
Use the values from the following table as a guide when you create each network, replacing the IP addresses with ranges that are available in your vSphere environment:

Infrastructure Network	Field	Configuration Example
	Name	`infrastructure`
	vSphere Network Name ^*	`pcf-virt-net/pks-infrastructure-subnet`
	CIDR	`192.168.101.0/26`
	Reserved IP Ranges ^†	`192.168.101.1-192.168.101.9`
	DNS	`192.168.101.2`
	Gateway	`192.168.101.1`
Main Network (Optional)	Field	Configuration Example
	Name	`pks`
	vSphere Network Name ^*	`pcf-virt-net/pks-subnet`
	CIDR	`192.168.16.0/26`
	Reserved IP Ranges ^†	`192.168.16.1-192.168.16.9`
	DNS	`192.168.16.2`
	Gateway	`192.168.16.1`
Service Network	Field	Configuration Example
	Name	`services`
	vSphere Network Name ^*	`pcf-virt-net/pks-service-subnet`
	CIDR	`192.168.20.0/22`
	Reserved IP Ranges ^†	`192.168.20.1-192.168.20.9`
	DNS	`192.168.20.2`
	Gateway	`192.168.20.1`

For each network that you create, select the Availability Zones to use with the network. Assign as many AZs to your network as needed by your deployment. For more information, see Compute and HA considerations and Scaling and Capacity Managment sections of the vSphere Reference Architecture.
Click Save.

Step 6: Assign AZs and Networks

Select Assign AZs and Networks.
Use the Singleton Availability Zone drop-down menu to select a singleton AZ. The BOSH Director is installed as a single instance in this Availability Zone.
Use the Network drop-down menu to select a network for your BOSH Director.
Click Save.

Step 7: Security pane

Click Security.
In Trusted Certificates, paste in your custom certificate authority (CA) certificates to insert into your organization’s certificate trust chain. This feature enables all BOSH-deployed components in your deployment to trust custom root certificates. If you want to use Docker registries to run TAS for VMs app instances in Docker containers, enter the certificate for your private Docker registry in this text box. For more information about running app instances in TAS for VMs using Docker registries, see Using Docker Registries.

To enter multiple certificates, paste in your certificates one after the other. For example, format your certificates as shown in the following example:
```
-----BEGIN CERTIFICATE-----
ABCDEFGH12345678ABCDEFGH12345678ABCDEFGH12345678AB
EFGH12345678ABCDEFGH12345678ABCDEFGH12345678ABCDEF
GH12345678ABCDEFGH12345678ABCDEFGH12345678...
------END CERTIFICATE------
-----BEGIN CERTIFICATE-----
BCDEFGH12345678ABCDEFGH12345678ABCDEFGH12345678ABB
EFGH12345678ABCDEFGH12345678ABCDEFGH12345678ABCDEF
GH12345678ABCDEFGH12345678ABCDEFGH12345678...
------END CERTIFICATE------
-----BEGIN CERTIFICATE-----
CDEFGH12345678ABCDEFGH12345678ABCDEFGH12345678ABBB
EFGH12345678ABCDEFGH12345678ABCDEFGH12345678ABCDEF
GH12345678ABCDEFGH12345678ABCDEFGH12345678...
------END CERTIFICATE------
```
If you want to use Docker registries to run TAS for VMs app instances in Docker containers, enter the certificate for your private Docker registry in this text box. For more information about running app instances in TAS for VMs using Docker registries, see Using Docker Registries.
To include both the Tanzu Operations Manager root CA and the certificates pasted into Trusted Certificates in the trusted_certs field in the BOSH director manifest, select the Include Tanzu Ops Manager Root CA in Trusted Certs check box. BOSH Director includes this CA in the trust store of every VM that it deploys.
If you are using Tanzu Operations Manager to generate certificates for either a load balancer or router, then you must select this check box.
To clear the default trusted certificates from all BOSH-deployed Linux VMs, select the Clear the Default Trusted Certificates Store check box. You must provide your own trusted certificates when selecting this check box because all TLS communication fails if trusted certificates are not available.

This option is available in Ops Manager v2.10.21 and higher.
Select Generate passwords or Use default BOSH password. VMware recommends that you use the Generate passwords option for greater security.
Click Save. To view your saved BOSH Director password, click the Credentials tab.

Step 8: BOSH DNS Config pane

The BOSH DNS Config pane enables you to configure DNS for BOSH Director by adding excluded recursors, a recursor timeout, and handlers.

The text boxes in the BOSH DNS Config pane are:

Excluded Recursors: Exclude recursor addresses, which are URL redirects, so that they are not contacted by the BOSH DNS server. For more information about how the BOSH DNS release selects recursors, see Recursors in Native DNS Support in the BOSH documentation.
Recursor Timeout: Specify a timeout for the BOSH DNS server to contact any connected recursor addresses. The time limit includes dialing, writing, and reading from the recursor. If any of these actions exceeds the time limit, the action fails.
Handlers: Specify recursor addresses that apply to specific domains. For example, you can use handlers to forward all requests to a domain to a private DNS for resolution. For more information about using handlers, see Additional handlers in Native DNS Support in the BOSH documentation.

To add excluded recursors, a recursor timeout, or handlers to the BOSH DNS release:

Click BOSH DNS Config.
(Optional) In Excluded Recursors, enter a list of prohibited recursor addresses.
(Optional) In Recursor Timeout, enter a time limit for contacting the connected recursors.

This time limit must include one of the Go parse duration time units. For example, entering 5s sets the timeout limit to five seconds. For more information about supported time units, see func ParseDuration in the Go Programming Language documentation.

(Optional) In Handlers, enter an array of custom domain handlers in JSON format. For example:

[
  {
    "cache": {
      "enabled": true
    },
    "domain": "example.com",
    "source": {
      "type": "http",
      "url": "http://example.endpoint.local"
    }
  }
]

Click Save.

Step 9: Syslog pane

BOSH Director logs contain sensitive information that can be considered privileged. For example, these logs might contain cloud provider credentials. If you choose to forward logs to an external syslog endpoint, use TLS encryption to prevent information from being intercepted by a third party.

Select Syslog.
(Optional) To send BOSH Director system logs to a remote server, select Yes.
In Address, enter the IP address or DNS name for the remote server.
In Port, enter the port number that the remote server listens on.
From the Transport Protocol drop-down menu, select TCP or UDP. This selection determines which transport protocol is used to send the logs to the remote server.
(Optional) Select the Enable TLS check box to send encrypted logs to remote server with TLS. After you select the checkbox:
1. In Permitted Peer, enter either the name or SHA1 fingerprint of the remote peer.
2. In SSL Certificate, enter the SSL certificate for the remote server.
  
  Note VMware strongly recommends that you enable TLS encryption when you are forwarding logs. Logs can contain sensitive information, such as cloud provider credentials.
(Optional) In Environment identifier, enter a string. This is a human-readable identifier that is included in each log entry.
(Optional) In Queue Size, enter an integer. This value specifies the number of log messages held in the buffer. The default value is 100,000.
(Optional) Select the Forward Debug Logs check box to forward the logs to an external source. This option is deselected by default. If you select it, you may generate a large amount of log data.
(Optional) In the Custom rsyslog Configuration field, enter configuration details for rsyslog. This field requires the rainerscript syntax.
Click Save.

Step 10: Resource Config pane

Click Resource Config.
Under the Instances, VM Type, and Persistent Disk Type fields, choose Automatic from the drop-down menus to allocate the recommended resources for the job.
If the Persistent Disk Type field displays the value None, the job does not require persistent disk space.

For the BOSH Director job, select a VM type with at least 8 GB memory.

If you set a field to Automatic and the recommended resource allocation changes in a future version, Tanzu Operations Manager automatically uses the updated recommended allocation.

If you install VMware Tanzu Application Service for VMs [Windows] (TAS for VMs [Windows]), provision your Main Compilation Job with at least 100 GB of disk space.
(Optional) If you configured NSX-T or NSX-V networking in the vCenter Config pane, and you want to configure security and load balancing for the BOSH Director job:
1. Click the menu expansion icon next to the BOSH Director job name. The NSX-T Configuration and NSX-V Configuration fields appear.
2. Enter your NSX-T or NSX-V configuration values in these fields.
Click Save.

Step 11: Add custom VM extensions (optional)

Use the Tanzu Operations Manager API to add custom properties to your VMs; associated security groups and load balancers, for example. For more information, see Managing custom VM extensions.

Step 12: Complete the BOSH Director installation

Click the Tanzu Operations Manager Installation Dashboard link to return to the Installation Dashboard.
Click Review Pending Changes. Select the product that you intend to deploy and review the changes. For more information, see Reviewing pending product changes.

Next steps

After you complete this procedure, follow the instructions for the runtime that you intend to install:

To install TAS for VMs, see the TAS for VMs documentation.
To install TKGI, see the TKGI documentation.

For more information about Tanzu Operations Manager runtimes, see Installing Runtimes.