In the past, I have written about various ways of "bootstrapping" vCenter Server (here and here) which can be useful for setting up greenfield vSphere deployments. This topic has always been of interest to me because it can be the most challenging to solve, especially when you only start out with a single ESXi host. Historically, these "bootstrapping" options have mostly been driven from a CLI standpoint which is not a bad thing when you think about it from an Automation standpoint and needing to replicate this a few dozen times. However, from a user experience point of view, it may not be as ideal, especially if this is an infrequent task. One of the other cool features of the ESXi Embedded Host Client (EHC) which recently had its v4 release is that it can be used to deploy Virtual Appliances stored in the OVF format.
OVF deployment had been around since v2 of EHC if I recall correctly, but it did not support all the different types of OVF capabilities such as Deployment Option as one example until most recently. One of the difficulties with OVF support on ESXi is not just supporting the ability to import/export but it is also supporting the full OVF specification which ESXi does not currently support today. This means, to provide full OVF support through EHC, it would have to implement a similar capability to what ovftool does today with the --injectOvfEnv option. Luckily, this was something that was added very early on based on my feedback which in my opinion is critical when it comes to greenfield deployments and one of the core use cases that I see for EHC.
Without further ado, below are the instructions on how to bootstrap the vCenter Server Appliance (VCSA) using the Embedded Host Client.
Step 1 - Download the VCSA OVA and then convert it to an OVF using either 7zip or ovftool. The reason you need to convert it to an OVF is that there is currently a known issue when trying to extract larger OVAs within the EHC. By doing this, you also speed up the time it takes to perform the upload and not have to wait for UI to extract it into the actual consumable format which is the OVF and VMDKs.
Step 2 - Click on the "Create/Register VM" option and then choose "Deploy a virtual machine from an OVF or OVA file" option. You will need to specify the name for your VCSA along with the OVF and the 3 VMDKs that is included if you are using vSphere 6.0/6.0 Update 1.
Step 3 - Next you will configure the VM Network and the disk provisioning option. You will also be asked to select the "Deployment Type" which is an option in vSphere 6.0/6.0 Update 1 that allows you to specify whether you are deploying an Embedded VCSA, External vCenter Server or External Platform Services Controller (PSC). You may notice the drop down includes duplicate entries and the reason for this is how the VCSA OVA was built which re-uses the same description in each of the labels but they actually have different meanings. Below is a quick table of the correct mappings to the current ordering parsed by EHC to the different VCSA Deployment Types:
| Label | Actual Deployment Type |
|---|---|
| Tiny (up to 10 hosts 100 VMs) | Embedded VCSA Node |
| Small (up to 100 hosts 1K VMs) | Embedded VCSA Node |
| Medium (up to 400 hosts 4K VMs) | Embedded VCSA Node |
| Large (up to 1K hosts 10K VMs) | Embedded VCSA Node |
| Tiny (up to 10 hosts 100 VMs) | External vCenter Server Node |
| Small (up to 100 hosts 1K VMs) | External vCenter Server Node |
| Medium (up to 400 hosts 4K VMs) | External vCenter Server Node |
| Large (up to 1K hosts 10K VMs) | External vCenter Server Node |
Step 4 - You will need to fill out the OVF properties which are required to properly configure the VCSA. The following 3 sections are the ONLY ones you need to modify for install:
- Networking Configuration
- SSO Configuration
- System Configuration
Step 4a - The Networking Configuration section will require you to specify the following:
- Host Network IP Address Family - ipv4 or ipv6
- Host Network Mode - static or dhcp
- Host Network IP Address - IP Address of the VCSA
- Host Network Prefix - This is the CIDR notation of the network you plan to place the VCSA on. Example would be /24 (255.255.255.0) which you need to specify as just 24
- Host Network Default Gateway - Gateway to use
- Host Network DNS Servers - DNS Server to use
- Host Network Identity (optional) - This is the FQDN of the VCSA. If you are in a DHCP enabled environment, you can leave this blank which it will automatically default to localhost.localdomain
Step 4b - The SSO Configuration section will require you to specify the following:
- Directory Password - SSO Admin password
- Directory Password confirm - SSO Admin password
- Directory Domain Name - SSO Domain (select vsphere.local if you want the default which I would recommend)
- Site Name - SSO Site Name
- New Identity Domain - This is required if it is a new setup and you are not setting up SSO replication with an existing PSC
Step 4c - The System Configuration section will require you to specify the following:
- Root Password - The root password for the OS
- Root Password confirm - The root password for the OS
- SSH Enabled (option) - If you wish for SSH to be enabled after deployment
- Tools-based Time Sync Enabled - If you do not have an NTP server, you should select this option
- NTP Servers (optional) - Specify a valid NTP server that you wish to use
Step 5 - You will have the ability to review your configurations before starting the deployment. You should double check to ensure that all OVF properties are correct, else you may get a failed deployment.
Step 6 - Once you are ready, go ahead and click the "Finish" button. This will start the OVF import which you can monitor using the Recent Tasks pane. As part of the OVF/OVA workflow, once the import has completed, it will automatically power on the VM for you. Please do NOT interrupt this process as EHC will be injecting the OVF properties you had specified earlier to the VM to ensure the VCSA will be properly configured.
Once the VM has been powered on, you can then click into the VM Console to view the status of the deployment and hopefully in a couple of minutes, you will have a fully configured and functional VCSA ready for use!
Although EHC today has implemented a pretty generic OVF/OVA interface in the UI to support almost any OVF/OVA, you can see how this could be further improved specifically for the VCSA deployments from a user experience perspective. Who knows, this might get even easier in the future 🙂
Cool feature. I am going to try it tomorrow.
You refer to using the OVF to do this deployment. You say to download it as though it is available from vmware, but all I have seen indicates that there is no longer an OVA or OVF VCSA deployment option. You need to use the ISO. Can you explain what I'm missing?
The OVF/OVA has always been available, even with the vSphere 6.0. What was new with that release is that it was indeed bundled within the ISO which included two preferred ways of deploying via new Guided UI or Scripted CLI method as going through OVF properties were not very user friendly and more importantly, there's no pre-checks/validations that could be built in unlike the new deployment methods. Have a look at this article (paragraph 1) http://www.virtuallyghetto.com/2015/02/ultimate-automation-guide-to-deploying-vcsa-6-0-part-1-embedded-node.html which describes where the OVA is located at within the VCSA ISO
This is a very promising new deployment method, especially for new-to-VMware folks, and sure beats manual error-prone editing of JSON files.
Hard-coding IPs is easiest, of course, with no DNS, but also a bit of an ugly UI later on (IPs instead of descriptive names).
Trying to get names/FQDN is a bit tougher, for the average home user with consumer WiFi router for DHCP/DNS (with no forward and reverse DNS/FQDN lookup). While working to refine the process that I've used before when 6.0 first arrived, I did notice that it sure seems that this new deployment method described here reveals that the first boot still relies on DHCP services being available. Turn DHCP off, no go, there's a network time out message early in that firstboot seen "Waiting for mandatory devices: eth0" and you end with a broken VM stating "Failed to start services. Firstboot Error." At that point, it does have the requested static IP assigned shown in vSphere Client, but the VCSA appliance is scrogged/non-functional. Any ideas for a way around this insistence on DHCP presence for proper first boot?
I was getting an error that it failed to inject the configurations. any idea on what the fix would be for this? We always had similar issues deploying through the default deployment method.