Server BMCs can need to be rebooted every so often
61–70 of 96 posts
Re: Server BMCs can need to be rebooted every so often
#62People are surprisingly chill about BMCs as attack surface, eg Intel management features get a lot more scrutiny.
In proper environment the BMC is on its own dedicated NIC with no way to bridge to that network from the machine and only access from host machine being from root/admin account. And then there are people that just port-forward BMC ports to the internet as cheap remote KVM...
Re: Server BMCs can need to be rebooted every so often
#63I do development on openbmc ( https://github.com/openbmc/openbmc ) which is an open source bmc implantation using bitbake, primarily targeted to aspeed, and nuvoton bmc chips.
Can a mere mortal usefully deploy openbmc on a small number of servers?
Re: Server BMCs can need to be rebooted every so often
#64Earlier quoted context omitted.
This was me though I ended up moving to SuperMicro instead. Not fancy but their BMC seems to get the job done, and also doesn't cost a significant chunk of money extra for basic functionality. And then even more money to have IPMI be dedicated connection not shared. And HP's frigging BIOS wouldn't even work with their own HP rack console! But it was happy with an Apple mouse and keyboard. Argh! Making me irritated ag…
That pisses me off, when some vendors want to charge extra for KVM on stuff that already have hardware to do it and competitors do it...
Meanwhile competitor systems all have dedicated ports out of box. SuperMicro does have a paid "full unlock" for their BMC, but the only thing it does is add bios updates and such. All the core normal management functionality is there by default. It also only costs $30.
Granted HPs had other irritations like really wonky proprietary fan control (heck, proprietary fan cables too) that would mysteriously fail to function with different flavors of the same OS, and couldn't be overridden from the BMC (then what's the point!?). Also they were slow with EPYC options when that's what a lot of us really wanted to be switching for, the performance and value propositions were getting really good vs Intel who were also jerks.
Like lots of big players the experience may get different if you're buying hundreds to thousands or more units and have a dedicated account manager who takes care of all this for you etc etc. But x86-based servers is a pretty damn competitive market and at some point one has to stop and ask why hours are being burned futzing with stuff when literally the entire basic point of getting "server class" hardware with remote management functionality is to save man hours by NOT having to futz. So yeah there's a little rant I didn't even know I still had in me years later :). HP you silly goofs.
Re: Server BMCs can need to be rebooted every so often
#65Earlier quoted context omitted.
Not returned, but i've seen clients refuse to go with HP again because iLO sucked too much and come upgrade time went Dell. Unfortunately for them right around the time iLO got okay-ish and iDRAC got shitty.
This was me though I ended up moving to SuperMicro instead. Not fancy but their BMC seems to get the job done, and also doesn't cost a significant chunk of money extra for basic functionality. And then even more money to have IPMI be dedicated connection not shared. And HP's frigging BIOS wouldn't even work with their own HP rack console! But it was happy with an Apple mouse and keyboard. Argh! Making me irritated ag…
Kind of depends which generation of servers. I had worked with a lot of x9 and x10 (xeon e-2600v1-4) which was alright, as long as you don't mind outdated java (well the newest x10 bmcs do html5 consoles too, IIRC); but I recently started renting an x8 server personally, and it's worse... My favorite is when serial over lan just stops responding when you go from console redirection to os opened serial port (and back)... real helpful for inputting disk encryption passphrases. Oh well, I'm renting this server because it's cheap, it's also 10+ years old, and it works enough.
Re: Server BMCs can need to be rebooted every so often
#66We had IDSes that were happy, up, network interface counts were climbing, but they were STONE DEAF to the network traffic we were actually interested in.
Re: Server BMCs can need to be rebooted every so often
#67I also remember a long series of machines (Supermicro I think) whose BMCs would stop responding after a few weeks if there was too much traffic on the network.
Also those BMC that hijack silently eth0, breaking your server's bonded connections, when the main BNC connector get disconnected for some reason...
Re: Server BMCs can need to be rebooted every so often
#68Earlier quoted context omitted.
I wonder what the BMC was doing to hurt performance. Maybe it was questionable DVFS that stopped when the BMC died? Poor fan management that caused thermal throttling?
That's a pretty good guess: lots of BMCs have fan control, and turning it off should make all fans stay at max power. In a datacenter the odds of anyone noticing that the fans are always on high is practically nil, unless you are specifically monitoring fan RPM. Most folks don't bother, as what you are actually interested in is temperature.
It took us a while to identify the issue and all systems were running fine, but we had to shut down many racks to avoid the temperature to rise too high.
Re: Server BMCs can need to be rebooted every so often
#69Earlier quoted context omitted.
This was me though I ended up moving to SuperMicro instead. Not fancy but their BMC seems to get the job done, and also doesn't cost a significant chunk of money extra for basic functionality. And then even more money to have IPMI be dedicated connection not shared. And HP's frigging BIOS wouldn't even work with their own HP rack console! But it was happy with an Apple mouse and keyboard. Argh! Making me irritated ag…
That pisses me off, when some vendors want to charge extra for KVM on stuff that already have hardware to do it and competitors do it...
In this world, the legacy vendors like Dell and HP feel like they have to differentiate their hardware somehow, or they lose all the margin. So they'll charge you for all those "value-add" things like KVM or OOB Firmware Updates, because they can't make money on the machines themselves anymore.
The irony is all that extra garbage they add to their servers is exactly the opposite of what you want at high scale and really only serves the "enterprise" market that tends to deploy VMware and hand-manage servers and need point-and-click stuff since there's no incentive to write software to manage small environments like that.
Re: Server BMCs can need to be rebooted every so often
#70Someone once told me that nobody ever returned a server because the BMC sucked too much, and that says everything you need to know about BMCs. Incidentally, at a previous gig, the software that handled issuing BMC commands had a BMC reboot as the first step in any script it ran.
Anecdote, but: I've seen a previous employer blackball a hardware vendor because of terrible BMC support.
[1]: all things i have personal experience with:
- chassis bootdev pxe => doesn't do that, just reboots to normal OS
- chassis power off => doesn't do it (oh, here's an ipmi raw command you can use for this BMC version. NO!)
- dhcp server sends an option in an offer it doesn't understand, drops the offer, no IP at all.
- gets scanned by auditor-checkbox-as-a-service (qualys), locks up and sends the host CPU into 100% and locks up that up too.
- Not supporting IPv6 properly (if there's a place to start deploying IPv6 it's BMCs), i.e. uses SLAAC properly, but doesn't use the gateway from the RA so you actually can't use it from outside it's own segment - needs a firmware update to fix but uhh, we didn't dual-stack the BMC network because the whole point is to get that IP space back.
We had to write a test suite for vendors to run against their BMC and validate these things and you were disqualified if you failed.