But at least in my case, the error counters keep going up every few seconds, but there hasn't been an event for 3 weeks. Cisco's message/fault guide indicates that this event is very serious error and that TAC should be contacted. If that's the case, how come these are logged as events and not faults? How come there is no call-home trigger for this condition?
The error accessing shared-storage is not harmful and does not affect the system operability
If the error counterts keep going up, try the following workaround:
1. Unplug the IO module.
2. Replug in the IO module. Make sure the module is in contact with the backplane firmly.
3. Reboot the IO module.
If after the workaround, the event keeps coming and going, you can leave it alone, since it does not hurt the system, but if it never clears it can be a chassis issue, so you may want to open a TAC case to confirm that.
Is your advice true if the error count is constantly increasing? Below is a related TAC note that one of my colleagues received:
Q: Why the error accessing shared-storage fault can happen and why it is not harmful.
A: In UCS chassis design, we build in a chip called, SEEPROM, on the backplane. SEEPROM is a permanent memory and used to store SAM DB version to avoid the case of SAM DB being overwritten by old version when failover happens. The communication between IO module and SEEPROM through a wiring on backplane is not repliable. To overcome this difficulty, we store the identical SAM DB version in three chassises rather than in one (so called three chassises redundancy). Because the communication between IO module and SEEPROM is not repliable, the error accessing shared-storage fault can happen sometimes - this is system behavior per specification and design. So, as long as one SEEPROM is readable, the UCS works normally. In your reported case, one chassis SEEPROM has read problem and the other two work. So, the error accessing shared-storage fault is not harmful and does not affect the system operability.
It seems that this isn't harmful if the error happens periodically. But what if the SEEPROM error count is increasing every minute? Doesn't that indicate that the SEEPRM can never be read? Wouldn't that be very serious if the UCS system had only one or two chassis?
Introduction This article will help you understand the steps on how to
download the UCS licenses from the Cisco Systems website and then
installing it on the UCS. The redacted (blue lines) just covers up
certain numbers for privacy please do not take them...
Introduction This article will help you understand and educate the
customer on how to clear their "expired licenses"
(license-graceperiod-expired) from their UCS-M. If a customer just
purchased a license and needs a step by step guide on how to download
==================== VIC FNIC driver does not support Virtual Volumes (
second level LUN ID ) An enhancement request has been created to track
this feature - CSCux64473 UPDATE - 12-14-2016 We made some traction on
the enhancement request - The Fix is in t...