IPMI and other solutions are nice, but what I would like to have is a standard serial interface to an UEFI shell running at all times. How I access that serial port should be my problem.
The UEFI boot services that the shell relies upon aren't available after the bootloader or OS calls ExitBootServices() (the code is literally dropped out of ram and those regions handed back to the os) so this is not an easy thing to implement
Silicon Graphics servers used to have a separate serial port that proved access to a (very) simple state machine that controlled power to the system. Send a
‘u’ it powered on. Send a ‘d’ it powered down. ‘s’ reported the state (IIRC).
There was literally nothing that could go wrong. Then install the OS from the regular console port over the network with bootp/tftp/http.
The complexity of DRAC/iLO setups to control an emulation of a VGA PC setup blows my mind.
IPMI does rather more than than giving you console access, though it's serial, not VGA. Typical server BMCs which embed IPMI do more again. Not to defend the quality of various BMC firmware and support I've encountered...
Agreed — installing modern Windows from physical DVD-R media is painful enough.
I've found iLO 4 virtual media support most useful for booting DOS-hosted firmware updates supplied as El Torito ISO images that aren't natively bootable from USB flash in a world where you can no longer find CD-R blanks at every corner drug store, and where newer machines commonly lack the legacy BIOS support required to boot the image at all.
It's also a fine way to boot minimal BSD or Linux rescue/netinstall images that don't involve live-booting a full desktop environment, or for installing smallish OSes like ESXi in cases where trading increased wallclock time for slightly reduced effort is justifiable.
If you use the web (or older java) console to share the ISO as a virtual drive then it tends to be dog slow. If you SSH into the iLO then you can point the virtual CD drive at a HTTP web server hosting the image which seems to be significantly quicker to read. It uses HTTP range requests for random IO too, so doesn't need to pre-read the entire ISO.
If you're up for DIY, it's easy to turn a sufficiently long serial break into a toggle on a reset line and/or power button with a couple of discrete components.
A serial break is the only situation in which an RS232 line is driven +ve with greater than 90% duty cycle: charge a cap slowly on +ve, discharge quickly on -ve (diode), drive a mosfet gate to pull reset line low only when it's been +ve for quarter of a second or so.
Easily the hardest part of doing this is finding a 'clean' way to get a wire attached to the serial RX and GND pins from the inside the case rather than bodging something really ugly. Some boards have a front-facing serial port, though, which has a pin header and cable => easy to tap into.
I'd soldered onto the little legs on a stand off board DB9 port on one batch of machines I installed, and then ended up being thwarted on the next batch of boards which had a slightly different (more enclosed) style of DB9 port that made it much harder to get at the pins.
Whatever you do along these lines will be infinitely better than the insecure, overengineered catastrophe of vendor IPMI/BMC firmware. I wish someone less lazy than me would make a product along these lines... ;-)