Dell PERC Question (Server Down)
-
So what was the general consensus here?
OK to boot XenServer off a name brand USB stick?
Or is the DELL server going to throw a fit about that, too?
-
Yes, we all use brand name.
-
@BRRABill said in Dell PERC Question (Server Down):
OK to boot XenServer off a name brand USB stick?
Yes, should work (I'm doing it.)
-
Any name brand stick should be fine.. just stay away from the SW freebies
-
@scottalanmiller said in Dell PERC Question (Server Down):
Yes, we all use brand name.
Continual crashing of non-DELL stuff after being told not to use non-DELL stuff has put the fear of ... DELL ... into me.
-
@BRRABill said in Dell PERC Question (Server Down):
@scottalanmiller said in Dell PERC Question (Server Down):
Yes, we all use brand name.
Continual crashing of non-DELL stuff after being told not to use non-DELL stuff has put the fear of ... DELL ... into me.
Other than non-Dell firmware, what non-Dell stuff has caused an issue?
-
@scottalanmiller said
Other than non-Dell firmware, what non-Dell stuff has caused an issue?
That's it.
Just where all my data is stored. Nothing major. LOL.
-
Well, after talking/debating/learning/arguing via chat with @scottalanmiller about how the server itself had nothing to do with the drives not working because of being non-DELL drives, I decided to reboot the server to refresh the iDrac settings for the drives.
Well, it turns out that when the server came up, the array was in a degraded state again.
I received the same "foreign configuration" error. But when I went into the config utility, it was different than previous times as one of the drives was showing up. And one said "missing" ... normally both of the drives go missing. So I chatted up DELL tech support again.
This time we cleared the foreign config on the drive, because it appeared to be on the "missing" disk. Sure enough, that made the drive appear again, we assigned it as a hot spare, and the array went into rebuilding mode. Before too long there was a fully functional array.
One of the other things I noticed was that the iDRAC was not showing the drives as having any status. Rather, they were a question mark. I asked about this, and the tech said there was a later firmware. (The last tech said there was not.) We updated the iDRAC firmware, and now all the drives are showing up properly.
One strange thing to note: the EDGE drives are showing up with green check marks, which they were not before. Maybe they strong armed the PERC into convincing it they are from DELL.
I know I've been told the iDRAC is out of band and has NOTHING to do with the server, but all of these problems started within 24 hours of enabling the iDRAC on my server. (This array was running for months wth no issues.) And clearly it was having trouble getting the status info of the drives. There is no possible way the two things could be related?
-
Well - I do agree they are separate, apparently this doesn't matter. Like your situation, during a recent iLo upgrade the fans on my server would spin up... hold.. spin down.. etc. I down graded the firmware and that problem went away.
When you were talking to Edge, did they ask you what version of iLo you had?
-
@BRRABill said in Dell PERC Question (Server Down):
I know I've been told the iDRAC is out of band and has NOTHING to do with the server, but all of these problems started within 24 hours of enabling the iDRAC on my server. (This array was running for months wth no issues.) And clearly it was having trouble getting the status info of the drives. There is no possible way the two things could be related?
That is correct insofar as you have nothing to do with the server. The DRAC is an outside actor, just like you are. You can make changes to the system as an outside actor, so can the DRAC. So the DRAC is not part of the server itself, but it does have access to manage it just like a person would.
-
@scottalanmiller said in Dell PERC Question (Server Down):
@BRRABill said in Dell PERC Question (Server Down):
I know I've been told the iDRAC is out of band and has NOTHING to do with the server, but all of these problems started within 24 hours of enabling the iDRAC on my server. (This array was running for months wth no issues.) And clearly it was having trouble getting the status info of the drives. There is no possible way the two things could be related?
That is correct insofar as you have nothing to do with the server. The DRAC is an outside actor, just like you are. You can make changes to the system as an outside actor, so can the DRAC. So the DRAC is not part of the server itself, but it does have access to manage it just like a person would.
So perhaps in his case, the DRAC was trying to take logs from the drives and caused them to crash?
-
@Dashrender said in Dell PERC Question (Server Down):
@scottalanmiller said in Dell PERC Question (Server Down):
@BRRABill said in Dell PERC Question (Server Down):
I know I've been told the iDRAC is out of band and has NOTHING to do with the server, but all of these problems started within 24 hours of enabling the iDRAC on my server. (This array was running for months wth no issues.) And clearly it was having trouble getting the status info of the drives. There is no possible way the two things could be related?
That is correct insofar as you have nothing to do with the server. The DRAC is an outside actor, just like you are. You can make changes to the system as an outside actor, so can the DRAC. So the DRAC is not part of the server itself, but it does have access to manage it just like a person would.
So perhaps in his case, the DRAC was trying to take logs from the drives and caused them to crash?
Possible. Like maybe they had an issue and the DRAC just tried to read data from them and triggered the event. Probably would have done the same if accessed manually.
-
So (as usual) I misread/misunderstood what you guys were saying.
It IS possible that some bad code in either the iDRAC or the way it interfaces with the server could cause the server to crash?
-
@BRRABill said in Dell PERC Question (Server Down):
So (as usual) I misread/misunderstood what you guys were saying.
It IS possible that some bad code in either the iDRAC or the way it interfaces with the server could cause the server to crash?
Yes, it is possible that the iDRAC is triggering an issue. The interface, other than shorting things out electrically, should be protection against code issues. If code issues make it past the demarcation point, that's an error on the server side, not the iDRAC side. Even if it is triggered by bad code in the iDRAC, the iDRAC only gets to do as much damage as the server lets it do.
So in the same way that you could tell the server to do something bad (delete your configuration) or could simple pull out a taser and fry the motherboard, the iDRAC can, too. But the iDRAC's code can only make it become a bad actor like you might yourself after a weekend bender.
-
@scottalanmiller said
So in the same way that you could tell the server to do something bad (delete your configuration) or could simple pull out a taser and fry the motherboard, the iDRAC can, too. But the iDRAC's code can only make it become a bad actor like you might yourself after a weekend bender.
I feel my admin skills get better after a few beers, thank you!
-
How does my fan issue get caused by the iLo?
Would it be something like, the iLo software has a bug, when it tries to read the fans it uses the wrong API calls, which the fans read as an error, and when the fans read an error this spin up?
-
And I'm not blaming the iDRAC.
Like I said, I just figured it would a reboot when it got licensed, but it did not. (That's actually the way things should ALWAYS work!)
And while I said it did not happen in the months prior to enabling the licensing on the iDRAC, that was also the weekend I installed my production mail server on a XS VM on this. SO, there is likely a lot more array activity.
I have reached out to EDGE and xByte, and will try to work with them further on the issue and report back. They have not been on ML in a while so hopefully they will chime in. (Actually, I will send an e-mail to let them know.)
-
@scottalanmiller sai
If code issues make it past the demarcation point, that's an error on the server side, not the iDRAC side. Even if it is triggered by bad code in the iDRAC, the iDRAC only gets to do as much damage as the server lets it do.
But the iDARC has full access to the server.
I understand if I did sometthing stupid, the server would let me, but I just don't see how using the iDRAC I should be expecting that kind of behavior.
Or that if the iDRAC told the server to do something bad we should be blaming anyone else than the iDRAC.
-
@Dashrender said in Dell PERC Question (Server Down):
How does my fan issue get caused by the iLo?
Would it be something like, the iLo software has a bug, when it tries to read the fans it uses the wrong API calls, which the fans read as an error, and when the fans read an error this spin up?
ILO reads the temperature sensors, it might pass the sensors out and then the speed control back in.
-
@BRRABill said in Dell PERC Question (Server Down):
@scottalanmiller sai
If code issues make it past the demarcation point, that's an error on the server side, not the iDRAC side. Even if it is triggered by bad code in the iDRAC, the iDRAC only gets to do as much damage as the server lets it do.
But the iDARC has full access to the server.
I understand if I did sometthing stupid, the server would let me, but I just don't see how using the iDRAC I should be expecting that kind of behavior.
Or that if the iDRAC told the server to do something bad we should be blaming anyone else than the iDRAC.
If the code in the iDRAC actually issues a call like "drop a drive", then the iDRAC is being a bad actor, just like you could do from the PERC console. If the issue is that the iDRAC is issueing gibbering and the PERC decides to drop the drive because of gibberish, that's the PERC's fault for doing something it wasn't told to do.
