Currently, the VMware vCenter Server Appliance (vCSA) requires a Windows helper VM. This helper VM can be loaded with a number of different items, most notably vSphere Update Manager (VUM) and VMware Horizon View Composer. The services this VM can contain are listed later in this article. Suffice it to say, the helper VM (or VMs) become critical to your environment. I was running W2K8 R2 but decided to move to W2K12 R2. This was more of an effort than I had imagined. Most things worked just fine, but it took a bit of research to find out why some items did not work. See my previous article vSphere Upgrade Saga: vCSA Helper VM for the first part of this series.

I started with a fresh install of W2K12 R2, therefore eliminating any upgrade issues and keeping the old image in case I needed to go backward. Remember, the helper VMs end up as critical components for management. I installed the following services:

• VMware vCenter Site Recovery Manager (see Part 1)
• VMware VIX
• VMware vRealize Log Insight Agent
• VMware vRealize Log Insight Importer
• VMware vSphere Authentication Proxy (see Part 1)
• VMware vSphere CLI
• VMware vSphere PowerCLI
• VMware vSphere Update Manager (see Part 1)
• VMware vSphere Update Manager PowerCLI

I had issues with VMware Horizon 6 View Composer and HP OneView for vCenter. The issues were more about names and forgotten items than they were about real technical issues.

VMware Horizon 6 View Composer

The View Composer presented several issues.

• The certificate for Composer would not validate
• Once that was fixed, the user could not log in
• Once that was fixed, the VMs would not delete properly

The problems with the certificate were the name of the certificate and the version of the certificate. Multiple installs of View Composer caused numerous certificates to be available. But the real problem was related to the user’s logging in, not the certificate. I removed all the certificates. Next, I reinstalled VMware Horizon 6 View Composer just to be safe, by first stopping the VMware Horizon 6 View Composer service and then using the following to list the certificates via the command prompt, running as the Administrator:

> cd C:\Program Files (x86)\VMware\VMware View Composer
> sviconfig -operation=ReplaceCertificate -delete=false
Press 0 to abort

Then I did the following to remove the six or seven certificates. The key is to cut and paste the thumbprint from the each of the certificates in the generated list to the “…” below, so that the certificate is deleted. I did this for all of the certificates:

> sviconfig -operation=DeleteCertificate -certificatethumbprint=...

Next, I removed and reinstalled VMware Horizon 6 View Composer. It is always good to start fresh. Running the first command above showed only one certificate available—therefore, no more certificate confusion.

I then attempted to reestablish the communication, but that failed. So, on the Horizon View Connection Broker, I used ADSIedit (Start -> Run -> adsiedit.msc) to clear all the pae-SVI* attributes so that I can start with a clean slate within Horizon View.

• On the View Connection Broker, start ADSIedit
• Connect to the localhost using any name, a connection point of dc=vdi,dc=vmware,dc=int, and a computer of localhost:389
• Expand DC=vdi,dc=vmware,dc=int
• Expand OU=Properties
• Expand OU=VirtualCenter
• Right-click on the property within OU=VirtualCenter and select properties
• Locate all the attributes that start with pae-SVI and clear them
• Apply

Next, in Horizon View’s management interface, I recreated the View Composer configuration by using DOMAIN\user as the login. Alas, this did not work the first time, as I forgot to add the DOMAIN\user to the Administrators group on the helper VM. Once that was completed, everything worked as expected.

HP OneView

I have several problems with HPE OneView for VMware vCenter 8.0.1. I finally went to this version and was grateful that it was finally in an OVA format. Installation was a breeze, as was configuring vCenter StoreVirtual VSA. The problem was interacting with OV4VC from the vCenter Web Client.

• Clicking on a portlet (OA, SIM, IPM, iLO, VC, OV) would lead to a white or blank screen
• OA, iLO, and VC (Virtual Connect) portlets do not show up, as there is no communication between the iLO and HPE OneView for VMware vCenter

The first problem I eventually found by looking at the Firefox debugger. I noticed that the error had to do with X-Frames-Options not allowing cross-domain elements to render. The solution was to install the Ignore X-Frames-Options add-on. One exists if you use Chrome as well.

The second problem was plaguing. In effect, everything points to vCenter’s not being able to find the iLO. Without the iLO, there is no way to find the OA or the VC. This is usually a username/password problem. However, that has been double and triple checked. The ESXi version is an HPE version with all the offline bundles. This should aid in communication, but all communication is unavailable.

I tried the following:

• Enabling HPE SSO for the OV4VC system within iLO, OA, and HPSIM.
• Specifying per-host username and passwords
• Restarting the OV4VC virtual machine

Nothing seems to work. Communication is unavailable. A look at the OV4VC server.log  (which you have to download as a collection from the OV4VC Administration pages—https://ov4vc/ui/index.html—then unpack and inspect) shows many of the following errors:

portlets.collector ERROR Error collecting server_entity for HostSystem:host-XX: 404 not found.
portlets.collector ERROR Error collecting oa_entity. No iLO for HostSystem:host-XX.

And then many:

engines.ic4vc_webserver INFO Discovering entity
engines.csc_engine ERROR unable to get entity type

Further errors show many:

AttributeError: type object '' has no attribute 'entity_type'

What this sums up to me is that there is a faulty connection between the OV4VC and the blades themselves, perhaps due to using self-signed certificates. I am not sure. I cannot test any query, as the logs do not show the queries used to verify why a 404 error is occurring.

What is odd here is that the iLO is defined as the BMC device for Distributed Power Management (DPM). The ESXi 6.0U2 HPE April 2016 Custom ISO is in use on all the blades. I recently had to move ESXi to MicroSD card, so a reinstall was warranted.

Solution: And that was the problem. The iLO was defined as the BMC device for DPM. Once I cleared all the DPM settings (it is forced to be disabled when using VSAN), OneView for vCenter discovered everything correctly.