UCS 2.0(1s) - b200-m2 - remove hard disk - constant error

Unanswered Question
Nov 15th, 2011

Setting up new UCS with 2.0(1s). The bundle shipped with the hard disks in each b200-m2. Prior to installing ESX5, the hard disks were removed (blade powered down) and blanking panels inserted. The service profile has a "no local storage policy" and the profile associates with the blades, boots, etc... but...

three of the four blades are reporting a dual F0181 errors:

Local disk 1 on server 1/4 operability: inoperable sys/chassis-1/blade-4/board/storage-SAS-1/disk-1/fault-F0181

Local disk 2 on server 1/4 operability: inoperable sys/chassis-1/blade-4/board/storage-SAS-1/disk-2/fault-F0181

I've re-acked the blades, I've decommisioned them, then re-ack'd the slots, etc. but can't seem to get the errors to clear.

Thoughts?

When I setup my fist UCS a year ago, I did the same process (removing the HD's) and don't recall having the issue.

Jeff

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Average Rating: 0 (0 ratings)
anikas Tue, 11/15/2011 - 19:28

There is a defect out there that may explain your issue.

CSCtt87598 Incorrect fault "local disk inoperable" set and cannot be cleared

1. When the LSI 1064E option ROM or the OS driver loads, it issues a port enable command to firmware for each drive in the blade. Once the port is enabled, the link between the LSI 1064E controller and the disk drive is brought up.

2. When the link between the LSI 1064E controller and a disk drive is down for any reason, the controller asserts the corresponding fault signal. If the link is up, the controller deasserts the corresponding fault signal.

3. When SAN Boot is configured, UCSM disables the LSI 1064E option ROM. Additionally, if an OS isn't booted, the LSI 1064E OS driver isn't loaded.

When SAN Boot is configured and no OS is booted, a port enable command isn't issued to firmware. Consequently, the link between the LSI 1064E controller and the disk drive isn't brought up. This results in the fault signal being asserted which is then reported to the user by UCSM.

This is expected behavior.

Sent from Cisco Technical Support iPhone App

JEFFREY SESSLER Tue, 11/15/2011 - 22:56

So in my case, I'm booting from SAN, but the fault is still up once the ESXi5 hypervisor has booted.

anikas Wed, 11/16/2011 - 04:31

I'm sorry I thought you had the error before esxi was loaded. I have found some instances of this error after people upgraded to 2.0. In these instances not everything was upgraded on the server like the board controller or CIMC. Can you check this under firmware management for this blade and compare it against the working ones? If this does not turn up anything then you would be best served by opening a TAC case. The fault should be clearing after you boot from SAN.

Sent from Cisco Technical Support iPhone App

anikas Wed, 11/16/2011 - 12:44

What is the local disk policy set to. Is it set to none?

Sent from Cisco Technical Support iPhone App

JEFFREY SESSLER Wed, 11/16/2011 - 17:41

I believe the problem is solved.

I had to:

Disassociate the service profile

Wait for the process to complete and the blade was in a power off state.

Remove the blade from the chassis

When the slot error came up, tell it to remove the server.

One the server was gone from UCS manager, re-insert the blade.

Once the server had completed its deep discovery, re-associate the service profile.

F0181 errors are gone.

anikas Fri, 11/18/2011 - 04:02

Excellent news looks like it was that defect and the deep discovery did the trick. Thanks for the follow up.

Sent from Cisco Technical Support iPhone App

Actions

Login or Register to take actions

This Discussion

Posted November 15, 2011 at 9:06 AM
Stats:
Replies:7 Avg. Rating:
Views:2149 Votes:0
Shares:0
Tags: ucs, 2.0, sas
+
Categories: General UCS Hardware
+

Related Content

Discussions Leaderboard