Today was always going to be a bit of a funny day as I scheduled the VCAP5-DCD exam for 10am this morning. I am happy to say that I passed! I’m a bit light on VMworld to report today, so forgive my DCD experience to pad it out! Preparation I have to confess my prep for this exam was light – I literally only watched the TrainSignal course by Scott Lowe (@scott_lowe) and just about finished that last night in the hotel!
John Troyer (@jtroyer) asked a question on Twitter last night about a CloudCred prize of $1000-2000: That got me thinking – was it possible to create an entire 2 host lab with storage on a $2000 budget? My first step was to convert it into a proper currency: I figured that I’d stick to the Intel NUC route that I’ve gone down for my lab at home – I love the NUC for its tiny form factor, silent operation and really low power consumption.
After my previous post about studying and the exam experience of the VCAP5-DCA exam (and 3 weeks of waking up to check my phone for the email all night) I am pleased to say that I received my Exam Score last week and it was a pass! I was really pleased to see that I passed with a very decent margin too, which was great! The rushed nature of the exam and long wait for the results leaves you going over the exam in your head convincing yourself how badly you’ve done, so it came as a huge relief and surprise.
With the release of vCenter Log Insight Public Beta (http://communities.vmware.com/community/vmtn/vcenter/vcenter-log-insight) I thought I’d strike while the iron is hot and run through the installation and configuration. Deploying the OVF This is such a bread and butter task that it doesn’t require more than a few words – it’s definitely worth looking at the Sizing PDF before you deploy (VMware-vCenter-Log-Insight-1.0-Beta-Virtual-Appliance-Sizing.pdf) as it’s not small even for a test installation. If you’re using less than the recommended 8GB RAM there are additional steps to change the heap size for performance.
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.