This post is a bit of funny one – as it really isn’t in series with the rest of my “Back to Basics” posts. It’s more “Let jump in the TARDIS, and go back to beginning”, shades of gravitational waves of the Big Bang. I decided to opt for the installable version of vCenter in previous posts because that’s what a lot of folks still use. But for my nested ESX environment I thought it would make things more “complete” if I deployed the vSphere5.5 edition of the vCenter Server Appliance (VCSA). The process is relatively straightforward. There are one or two anomalies. Firstly, if you want to assign a static FQDN/IP address you have to cancel the opening wizard after accepting the EULA. It’s possible to crank up the wizard again once that change has been made, but in the end I thought the manual steps were just as quick and easy. My second anomaly is how well the VCSA responds to FQDN/IP changes after it has been setup. I’m afraid to say I personally struggled with that – so I think if I was speaking to students like I used to, I’d recommend setting an FQDN/IP that probably never change that way you don’t have issues. One thing I found if you do go around renaming and re-ip-ing the VCSA is it has a knock on effect on the “Lookup Service”. I’ve seen that before a couple of times – when the postgres DB filled the VCSA partition in the 5.1 release.
Anyway, for sake of completeness here’s my back to basic post on the VCSA. Enjoy!
UPDATE:
This blogpost has recently updated with a “Show Me How” video, which demo’s the import and post-configuration of the VCSA…
Introduction:
VMware vCenter is the companies core management platform, and its common for other technologies both from VMware and third-parties to use it as the central point for accessing ESX hosts and clusters, as well accessing VMs and other components upon which they can add value or further orchestration. At the time of writing VMware support two version of vCenter – an installable version which runs on the Microsoft Windows platform and virtual appliance edition which runs on the SUSE Linux platform. In terms of their core APIs, the two editions are functionally the same. However, there are some features that are for the moment only available on the Windows editions. Historically, third-party add-ons have run as Windows plug-ins. Finally, whilst the scale of vCenter Server Appliance (VCSA) has increased in recent releases, it has lower configurable maximums. In production environments it is the Windows edition that predominates – and this is combination of history (the first version of vCenter was Windows only) and compatibility. With this said, the VCSA is considerably easier to deploy and update/upgrade than the Windows edition – and for this reason it might be more suitable for a small-medium sized deployment where “core” virtualization is all that is required.
After the configuration of the appliance all the core services that make up vCenter will be enabled including:
- vSphere Web Client
This is the core interface of managing VMware ESX hosts and clusters, Virtual Machines and templates – as well as configuring storage and networking. It’s a replacement for the older legacy “C#” vSphere Client. At the moment the older C# vSphere Client is still supported for direct management of a VMware ESX host.
- Log Browser
This service drives the collection of diagnostic information and presentation in the Log Browser column under the Manage tab on an VMware ESXi host or vCenter Server.
- ESXi Dump Collector
By default if the VMware ESX host encounters a critical error that causes a kernel panic (commonly referred to as a Purple Screen of Death – PSOD), the system will dump system data (not memory contents) that can assist in diagnosing problems. For diskless systems that do not have local storage, the “dump collector” service can be configured. This forces the VMware ESX host to send this diagnostics data across the network. It is particular interest to customers who adopt the “Auto Deploy” method of rolling out VMware ESX in their datacenters.
- Syslog Collector
VMware has its own simple “Syslog Collector” which collates all the log files on each VMware ESX into a central location. Whilst the service is useful – you may wish to look at VMware’s Log Insighttechnology, or alternative look at other syslog tools such as Splunk.
- vSphere Auto Deploy (Exception, Not Started by Default)
Auto Deploy is a method of rolling out VMware ESX host which allows for diskless and stateless operations. The physical server boots across the network using the PXE, and the configuration is delivered by associating the server with a “Host Profile” held within vCenter. It offers a very rapid deployment and easy way to “upgrade” from one distribution of VMware ESX to another. Currently, Auto Deploy requires Enterprize+ licensing.
Virtual Hardware Requirements
By default the vCSA uses 2 vCPUs and 8GB of RAM. In terms of diskspace the virtual disk is 134GB in size when first deployed the on disk consumption is 7GB if thinly provisioned. This has been regarded by some as quite a large amount of virtual resources – but it does include in many cases an embedded database.
From the Service on the appliance tab, the administrator select scalability can select from Small (100 hosts/1000 VMs), Medium and Large (400 hosts/4000 VMs). When configured for small inventory the appliance uses 8GB of RAM whereas medium and large consume 16GB and 24GB RAM respectively.
Software Requirements
As it is the vCSA does not require any specialist software for it to function, except a supported virtual platform for it to run on – in most cases this will vSphere/VMware ESX, although some homelabs do run it on a PC/MAC style equipment using VMware Workstation/Fusion in a VMware ESX “nested” configuration. The vCenter database is supported into two formats – an “Embedded” Postgres database which is built-in to the appliance. Currently, the only external database supported is Orcale. Due to the cost incurred in licensing Orcale, most organizations who deploy the vCSA use the built-in database.
vCenter Server Appliance Configuration
Step1. Download and Import the vCenter Server Appliance
The vCenter Server Appliance is downloadable in a pre-zipped format with .OVA extension. The .OVA format is based on the popular .tar extension – and contains the virtual disks (.vmdk), virtual machine configuration file (.vmx) and the Open Virtual Machine Format file (.ovf). When used with the vSphere Client’s import options, it will extract the single .ova file together with the files required need for it to boot. The import process needs to be run using the legacy vSphere Client. Once configured the administrator can add VMware ESXi hosts to it. In large environments many company configure a “Management Cluster” for running the vCenter Server together with other ancillary services. In smaller environments its entirely acceptable to run the vCenter on the same VMware ESX hosts and clusters it manages.
1. Open the vSphere Client on an VMware ESXi host
2. Click File in the menu, and select Deploy OVF Template
3. Click the Browse button, and locate the VCSA .ova file
4. Accept the informational OVF Template Details
5. Type a friendly name for the VCSA such as vcnyc
6. Next select a datastore to hold the VCSA. If all you have access to is local storage it is fine to use that, with view to relocating to more available storage at later a stage. If on the other hand the VMware ESXi host has already has access to storage you can select a class of storage that meets your needs.
7. Select a Disk Format for the VCSA. For maximum efficiency you can use thin provisioning.
8. Select a portgroup from the pull-down list of destination networks. At the very least you should have access to the default “VM Network” which should reside on the same Standard Switch and use the same physical NICs as used by the VMware ESXi host.
9. Finally, enable the option to Power on after deployment, and click Finish
Step2. Setting a Static Hostname and IP Address
The VCSA has a web-page front-end which listens on port 5840, and can be accessed remotely by IP Address the appliance finds a DHCP service. The front-end and port number is common one for many VMware Appliances. In this example we will configure the vCSA with a static IP address and hostname.
1. Locate the VCSA IP address. This can be seen in the General panel of the VCSA or by opening a Remote Console on the VM.
2. Open a web-browser at this IP address with
https://<IP_Address>:5480
3. Accept any certificate warnings that are displayed.
4. Next you should be presented with a login page – the default username is root and the password is vmware
5. At first logon a vCenter Server Step wizard will appear. You must Accept the EULA before proceeding
6. If you want to configure the VCSA with static IP address, you must cancel the welcome wizard.
7. Click the Network tab, select the Address column and switch the Eth0 interface to be Static
8. In the Hostname field, type a new hostname – confirm this hostname/FQDN is registered in DNS.
9. Set an Alternative DNS Server if you have secondary. Set the Static IPv4 IP Address and Subnet Mask – and click Save Settings
Note: Carrying out this task will result in a disconnect to the web admin page. The administrator will need to reload the web admin page to carry on with the remaining configuration. The web interface will warn the administrator of this fact.
Step3. How to Shutdown and Reboot the VCSA
Some system reconfiguration does require a reboot of the VCSA. The vCSA can be shutdown or rebooted from the System tab. Before shutting down the vCSA for whatever reason, make a note of the current VMware ESX host it is running to facilitate the power back on.
Step4. Select a Time Configuration
1. After login back into the VCSA Web Admin page, under the vCenter tab
2. Select the Time column
3. In this case we used VMware Tools synchronisation – so the vCSA retrieves the time from the VMware ESXi host – which in turn is configured for NTP. Note how if you join the VMware ESXi host to Active Directory this select time synchronisation method is used instead.
4. Click Save Settings
Step5. Enable vCSA Embedded Database
1. VCSA Web Admin page, under the vCenter tab under Summary click the Configure Database link
2. From the Database pull-down list, select Embedded
3. Click the Test Settings button, and then Save Settings – The test option loads the default schema values for the embedded database. Testing Settings is relatively quick..
But Saving Settings does take sometime to complete – however, once complete the status should state “Operation Successful” and it should also show the database schema in use. In this case “VirtualCenter Database 5.5”
Step6. Enable vCSA SSO Embedded Database
1. VCSA Web Admin page, under the vCenter tab under Summary click the Configure SSO link
2. Change the Deployment Type from Unconfigured to Embedded
3. Next set the password for the built-in user administrator@vsphere.local. This password must include all four character classes – uppercase, lowercase, numeric and symbol. Initially, this administrator@vsphere.local account is the only one that can login to the system until, the vCSA is configured for Active Directory and delegation has taken place.
4. Click the Test Settings button. Testing Settings is relatively quick…
5. Click the Save Settings button – accept the warning message. Saving Settings does take some time apply.
Step7. Start the vCenter Service
At this stage both the vCenter and SSO database will be configured, and we can click the Start button for the vCenter for the first time.
The first initialisation of the vCenter “vpxd” service does take sometime – but subsequent restarts take much less time.
Once the vCenter service has started you can access the Web Client using:
https://<FQDN>:9443
At this stage the vCenter Server Appliance is ready to use – however, there are some post-configuration tasks that are well worth looking at…
Configure Active Directory Integration
Note: This change enables Active Directory time synchronization as the main method of keep time accurate in the vCenter.
1. VCSA Web Admin page, under the vCenter tab under Summary click the Configure Authentication link
2. Tick the option to have Active Directory Enabled
3. Enter the Domain, Administrator User and password to join the vCSA to the Active Directory domain
Further configuration of the SSO service together with a delegation of priivileges to AD account is the same process with the Windows vCenter – typical post-configuration tasks found in the Web Client can be found here.
4. Reboot the appliance from System tab and Reboot button
Post-Configuration of vCenter Install (Links to Windows vCenter Content)
Other vCSA Admin Tasks
Services Configuration
The Services tab allows the administrator to control the amount of disk space assigned to the ESXi Dump Collector and AutoDeploy services. By default the allocation of disk space is 2GB for each services. Additionally, its possible to reconfigure the amount of resources allocated to the Inventory Service based on the number of hosts and/or VMs. You can select from Small (100 hosts/1000 VMs), Medium and Large (400 hosts/4000 VMs). When configured for small inventory the appliance uses 8GB of RAM whereas medium and large consume 16GB and 24GB RAM respectively.
Relocating LogFile and Core Dumps to NFS
By default Logfiles and Corp Dumps are saved a /storage/core location on the vCSA virtual disk. If not capped or relocated it is possible for this to fill partition. For ease of access many administrator prefer to relocate these file to some external storage, currently NFS is supported.
The syntax for specifying the NFS export is <IPaddress>:/export path. For example 172.168.3.254:/nfs/vcync would a valid mounting path to relocate storage location. A typical problem with this could be merely the inability to access the storage due to IP routing issues. The vCSA does by default support SSH so you can use an SSH client like PuTTy to run commands like ping and traceroute to test IP connectivity before starting
1. Navigate to the Storage tab
2. Tick the options to Enable storing log files on NFS and Enable storing core files on NFS
3. Specify the path for the NFS mounting location
4. Click the button to Test Settings and Save Settings.
Note: A reboot is required to enable these options.
5. Reboot the appliance from System tab and Reboot button
Updating the vCSA
One of the most compelling reasons to use the vCSA is the ease by which it can be upgraded from one release to another. This compares more favourably than using setup .exe packages to perform updates to the Windows vCenter. The vCSA allows for manual updating, as well as controls for check how frequently to look for updates and whether to apply them.
Manual Update:
1. Select the Updates tab
2. Click the Check Updates button. After a short while the appliance will update to indicate if a new version is available. In this case the system has discovered that there are Available Updates from vCenter Build 13122297 to Build 1476389. This second build is vCenter 5.5.0 b.
3. Click the Install Updates button to apply the new version. This process will take sometime. But once it has completed you will be instructed to reboot the vCSA to allow the updates to take affect.
4. To reboot the appliance from System tab and Reboot button
Configuring Auto Updates:
By default the vCSA does not carry out automatic updates – its possible to configure it to automatically check fro updates (but not apply them) or automatically check for updates, download and apply them. Once Automatic Updates is enabled you can configure the frequency of the check, and its also possible not pull updates from vmware.com, but from an offline CD-ROM bundle.
Other settings in the Admin Tab
The Admin tab on the vCSA can be used to control a couple of settings including:
- Reset root password (somewhat confusingly this referred to as “Administrator”)
The administrator@vsphere.local password and expiration is controlled by the SSO service
- Password Expiration
Turn off/on and set how long the password can be used before a reset
- Email account for password reset notifications
SMTP settings held under the Web Client (>>vCenter, >>vCenter FQDN, >>Manage tab, Edit button and Mail) and are used for the source relaying this email
- Enabled/Disable SSH Logins
By default SSH Logins are enabled for the root account. This can be turned off in environment where this is regard as insecure. It is still possible to use the Web Client or vSphere Client “Remote Console” to login to the vCSA and get an interactive login prompt.
- Certificate Regeneration
If the vCSA hostname or FQDN this option can be used to request the SSL engine to generate a new certificate which matches the new name, and replace the old certificate. These certificates are auto-generated, and are not trusted by a higher root CA authority.