VMware Cloud Foundation Planning and

Preparation Guide

14 JAN 2020
VMware Cloud Foundation 3.9
VMware Cloud Foundation Planning and Preparation Guide

You can find the most up-to-date technical documentation on the VMware website at:

https://docs.vmware.com/

VMware, Inc.
3401 Hillview Ave.
Palo Alto, CA 94304
www.vmware.com

©
Copyright 2018-2020 VMware, Inc. All rights reserved. Copyright and trademark information.

VMware, Inc. 2
 Contents

About the VMware Cloud Foundation Planning and Preparation Guide 4

1 Minimum Hardware Requirements 5

Isolating Traffic Across Physical NICs 8

2 Software Requirements 10
Cloud Builder VM Support 10
Third-Party Software 11
VMware Software Licenses 11
Passwords 12

3 Port Requirements 13

4 External Services 15
External Services Overview 15
Physical Network Requirements 17
Network Pools 19
VLANs, IP Subnets, and Application Virtual Networks 20
VLAN IDs and IP Subnets 20
Names and IP Subnets of Application Virtual Networks 21
Host Names and IP Addresses 22
Host Names and IP Addresses for External Services 22
Host Names and IP Addresses for the Virtual Infrastructure Layer 23
Host Names and IP Addresses for the Operations Management Layer 27
Host Names and IP Addresses for the Cloud Management Layer 30
Requirements for vRealize Automation 33
Active Directory Service Accounts for vRealize Automation 33
Certificates for vRealize Automation 34
Configure Microsoft SQL Server for vRealize Automation 39
Prepare the IaaS Windows Server OVA Template for vRealize Automation 44

5 Capacity Planning for Management and Workload Domains 48

Virtual Infrastructure Layer Footprint 48
Operations Management Layer Footprint 50
Cloud Management Layer Footprint 51

6 Virtual Machine Placement 53

VMware, Inc. 3
About the VMware Cloud Foundation
Planning and Preparation Guide

The VMware Cloud Foundation Planning and Preparation Guide provides detailed information
about the software, tools, and external services that are required prior to using VMware Cloud
Foundation to implement a Software-Defined Data Center (SDDC).

This document should be reviewed in its entirety, prior to beginning a VMware Cloud Foundation
deployment to ensure a successful deployment. Review this document several weeks prior to the
start of the deployment in order to provide enough time to realize all the requirements.

VMware Cloud Foundation can be deployed in one of two different architecture models -
Standard or Consolidated.

n In the standard architecture model, the SDDC management workloads are separated from
the tenant workloads by using multiple workload domains.

n In the consolidated architecture model, only one workload domain containing both the
management and tenant workloads is created and resource pools are used to isolate
workloads.

Although this document focuses on the standard architecture model, the general requirements
provided are applicable to both.

Intended Audience
The VMware Cloud Foundation Planning and Preparation Guide is intended for cloud architects,
infrastructure administrators, and cloud administrators who are familiar with VMware software
and want to quickly deploy and manage an SDDC.

Required VMware Software

The VMware Cloud Foundation Planning and Preparation Guide is compliant and validated with
certain product versions. See the VMware Cloud Foundation release notes for more information
about supported product versions.

VMware, Inc. 4
Minimum Hardware Requirements
1
To implement an SDDC with VMware Cloud Foundation, your hardware must meet certain
minimum requirements.

This topic provides general guidance on the minimum requirements for a management domain
and a virtual infrastructure workload domain in a Cloud Foundation system. For more details
about sizing a Cloud Foundation system for your environment, see Chapter 5 Capacity Planning
for Management and Workload Domains.

Management Domain
The management domain contains infrastructure workloads. The management domain requires a
minimum of four servers. The management domain can be expanded to provide more resources
for additional workloads or increased availability.

In the standard architecture deployment model, the infrastructure workloads contained within the
management domain are kept isolated from tenant workloads through the creation of additional
workload domains. In the consolidated architecture model, both infrastructure and tenant
workloads are contained within the management domain. Workloads are kept separated in this
model through the implementation of resource pools. Regardless of the deployment model used,
ensure that the servers provide ample resources to support the deployed workloads. This
includes being able to support availability and maintenance actions where the workloads on a
server must be transferred to the other servers in the workload domain.

Cloud Foundation supports the use of vSAN ReadyNodes that are certified with supported
versions of ESXi in the management domain. Refer to https://kb.vmware.com/s/article/52084 for
guidance on what components can be modified in a vSAN ReadyNode. See the VMware Cloud
Foundation Release Notes for information about supported versions of ESXi.

The management domain contains a management cluster which must meet or exceed the
following minimum hardware requirements.

VMware, Inc. 5
VMware Cloud Foundation Planning and Preparation Guide

Table 1-1. Minimum Hardware Requirements for the Management Cluster

Component Requirements

Servers n Four vSAN ReadyNodes

For information on compatible vSAN ReadyNodes, see the
VMware Compatibility Guide.

CPU per server Aligns with minimum requirements for vSAN ReadyNodes.
For more information, refer to the VMware vSAN
Documentation.

Memory per server 192 GB

Storage per server Aligns with minimum requirements for vSAN ReadyNodes.
For more information, refer to the VMware vSAN
Documentation.

NICs per server n Two 10 GbE (or faster) NICs (IOVP Certified)
n (Optional) One 1 GbE BMC NIC

Note Servers cannot have more than two NICs for

communication, plus one BMC NIC for out-of-band host
management.

With Cloud Foundation 3.9.1, you can use more then two
NICs. See Isolating Traffic Across Physical NICs .

Virtual Infrastructure Workload Domains

A virtual infrastructure (VI) workload domain is used in the standard architecture deployment
model to contain the tenant workloads. A VI workload domain consists of a minimum of one
cluster consisting of three or more servers. Additional clusters can be added to a VI workload
domain as required.

Workloads in each cluster use vSphere High Availability (HA) to coordinate the failover to other
servers if there is a failure. To provide for the best levels of availability, all servers in a given
cluster must be of the same model and type. A cluster does not need to have servers of the
same model and type as other clusters. For example, consider a VI workload domain that has
two clusters:

n All servers in Cluster 1 must be homogeneous.

n All servers in Cluster 2 must be homogeneous.

n Servers in Cluster 1 do not need to have the same model and type as servers in Cluster 2.

Cloud Foundation supports the use of most vSAN ReadyNodes for vSAN backed VI workload
domains. Refer to https://kb.vmware.com/s/article/52084 for guidance on what components can
be modified in a vSAN ReadyNode. For NFS backed workload domains, you can use vSAN
ReadyNodes or servers compatible with the vSphere version included with the Cloud Foundation
Bill of Materials (BOM).

The servers used for a VI workload domain must meet or exceed the following minimum
requirements.

VMware, Inc. 6
VMware Cloud Foundation Planning and Preparation Guide

Table 1-2. Minimum Hardware Requirements for a VI Workload Domain

Component Requirements

Servers n For vSAN-backed VI workload domains, three

compatible vSAN ReadyNodes are required.

For information about compatible vSAN ReadyNodes,

see the VMware Compatibility Guide.
n For NFS-backed VI workload domains, three servers
compatible with the vSphere version included with the
Cloud Foundation BOM are required. For information
about the BOM, see the Cloud Foundation Release
Notes. For compatible servers, see the VMware
Compatibility Guide.
n For VMFS on FC-backed VI workload domains, three
servers compatible with the vSphere version included
with the Cloud Foundation BOM are required. For
information about the BOM, see the Cloud Foundation
Release Notes. In addition, the servers must have
supported FC cards (Host Bus Adapters) and drivers
installed and configured. For compatible servers and FC
cards, see the VMware Compatibility Guide.
Servers within a cluster must be of the same model and
type.

CPU, memory, and storage per server n For vSAN-backed VI workload domains, supported
vSAN configurations are required.
n For NFS-backed VI workload domains, configurations
must be compatible with the vSphere version included
with the Cloud Foundation BOM. For information about
the BOM, see the Cloud Foundation Release Notes.
n For VMFS on FC-backed VI workload domains,
configurations must be compatible with the vSphere
version included with the Cloud Foundation BOM. For
information about the BOM, see the Cloud Foundation
Release Notes.

NICs per server n Two 10 GbE (or faster) NICs (IOVP Certified)
n (Optional) One 1 GbE BMC NIC

Note Servers can have a maximum of two NICs for

primary communication, plus one BMC NIC for out-of-band
host management.

With Cloud Foundation 3.9.1, you can use more then two
NICs. See Isolating Traffic Across Physical NICs .

Note A Cloud Foundation solution can include a maximum of 15 domains (one management
domain and 14 workloads domains) in accordance with the vCenter Server maximums for linked
vCenter Servers.

VMware, Inc. 7
VMware Cloud Foundation Planning and Preparation Guide

Storage Options
VMware Cloud Foundation uses and is validated against vSAN, NFSv3, and VMFS on FC. The
management domain uses vSAN for storage. You can use vSAN, NFSv3, or VMFS on FC for VI
workload domains. The type of storage used by a VI workload domain is defined when the VI
workload domain is created. After the VI workload domain is created and the storage type has
been selected, you cannot change to another storage type. The storage type selected during the
VI workload domain creation applies to all clusters that are created within the VI workload
domain.

You must configure a network pool for the desired storage type before you create the VI
workload domain.

If using vSAN storage, familiarize yourself with the vSAN documentation on docs.vmware.com, if
you have not done so already. With any vSAN deployment, it is imperative that you maintain the
firmware and drivers across the entire storage path, including the storage controller, any SSD
drives, and ESXi. Use the vSAN HCL, https://www.vmware.com/resources/compatibility/
search.php?deviceCategory=vsan, to validate driver and firmware versions for associated
components. Ensure that the hardware is updated to supported levels before starting the
deployment.

Networking Platform Options

The management domain includes NSX for vSphere. For VI workload domains, you can select
either NSX for vSphere or NSX-T.

This chapter includes the following topics:

n Isolating Traffic Across Physical NICs

Isolating Traffic Across Physical NICs

Starting with Cloud Foundation 3.9.1, you can isolate VMkernel traffic (management, vSAN,
vMotion, or overlay) across multiple physical NICs (pNICs). You can enable four pNICs per host in
NSX for vSphere workload domains, and up to six pNICs per host in NSX-T workload domains.
Each vDS supports two pNICS, so you must define additional vDSes and map traffic per vDS as
appropriate. This capability is available for Cloud Foundation 3.9.1 deployments or when
upgrading to Cloud Foundation 3.9.1.

You can use hosts with additional pNICs for the following:

n Management domain (by using these hosts in the Cloud Foundation bring-up process)

n Creating VI workload domains

n Adding clusters to the management domain or VI workload domains

n Adding hosts to a cluster

VMware, Inc. 8
VMware Cloud Foundation Planning and Preparation Guide

You can stretch an NSX for vSphere cluster that contains hosts with multiple pNICs (four pNICs
and two vDSes) enabled. An NSX-T cluster with the following pNIC combinations can be
stretched using manual guidance:

n Four pNICs (one vDS and one N-VDS)

n Six pNICs (two vDS and one N-VDS)

For information on stretching an NSX for vSphere cluster, see Stretching Clusters in the VMware
Cloud Foundation Operations and Administration Guide. For information on stretching an NSX-T
cluster, see About Deployment of VMware NSX-T Workload Domains with Multiple Availability
Zones for VMware Cloud Foundation.

Traffic isolation across physical NICs is not supported through the UI. You must enable the
additional pNICs on hosts before commissioning them to Cloud Foundation. You can then update
the API spec to map traffic flow to reflect your physical topology. For information on using APIs,
see VMware Cloud Foundation API Reference Guide.

VMware, Inc. 9
Software Requirements
2
Additional software is required in order to deploy and manage VMware Cloud Foundation.

The required software depends on the configuration options you choose.

This chapter includes the following topics:

n Cloud Builder VM Support

n Third-Party Software

n VMware Software Licenses

n Passwords

Cloud Builder VM Support

In order to deploy Cloud Foundation, you first need to deploy the Cloud Builder VM.

The Cloud Builder VM takes your configuration inputs and provides the automated workflows
that instantiate the management domain. The host for the Cloud Builder VM can be any
supported system capable of running Cloud Foundation Builder. A dedicated ESXi host,
workstation, or a laptop running VMware Fusion or Workstation are examples of supported
systems. You can download the Cloud Builder VM through your MyVMware account.

The Cloud Builder VM requires the following resources.

Table 2-1. Cloud Builder VM Resource Requirements

Component Requirement

CPU 4 vCPUs

Memory 4 GB

Storage 350 GB

The Cloud Builder VM requires network connectivity to the ESXi management network, so that it
can communicate to all ESXi hosts added to the solution. The Cloud Builder VM also needs to be
able to communicate to the DNS and NTP servers used in the VMware Cloud Foundation
environment so that it can validate the deployment inputs provided. The DNS and NTP settings
used when deploying the Cloud Builder VM must be the same as the settings configured on the
hosts.

VMware, Inc. 10
VMware Cloud Foundation Planning and Preparation Guide

VMware Imaging Appliance

The Cloud Builder VM includes the VMware Imaging Appliance (VIA). You can use VIA to install
ESXi and VIBs on servers for use in the management domain and VI workload domains. Using
VIA is optional, and if your servers are already installed with a supported version of ESXi, you do
not need to use VIA.

You can use VIA to image servers prior to bring-up of a Cloud Foundation system and to image
additional servers post-bring-up.

Third-Party Software
Additional third-party software may be required in order to support the VMware Cloud
Foundation solution.

In order to access the Cloud Builder VM UI to begin the Cloud Foundation deployment, you will
need a host with a supported web browser. You will use the same host and browser to access
the Cloud Foundation UI after deployment. See the VMware Cloud Foundation release notes for
information about supported web browsers.

In addition, this host must have connectivity to the management network. When implementing a
network specific to the out-of-band management of the servers through the BMC ports, the host
should be multi-homed and able to access the configured out-of-band network as well.

Finally, the host should have enough storage space available to support the transfer of
applications, log bundles, and, optionally, vRealize Automation template images.

You can use Cloud Foundation to automate the deployment of vRealize Automation. If you
choose this option, the following additional products are required in order to complete the
deployment. See the VMware Cloud Foundation Operations and Administration Guide for more
information about deploying vRealize Automation.

Table 2-2. Third-Party Software Required to Automate the Deployment of vRealize Automation
Required by
VMware
SDDC Layer Component Vendor Product Item Product Version

Cloud vRealize Microsoft Windows Windows 2016 Standard (64-bit)

Management Automation Server

Microsoft SQL Server SQL Server 2012 or SQL Server 2016

Standard or higher (64-bit)

VMware Software Licenses

Before you deploy VMware Cloud Foundation, ensure that you have appropriate license keys for
the required VMware software. The license keys must match with the version of the product
installed. See the Bill of Materials (BOM) in the VMware Cloud Foundation Release Notes for
information on the specific product versions supported in each release.

VMware, Inc. 11
VMware Cloud Foundation Planning and Preparation Guide

You will need a license key for each of the following:

n SDDC Manager

n VMware vSphere

n VMware vCenter Server

n VMware vSAN

n VMware NSX for vSphere

VMware NSX-T uses an evaluation license for 60 days. After that time period, a license is
required.

n VMware vRealize Log Insight

n VMware vRealize Automation (optional); you can also use a vRealize Suite or vCloud Suite
license key.

n VMware vRealize Operations (optional); you can also use a vRealize Suite or vCloud Suite
license key.

Note Although part of the platform deployed by Cloud Foundation, vCenter Server is sold and
licensed separately and you must provide a separate vCenter Server license for Cloud
Foundation. Only one vCenter Server license is needed per Cloud Foundation instance,
regardless of the number of workload domains in the environment.

Passwords
You must specify the passwords to be used for the various accounts used during the deployment
of Cloud Foundation.

Refer to the deployment parameter spreadsheet for a list of accounts for which you must define
passwords. See the VMware Cloud Foundation Architecture and Deployment Guide for details
about the deployment parameter spreadsheet and the password requirements.

VMware, Inc. 12
Port Requirements
3
This section lists the firewall ports required to access Cloud Foundation.

Cloud Foundation Builder

Table 3-1. Inbound Ports
Port Protocol Description

22 TCP SSH access to vSphere components

67 TCP/UDP VIA - DHCP server on Cloud Foundation Builder

443 TCP Cloud Builder UI

8445 TCP VIA UI

Table 3-2. Outbound Ports

Port Protocol Description Notes

22 TCP SSH to all ESXi hosts and vRealize network Two dynamic ports are
selected from the range for
53 TCP/UDP DNS name resolution
mountd and statd
68 TCP/UDP ESXi hosts

123 TCP/UDP Time sync on Cloud Foundation Builder

443 TCP Bring-up - vSphere API

902 TCP Bring-up - OVF deploy

123 NTP Upstream NTP

SDDC Manager
Table 3-3. Inbound Ports
Port Protocol Description

22 TCP SSH access into SDDC Manager

111 TCP/UDP RPC - for NFS server on SDDC Manager

123 TCP/UDP Time sync - NTP server on SDDC Manager

135 TCP DCE RPC Daemon (dcerpcd)

443 TCP Access to SDDC Manager UI

VMware, Inc. 13
VMware Cloud Foundation Planning and Preparation Guide

Table 3-3. Inbound Ports (continued)

Port Protocol Description

2020 TCP VMware Authentication Service (vmafdd)

2049 TCP/UDP NFS Daemon (nfsd)

This daemon is used for client file-system requests.

4045 TCP/UDP NFS Lock Manager (lockd)

This daemon is used for record-locking operations on NFS files. It sends and manages
locking requests from the client to the NFS server.

32766 TCP/UDP NFS RPC Listen (statd)

This daemon works with (lockd) to provide crash and recovery functions for the lock
manager.

32767 TCP/UDP NFS (mountd)

This is a remote procedure call (RPC) server that handles file-system mount requests
from remote systems and provides access control.

Table 3-4. Outbound Ports

Port Protocol Description

22 TCP SSH

53 TCP/UDP DNS

123 TCP/UDP NTP

443 TCP HTTPS

514 UDP Syslog output to vRealize Log Insight

7444 TCP Access for single-sign on (SSO)

9000 TCP vRealize Log Insight agent to access vRealize Log Insight

VMware, Inc. 14
External Services
4
VMware Cloud Foundation relies on a set of key infrastructure services to be made available
externally. These external services must be configured and accessible before beginning a
deployment.

This chapter includes the following topics:

n External Services Overview

n Physical Network Requirements

n Network Pools

n VLANs, IP Subnets, and Application Virtual Networks

n Host Names and IP Addresses

n Requirements for vRealize Automation

External Services Overview

A variety of external services are required for the initial deployment of Cloud Foundation and for
the deployment of other optional components like vRealize Operations or vRealize Automation.

The following table lists the required and optional external services and dependencies.

Table 4-1. External Services

Service Purpose

Active Directory (AD) (Optional) Provides authentication and authorization.

Note AD is required if you are deploying vRealize Automation.

Dynamic Host Configuration Protocol Provides automated IP address allocation for VXLAN Tunnel Endpoints (VTEPs)
(DHCP) and NSX-T host VTEPs.

Domain Name Services (DNS) Provides name resolution for the various components in the solution.

Network Time Protocol (NTP) Synchronizes time between the various components.

VMware, Inc. 15
VMware Cloud Foundation Planning and Preparation Guide

Table 4-1. External Services (continued)

Service Purpose

Simple Message Transfer Protocol (Optional) Provides method for email alerts.
(SMTP)

Certificate Authority (CA) (Optional) Allows replacement of the initial self-signed certificates used by Cloud
Foundation.

Note A CA is required if you are deploying vRealize Automation.

Active Directory
Cloud Foundation uses Active Directory (AD) for authentication and authorization to resources.

The Active Directory services must be reachable by the components connected to the
management and vRealize networks.

User and Group accounts must be configured in AD prior to adding them to the SDDC Manager
and assigning privileges.

If you plan to deploy vRealize Automation, Active Directory services must be available. See the
vRealize Automation documentation (https://docs.vmware.com/en/vRealize-Automation/
index.html) for more information about its AD configuration.

DHCP
Cloud Foundation uses Dynamic Host Configuration Protocol (DHCP) to automatically configure
each VMkernel port of an ESXi host used as a VTEP with an IPv4 address. One DHCP scope must
be defined and made available for this purpose. The defined scope must be large enough to
accommodate all of the initial and future servers used in the Cloud Foundation solution. Each host
requires two IP addresses, one for each VTEP configured.

If you plan on creating an NSX-T workload domain, you need DHCP to configure TEP on the
hosts.

DNS
During deployment, you will need to provide the DNS domain information to be used to
configure the various components. The root DNS domain information is required and, optionally,
you can also specify subdomain information.

DNS resolution must be available for all of the components contained within the Cloud
Foundation solution. This includes servers, virtual machines, and any virtual IPs used. See Host
Names and IP Addresses for details on the components requiring DNS resolution prior to starting
a Cloud Foundation deployment.

Ensure that both forward and reverse DNS resolution is functional for each component prior to
deploying Cloud Foundation or creating any workload domains.

VMware, Inc. 16
VMware Cloud Foundation Planning and Preparation Guide

NTP
All components must be synchronized against a common time by using the Network Time
Protocol (NTP) on all nodes. Important components of Cloud Foundation, such as vCenter Single
Sign-On (SSO), are sensitive to a time drift between distributed components. Synchronized time
between the various components also assists troubleshooting efforts.

Requirements for the NTP sources include the following:

n The IP addresses of two NTP sources can be provided during the initial deployment

n The NTP sources must be reachable by all the components in the Cloud Foundation solution

n Time skew is less than 5 minutes between NTP sources

SMTP Mail Relay (Optional)

Certain components of the SDDC, such as vCenter, Log Insight, and vRealize Automation, can
send status messages to users by email. To enable this functionality, a mail relay that does not
require user authentication must be available through SMTP. As a best practice, limit the relay
function to the networks allocated for use by Cloud Foundation.

Certificate Authority (Optional)

The components of the SDDC require SSL certificates for secure operation. During deployment,
self-signed certificates are used for each of the deployed components. These certificates can be
replaced with certificates signed by an internal enterprise CA or by a third-party commercial CA.

If you plan to replace the self-signed certificates, the CA must be able to sign a Certificate Signing
Request (CSR) and return the signed certificate. All endpoints within the enterprise must also
trust the root CA of the CA.

If you plan to deploy vRealize Automation, a Certificate Authority is required, and the installation
workflow will request certificates.

Physical Network Requirements

Before you start deploying Cloud Foundation, you must configure your physical network.

Prior to deploying Cloud Foundation, configure your physical network to enable the following
functionality.

VMware, Inc. 17
VMware Cloud Foundation Planning and Preparation Guide

Table 4-2. Physical Network Requirements

Requirement Feature

IGMP snooping querier Required for the following traffic types:

n VXLAN

Jumbo frames Required for the following traffic types:

n vSAN
n vSphere vMotion
n VXLAN
n NFS
A minimum MTU value of 1600 is required, however it is
recommended that you set the MTU to 9000.

BGP adjacency and BGP autonomous system (AS) numbers Dynamic routing in the SDDC
(Cloud Foundation 3.9.1) Prepare your top of rack (ToR) switches by configuring
Border Gateway Protocol (BGP) on the switches, defining
the Autonomous System (AS) number and Router ID, and
creating interfaces to connect with Edge Services
Gateways (ESGs).
You will need the BGP Autonomous System (AS) number
and the Router ID for each ToR switch when you deploy
Cloud Foundation 3.9.1.

Physical Network Design

Design of the physical SDDC network includes defining the network topology for connecting the
physical switches and the ESXi hosts, determining switch port settings for VLANs and link
aggregation, and designing routing. VMware Cloud Foundation can use most enterprise grade
physical network architectures.

Switch Types and Network Connectivity

Follow network vendor best practices for physical connectivity as well as configuration of VLANs
and switch-port port settings.

Top of Rack Physical Switches

When configuring top of rack (ToR) switches, consider the following best practices.

n Configure redundant physical switches to enhance availability.

n Configure switch ports that connect to ESXi hosts manually as trunk ports. Virtual switches
are passive devices and do not support trunking protocols, such as Dynamic Trunking
Protocol (DTP).

n Modify the Spanning Tree Protocol (STP) on any port that is connected to an ESXi NIC to
reduce the time it takes to transition ports over to the forwarding state, for example, using
the Trunk PortFast feature on a Cisco physical switch.

VMware, Inc. 18
VMware Cloud Foundation Planning and Preparation Guide

n Provide DHCP or DHCP Helper capabilities on all VLANs that are used by the management
and VXLAN VMkernel ports. This setup simplifies the configuration by using DHCP to assign
IP address based on the IP subnet in use.

n Configure jumbo frames on all switch ports, inter-switch link (ISL) and switched virtual
interfaces (SVIs).

Top of Rack Connectivity and Network Settings

Each ESXi host is connected redundantly to the SDDC network fabric ToR switches by using a
minimum of two 10-GbE ports (two 25-GbE or faster ports are recommended). Configure the ToR
switches to provide all necessary VLANs via an 802.1Q trunk. These redundant connections use
features of vSphere Distributed Switches and NSX Data Center for vSphere to guarantee that no
physical interface is overrun and redundant paths are used as long as they are available.

Network Pools
Cloud Foundation uses a construct called a network pool to automatically configure VMkernel
ports for vSAN, NFS, and vMotion.

Cloud Foundation uses an Internet Protocol Address Management (IPAM) solution to automate
the IP configuration of VMkernel ports for vMotion, vSAN, and NFS (depending on the storage
type being used). A network pool contains network information details for each network. For
example:

When a server is added to the inventory of Cloud Foundation, it goes through a process called
host commissioning. During this process, the hosts are associated with an existing network pool.
When the host is provisioned during the create VI workload domain, add cluster, or add host
workflow, it automatically configures the VMkernel ports and allocates IP addresses for vMotion,
vSAN, and NFS from the network pool the host was associated with.

You can expand the Included IP address range of a network pool at any time, however you
cannot modify the other network information. Ensure you have defined each subnet in the
network pool to account for current and future growth in your environment.

VMware, Inc. 19
VMware Cloud Foundation Planning and Preparation Guide

VLANs, IP Subnets, and Application Virtual Networks

Before you deploy Cloud Foundation, you must allocate VLANs and IP subnets to the different
types of traffic in the SDDC, such as ESXi management, vSphere vMotion, and others. For
application virtual networks, you must plan separate IP subnets for these networks.

n VLAN IDs and IP Subnets

Network traffic types within Cloud Foundation are isolated from each other through the use
of VLANs. Before deploying your SDDC, you must allocate VLAN IDs and IP subnets for
each required traffic type.

n Names and IP Subnets of Application Virtual Networks

You must allocate an IP subnet to each application virtual network to be consumed by the
management applications that are deployed on these networks.

VLAN IDs and IP Subnets

Network traffic types within Cloud Foundation are isolated from each other through the use of
VLANs. Before deploying your SDDC, you must allocate VLAN IDs and IP subnets for each
required traffic type.

You must configure the VLAN IDs and IP subnets in your network in order to pass traffic through
your network devices. Verify the allocated network information is configured and does not
conflict with pre-existing services before starting your Cloud Foundation deployment.

The number and size of the subnets required for a deployment will depend on the number of
workload domains created, the number of clusters defined, and the optional components
installed.

The following table demonstrates the basic allocation of VLANs and IP subnets for a sample
deployment. Utilize this sample to define the actual VLANs and IP subnets according to your
environment.

Table 4-3. Sample VLAN and IP Subnet Configuration

Workload Domain Cluster VLAN Function VLAN ID Subnet Gateway

Management cluster-01 Management 1611 172.16.11.0/24 172.16.11.253

vSphere vMotion 1612 172.16.12.0/24 172.16.12.253

vSAN 1613 172.16.13.0/24 172.16.13.253

VXLAN (NSX VTEP) 1614 172.16.14.0/24 172.16.14.253

vRealize Suite 1616 172.16.16.0/24 172.16.16.253

(Cloud Foundation
3.9 only)

Uplink 1 2711 172.27.11.0/24 172.27.11.253

Uplink 2 2712 172.27.12.0/24 172.27.12.253

VMware, Inc. 20
VMware Cloud Foundation Planning and Preparation Guide

Table 4-3. Sample VLAN and IP Subnet Configuration (continued)

Workload Domain Cluster VLAN Function VLAN ID Subnet Gateway

VI Workload #1 cluster-01 Management (ESXi) 1711 173.17.11.0/24 173.17.11.253

(NSX for vSphere)
vSphere vMotion 1712 173.17.12.0/24 173.17.12.253

vSAN 1713 173.17.13.0/24 173.17.13.253

VXLAN (NSX VTEP) 1714 173.17.14.0/24 173.17.14.253

Uplink 1 1716 173.17.15.0/24 173.17.15.253

Uplink 2 1717 173.17.16.0/24 173.17.16.253

cluster-02 Management (ESXi) 1811 174.18.11.0/24 174.18.11.253

vSphere vMotion 1812 174.18.12.0/24 174.18.12.253

vSAN 1813 174.18.13.0/24 174.18.13.253

VXLAN (NSX VTEP) 1814 174.18.14.0/24 174.18.14.253

Uplink 1 1816 174.18.15.0/24 174.18.15.253

Uplink 2 1817 174.18.16.0/24 174.18.16.253

VI Workload #2 cluster-01 Management (ESXi) 1911 175.19.11.0/24 175.19.11.253

(NSX-T with
vSphere vMotion 1912 175.19.12.0/24 175.19.12.253
shared NSX-T
Edge cluster) vSAN 1913 175.19.13.0/24 175.19.13.253

Hosts TEP 1914 175.19.14.0/24 175.19.14.253

NSX-T Edge TEP 1915 175.19.15.0/24 175.19.15.253

NSX-T Edge Uplink 1 1916 175.19.16.0/24 175.19.16.253

NSX-T Edge Uplink 1917 175.19.17.0/24 175.19.17.253

2

Note Cloud Foundation 3.9 deploys vRealize Suite products to a dedicated VLAN-backed
vSphere Distributed Port Group. The IP subnet must be routable to the Cloud Foundation
management network and the firewall, if any, between the networks should be disabled or
configured per the Cloud Foundation documentation. ICMP traffic between the management
network and vRealize network should be permitted.

Cloud Foundation 3.9.1 deploys vRealize Suite products to application virtual networks. See
Names and IP Subnets of Application Virtual Networks.

The first NSX-T VI workload domain needs additional VLANs for the NSX-T Edge cluster, which is
shared among the other NSX-T VI workload domains. Subsequent NSX-T workload domains will
not need these VLANs.

Names and IP Subnets of Application Virtual Networks

You must allocate an IP subnet to each application virtual network to be consumed by the
management applications that are deployed on these networks.

VMware, Inc. 21
VMware Cloud Foundation Planning and Preparation Guide

Cloud Foundation 3.9.1 uses NSX Data Center for vSphere to create VXLAN-based networks,
called application virtual networks (AVNs). vRealize Suite products are deployed using these
AVNs.

The following table includes AVN IP subnets for a sample deployment. Use this sample to define
the actual IP subnets for your environment. A single /24 subnet is used for each AVN. IP
management is critical to ensure no shortage of IP addresses.

Table 4-4. Sample IP Subnets for the Application Virtual Networks

Application Virtual Network IP Subnet

Mgmt-xRegion01-VXLAN 192.168.11.0/24

Mgmt-RegionA01-VXLAN 192.168.31.0/24

AVNs require a /24 subnet reserved for use by the Universal Distributed Logical Router (UDLR)
for East-West Management Traffic and ECMP-enabled NSX Edge devices for North-South
management traffic.

Host Names and IP Addresses

Before you deploy Cloud Foundation, or before you create or expand a workload domain, you
must define the hostnames and IP addresses for various system components.

Most of the defined hostnames and IP addresses need to exist in DNS and be resolvable, through
forward and reverse lookups.

The hostnames and IP addresses required are categorized as follows:

n External services: Services that are external to the Cloud Foundation solution and are
required for proper operation.

n Virtual infrastructure layer: Components that provide for the basic foundation of the solution.

n Operations management layer: Components used for day-to-day management of the

environment, for example, vRealize Operations.

n Cloud management layer: Services that consume the infrastructure layer resources, for
example, vRealize Automation.

Host Names and IP Addresses for External Services

Allocate host names and IP addresses to all external services required by Cloud Foundation.

Allocate host names and IP addresses to the following components and configure DNS with an
FQDN that maps to the IP address where defined:

Component Requires DNS Configuration

NTP Yes

Active Directory Yes

VMware, Inc. 22
VMware Cloud Foundation Planning and Preparation Guide

The following table provides an example of the information to be collected for the external
services. This example uses a fictional DNS domain called rainpole.local for illustration purposes.
Modify the sample information to conform to your site's configuration.

Table 4-5. Sample External Services Hostname and IP Information

Component Group Hostname DNS IP Address Description

NTP ntp sfo01.rainpole.local Round robin DNS pool

containing the NTP
servers

0.ntp sfo01.rainpole.local 172.16.11.251 First NTP server

1.ntp sfo01.rainpole.local 172.16.11.252 Second NTP server

AD/DNS/CA dc01rpl rainpole.local 172.16.11.4 Windows 2012 R2 host

that contains the
Active Directory
configuration, the DNS
server for the
rainpole.local
domain, and the
Certificate Authority
for signing
management SSL
certificates

dc01sfo sfo01.rainpole.local 172.16.11.5 Active Directory and

DNS server for the
sfo01 subdomain

Host Names and IP Addresses for the Virtual Infrastructure Layer

Allocate host names and IP addresses to all components you deploy for the virtual infrastructure
layer of Cloud Foundation.

Allocate host names and IP addresses to the following components and configure DNS with an
FQDN that maps to the IP address where defined:

Component Requires DNS Configuration

SDDC Manager Yes

VMware Platform Services Controller® instances Yes

VMware vCenter Server® instances Yes

NSX Manager instances Yes

VMware NSX® Edge™ services gateways (Cloud No

Foundation 3.9.1)

During the initial deployment of Cloud Foundation, the management domain is created.
Components specific to the management domain need to be defined prior to installation.

VMware, Inc. 23
VMware Cloud Foundation Planning and Preparation Guide

After the initial deployment, you can create additional workload domains as required.
Components specific to each additional workload domain need to be defined prior to their
creation.

Planning ahead for the initial deployment and the workload domains to be created will avoid
delays in a deployment.

The following tables provide examples of the information to be collected for the virtual
infrastructure layer using the standard deployment model. The examples use a fictional DNS
domain called rainpole.local for illustration purposes. Modify the sample information to conform
to your site's configuration.

The required host names and IP addresses vary depending on your version of Cloud Foundation:

n Table 4-6. Cloud Foundation 3.9.1 Sample Host Names and IP Addresses for the Virtual
Infrastructure Layer

n Table 4-7. Cloud Foundation 3.9 Sample Host Names and IP Addresses for the Virtual
Infrastructure Layer

Table 4-6. Cloud Foundation 3.9.1 Sample Host Names and IP Addresses for the Virtual
Infrastructure Layer
Workload
Domain Hostname DNS Zone IP Address Description

Management sfo01m01sddc sfo01.rainpole.local 172.16.11.60 SDDC Manager

mgr

sfo01m01psc01 sfo01.rainpole.local 172.16.11.61 Platform Services Controller 01

sfo01m02psc0 sfo01.rainpole.local 172.16.11.63 Platform Services Controller 02

2

sfo01m01vc01 sfo01.rainpole.local 172.16.11.62 vCenter Server

sfo01m01esx01 sfo01.rainpole.local 172.16.11.101 ESXi host 01

sfo01m01esx02 sfo01.rainpole.local 172.16.11.102 ESXi host 02

sfo01m01esx03 sfo01.rainpole.local 172.16.11.103 ESXi host 03

sfo01m01esx04 sfo01.rainpole.local 172.16.11.104 ESXi host 04

sfo01m01nsx01 sfo01.rainpole.local 172.16.11.64 NSX-V Manager

sfo01m01nsxc0 172.16.11.65 NSX-V Controller 01

1

sfo01m01nsxc0 172.16.11.66 NSX-V Controller 02

2

sfo01m01nsxc0 172.16.11.67 NSX-V Controller 03

3

sfo01m01esg01 n 172.27.11.2 ECMP-enabled NSX Edge device for North-

n 172.27.12.3 South management traffic

n 192.168.10.1

VMware, Inc. 24
VMware Cloud Foundation Planning and Preparation Guide

Table 4-6. Cloud Foundation 3.9.1 Sample Host Names and IP Addresses for the Virtual
Infrastructure Layer (continued)
Workload
Domain Hostname DNS Zone IP Address Description

sfo01m01esg02 n 172.27.11.3 ECMP-enabled NSX Edge device for North-

n 172.27.12.2 South management traffic

n 192.168.10.2

sfo01m01udlr01 n 192.168.10.3 Universal Distributed Logical Router (UDLR)

n 192.168.10.4 for East-West management traffic

n 192.168.11.1
n 192.168.31.1

sfo01w01vc01 sfo01.rainpole.local 172.16.11.68 Additional vCenter Server for VI Workload

#1

sfo01w01nsx01 sfo01.rainpole.local 172.16.11.69 Additional NSX-V Manager for VI Workload

#1

sfo01w02vc01 sfo01.rainpole.local 172.16.11.70 Additional vCenter Server for VI Workload

#2

sfo01w02nsx01 sfo01.rainpole.local 172.16.11.71 NSX-T Manager VIP

sfo01w02nsxc0 172.16.11.120 NSX-T Manager 1 for Workload #2

1

sfo01w02nsxc0 172.16.11.121 NSX-T Manager 2 for Workload #2

2

sfo01w02nsxc0 172.16.11.122 NSX-T Manager 3 for Workload #2

3

VI Workload #1 sfo01w01esx01 sfo01.rainpole.local 172.16.17.101 ESXi host 05

(NSX for
sfo01w01esx02 sfo01.rainpole.local 172.16.17.102 ESXi host 06
vSphere)
sfo01w01esx03 sfo01.rainpole.local 172.16.17.103 ESXi host 07

sfo01w01esx04 sfo01.rainpole.local 172.16.17.104 ESXi host 08

sfo01w01nsxc0 172.17.17.120 NSX-V Controller 01

1

sfo01w01nsxc0 172.17.17.121 NSX-V Controller 02

2

sfo01w01nsxc0 172.17.17.122 NSX-V Controller 03

3

VI Workload #2 sfo01w02esx01 sfo01.rainpole.local 172.16.18.101 ESXi host 09

(NSX-T)
sfo01w02esx02 sfo01.rainpole.local 172.16.18.102 ESXi host 10

sfo01w02esx03 sfo01.rainpole.local 172.16.18.103 ESXi host 11

sfo01w02esx0 sfo01.rainpole.local 172.16.18.104 ESXi host 12

4

VMware, Inc. 25
VMware Cloud Foundation Planning and Preparation Guide

Table 4-6. Cloud Foundation 3.9.1 Sample Host Names and IP Addresses for the Virtual
Infrastructure Layer (continued)
Workload
Domain Hostname DNS Zone IP Address Description

sfo01w02nsxe0 sfo01.rainpole.local 172.16.18.201 NSX-T Edge 01

1

sfo01w02nsxe0 sfo01.rainpole.local 172.16.18.202 NSX-T Edge 02

2

Table 4-7. Cloud Foundation 3.9 Sample Host Names and IP Addresses for the Virtual
Infrastructure Layer
Workload
Domain Hostname DNS Zone IP Address Description

Management sfo01m01sddc sfo01.rainpole.local 172.16.11.60 SDDC Manager

mgr

sfo01m01psc01 sfo01.rainpole.local 172.16.11.61 Platform Services Controller 01

sfo01m02psc0 sfo01.rainpole.local 172.16.11.63 Platform Services Controller 02

2

sfo01m01vc01 sfo01.rainpole.local 172.16.11.62 vCenter Server

sfo01m01esx01 sfo01.rainpole.local 172.16.11.101 ESXi host 01

sfo01m01esx02 sfo01.rainpole.local 172.16.11.102 ESXi host 02

sfo01m01esx03 sfo01.rainpole.local 172.16.11.103 ESXi host 03

sfo01m01esx04 sfo01.rainpole.local 172.16.11.104 ESXi host 04

sfo01m01nsx01 sfo01.rainpole.local 172.16.11.64 NSX-V Manager

sfo01m01nsxc0 172.16.11.65 NSX-V Controller 01

1

sfo01m01nsxc0 172.16.11.66 NSX-V Controller 02

2

sfo01m01nsxc0 172.16.11.67 NSX-V Controller 03

3

sfo01w01vc01 sfo01.rainpole.local 172.16.11.68 Additional vCenter Server for VI Workload

#1

sfo01w01nsx01 sfo01.rainpole.local 172.16.11.69 Additional NSX-V Manager for VI Workload

#1

sfo01w02vc01 sfo01.rainpole.local 172.16.11.70 Additional vCenter Server for VI Workload

#2

sfo01w02nsx01 sfo01.rainpole.local 172.16.11.71 NSX-T Manager VIP

sfo01w02nsxc0 172.16.11.120 NSX-T Manager 1 for Workload #2

1

sfo01w02nsxc0 172.16.11.121 NSX-T Manager 2 for Workload #2

2

VMware, Inc. 26
VMware Cloud Foundation Planning and Preparation Guide

Table 4-7. Cloud Foundation 3.9 Sample Host Names and IP Addresses for the Virtual
Infrastructure Layer (continued)
Workload
Domain Hostname DNS Zone IP Address Description

sfo01w02nsxc0 172.16.11.122 NSX-T Manager 3 for Workload #2

3

VI Workload #1 sfo01w01esx01 sfo01.rainpole.local 172.16.17.101 ESXi host 05

(NSX for
sfo01w01esx02 sfo01.rainpole.local 172.16.17.102 ESXi host 06
vSphere)
sfo01w01esx03 sfo01.rainpole.local 172.16.17.103 ESXi host 07

sfo01w01esx04 sfo01.rainpole.local 172.16.17.104 ESXi host 08

sfo01w01nsxc0 172.17.17.120 NSX-V Controller 01

1

sfo01w01nsxc0 172.17.17.121 NSX-V Controller 02

2

sfo01w01nsxc0 172.17.17.122 NSX-V Controller 03

3

VI Workload #2 sfo01w02esx01 sfo01.rainpole.local 172.16.18.101 ESXi host 09

(NSX-T)
sfo01w02esx02 sfo01.rainpole.local 172.16.18.102 ESXi host 10

sfo01w02esx03 sfo01.rainpole.local 172.16.18.103 ESXi host 11

sfo01w02esx0 sfo01.rainpole.local 172.16.18.104 ESXi host 12

4

sfo01w02nsxe0 sfo01.rainpole.local 172.16.18.201 NSX-T Edge 01

1

sfo01w02nsxe0 sfo01.rainpole.local 172.16.18.202 NSX-T Edge 02

2

Host Names and IP Addresses for the Operations Management Layer

The operations management layer focuses on the components used for day-to-day management
of the Cloud Foundation environment. Allocate host names and IP addresses to all components
you deploy for the operations management layer of Cloud Foundation.

Allocate host names and IP addresses to the following components and configure DNS with an
FQDN that maps to the IP address where defined:

Component Requires DNS Configuration

VMware vRealize® Suite Lifecycle Manager™ Yes

VMware vRealize® Operations Manager™ Yes

VMware vRealize® Log Insight™ Yes

VMware, Inc. 27
VMware Cloud Foundation Planning and Preparation Guide

Cloud Foundation automatically deploys vRealize Log Insight in the management domain during a
deployment. Other components within the management domain are automatically configured to
utilize this vRealize Log Insight instance. With the appropriate licensing in place, this vRealize Log
Insight Instance can also be utilized by other workload domains. You must define the hostnames
and IP addresses for the vRealize Log Insight components prior to beginning the deployment of
Cloud Foundation.

Cloud Foundation automates the deployment of vRealize Operations. This optional component is
deployed within the management domain. In order to deploy vRealize Operations, you must first
deploy vRealize Suite Lifecycle Manager. When you deploy vRealize Automation or vRealize
Operations, Cloud Foundation deploys an NSX Edge used to load balance vRealize Suite product
services within the management domain. vRealize Suite Lifecycle Manager and the NSX Edge are
shared between vRealize Automation and vRealize Operations. You must define hostname and IP
information for the vRealize Operations components to be installed within the solution and the
shared components if not previously deployed.

vRealize Operations and vRealize Automation are not supported for NSX-T workload domains
yet.

The following tables provide examples of the information to be collected for the operations
management layer, including the shared components with vRealize Automation. If you are
deploying both vRealize Operations and vRealize Automation, the shared components are only
installed once. The examples use a fictional DNS domain called rainpole.local for illustration
purposes. Modify the sample information to conform to your site's configuration.

The required host names and IP addresses vary depending on your version of Cloud Foundation:

n Table 4-8. Cloud Foundation 3.9.1 Sample Host Names and IP Addresses for Operations
Management Layer

n Table 4-9. Cloud Foundation 3.9 Sample Host Names and IP Addresses for Operations
Management Layer

Table 4-8. Cloud Foundation 3.9.1 Sample Host Names and IP Addresses for Operations
Management Layer
IP
Component Addre Netwo
Group Hostname DNS Zone ss rk Description

vRealize Suite vrslcm01svr rainpole.lo 192.168 Mgmt- vRealize Suite Lifecycle Manager
Lifecycle 01a cal .11.20 xRegio (Shared component with vRealize Automation and
Manager n01- vRealize Operations)
VXLAN

vRealize Log sfo01vrli01 sfo01.rain 192.168 Mgmt- Virtual IP address of the vRealize Log Insight
Insight pole.local .31.10 Region integrated load balancer
A01-
sfo01vrli01a sfo01.rain 192.168 Master node of vRealize Log Insight
VXLAN
pole.local .31.11

sfo01vrli01b sfo01.rain 192.168 Worker node 1 of vRealize Log Insight

pole.local .31.12

VMware, Inc. 28
VMware Cloud Foundation Planning and Preparation Guide

Table 4-8. Cloud Foundation 3.9.1 Sample Host Names and IP Addresses for Operations
Management Layer (continued)
IP
Component Addre Netwo
Group Hostname DNS Zone ss rk Description

sfo01vrli01c sfo01.rain 192.168 Worker node 2 of vRealize Log Insight

pole.local .31.13

vRealize vrops01svr rainpole.lo 192.168 Mgmt- Virtual IP address of load balancer for the analytics
Operations 01 cal .11.35 xRegio cluster of vRealize Operations Manager
Manager n01-
vrops01svr rainpole.lo 192.168 Master node of vRealize Operations Manager
VXLAN
01a cal .11.31

vrops01svr rainpole.lo 192.168 Master replica node of vRealize Operations Manager

01b cal .11.32

vrops01svr rainpole.lo 192.168 Data node 1 of vRealize Operations Manager

01c cal .11.33

vrslcm01svr rainpole.lo 192.168 vRealize Suite Lifecycle Manager (shared component

01a cal .11.20 with vRealize Automation)

sfo01m01lb 192.168 vRealize Edge load balancer (shared component with

01 .11.2 vRealize Automation)

Table 4-9. Cloud Foundation 3.9 Sample Host Names and IP Addresses for Operations
Management Layer
IP
Component Addre
Group Hostname DNS Zone ss Network Description

vRealize Suite vrslcm01svr rainpole.lo 172.16.1 vRealize vRealize Suite Lifecycle Manager
Lifecycle 01a cal 6.78 (Shared component with vRealize Automation and
Manager vRealize Operations)

vRealize Log sfo01vrli01 sfo01.rain 172.16.1 Manage Virtual IP address of the vRealize Log Insight
Insight pole.local 1.70 ment integrated load balancer

sfo01vrli01a sfo01.rain 172.16.1 Master node of vRealize Log Insight

pole.local 1.71

sfo01vrli01b sfo01.rain 172.16.1 Worker node 1 of vRealize Log Insight

pole.local 1.72

sfo01vrli01c sfo01.rain 172.16.1 Worker node 2 of vRealize Log Insight

pole.local 1.73

vRealize vrops01svr rainpole.lo 172.16.1 vRealize Virtual IP address of load balancer for the analytics
Operations 01 cal 6.74 cluster of vRealize Operations Manager
Manager
vrops01svr rainpole.lo 172.16.1 Master node of vRealize Operations Manager
(Optional)
01a cal 6.75

vrops01svr rainpole.lo 172.16.1 Master replica node of vRealize Operations Manager

01b cal 6.76

vrops01svr rainpole.lo 172.16.1 Data node 1 of vRealize Operations Manager

01c cal 6.77

VMware, Inc. 29
VMware Cloud Foundation Planning and Preparation Guide

Table 4-9. Cloud Foundation 3.9 Sample Host Names and IP Addresses for Operations
Management Layer (continued)
IP
Component Addre
Group Hostname DNS Zone ss Network Description

vrslcm01svr rainpole.lo 172.16.1 vRealize Suite Lifecycle Manager (shared component

01a cal 6.78 with vRealize Automation)

sfo01m01lb rainpole.lo 172.16.1 vRealize Edge load balancer (shared component with
01 cal 6.79 vRealize Automation)

Host Names and IP Addresses for the Cloud Management Layer

Allocate host names and IP addresses to all components you deploy for the cloud management
layer of Cloud Foundation.

Allocate host names and IP addresses to the following components and configure DNS with an
FQDN that maps to the IP address where defined:

Component Requires DNS Configuration

VMware vRealize® Automation™ Yes

Microsoft SQL Server for vRealize Automation Yes

Before you can deploy vRealize Automation, you must deploy vRealize Suite Lifecycle Manager.
When you deploy vRealize Automation or vRealize Operations, Cloud Foundation deploys an
NSX Edge used to load balance vRealize Suite product services within the management domain.
vRealize Suite Lifecycle Manager and the NSX Edge are shared between vRealize Automation
and vRealize Operations.

The following tables provide examples of the information to be collected for the cloud
management layer, including the shared components with vRealize Automation. If you are
deploying both vRealize Operations and vRealize Automation, the shared components are only
installed once. For illustration purposes, this example uses a fictional DNS root domain named
rainpole.local. Modify the example information for your organization's configuration.

Important Host names for IaaS VMs should be 15 characters or less due to limitations in the
Windows OS. If the host names are longer they will be trimmed during the installation and
installation will fail.

The required host names and IP addresses vary depending on your version of Cloud Foundation:

n Table 4-10. Cloud Foundation 3.9.1 Sample Host Names and IP Addresses for vRealize
Automation

n Table 4-11. Cloud Foundation 3.9 Sample Host Names and IP Addresses for vRealize
Automation

VMware, Inc. 30
VMware Cloud Foundation Planning and Preparation Guide

Table 4-10. Cloud Foundation 3.9.1 Sample Host Names and IP Addresses for vRealize
Automation
Component IP
Group Hostname DNS Zone Address Network Description

vRealize vra01svr01 rainpole.lo 192.168.1 Mgmt- Virtual IP address of the vRealize Automation
Automation cal 1.53 xRegion Appliance
01-
vra01svr01a rainpole.lo 192.168.1 vRealize Automation Appliance
VXLAN
cal 1.51

vra01svr01b rainpole.lo 192.168.1 vRealize Automation Appliance

cal 1.52

vra01svr01c rainpole.lo 192.168.1 vRealize Automation Appliance

cal 1.50

vra01iws01 rainpole.lo 192.168.1 Virtual IP address of the vRealize Automation IaaS

cal 1.56 Web Servers

vra01iws01a rainpole.lo 192.168.1 vRealize Automation IaaS Web Server

cal 1.54

vra01iws01b rainpole.lo 192.168.1 vRealize Automation IaaS Web Server

cal 1.55

vra01ims01 rainpole.lo 192.168.1 Virtual IP address of the vRealize Automation IaaS

cal 1.59 Manager Service

vra01ims01a rainpole.lo 192.168.1 vRealize Automation IaaS Manager Service and DEM
cal 1.57 Orchestrator

vra01ims01b rainpole.lo 192.168.1 vRealize Automation IaaS Manager Service and DEM
cal 1.58 Orchestrator

vra01dem01 rainpole.lo 192.168.1 vRealize Automation DEM Worker

a cal 1.60

vra01dem01 rainpole.lo 192.168.1 vRealize Automation DEM Worker

b cal 1.61

sfo01ias01a sfo.rainpol 192.168. Mgmt- vRealize Automation Proxy Agent

e.local 31.52 RegionA
01-
sfo01ias01b sfo.rainpol 192.168. vRealize Automation Proxy Agent
VXLAN
e.local 31.53

VMware, Inc. 31
VMware Cloud Foundation Planning and Preparation Guide

Table 4-10. Cloud Foundation 3.9.1 Sample Host Names and IP Addresses for vRealize
Automation (continued)
Component IP
Group Hostname DNS Zone Address Network Description

sfo01m01lb0 192.168.1 Mgmt- NSX Edge Load Balancer

1 1.2 xRegion (Shared component with vRealize Automation and
01- vRealize Operations)
VXLAN

Microsoft SQL vra01mssql0 rainpole.lo n 172.1 n VMN Microsoft SQL Server for vRealize Automation
Server 1 cal 6.11. etwo
72 rk
(VM n Mgm
Net t-
work xReg
) ion0
n 192.1 1-
68.11 VXL
.62 AN
(VXL
AN)

Table 4-11. Cloud Foundation 3.9 Sample Host Names and IP Addresses for vRealize Automation
IP
Component Addres
Group Hostname DNS Zone s Network Description

vRealize vra01svr01 rainpole.lo 172.16.16 vRealize Virtual IP address of the vRealize Automation
Automation cal .80 Appliance

vra01svr01a rainpole.lo 172.16.16 vRealize Automation Appliance

cal .81

vra01svr01b rainpole.lo 172.16.16 vRealize Automation Appliance

cal .82

vra01svr01c rainpole.lo 172.16.16 vRealize Automation Appliance

cal .83

vra01iws01 rainpole.lo 172.16.16 Virtual IP address of the vRealize Automation IaaS

cal .84 Web Servers

vra01iws01a rainpole.lo 172.16.16 vRealize Automation IaaS Web Server

cal .85

vra01iws01b rainpole.lo 172.16.16 vRealize Automation IaaS Web Server

cal .86

vra01ims01 rainpole.lo 172.16.16 Virtual IP address of the vRealize Automation IaaS

cal .87 Manager Service

vra01ims01a rainpole.lo 172.16.16 vRealize Automation IaaS Manager Service and

cal .88 DEM Orchestrator

vra01ims01b rainpole.lo 172.16.16 vRealize Automation IaaS Manager Service and

cal .89 DEM Orchestrator

VMware, Inc. 32
VMware Cloud Foundation Planning and Preparation Guide

Table 4-11. Cloud Foundation 3.9 Sample Host Names and IP Addresses for vRealize Automation
(continued)
IP
Component Addres
Group Hostname DNS Zone s Network Description

vra01dem01 rainpole.lo 172.16.16 vRealize Automation DEM Worker

a cal .90

vra01dem01 rainpole.lo 172.16.16 vRealize Automation DEM Worker

b cal .91

sfo01ias01a rainpole.lo 172.16.11. Manageme vRealize Automation Proxy Agent

cal 92 nt

sfo01ias01b rainpole.lo 172.16.11. vRealize Automation Proxy Agent

cal 93

sfo01m01lb rainpole.lo 172.16.16 vRealize NSX Edge Load Balancer

01 cal .79 (Shared component with vRealize Automation and
vRealize Operations)

Microsoft vra01mssql rainpole.lo 10.0.0.1 Any Microsoft SQL Server for vRealize Automation
SQL Server 01 cal 0 accessible
network

Requirements for vRealize Automation

Before you begin the procedure to add vRealize Automation to Cloud Foundation, plan for and
verify that the following configurations are established in addition to the prerequsites for both
the VLANs and IP subnets and the host names and IP addresses.

Active Directory Service Accounts for vRealize Automation

Before you deploy and configure vRealize Automation in Cloud Foundation, you must provide
specific configuration for an Active Directory user. This user acts as a service account for
authentication in cross-application communication.

The service account provides non-interactive and non-human access to services and APIs to the
vRealize Automation components of Cloud Foundation.

The service account is a standard Active Directory account that you configure in the following
way:

n The password never expires.

n The user cannot change the password.

VMware, Inc. 33
VMware Cloud Foundation Planning and Preparation Guide

Source Destination Description Required Role

vRealize Active Directory Service account for performing Active n Account Operators Group
Automation Directory domain join operations for n Delegation to Join
computer accounts used by vRealize Computers to Active
Automation IaaS components. Directory Domain

vRealize n vRealize Service account for access from vRealize n Administrator

Automation Automation Automation to vCenter Server and the n vRealize Orchestrator
n Microsoft SQL Microsoft SQL Server instance. Administrator
Server

Note Delegation to Join Computers to Active Directory Domain is only required to deploy
vRealize Automation. After deployment, it is no longer required.

Certificates for vRealize Automation

Before you add vRealize Automation to Cloud Foundation, you must prepare the certificates for
the vRealize Automation components. In the vRealize Automation installation wizard, you will
provide the certificates signed by a certificate authority (CA) that will be used for the vRealize
Automation deployment.

n If using Microsoft CA-signed certificates for vRealize Automation in Cloud Foundation, verify
that the certificate service template is properly configured for basic authentication.

Create and Add a Microsoft Certificate Authority Template

If your organization plans to use a Microsoft Certificate Authority instead of an external third
party certificate authority, you must set up the Microsoft Certificate Authority template on the
Microsoft Certificate Authority servers. The template contains the certificate authority (CA)
attributes for signing certificates for the Cloud Foundation solutions. After you create the new
template, you add it to the certificate templates in the Microsoft Certificate Authority.

Setting up a Microsoft Certificate Authority template involves creating a template and then
adding that template to the certificate templates of the Microsoft Certificate Authority.

Procedure

1 Log in to the Microsoft Certificate Authority server by using a Remote Desktop Protocol
(RDP) client.

2 Click Windows Start > Run, enter certtmpl.msc, and click OK.

3 On the Certificate Template Console, under Template Display Name, right-click Web Server
and click Duplicate Template.

4 In the Properties of New Template dialog box, leave Windows Server 2003 selected for
backward compatibility.

5 Click the General tab.

6 In the Template display name text box, enter VMware as the name of the new template.

VMware, Inc. 34
VMware Cloud Foundation Planning and Preparation Guide

7 Click the Extensions tab and specify extensions information.

a Select Application Policies and click Edit.

b Select Server Authentication, click Remove, and click OK.

c Select Client Authentication, click Remove, and click OK.

If Client Authentication does not appear in Application Policies, then you can skip this
step.

d Select Key Usage and click Edit.

e Select the Signature is proof of origin (nonrepudiation) check box.

f Leave the default for all other options. Click OK

8 Click the Subject Name tab, ensure that the Supply in the request option is selected, and
click OK to save the template.

9 To add the new template to your Microsoft Certificate Authority, click Windows Start > Run,
enter certsrv.msc, and click OK

10 In the Certification Authority window, expand the left pane if it is collapsed.

11 Right-click Certificate Templates and select New > Certificate Template to Issue.

12 In the Name column of the Enable Certificate Templates dialog box, select the VMware
certificate that you created and click OK.

Results

Generating Certificates for vRealize Automation

Before you can deploy vRealize Automation for use with Cloud Foundation, you must generate
certificates for all the vRealize Automation components. In the vRealize Automation installation
wizard, you will provide the certificates signed by a certificate authority (CA) that will be used for
the vRealize Automation deployment.

vRealize Automation supports certificates that are signed by a Microsoft Certificate Authority, as
well as certificates that are signed by a non-Microsoft Certificate Authority. The procedure for
generating certificates varies depending on the Certificate Authority that you are using in your
environment.

Generate vRealize Automation Certificates for Use with a Non-Microsoft Certificate Authority
Use the SDDC Manager VM to generate a certificate request and private key. Your Certificate
Authority uses the certificate request to generate a certificate you can use when you deploy
vRealize Automation.

Procedure

1 Using SSH, log in to the SDDC Manager VM with the user name vcf and password you
specified in the deployment parameter sheet.

VMware, Inc. 35
VMware Cloud Foundation Planning and Preparation Guide

2 Enter su and the password you specified in the deployment parameter sheet.

3 Navigate to the /opt/vmware/vcf/operationsmanager/scripts/cli directory.

4 Run the following command.

./generate_certificate.sh

5 Enter 1 to generate a certificate signing request.

6 Press Enter to accept the default resource type (vra).

7 Enter the information for use with your certificate request.

For example, Country Name, State or Province Name, and so on.

8 Enter the subject alternative names (SANs) for each of the vRealize Automation components.

Add the FQDN and hostname for each component as a separate SAN entry.

Component Sample SANs

vRealize Automation Appliance vra01svr01.rainpole.local

Load Balancer VIP

vra01svr01

vRealize Automation Appliance vra01svr01a.rainpole.local

vra01svr01a

vRealize Automation Appliance vra01svr01b.rainpole.local

vra01svr01b

vRealize Automation Appliance vra01svr01c.rainpole.local

vra01svr01c

vRealize Automation IaaS Web vra01iws01.rainpole.local

Server VIP

vra01iws01

vRealize Automation IaaS Web vra01iws01a.rainpole.local

Server

vra01iws01a

vRealize Automation IaaS Web vra01iws01b.rainpole.local

Server

vra01iws01b

vRealize Automation IaaS Manager vra01ims01.rainpole.local

Service VIP

vra01ims01

vReaize Automation IaaS Manager vra01ims01a.rainpole.local

Service and DEM Orchestrator

vra01ims01a

vReaize Automation IaaS Manager vra01ims01b.rainpole.local

Service and DEM Orchestrator

VMware, Inc. 36
VMware Cloud Foundation Planning and Preparation Guide

Component Sample SANs

vra01ims01b

vRealize Automation DEM Worker vra01dem01a.rainpole.local

vra01dem01a

vRealize Automation DEM Worker vra01dem01b.rainpole.local

vra01dem01b

9 Enter done.

10 Enter the file path to copy the private key.

The default path is /tmp/private_key.pem.

11 Enter the file path to copy the csr file.

The default path is /tmp/csr.pem.

What to do next

Send the certificate signing request to your Certificate Authority to get a certificate. You will
need the server certificate, root CA certificate, and your private key to deploy vRealize
Automation.

Generate vRealize Automation Certificates for Use with a Microsoft Certificate Authority
Use the SDDC Manager VM to generate a certificate and private key. Use the certificate and
private key when you deploy vRealize Automation.

Prerequisites

You have configured a Microsoft Certificate Authority. See "Configure Certificate Authority" in the
VMware Cloud Foundation Operations and Administration Guide.

Procedure

1 Using SSH, log in to the SDDC Manager VM with the user name vcf and password you
specified in the deployment parameter sheet.

2 Enter su and the password you specified in the deployment parameter sheet.

3 Navigate to the /opt/vmware/vcf/operationsmanager/scripts/cli directory.

4 Run the following command.

./generate_certificate.sh

5 Enter 2 to generate a certificate.

6 Press Enter to accept the default resource type (vra).

VMware, Inc. 37
VMware Cloud Foundation Planning and Preparation Guide

7 Enter the information for use with your certificate request.

For example, Country Name, State or Province Name.

8 Enter the subject alternative names (SANs) for each of the vRealize Automation components.

Add the FQDN and hostname for each component as a separate SAN entry.

Component Sample SANs

vRealize Automation Appliance vra01svr01.rainpole.local

Load Balancer VIP

vra01svr01

vRealize Automation Appliance vra01svr01a.rainpole.local

vra01svr01a

vRealize Automation Appliance vra01svr01b.rainpole.local

vra01svr01b

vRealize Automation Appliance vra01svr01c.rainpole.local

vra01svr01c

vRealize Automation IaaS Web vra01iws01.rainpole.local

Server VIP

vra01iws01

vRealize Automation IaaS Web vra01iws01a.rainpole.local

Server

vra01iws01a

vRealize Automation IaaS Web vra01iws01b.rainpole.local

Server

vra01iws01b

vRealize Automation IaaS Manager vra01ims01.rainpole.local

Service VIP

vra01ims01

vReaize Automation IaaS Manager vra01ims01a.rainpole.local

Service and DEM Orchestrator

vra01ims01a

vReaize Automation IaaS Manager vra01ims01b.rainpole.local

Service and DEM Orchestrator

vra01ims01b

vRealize Automation DEM Worker vra01dem01a.rainpole.local

vra01dem01a

vRealize Automation DEM Worker vra01dem01b.rainpole.local

vra01dem01b

9 Enter done.

VMware, Inc. 38
VMware Cloud Foundation Planning and Preparation Guide

10 Enter the file path to copy the private key.

The default path is /tmp/private_key.pem.

11 Enter the file path to copy the csr file.

The default path is /tmp/csr.pem.

12 Enter the file path to copy the server certificate.

The default path is /tmp/server.pem.

13 Enter the file path to copy the root CA certificate.

The default path is /tmp/rootca.pem.

What to do next

Deploy vRealize Automation. You will need the private key, server certificate, and root CA
certificate.

Configure Microsoft SQL Server for vRealize Automation

Before you deploy vRealize Automation in Cloud Foundation, configure the Microsoft SQL Server
as a prerequisite.

Microsoft SQL Server Recommendations

vRealize Automation uses Microsoft SQL Server on Windows Server as the database
management system (DBMS) to store data for the vRealize Automation IaaS components. The
specific configuration of SQL Server for use in your environment is not addressed in this guide.
High-level guidance is provided to ensure more reliable operation of your vRealize Automation
deployment.

Review the vRealize Automation Support Matrix (PDF) for supported Microsoft SQL Sever
versions for vRealize Automation.

Note If using Microsoft SQL Server 2016 or 2017, use 100 or 120 compatibility level.

To provide optimal performance for the vRealize Automation IaaS database, configure the
Microsoft Windows Server virtual machine for Microsoft SQL Server with a minimum of 8 vCPU
and 16 GB vRAM.

Microsoft SQL Server binaries should be installed in the operating system VMDK. Microsoft SQL
Server, even if another drive is selected for binary installation, will still install components on the
operating system drive. Separating Microsoft SQL Server installation files from data and
transaction logs also provides better flexibility for backup, management, and troubleshooting.

VMware, Inc. 39
VMware Cloud Foundation Planning and Preparation Guide

Place Microsoft SQL Server data files (system and user), transaction logs, and backup files into
separate VMDKs. For example:

n Operating System

n SQL User Database Data Files

n SQL User Database Log Files

n SQL TempDB

n SQL Backup Files

Utilize the VMware Paravirtualized SCSI (PVSCSI) Controller as the virtual SCSI Controller for data
and log VMDKs. The PVSCSI Controller is the optimal SCSI controller for an I/O-intensive
application on vSphere allowing not only a higher I/O rate but also lowering CPU consumption
compared with the LSI Logic SAS. In addition, the PVSCSI adapters provide higher queue depth,
increasing I/O bandwidth for the virtualized workload.

Use multiple PVSCSI adapters. VMware supports up to four (4) adapters per virtual machines and
as many as necessary, up to this limit, should be leveraged. Placing operating system, data, and
transaction logs onto a separate vSCSI adapter optimizes I/O by distributing load across multiple
target devices and allowing for more queues on the operating system level. Consider distributing
disks between controllers.

For more information, refer to the Architecting Microsoft SQL Server on VMware vSphere Best
Practices Guide.

Assign the Server Role to vRealize Automation Service Account

Assign the Microsoft SQL Server sysadmin server role to the vRealize Automation service
account.

vRealize Automation uses the Microsoft SQL Server sysadmin server role privilege to create and
run scripts on the SQL Server database. By default, only users who are members of the
sysadmin server role, or the db_owner and db_ddladmin database roles, can create objects in
the database.

Procedure

1 Log in to the Microsoft SQL Server virtual machine as an administrative account by using a
Remote Desktop Protocol (RDP) client.

2 From the Start menu, click All Programs, click Microsoft SQL Server, and click SQL Server
Management Studio.

Note If Microsoft SQL Server Management Studio does not appear in your All Programs
menu, the component might not have successfully installed. Verify that you have successfully
installed Microsoft SQL Server Management Studio, and then continue with this procedure.

VMware, Inc. 40
VMware Cloud Foundation Planning and Preparation Guide

3 In the Connect to Server dialog box, leave the default value of the Server Name text box,
select Windows Authentication from the Authentication drop-down menu, and click
Connect.

Note During the Microsoft SQL Server installation, the Database Engine configuration wizard
prompts you to provide the user name and password for the SQL Server administrator. If this
user was not added during the installation, select SQL Authentication from the
Authentication drop-down menu, and enter the user name sa in the User name text box, and
the password sa_password in the Password text box.

4 In the Object Explorer pane, expand the server instance (for example, vra01mssql01).

5 Right-click the Security folder, click New, and click Login.

6 In the Login Properties dialog box, click the General page and enter the service account
name (for example, rainpole\svc-vra) in the Login name text box.

7 Click the Server Roles page, select the sysadmin check box, and click OK.

Configure Network Access for Distributed Transaction Coordinator

Configure network access and security between vRealize Automation and your Microsoft SQL
Server instance using Microsoft Distributed Transaction Coordinator (MSDTC). MSDTC
coordinates transactions that update two or more transaction-protected resources, such as
databases, message queues, file systems. These transaction-protected resources may be on a
single computer, or distributed across many networked computers.

Procedure

1 Log in to the Microsoft SQL Server virtual machine as an administrative account using a
Remote Desktop Protocol (RDP) client.

2 From the Start menu, click Run, type comexp.msc in the Open text box, and click OK.

The Component Services manager displays. Component Services lets you manage
Component Object Model (COM+) applications.

3 In the navigation tree, select Component Services > Computers > My Computer >
Distributed Transaction Coordinator > Local DTC.

4 Right-click Local DTC and click Properties.

The Local DTC Properties dialog box displays.

5 Click the Security tab in the Local DTC Properties dialog box.

6 In the Security tab, configure the following values, and click OK.

Setting Value

Network DTC Access Selected

Allow Remote Clients Selected

Allow Remote Administration Selected

VMware, Inc. 41
VMware Cloud Foundation Planning and Preparation Guide

Setting Value

Allow Inbound Selected

Allow Outbound Selected

Mutual Authentication Required Selected

Enable XA Transactions Deselected

Enable SNA LU 6.2 Transactions Selected

Account Leave the default setting (NT AUTHORITY\NetworkService)

Password Leave blank

7 Click Yes to restart the MSDTC Service, click OK to confirm that the service has successfully
restarted, and close the Component Services manager.

Allow Microsoft SQL Server and MSDTC Access through the Windows Firewall
for vRealize Automation
Configure the Windows Firewall to allow inbound access for Microsoft SQL Server and the
Microsoft Distributed Transaction Coordinator (MSDTC).

Procedure

1 Log in to the Microsoft SQL Server virtual machine with an administrative user by using a
Remote Desktop Protocol (RCP) client.

2 From the Start menu, click Run, type WF.msc in the Open text box, and click OK.

The Windows Firewall with Advanced Security dialog box appears to configure firewall
properties for each network profile.

3 Allow Access for Microsoft SQL Server on TCP Port 1433.

a In the navigation pane, under Windows Firewall with Advanced Security, select and
right-click Inbound Rules, and click New Rule in the action pane.

The New Inbound Rule Wizard appears.

b On the Rule Type page of the New Inbound Rule Wizard, select the Port radio button,
and click Next.

c On the Protocol and Ports page, select TCP and enter the port number 1433 in
the Specific local ports text box, and click Next.

d On the Action page, select Allow the connection, and click Next.

e On the Profile page, select the Domain,Private, and Public profiles, and click Next.

f On the Name page, enter a Name and a Description for this rule, and click Finish.

VMware, Inc. 42
VMware Cloud Foundation Planning and Preparation Guide

4 Allow access for Microsoft Distributed Transaction Coordinator.

a In the navigation pane, under Windows Firewall with Advanced Security, select and
right-click Inbound Rules, and click New Rule in the action pane.

b On the Rule Type page click Predefined, click Distributed Transaction Coordinator, and
click Next.

c On the Predefined Rules page, select all rules for Distributed Transaction Coordinator
(RPC-EPMAP), Distributed Transaction Coordinator (RPC), Distributed Transaction
Coordinator (TCP-In), and click Next.

d On the Action page, select Allow the connection, and click Finish.

5 Exit the Windows Firewall with Advanced Security wizard.

6 Right click Powershell, select Run as Administrator, and run the following commands. These
commands adjust the User Account Controls, disable IPv6, and restart the server to activate
these changes.

Command

set-ItemProperty -Path "HKLM:\Software\Microsoft\Windows\CurrentVersion\Policies\System" -Name "EnableLUA" -

Value "0"

set-ItemProperty -Path "HKLM:\System\CurrentControlSet\Services\TCPIP6\Parameters" -Name "DisabledComponents" -

Value 0xff

Restart-Computer

Configure a Microsoft SQL Server Database for vRealize Automation IaaS

Components
Create and configure the Microsoft SQL Server database for the vRealize Automation IaaS
Components.

Prerequisites

n A supported version of Microsoft SQL Sever for vRealize Automation is installed per the
vRealize Automation Support Matrix (PDF).

n The vRealize Automation service account has been added to Microsoft SQL Server with the
sysadmin server role.

n Microsoft Distributed Transaction Coordinator has been configured.

n The Windows Firewall inbound access has been configured for Microsoft SQL Server (TCP
port 1433) and the Microsoft Distributed Transaction Coordinator.

Procedure

1 Log in to the Microsoft SQL Server virtual machine as an administrative account by using a
Remote Desktop Protocol (RDP) client.

VMware, Inc. 43
VMware Cloud Foundation Planning and Preparation Guide

2 From the Start menu, click All Programs, click Microsoft SQL Server, and click SQL Server
Management Studio.

Note If Microsoft SQL Server Management Studio does not appear in your All Programs
menu, the component might not have successfully installed. Verify that you have successfully
installed Microsoft SQL Server Management Studio, and then continue with this procedure.

3 In the Connect to Server dialog box, leave the default value of the Server Name text box,
select Windows Authentication from the Authentication drop-down menu, and click
Connect.

Note During the Microsoft SQL Server installation, the Database Engine configuration wizard
prompts you to provide the user name and password for the SQL Server administrator. If this
user was not added during the installation, select SQL Authentication from the
Authentication drop-down menu, and enter the user name sa in the User name text box, and
the password sa_password in the Password text box.

4 In the Object Explorer pane, right-click Databases and choose New Database.

5 The New Database dialog box, select the General tab and enter the database name, for
example, vRADB01.

6 Set Database Owner to the same value as the service user name, for example svc-vra.

7 Select the Options tab and configure the following settings:

a Set Recovery Model option to Simple.

b If using Microsoft SQL Server 2016 or 2017, set Compatibility Level as 100 or 120.

c Under Other options, change the Allow Snapshot Isolation option to true.

d Under Other options, change the Is Read Committed Snapshot option to true.

8 Click OK.

Prepare the IaaS Windows Server OVA Template for vRealize

Automation
Before you deploy vRealize Automation in Cloud Foundation, prepare a Microsoft Windows
Server OVA template for the vRealize Automation IaaS components.

Creation of the Microsoft Windows Server OVA template is one of the prerequisites for
deploying vRealize Automation in Cloud Foundation, as described in the VMware Cloud
Foundation Operations and Administration Guide.

VMware, Inc. 44
VMware Cloud Foundation Planning and Preparation Guide

Prerequisites

n Verify that you have a Microsoft Windows Server virtual machine to serve as the template for
the vRealize Automation IaaS components. It must have the following configuration:

Attribute Value

Operating Microsoft Windows Server 2016 (64-bit)

System

vCPU Two

Memory 8 GB

Disk 50 GB LSI

Network VMXNET3

Other Browser

In Internet Explorer, disable the Enhanced Security Configuration feature.

Remote Desktop

Enable Remote Desktop Connections.

n Verify that the virtual machine is not joined to Active Directory.

n Verify that you can access and download Java Runtime Environment (JRE) executable:
jre-8u201-windows-x64.exe or later version.

Procedure

u On the Microsoft Windows Server virtual machine, launch the PowerShell console as an
administrator and run the following commands:

a Set the PowerShell Execution Policy

Set-ExecutionPolicy Unrestricted

b Disable User Account Control (UAC)

Set-ItemProperty -Path ‘HKLM:\Software\Microsoft\Windows\CurrentVersion\Policies\System’ -

Name ‘EnableLUA’ 0

c Disable IPv6

Set-ItemProperty -Path ‘HKLM:\System\CurrentControlSet\Services\TCPIP6\Parameters’ -Name

'DisabledComponents' -Value 0xff

u Download and install Java Runtime Environment version 1.8 Update 201 or later (64-bit) on
the Microsoft Windows Server virtual machine.

Note The Microsoft Windows Server virtual machine in this deployment was tested with
Java Runtime Environment jre-8u201-windows-x64.exe. Use this version or later.

VMware, Inc. 45
VMware Cloud Foundation Planning and Preparation Guide

u Configure JAVA_HOME on the Microsoft Windows Server virtual machine.

a Click Start and enter sysdm.cpl to open the System Properties dialog box.

b Select the Advanced tab and click Environment Variables.

c Under System Variables, click New and configure the following:

n For variable name, specify JAVA_HOME.

n For variable value, specify C:\Program Files\Java\jre1.8.0_201 (depending on

your JRE version).

d Click OK.

u While still in the System Properties dialog box, add the Java Runtime Environment installation
folder to the Path environment variable.

a Under System Variables, locate the Path variable and click Edit.

b Append the following to the path and click OK:

C:\Program Files\Java\jre1.8.0_201\bin

c Click OK until you exit the System Properties dialog box.

u Run the following command in a command prompt to validate the Java version:

java.exe -version

u Verify that the source path for Microsoft Windows Server is available offline.

n Copy the Microsoft Windows Server source directory \sources\sxs from the Windows
install media to the virtual machine folder C:\sources\sxs.

n Update the registry string value for HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows

\CurrentVersion\policies\Servicing\LocalSourcePath to location of the installation
files. For example, C:\sources\sxs. If the Servicing key is missing, create it.
LocalSourcePath is a string value.

u On the Microsoft Windows Server virtual machine, enable secondary log-in with an automatic
start-up type.

a Open the Services panel in Windows Server (Start > Services) and right-click Secondary
Logon and select Properties.

b Change the Startup type setting to Automatic.

c Click OK to exit the Properties dialog box.

u Reboot the Microsoft Windows Server virtual machine.

u Using the previously established user account (for example,svc-vra), join the newly
configured Microsoft Windows Server virtual machine to the Active Directory domain.

VMware, Inc. 46
VMware Cloud Foundation Planning and Preparation Guide

u After joining, verify that there are no Active Directory group policies that will change the UAC
or firewall configuration.

Note The newly joined Microsoft Windows Server virtual machine should remain with UAC
and firewall disabled. If not, you must disable or suppress the Group Policy that enforces a
firewall or UAC enforcement when a new computer object joins the Active Directory.

u Add the vRealize Automation service account to the Local Administrators group (set as
svc-vra in previous examples).

u Log in using the vRealize Automation service account.

u Verify the proxy server configuration.

If the configuration is enabled, virtual machines from the vRealize Suite network must be able
to access the proxy server. As an alternative, you can configure direct communication in
Control Panel > Internet Settings and configure no proxy.

Caution Do not activate the Microsoft Windows Server operating system on the virtual
machine or run sysprep or generalise on it before converting it to a template.

u Shut down the Microsoft Windows Server virtual machine and export as OVA template with
ovftool.

ovftool --noSSLVerify
vi://'administrator@vsphere.local':'<VC_Password>'@<VC_IP_or_FQDN>/<Datacenter_Name>/vm/<VM_Name>
\
<IAAS_Template_Name>.ova

VMware, Inc. 47
Capacity Planning for
Management and Workload
Domains
5
Before deploying Cloud Foundation, you must ensure that your environment has enough
available compute and storage resources to accommodate the footprint of the management
domain, any additional workload domains, and any optional components you plan to deploy.

Note Storage footprint shows allocated space. Do not consider it if you use thin provisioning.

This chapter includes the following topics:

n Virtual Infrastructure Layer Footprint

n Operations Management Layer Footprint

n Cloud Management Layer Footprint

Virtual Infrastructure Layer Footprint

The resources required by the virtual infrastructure layer will vary depending on which
deployment model you choose and the number of workload domains you plan to create.

The following table displays the amount of resources the virtual infrastructure layer components
consume for a management domain, a single virtual infrastructure workload domain, and a single
Horizon domain. Duplicate the resource consumption shown for each additional workload
domain.

This table does not factor in additional storage requirements to account for availability or
maintenance considerations. In a production environment, you need to account for adequate
resources to allow for the failure of hosts, virtual machine snapshots, and backups. It also does
not consider additional workloads deployed to the virtual infrastructure layer outside of Cloud
Foundation. This can include virtual machines you deploy that provide backup, antivirus, or other
security services to the environment.

Table 5-1. Virtual Infrastructure Layer Footprint

Domain Component Installed In vCPUs Memory (GB) Storage (GB) Notes

Base SDDC Management 4 16 800

Management Manager domain
Domain
vCenter Server Management 4 16 290
Footprint
domain

VMware, Inc. 48
VMware Cloud Foundation Planning and Preparation Guide

Table 5-1. Virtual Infrastructure Layer Footprint (continued)

Domain Component Installed In vCPUs Memory (GB) Storage (GB) Notes

Platform Management 2 4 60
Services domain
Controller

Platform Management 2 4 60
Services domain
Controller

NSX Manager Management 4 16 60

domain

NSX Controller Management 4 4 28

01 domain

NSX Controller Management 4 4 28

02 domain

NSX Controller Management 4 4 28

03 domain

Each NSX for vCenter Server Management 8 24 500

vSphere VI domain
Workload
NSX Manager Management 4 16 60
Domain
domain

NSX Controller Workload domain 4 4 28

01

NSX Controller Workload domain 4 4 28

02

NSX Controller Workload domain 4 4 28

03

First NSX-T VI vCenter Server Management 8 24 500 A vCenter Server

Workload domain is deployed in the
Domain management
domain for each
NSX-T VI
workload domain.

NSX Manager Management 12 48 200 These

domain components are
deployed for the
NSX Manager Management 12 48 200
first NSX-T VI
domain
workload domain.
NSX Manager Management 12 48 200 Additional
domain workload
domains share
NSX Edge 01 Workload domain 8 32 200
these
(Optional)
components.
NSX Edge 02 Workload domain 8 32 200
(Optional)

VMware, Inc. 49
VMware Cloud Foundation Planning and Preparation Guide

Table 5-1. Virtual Infrastructure Layer Footprint (continued)

Domain Component Installed In vCPUs Memory (GB) Storage (GB) Notes

Each Horizon Each Management 2 10 Depends on These

Domain Connection domain the size of the components are
See Sizing Server system drive deployed for
Guidelines in of OVA each Horizon
the VMware template. domain.
Cloud Recommend
Foundation minimum is
Operations 80.
and
Each Management 2 10 Depends on
Administratio
Composer domain the size of the
n Guide.
Server system drive
of OVA
template.
Recommend
minimum is
80.

Each App Management 2 10 Depends on

Volumes domain the size of the
Manager system drive
of OVA
template.
Recommend
minimum is
80.

Each Unified Management 2 4 20

Access domain
Gateway
appliance

Each User Management 2 10 Depends on

Environment domain the size of the
Manager system drive
of OVA
template.
Recommend
minimum is
80.

TOTAL (does not include Horizon components) 122 vCPU 396 GB 3,498 GB

Operations Management Layer Footprint

The amount of resources required to support the operations management layer depends on the
components installed.

A vRealize Log Insight instance is required and is automatically deployed as part of the
management domain. Installation of vRealize Operations is optional.

VMware, Inc. 50
VMware Cloud Foundation Planning and Preparation Guide

During the deployment wizard for vRealize Operations, you are given the opportunity to select
the number of analytics nodes to deploy. The samples shown within this document reflect a three
node deployment. You will need to adjust accordingly if you deploy more than three nodes.

Refer to the following table for information on the minimum resource requirements for the
operations management layer components.

Table 5-2. Operations Management Layer Footprint

Operating
Product Component System vCPUs Memory (GB) Storage (GB)

vRealize Operations Manager Virtual

8 32 1,024
Analytics Node1 Appliance

vRealize Operations vRealize Operations Manager Virtual 8 32 1,024

(Optional) Analytics Node 2 Appliance

vRealize Operations Manager Virtual 8 32 1,024

Analytics Node 3 Appliance

vRealize Log Insight vRealize Log Insight Node 1 Virtual 8 16 1,312

Appliance

vRealize Log Insight Node 2 Virtual 8 16 1,312

Appliance

vRealize Log Insight Node 3 Virtual 8 16 1,312

Appliance

TOTAL 48 vCPU 144 GB 7,008 GB

Cloud Management Layer Footprint

vRealize Automation is an optional component that can be deployed as part of the cloud
management layer.

The following table depicts the resources required to support the deployment of vRealize
Automation.

Note Not all of the components listed need to consume resources within the Cloud Foundation
environment. The Microsoft SQL server instance can be deployed within the management
domain or at an external location accessible over the network. Review the vRealize Automation
documentation (https://docs.vmware.com/en/vRealize-Automation/index.html) for more
information on the resource requirements.

Table 5-3. Cloud Management Layer Footprint

vRAM
Product Component Operating System vCPUs (GB) Storage (GB)

vRealize Automation vRealize Automation Virtual Appliance 4 18 140

Appliance 1

vRealize Automation Virtual Appliance 4 18 140

Appliance 2

VMware, Inc. 51
VMware Cloud Foundation Planning and Preparation Guide

Table 5-3. Cloud Management Layer Footprint (continued)

vRAM
Product Component Operating System vCPUs (GB) Storage (GB)

vRealize Automation Virtual Appliance 4 18 140

Appliance 3

vRealize Automation Windows VM 2 8 60

IaaS Web Server 1

vRealize Automation Windows VM 2 8 60

IaaS Web Server 2

vRealize Automation Windows VM 2 8 60

IaaS Manager Server
1

vRealize Automation Windows VM 2 8 60

IaaS Manager Server
2

vRealize Automation Windows VM 2 8 60

DEM Worker 1

vRealize Automation Windows VM 2 8 60

DEM Worker 2

vRealize Automation Windows VM 2 8 60

Proxy Agent 1

vRealize Automation Windows VM 2 8 60

Proxy Agent 2

Microsoft SQL Server Windows VM 8 16 200

(external)

Total 36 vCPU 134 GB 1,100 GB

VMware, Inc. 52
Virtual Machine Placement
6
Administrators familiar with vSphere will benefit from being able to visualize the placement of the
deployed virtual machines.

This section provides some examples of various basic configurations.

Management Domain
This example illustrates the environment after the initial deployment of VMware Cloud
Foundation. The configuration shown depicts four hosts, which are contained in a cluster. These
four hosts make up the management domain. No other workload domains have been deployed.

VMware, Inc. 53
VMware Cloud Foundation Planning and Preparation Guide

Within this cluster are a series of virtual machines that have been automatically deployed by
Cloud Foundation. These include:

n SDDC Manager

n vCenter Server

n Platform Services Controllers

n NSX Manager

n NSX Controllers

n vRealize Log Insight

This example could provide the basis for either a consolidated or standard deployment
architecture. If this was a consolidated deployment, the resource pools shown would be used to
separate tenant workloads from the infrastructure workloads. If this was a standard deployment
model, additional workload domains would be added and additional components would be
automatically deployed.

Management Domain with vRealize Operations

This example illustrates a Cloud Foundation environment that consists of a management domain
after an automated deployment of vRealize Operations Manager. No additional workload
domains have been added in this example.

VMware, Inc. 54
VMware Cloud Foundation Planning and Preparation Guide

The deployment of vRealize Operations Manager within the environment is optional. In this
example, vRealize Operations Manager was deployed with two nodes. You can define the
number of nodes to be deployed as part of vRealize Operations Manager. See the VMware Cloud
Foundation Operations and Administration Guide for more information on deploying vRealize
Operations Manager within Cloud Foundation.

In the example, you can see the vRealize Operations Manager components that were deployed,
including the vRealize Life Cycle Management (VRLCM) appliance and the NSX edge devices.
These components are shared with vRealize Automation and are only deployed once, even if you
deploy both vRealize Operations Manager and vRealize Automation.

Multiple Workload Domains with vRealize Automation

This example includes a management domain and a VI workload domain. In this scenario, there
are multiple vCenter Servers and NSX managers deployed; one instance each for the
management domain and the VI workload domain.

VMware, Inc. 55
VMware Cloud Foundation Planning and Preparation Guide

VMware, Inc. 56
VMware Cloud Foundation Planning and Preparation Guide

In addition, vRealize Automation has been deployed. Deploying vRealize Automation is optional.
A vRealize Life Cycle Management (VRLCM) appliance and NSX edge devices are deployed for
vRealize Automation. These components are shared with vRealize Operations and are only
deployed once, even if you deploy both vRealize Operations Manager and vRealize Automation.

Note vRealize Automation requires a Microsoft SQL server. Although it can be installed within
the management domain, it is an external component and can exist outside of the VMware Cloud
Foundation environment, as long as it is reachable over the network. IN this example, the
Microsoft SQL server is not installed in the management domain.

VMware, Inc. 57