Subscribe to my RSS Feed
Join 2,575 other subscribers
My ramblings on the stuff that holds it all together
I’ve had some SRs open with VMware GSS lately on some vCAC issues, and the first thing they usually ask for is logs – to save yourself (and GSS) some time it’s worth gathering up the following logs and providing them immediately when you open your SR (using the upload tool) – this helps GSS to hit the ground running with your issue
|Log description||Log File Name||Default Location|
|vCAC Installation log||MMDDYYHHMMSS.txt||c:\vcacLog|
|vCAC Server (everything) log||All.log||C:\Program Files (x86)\VMware\vCAC\Server\Logs|
|vCAC Server (errors only) log||Error.log||C:\Program Files (x86)\VMware\vCAC\Server\Logs|
|vCAC Agent logs||vSphereAgent.log (name based on Agent type)||C:\Program Files (x86)\VMware\vCAC\Agents\<AgentName>\logs|
|vCAC DEM Orchestrator (everything) log||DEM Orchestrator Name_All.log||C:\Program Files (x86)\VMware\vCAC\Distributed Execution Manager\<DEM-OrchestratorName>\Logs|
|vCAC DEM Orchestrator (errors only) log||DEM Orchestrator Name_Errors.log||C:\Program Files (x86)\VMware\vCAC\Distributed Execution Manager\<DEM-OrchestratorName>\Logs|
|vCAC DEM Worker (everything) log||DEM Worker Name_All.log||C:\Program Files (x86)\VMware\vCAC\Distributed Execution Manager\<DEM-WorkerName>\Logs|
|vCAC DEM Worker (errors only) log||DEM Worker Name_Errors.log||C:\Program Files (x86)\VMware\vCAC\Distributed Execution Manager\<DEM-WorkerName>\Logs|
|vCAC DEM logs – Additional logging||Windows Event Viewer||N/A|
|vCAC Repository logs||Repository.log||C:\Program Files (x86)\VMware\vCAC\Server\Model Manager Web\Logs|
|vCAC Website logs||Windows Event Viewer||N/A|
vCAC is a complex product with a lot of moving parts, it’s a pain to have to switch back & forth between monitoring views in the UI.
The IaaS server is a Windows box, and does most of the heavy lifting so you can’t just SSH in and tail a log file (well, you sort of could… but)
I like to have all this info on a secondary monitor scrolling past in realtime, mainly so I can look like I am in the Matrix but it’s useful when you’re trying to debug a weird edge-case that only happens in real-time, I achieve this by..
Using mTail on my Windows administrative workstation.
Mapping a drive to the C$ share on my IaaS server
Open the following log files in mTail and put it on a secondary monitor so I can watch what’s going on in real-time (don’t forget to hit start to monitor the file)
\\IaaSserver\c$\Program Files (x86)\VMware\vCAC\Agents\<NAME OF YOUR AGENT(S)>\logs\vSphereAgent.log
\\IaaSserver\c$\c$\Program Files (x86)\VMware\vCAC\Server\Logs\All.log
For good measure you can also open your vCenter log files in the same way if you want to.
Handy hint – if you are tryign to catch a specific errror in the noise of the logs, check the Filter box and put the search expression in – then it will only show when that message occurs in the logs (like doing tail –f <file> | grep “string” in *NIX). you can use the following strings to limit to certain message categories.
if you’re using the vCAC vCenter Orchestrator (vCO) client to customise a workflow it uses a Java client.
If you recently updated or downloaded Java to your machine then you’ll see the following error message..
This is because it is using a self-signed certificate, and the latest Java builds prevent this as a security measure, reasonable I guess.
You’ll need to add your vCAC appliance URL to the exception list, note you need to specify the port number, or it won’t work. you can set this ON YOUR CLIENT WORKSTATION via Control Panel –> Java / Security on a Windows machine.
And you will now be able to connect, albeit with some warnings from the Java client.. (as shown below)
The moral of the story is, Java may run on 3 billion devices, but all of them break in subtle ways, each & every time when you update something 🙂