As some of you read previously, I had been experiencing disk latency issues on our SAN and tried many initial methods to troubleshoot and understand the root cause. Due to other more pressing issues this was placed aside until we started to experience VMs being occasionaly restarted by vSphere HA as the lock had been lost on a given VMDK file. (NOT GOOD!!) The Environment:- 3x vSphere 5.1 Hosts

I’ve previously posted around this topic as part of another problem but having had to figure out the process again I think it’s worth re-posting a proper script for this. VMware KB 1016106 is snappily titled “ESXi/ESX hosts with visibility to RDM LUNs being used by MSCS nodes with RDMs may take a long time to boot or during LUN rescan” and describes the situation where booting ESXi (5.1 in my case) takes a huge amount of time to boot because it’s attempting to gain a SCSI reservation on an RDM disk used by MS Clustering Services.

The voting is now open for your favourite VMware virtulization blogs over at vmware-land.com With 200+ blogs now up and running with content covering every aspect from PowerCLI to VDI, technical deepdives and general VMware topical blogging! there is a very strong chance you will have read an article in at least a few of them.

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.

Today while creating new VMs from a template I got the error “the server fault invalidargument had no message” when editing the VM settings, the settings were modified successfully but the error was present whether a change had been made or not to the settings of the VM. A quick search of the web suggested removing said VM from the inventory and re-adding from the datastore, for many this fixed the issue but not for me.

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:

I’m very pleased to say that as of 21st December, I passed my VCP510 exam and am now VCP5 qualified! It’s something that I’ve wanted to do for a long time (since VCP3) but have never been able to get funding for the required course. My current employer sent me on the vSphere 5 Fast Track course earlier this year, so I was all set to take the exam. My exam experience was somewhat marred by a very poor first attempt which I narrowly failed.

This year for me personally has been extremely busy and eventful coupled with a great deal of learning. Without wishing to bore the pants off of any would be reader I shall summarize my ruminations as someone whom is still quite new to the VMware world. The first thing that comes to mind is a a couple of recent meetings I have had with VMware. Learning that they are now very keen to engage with ’the rest of us’ and by that I mean those of us working in SME’s as we represent well over 50% of their business revenue.

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.