We have the same. This is not a bug. Sometime this alarm is triggerd but it always goes back to green after a while (few hours).
From time to time the hardware wants to check te battery of raid BBWC en then you get the waring.
You also get the warning the battery is simply charging.
Hi
We have the same problem on hardware FUJITSI SIEMENS PRIMERGY BX620 S4.
We have the same. This is not a bug. Sometime this alarm is triggerd but it always goes back to green after a while (few hours).
From time to time the hardware wants to check te battery of raid BBWC en then you get the waring.
You also get the warning the battery is simply charging.
If what you say is correct and this is not a bug, I will disable this alarm. I can't go in every day and check to see if the alarm is just about the battery charging, I will end up ignoring the alarm sign on the hosts and miss a real alarm.
Hi SirOracle,
We did not have any issues on ESX3.5 (on our PowerEdge 1950's), once we installed Vsphere two of the hosts had this weird phantom alarm that we could not shake.
A polite staffer from VMWare Global support told me that it was something they were aware of internally, so If I were you I would just disable that alarm until further notice.
It is the alert generated from ESX CIM layer for your internal storage Controller BBU (Battery Backup Unit). I never seen this issue much on our servers, so it is not a bad idea to check the Storage Controller battery once.
All the servers are back to normal now, but it took several days. Under the tab Hardware Status I saw more information about the warning, "Learn cycle requested", not sure what was meant by that, but it all looks fine now.
Thanks guyes for keeping me calm while I waited for the warning to go away
i have this problem with FSC Primergy RX300 S3, but with ESX4 (not ESXi)
Systemstatus shows "Battery Status: Charging" (Leran Cycle Complete) with a yellow sign for more than 24hrs now.
I have this same issue (have had this since I deployed my first ESXi back on 3.5 U1)...its all ok. Its just the RAID controller battery going through a 'learn' 'recharge' cycle. I wouldnt worry about it. i have all Dell PE2950's and R710s.
I have this problem with FSC Primergy RX300 S5 with ESX4. It's very infuriating alarm.
It does not seem to be a problem with the communication between ESX and the Dell health report agent or whatever they call it as I first thought.
The common denominator between a lot of Dell systems is the PERC6 raid controller. The PERC6 is a re-branded LSI Logic board, which would explain how the same issue appears across different brands of machines.
When reading trough the changelog of the latest firmware upgrades for the PERC6 controller, I found this:
4. _Corrected an issue where the battery learn cycle delay was not delaying for the right amount of time._
So.. that should be it, and was. After I upgraded the PERC6 firmware, my three PE R610 stopped complaining in vCenter.
To everyone with this issue, upgrade firmware on your raid controller
//Chris
Yeah I saw the same thing too in the changelog, that must be the fix. I am assuming you flash the controllers firmware via the Dell Update disc correct?
Well, acually, with these Gen11 servers Dell has implemented somthing they call USC.(Unified Server Configurator) and it's a part of iDRAC that connects to a repository and downloads whatever you want to update. So basicly i can remote my machines from the office, reboot it and enter the USC and run firmware and driver updates through that... Now if I only could figure out how to get the backup tapes to run them selves over to the bank im set! 😄
But with older machines i suppose u need a bootable media with the fw files on it as wel. (could be wrong tho)
//Chris
We have this issue with a new Supermicro H8QM3-2 2041M-32R+B server with an LSI Megaraid 8708ELP SAS controller (with BBU).
Seems to be the LSI controller that causes this (about the same as the PERC6 LSI controller rebranded to Dell).
We run the newest LSI firmware (11.0.1.0017) and we still get this error message every other day. Even though the battery learn cycle are complete at the moment. Learn cycle repeat every 90 or 120 days if I remember correctly.
This message should not appear so frequently, so either this is a firmware issue where the firmware sends faulty data to ESX or ESX is reporting an error where no error occurs.
Well I just verified that upgrading to the latest 6.2.13 firmware for the Perc 6i controller in my Dell 2900's doesn't make the alarm go away. I had two hosts with the error that were running the latest and as soon as I took my 3rd host from 6.1.x to 6.2.13 the alarm immediately showed up on it. After waiting a day and updating the hardware status they went away on their own again. Opened a case with VM support asking why this keeps happening and their answer was basically it's a hardware problem, are you sure there's nothing wrong with your servers. Told them it's a cross platform vendor issue and there's nothing wrong with my servers. So they just basically gave me the blow off and told me to ignore the alarm. There's good practice. I think VM must have issues interpreting the status in general and they need to tweek how the sensor is monitored since it happens across dis-similar hardware.
Hi,
The same upgrade on DELL R610 didn't make it for us. ?:|
Still thoses 'Host battery status' alerts showing when ESX restores from standby or shutdown.
BTW, thoses alerts are not showing everytime.
Another thing to notice is that this "4. Corrected an issue where the battery learn cycle delay was not delaying for the right amount of time." fix didn't come with R216024 but with previous version R201071.
Dunno if the latest version did not reintroduced this "bug" and I didn't want to downgrade to verify this. So I'll still observe thoses alarms and if comming too many often, will simply disable them.
This is really anoying. I'll try to get some more infos from DELL & VMWare ASAP.
Hi Guys
We have 3 Dell R710 Servers in our Vsphere Cluster:
PERC FW: 6.2.0 (up to date)
We have the problem with all of the 3 servers, even a BIOS Update from 1.1.4 to 1.2.6 didn't solve the problem. The only solution for us was to disable the alarm :smileyblush:
Greets Thomy
I'm getting the same issue across all our IBM 3850M2
I have also been getting this issue on every IBM x3650M2 that I've placed in the field. Has anyone fixed it for a IBM or can someone from VMware comment on the issue?
Mike P
MCSE, VCP3/4