Sam has been working in the IT industry for nearly 20 years now, and is currently working for VMware as a Senior Technical Marketing Manger in the Cloud Management Business Unit (CMBU) focussed on Automation. Previously, he has worked as consultant for VMware PSO, specializing in cloud automation and network virtualization. His technical experience includes design, development and implementation of cloud solutions, network function virtualisation and the software defined datacentre. Sam specialises in automation of network virtualisation for cloud infrastructure, enabling public cloud solutions for service providers and private or hybrid cloud solutions for the enterprise.
Sam holds multiple high level industry certifications, including the VMware Certified Design Expert (VCDX) for Cloud Management and Automation. He is also a proud member of the vExpert community, holding the vExpert accolade from 2013-present, as well as being selected for the vExpert NSX, vExpert VSAN and vExpert Cloud sub-programs.
VMware vSphere Single Sign On (SSO) can be installed in Multi-site mode to support local sign-on to vCenters that you want to be part of the same single sign on domain - for example, if you want to install Linked-Mode and have the advantage of a single pane of glass view, but can’t risk using a single SSO instance across the WAN. In other words, from VMware’s blog post:
I ran into this issue yesterday while reconnecting hosts in our vCenter Server following a complete reinstall - the reasons for which are a long story, but suffice to say that there were new certificates and the host passwords were encrypted with the old ones.
The LUNs had been unpresented at the hardware level by the storage team, but had not been unmounted or removed from vCenter. This is not the way to remove storage - let me re-iterate: remove storage properly.
One thing we have been meaning to do for a while but haven’t got round to is getting our Virtual Center Servers into “Linked” mode - essentially to provide a single pane of glass view of our entire virtual estate. One vCenter resides on the other side of our DMZ and manages hosts isolated for security purposes. I’ve created an IPSec server-to-server connection and allowed that through the firewall to secure traffic between the DMZ VC and LAN VC.
In vSphere 5.1 “Tags” replace the old custom attributes to provide a way of adding metadata to vSphere objects. The “Tags” are organised into categories to “define how the tags can be applied to inventory objects”. The easiest way to think of the difference is that custom attributes are “free text” and the tags are statically defined properties.
There is a wizard for converting custom attributes to tags, but it can get a bit confusing and is pretty poor - let me explain.
Here’s a lesson in checking the basics! I added new ESXi 5 host to a cluster today and spent a good couple of hours troubleshooting the error:
vSphere HA agent for host [Host’s Name] has an error in [Cluster’s Name] in [Datacenter’s Name]: vSphere HA agent cannot be correctly installed or configured After a few basic checks, migrating the host in and out of the cluster and rebooting, I headed off to google and began troubleshooting.
Just a quick post regarding the vSphere Management Assistant 5 - when deploying the vMA with a static IP address, you might see the following error:
Power On virtual machine Cannot initialize property ’ vami.DNS0.vSphere_Man- agement_Assistant_(vMA)’ , since network ‘’ has no associated IP pool configuration.
Edit the vMA virtual machine’s properties and go to Options, vApp Options and select disable. Acknowledge the warning and click OK to close the VM properties.
If you are close to the VMware ESXi storage path limit of 1024 paths per host, you may want to consider the following: local storage, including CD-ROMs, are counted in your total paths.
Simply because of the size and age of the environment, some of our production clusters have now reached the limit (including local paths) - you see this message in the logs
[2012-08-20 01:48:52.256 77C3DB90 info ‘ha-eventmgr’] Event 2003 : The maximum number of supported paths of 1024 has been reached.
I’m currently updating a very small 4-host cluster built for a specific application within our datacentre, the hosts are IBM HS22 blades. Since we have the VMware Update Manager infrastructure in place already, I downloaded the IBM ESXi 5.0 Update 2 ISO and imported it into Update Manager, created a baseline and then applied it to the cluster. I scanned the cluster with the baseline and was issued this warning for each host:
This is my current scenario: there are two existing servers in a stand-alone array - TMG01 and TMG02, and over in a DR site there is a new server (TMG03) that is in the process of being built. To comply with DR, all 3 servers must have their configurations up to date, however there is no direct communication allowed between the two DMZs, so simply adding to the new server as an array member is not possible.
A couple of months ago I posted the first version of my SCOM 2007 R2 Daily Health Check Script - here is version 2. It’s more than a little motivated by some friendly competition with a Microsoft PFE for SCOM, hopefully you’ll agree it’s a big improvement on the last version.
Updated for this version
Formatting changed to make it more readable and more compatible Added “Report generated on ” to the top of the report Management Server states reported as one section Default MP check moved to beneath the Management servers Agents in pending states moved to be with the Agent health states Clarified “Unresponsive Agents” and “Agents reporting errors” Management server alerts streamlined Added top 10 alerts for the last 7 days, and added top alerters for each I’m planning to wrap in some SQL database size checks and some of the other recommendations later - I’ll post again here when that’s ready 🙂
