Below vCenter 6.0 U1 alarm frequently changing, any idea ?
alarm.VsphereClientHealthAlarm - Event: Status change (7582963) Summary: vsphere-client status changed from green to yellow Date: 9/21/2015 12:05:53 PM Arguments: componentId = vsphere-client componentName = vsphere-client newStatus = yellow oldStatus = green serviceId = vsphere-client
Windows, not sure. But appliance, it is a known issue. Hopefully a patch/update will fix this.
This fix took care of the issue for a while in our environment, but it has since returned. I hoped that maybe the alarm setting somehow got set back to it's default, but when I checked, it was still in effect. I restarted the service again and even rebooted the vCenter appliance and it's still happening at both our disaster recovery and production sites.
Has anybody else implemented this fix and had the problem return later?\
Gave this a look tonight. Seems like the vmware-dataservice-sca/vmware-sca is looking for a script called "dummy_path" (I know).
Found this little gem in the sca.log:
grep -Hin "dummy" /var/log/vmware/sca/sca.log|head -1
/var/log/vmware/sca/sca.log:8:2015-12-30T23:17:36.083Z [pool-5-thread-14 ERROR com.vmware.sca.servicecontrol.handlers.ScriptControlHandler] Failed to locate script; name: dummy_path, dirs: [/usr/lib/vmware-sca/scripts, /etc/vmware-sca/scripts], [java.lang.Exception: Script doesn't exist; path: /etc/vmware-sca/scripts/dummy_path]
So created a little "dummy_path"-script, which will only exit when run.
#I'm dumb, and will now exit. With a zero. Because. Awesome.
I didn't have the time to check which process which was trying to run the script, so I gave everyone rights (I know. Not cool).
chmod 777 /etc/vmware-sca/scripts/dummy_path
Profit (I've not seen the issue since, nor any complaints about the dummy_path-script). Oh, and I'm running the VCSA 188.8.131.5200 Build Number 3018521.
Guessing this isn't a "supported workaround", or anything like that (and may cause other problems). Just playing around with my home lab.
Same issue running V6 U1 on windows 2012 R2, reboot seems to clear the problem for a while.
This is a vanilla install, i'm planing on moving my current ESXi host onto this new VC.
Does anyone know if this been confirmed as a known issue or is there something I need to do, like call tech support.
If running VC in Windows, you could check the sca.log from:
%allusersprofile%\vmware\vcenterserver\logs\sca\sca.log, which is usually C:\programdata\vmware\vcenterserver\logs\sca\sca.log
Like others, if it's regarding the "dummy_path"-script, this (hopefully) is a known issue by now. As commented above. I've created a "dummy_path"-script (which will only exit, with the status 0 see my comment above). I've not tested this in VC in Windows, but guessing it's the same issue (script not found = script not found, right?).
Before, I was getting alarms from "Data Service" every 1-2 minutes. If really quick, I saw something like "The Data Service container process is running low on heap memory (> 90% utilized.)". I've also traced the sca-process (java), just to monitor the memory usage.
The alarms haven't triggered since I created the "dummy_path"-script.
It seems that newest patch (VC-6.0.0U1b-Appliance Build 3343022) resolved this bug
Windows update 1b seems to have fixed the issue, however it still complains it can't find the file dummy_path in the sca.log
I tried to create a script as suggested above but it couldn't recognize it as a win 32 application.
Ok my hura optimism was premature. The problems still occurs.
I know. Bummer. Actually seemed fine after the U1b-upgrade (I upgraded about 5 days ago), until last night, then the alarms hit me (lots of email notifications). Seems like my little "dummy_path"-script doesn't apply as a workaround this time (even though the errors disappears from the sca.log). Removed the SendEmail-action for now. Maybe I'll dig into the VCSA logs later.
in case anyone is experiencing, I'm running windows vcenter 6U1b and am still getting the issue
same problem here, windows 2008 r2 running latest vcenter 6U1b.
any solution or workaround for vcenter on windows ?
Same problem here....
vpxd status changed from green to yellow and keeps coming back.
I ran into a similar issue after upgrading from vCenter 5.5 to 6.0 U1b (Windows Server) this morning: I'd receive alarms for vsphere-client and vmware-dataservice-sca status changes green -> yellow every 10 - 15 minutes and came across this thread while troubleshooting.
I added the server's IP address under runtime settings "Managed IP Address" and it's been over 1 hour since I received any more alarms... so I'm hoping that did it, at least for my scenario. This setting is blank by default, which might also explain why it's happening to fresh installs? I also have a ticket open with VMware to see what they have to say about it...
Not really. Same problem after upgrade.
Interesting, we received these alarms when doing a fresh install of 6.0 U1a. We just recently updated to 6.0 U1b in hopes this issue would go away however that is not the case. We are actually receiving even more variations of the green --> yellow alarms including but not limited to dataservice, syslog, vsphere web client etc. Originall we only received dataservice alarms.
Seeing them too on my Update 1b appliance.
I added too and frorn yesterday (>24h) i dindn't receive any alarms.
I've also created a VMware SR for this and their response (which worked for me) is:
1) Log into vCenter server using thick Client/ vsphere client. Navigate to Alarm Settings *--> Health status changed alarm --> Edit Settings --> Triggers --> Change Status from unset to Warning.
2) In advanced options on the same page --> Select argument as data center name --> Operator as equal to --> Value is Data Center name.
3) Click on Actions Tab --> Select warning to alert and Warning to OK as once.
4) Restart the vCenter Server Services.
Adding the "vCenter Server managed address" in the "Runtime settings" seems to have solved the issue for me as well.
That's Web Client > vCenter > Manage > Settings > General > Edit > Update "Runtime settings". Reboot VC-server.
PS: Still running the latest VCSA (U1b / 3339084).
This so far has kept these alarms at bay.