The vSphere UMDS provides a way to download patches for VMware servers that have an air-gap, or for some reason aren’t allowed to go out to the internet themselves – in my case a security policy prevented a DMZ vCenter Server from connecting to the internet directly. The solution is to use UMDS to download the updates to a 2nd server that was hosted in the DMZ and then update the vCenter Server from there.
This article originally started off life as a record of how I managed to get this working, as a lot of my posts do, but this time it appears I am foiled. Last week, I had 3 vCenter Servers that appeared to be happily talking to each other in Linked Mode sharing a singe Multi-site SSO domain without any real issues. I had a single-pane-of-glass view of all 3 and I could manage them all from the one client.
Had a strange one after deploying an XP VM from a template today - the VM would not power on and threw the following error: An error was received from the ESX host while powering on VM [VM name]. cpuid.coresPerSocket must be a number between 1 and 8 Digging around on google the error seemed to be related to over-allocating vCPUs (e.g. assigning 8 vCPUs on a VM with 4 physical CPU cores).
So VMware’s Support Assistant is pretty awesome and it’s free! I thought I’d do a quick run through of the installation and set up for anyone who was interested, it’s fairly straightforward and if you raise a lot of calls or have multiple calls on the go it’s a time saver! VMware’s official page for the Support Assistant is here - https://www.vmware.com/products/datacenter-virtualization/vcenter-support-assistant/overview.html The OVF deploy is so simple I’ve just taken screenshots:
While adding an additional vCenter Server to our Multi-Site Single Sign On instance I encountered a problem as I entered the details of the existing SSO. The error thrown was: User credentials are incorrect or empty. Provide correct credentials. After a couple of hours online with VMware support I took a guess at the problem. On the existing Single Sign On Configuration I have added the Active Directory domain DefinIT and in order to enable integrated authentication from the vSphere Client I moved it to the top of the list - this meant that System-Domain is no longer the default authentication domain.
DataStore conflicts with an existing DataStore in the DataCenter – Manually disabling Storage I/O Control
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.
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
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: