Opening Up the Baseboard Management Controller(queue.acm.org)
queue.acm.org
Opening Up the Baseboard Management Controller
https://queue.acm.org/detail.cfm?id=3378404
17 comments
Does anyone know what firmware is on the Raptor Blackbird/Talos boards?
https://git.raptorcs.com/git/
It looks to be openBMC
It looks to be openBMC
Open up your computer, pull out the bmc, throw it in the garbage. If you are reliant on these things then you are still in a pet-computer world and you’ll benefit greatly by moving to the cattle model. This article has a section on why you need a bmc but doesn’t succeed in advocating for it. It’s another computer inside your main computer with its own set of flaws, bugs, and costs.
Actually, a good BMC lets you automate your fleet of machines and treat them like cattle, rebooting/reimaging on demand.
> a good BMC
I hope to see such a thing some day. The code quality and support lifecycles for these things are horrendous.
I hope to see such a thing some day. The code quality and support lifecycles for these things are horrendous.
Cattle is when you DGAF that 1% of your machines failed to reboot. A tech can deal with it whenever.
How are you rebooting your cattle though if not via the BMC?
More importantly, how do those cattle become cattle in the first place without BMC? How do you turn them into another breed of cattle without BMC?
Not that it can't be done... but that's a system dependent on the hardware doing the right thing, as opposed to a system that can tell the hardware what to do every step of the way.
Not that it can't be done... but that's a system dependent on the hardware doing the right thing, as opposed to a system that can tell the hardware what to do every step of the way.
There are other solutions, like network pdus. It’s different but does the same job.
I'm also curious how they're reimaging those machines.
What's wrong with PXE boot?
How are you triggering the machine to PXE boot? How are you recovering from situations where the machine becomes unresponsive or needs someone to look at a console to see why a failure occurred?
PXE boot it every single time and if it fails it goes on the repair list and some tech looks at it within 90 days and I DGAF about one dead cow.
IPMI is bad. No argument.
Having the ability to remotely reboot servers is good, even in a “cattle” environment. Being able to pull temperature sensor data from servers is useful in a data center environment. Having an out of band console available can be helpful during incidents and outages, or with remote sites where there’s no tech that will be there. BMCs are useful in a large scale environment.
Having the ability to remotely reboot servers is good, even in a “cattle” environment. Being able to pull temperature sensor data from servers is useful in a data center environment. Having an out of band console available can be helpful during incidents and outages, or with remote sites where there’s no tech that will be there. BMCs are useful in a large scale environment.
IPMI is the least bad solution to a problem. If someone came up with a better solution I'd be all over it.
You must realise that potential 90 day downtimes just aren't acceptable in some domains.
Just because most BMC implementations are bug riddled shitshows, that does not mean the concept of a BMC is bad. OpenBMC is the exact right solution to the problem of bad BMC implementations.
Of course, you've signed up with that name just to issue decrees about IPMI being bad :)
Just because most BMC implementations are bug riddled shitshows, that does not mean the concept of a BMC is bad. OpenBMC is the exact right solution to the problem of bad BMC implementations.
Of course, you've signed up with that name just to issue decrees about IPMI being bad :)
No, that's the chipset and/or I/O buses. BMC is like a biometric remote-accessible monitor forcefully implanted in your body.