In this blog post, we describe the procedure to deploy Pivotal CF Operations Manager (a web-based tool for deploying Cloud Foundry) and BOSH (a VM that creates other VMs) to a VMware vCenter.
[2014-10-18 this blog post has been updated to reflect ESXi 5.5U2, VCSA 5.5U2, the pivotal.io domain, and Pivotal CF 1.3.1]
[2014-06-29 this blog post has been updated to reflect installation on a 64GiB Mac Pro (not a 16GiB Mac Mini, which didn’t have enough RAM to deploy Cloud Foundry)]
Pre-requisites
1. VMware ESXi and vCenter
In *World’s Smallest IaaS, Part 1, we deployed VMware ESXi and vCenter on an Apple Mac Pro. ESXi must be up and running, and vCenter must be up and running, too. And network accessible.
2. Pivotal CF
- Browse to https://network.pivotal.io/products.
- Log in (if you don’t have a userid, create one; they’re free)
- Click the Pivotal CF tile
- Click Download; it should be a .tgz file; it should be approximately 5.6GB
- double-click the downloaded file to untar it (using a Windows box may require the installation of an application to untar the file).
Deploy Ops Manager
- browse to https://vcenter.cf.nono.com
- click on Log in to vSphere Web Client
- log in as root with whatever-we-set-the-password-to
- click VMs and Templates
- Click Actions → Deploy OVF Template…
- if prompted to download and install the plugin, install the plugin; we’ll need this to deploy Ops Manager. If you’re using Firefox 30, you may need go to Tools → Add-ons → Plugins → VMWare Client Support Plug-in and set it to Always Activate
- Install the plugin. It will close our browsers; we’ll re-open them after installation is complete.
- Click Actions → Deploy OVF Template…
- Click Allow to when prompted by the Client Integration Access Control
- Select Local File; click Browse…
- Select the pcf-vsphere-1.3.1.0.ova file that we untarred from the Pivotal CF file we downloaded (it should be under the pcf-1.3.1.0_allinone directory); click Open
- Click Next
- (Review details) click Next
- (Accept EULAs) click Accept; click Next
- (Select Name and Folder) click Next
- (Select a resource)
- select Cluster
- click Next
- (Select storage) click Next
- (Setup networks) click Next
- (Customize template)
- IP Address: 10.9.8.30 (this is the IP address for opsmgr.cf.nono.com)
- Netmask: 255.255.255.0
- Default Gateway: 10.9.8.1
- DNS: 8.8.8.8 (Google’s DNS Server)
- NTP: time.apple.com (Apple’s NTP Server)
- Admin password: whatever-you-want-to-set-the-password-to
- click Next
- (Ready to complete)
- review settings one last time
- check Power on after deployment
- click Finish
Wait two minutes for the machine to boot
Use Ops Manager to Deploy BOSH
We are now ready to use Ops Manager to Deploy BOSH
- browse to https://opsmgr.cf.nono.com
- create an account, pivotalcf. Assign a password. Click Create Admin User

Ops Manager’s initial screen. Create the administrative user. We typically use ‘pivotalcf’ as the administrator account
- click on Operations Manager Director for vmware vSphere tile (although the description doesn’t have the word ‘BOSH’ in it, this tile deploys BOSH)

Click the “Operations Manager” tile to configure the BOSH VM. Note the orange band at the bottom of the tile—it indicates that the product is available but has not yet been configured
We see the configuration screen. There are several panels. We fill them out
- vCenter Config
- IP address: 10.9.8.20 (this must be an IP address, e.g. ‘10.9.8.20’; hostnames (e.g. ‘vcenter.cf.nono.com’) aren’t accepted)
- Login credentials: root, whatever-we-set-the-password-to
- Datacenter Name: Datacenter
- Datastore Names: datastore1
- Click Save

Initial configuration for BOSH. The vCenter must be reachable from the Ops Manager VM to validate settings
- click Director Config on the left navbar
- NTP servers: time.apple.com
- click Save
- click Create Availability Zones
- click Add
- Name: Cluster
- Cluster: Cluster
- Resource Pool: leave blank [1]
- click Save

Click “Add” to create an Availability Zone. “Availability Zone” is a term borrowed from Amazon AWS, and corresponds most closely with vSphere’s “Cluster”. Having multiple Availability Zones is a technique to make one’s application highly available. For our instructional purposes we need but one Availability Zone.
- click Assign Availability Zones
- Singleton Availability Zone: choose Cluster from the dropdown
- click Save
- click Create Networks
- click Add
- Name: VM Network
- vSphere Network name: VM Network
- Subnet: 10.9.8.0/24
- Excluded IP Ranges: 10.9.8.1-10.9.8.30 [2]
- DNS: 8.8.8.8
- Gateway: 10.9.8.1
- click Save
- click Assign Networks
- Infrastructure Network: select VM Network from the dropdown
- Deployment Network: select VM Network from the dropdown
- click Save
- click Installation Dashboard
- click the white-on-blue Install button on the right hand side
Monitoring BOSH Install Progress
Once you have clicked Install, you will see the install screen. Click Show verbose output to see detailed description of the progress of the installation.
When installation has completed, you’ll see a notification, “Changes Applied”
Click Return to Installation Dashboard
Congratulations, we have deployed Cloud Foundry’s Ops Manager and BOSH. Ready for more? Let’s install Elastic Runtime (i.e. Cloud Foundry), which is described in the subsequent post, World’s Smallest IaaS, Part 3: the PaaS.
1 The installation described in this blog post is wonderfully small, so we’re dispensing with Resource Pools; however, on much larger vCenter enviroments (e.g. Cloud Foundry Engineering’s internal vCenter servers), we have found it useful to use Resource Pools to maintain separate Ops Manager/Cloud Foundry deployments. We use a 1:1 mapping of Resource Pools to deployments (e.g. the hypothetical ESXi server esxi.dance.example.com may have several Resource Pools (e.g. tango, waltz, jig), each of which correspond to an Ops Manager/Cloud Foundry deployment (e.g. opsmgr.tango.example.com, opsmgr.waltz.example.com)).
The advantage of using Resource Pools comes into play when we need to destroy and rebuild a Cloud Foundry deployment: we can safely destroy every single VM in a given Resource Pool without worry of accidentally deleting a VM belonging to a different deployment.
2 We exclude a range that includes the gateway, the ESXi server, the vCenter server, and the Ops Manager server.
Readers who choose to colocate their IaaS deployment on their existing network (i.e. who choose not to create a new subnet) should take care to assign IP addresses outside the range allocated by their DHCP server.
For example, a network’s DHCP server and gateway is an Apple Airport Time Capsule whose address is 10.0.1.1, whose subnet is 10.0.1.0/24, and whose DHCP range is 10.0.1.10 – 10.0.1.200. In such a case, the range to exclude would be 10.0.1.1-10.0.1.200. If the ESXi, vCenter, and Ops Manager servers’ IP addresses lay outside that range, those IP addresses would need to be excluded as well (e.g. if ESXi’s IP address was 10.0.1.201, vCenter’s IP address was 10.0.1.202, and Ops Manager’s IP address was 10.0.1.203, then the excluded IP range would need to be 10.0.1.1-10.0.1.203)
About the Author