Subscribe to my RSS Feed
Join 2,575 other subscribers
My ramblings on the stuff that holds it all together
If you came to London VMUG last week and were one of the people who attended my vCAC real world session, you’ll have seen the demo gods not shining kindly on me as I couldn’t logon to my vCAC demo environment.
This was particularly annoying as I was testing it not 15mins before my session started and it was working 100%
With some quick on-stage debugging I found that I was unable to logon as any of the tenants on my vCAC deployment so was unable to show my cool demo 😦
After some further digging I found that I could logon to the root org https://vcacserver.net/shell-ui-app/ using the email@example.com account but nothing else and I couldn’t logon to any of my tenant organisations despite the credentials being 100% correct.
When logged onto the root org as administrator I could see the following error… which translates as “not good, your tenant has disapeared and I have an internal problem”
After some digging this seems this is a sort of time-bomb bug that has only been recently discovered, it occours after 90 days and will stop tenants being able to login using LDAP credentials.
When attempting to log into a tenant, a blank page is displayed with a Submit button in the upper left corner.
You receive a System Exception error when accessing the tenant identity store configuration page and the identity store configuration may have disappeared.
You cannot log in to a tenant using an LDAP account.
You are unable to add a new identity store configuration to the affected tenant.
The tenant identity store disappears from the SSO Administrator login.
This KB article details the issue and a temporary workaround
I assume a fix will follow in due-course.
In my case I worked out that it was exactly 90 days until about 15mins before my vCAC session started last Thursday – which is bad-timing taken to the extreme.
Once I have verified this fix in my environment and resumed access I will post a video of my intended real-world demo, where I’m using vCAC to deploy a VM and talk to a massive “enterprise system” via a REST API (e.g Twitter :)) – whilst an odd use-case this is an easy way of demonstrating the extensibility of vCAC (well, when it works anyway)
So, in summary if you have a vCAC implementation that you deployed since 6.0.1 came out you’re going to run into this install date +90 days.
If you are trying to add a blueprint using the clone or linked clone methods in vCloud Automation Center 6.x (vCAC) using a recently created VM or template from vCenter you won’t be able to find it in the search box no matter how hard you try or esoteric your search strings.
This is because by default the vCAC server only inventories the VMs on your vCenter every 24hrs, you can either manually perform an inventory update or increase the frequency.
It was confusing (to me) as the agent logs showed by vSphere IaaS server polling the vCenter service sucessfully, frequently so I assumed it would be looking for new VMs etc, alas no.
You can see the polling & inventory activities in the agent’s log file at the following location
c:\program files (x86)\VMware\vCAC\Agents\\Logs\vSphereAgent.log
To resolve this you can either A) wait 24hrs (hmm) or B) go to Home/Infrastructure/Compute Resources
Right click on your compute resource (e.g vCenter)
And click Data Collection
Under the inventory section you can update the frequency, or click request now to force an immediate update
This took 5-10mins to complete on my fairly large test cluster.