[caption id=“attachment_3287” align=“alignnone” width=“479”] Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0[/caption] Certificates are always fun… or should I say PITA? Whatever… During a small Horizon View PoC, I noticed an error message for the View Connection Server. That’s right, Mr. Connection Server. The certificate subject name does not match the servers external URL, as this screenshot clearly shows. [caption id=“attachment_3289” align=“aligncenter” width=“651”] Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0[/caption] But both settings are unused, because a VMware Access Point appliance is in place.

As part of a project, I had to deploy a VMware EUC Access Point appliance. Nothing fancy, because the awesome VMware Access Point Deployment Utility makes it easy to deploy. Unfortunately, the deployed Access Point appliance was not working as expected. When I tried to access my Horizon View infrastructure behind the Access Point appliance, I got a HTTP 504 error. The REST API interface was working. I was able to exclude invalid certificates, routing, or firewall policies.

I wanted to retire my Synology DS414slim, and switch completely to vSAN. Okay, no big deal. Many folks use vSAN in their lab. But I’d like to explain why I moved to vSAN and why this move failed. I think some of my thoughts are also applicable for customer environments. So far, I used a Synology DS414slim with three Crucial M550 480 GB SSDs (RAID 5) as my main lab storage.

A few days ago, I ran into a very nasty problem. Fortunately, it was in my lab. Some months ago, I replaced the certificates of my vCenter Server Appliance (VCSA), and I’ve chosen to use the VMware Certificate Authority (VMCA) as a subordinate of my AD-based enterprise CA. The VMCA was used as intermediate CA. The certificates were replaced using the vSphere 6.0 Certificate Manager (/usr/lib/vmware-vmca/bin/certificate-manager), and I followed the instructions of KB2112016 (Configuring VMware vSphere 6.

Customers that use HPE 3PAR StoreServs with 3PAR OS 3.2.1 or 3.2.2 and VMware ESXi 5.5 U2 or later, might notice one or more of the following symptoms: hosts lose connectivity to a VMFS5 datastore hosts disconnect from the vCenter VMs hang during I/O operations you see the messages like these in the vobd.log or vCenter Events tab Lost access to volume due to connectivity issues. Recovery attempt is in progress and the outcome will be reported shortly

I thought, everyone knows it, but I’m always being asked “Where’s the hardware status tab?” after an update from vSphere 5.x to 6. Many customers still use the vSphere Client (C # client), and steer clear of the vSphere Web Client. To be honest: Me too. I often use the C# client, especially if I do mass operations, or for a quick look at something. This is really nothing new, the answer is clear.

Apparently it’s “how to monitor hardware status” week on vcloudnine.de. Some days ago, I wrote an article about using SNMP for hardware monitoring. You can also use the vSphere Web Client to get the status of the host hardware. A third way is through the vSphere API. I just want to share a short example how to use vSphere API calls and pyVmomi. pyVmomi is the Python SDK for the VMware vSphere API.

The Simple Network Management Protocol (SNMP) is a protocol for monitoring and configuration of network-attached devices. SNMP exposes data in the form of variables and values. These variables can then be queried or set. A query retrieves the value of a variable, a set operation assigns a value to a variable. The variables are organized in a hierarchy and each variable is identified by an object identifiers (OID). The management information base (MIB ) describes this hierarchy.

In December 2013, VMware made an christmas gift to the community by releasing pyVmomi. pyVmomi is a SDK that allows you to manage VMware ESXi and vCenter using Python and the VMware vSphere API. Nearly 18 months are past since then and pyVmomi has developed over time. I’ve started to play around with Python, and I’ve written about the reasons in one of my last blog posts (Hey infrastructure guy, you should learn Python!

After updating my lab to VMware vSphere 6.0 U2, one of my hosts continuously thrown an error during an update scan. Host returns ESX error code 99, unhandled exception has occurred The first thing I’ve checked was the esxupdate.log on the affected ESXi host. This is the output, that was logged during a scan operation. 2016-04-04T13:42:13Z esxupdate: vmware.runcommand: INFO: runcommand called with: args = ‘[’/sbin/esxcfg-advcfg’, ‘-q’, ‘-g’, ‘/UserVars/EsximageNetTimeout’]’, outfile = ‘None’, returnoutput = ‘True’, timeout = ‘0.