> I was hoping UEFI would have encouraged people to return to loggable > interaction with the BIOS. I have this same problem with people who emulate > a display device in most virtual machines.
So this could be better. Currently our (Lenovo)system firmware defaults to text output supported if in use. It also populates the ACPI SPCR table so that in theory linux could pick it up, see: https://github.com/torvalds/linux/blob/master/drivers/acpi/spcr.c I don't know why I haven't seen this in a major distro as supported. For my part, I've been trying to demonstrate 'text consoles' to users in a web browser to make people like it and demonstrate it can be highlighted and right click 'search google for'. I've been avoiding the word 'serial' until the audience is happy with what they are seeing, as I have found leading with the phrase 'serial console' causes people to tune out as they think 'serial died decades ago'. The other thing that I did in confluent was have the replay buffer understand VT100, maintain a terminal rendered view in the buffer and have a shot at recreating screen on recreate. Also, it would be nice if we moved beyond 115.2 kpbs for the console rate. > VGA/graphics, audio devices and related connectors seem wasteful. Funnily enough, I have no idea if this is productively minimalistic, but we have started selling servers where you can opt out of the video port and all usb ports. This might be a bit too extreme for most though. I also suspect it's not particularly cost saving. >The SOL interface with emulated and/or back-to-back serial ports seems awkward >and a better character oriented interface might clean up some usability >issues. The SOL network protocol also seems pretty awkward and could probably >use some transition to a tcp based protocol. Whole-heartedly agree. Currently there's a problem where there exists no other completely normalized standard for getting serial console. In redfish, there's a token way to say 'yeah, we have some sort of serial port, have fun' but no prescription or way to describe exactly how to use it unless it's IPMI. On the backend/UART side, one would hope we'd come up with something nicer... > The "shared" mode 1G interface also is awkward for various reasons (and I get > the impression Intel is making it even worse with their management engine). > For newer equipment we are going with dedicated IPMI network interfaces and > 10G (maybe 25G, IB and/or OPA) for the node networking. One thing we've been doing is trying to make the dedicated path cheaper (e.g. a configuration where 16 servers in 4 enclosures can share a single dedicated management port). > Oh yeah, another complaint for the DMTF folks: the system clock should be in > UTC, not "local time". Heh, confusion over whether timestamps are local or remote caused me to incorporate time zone correction to reventlog (and nodeventlog). Every time it pulls log it asks 'what time do you think it is *right now*' and adjusts all the timestamps it sees according to how different the current claimed time is from what the time is. It's why reventlog/nodeventlog disagree with ipmitool on timestamps. Well, that confusion and the propensity for BMCs to have whatever unset clock people feel like. -----Original Message----- From: Stuart Barkley <stua...@4gh.net> Sent: Thursday, May 31, 2018 11:34 AM To: xCAT Users Mailing list <xcat-user@lists.sourceforge.net> Subject: Re: [xcat-user] [External] IBM IPMI USB interface some ranting below...I doubt there is much support for many of the things below... On Thu, 31 May 2018 at 08:51 -0000, Jarrod Johnson wrote: > On preferring KCS not to be there, is this because it is extraneous or > because it leaves root-level user access to reconfigure networking and > credentials for the BMC? Would that sort of thing be less worrisome > when configured to only allow read access once in an OS (enough for > 'sensors', 'fru', and 'sel' sorts of commands to work, but not for > 'lan set' and such. I just prefer using the network interface when running lots of nodes. I don't really object to the KCS interface that much and am not worried about root access to the device. It seems a little awkward and possibly a standard I2C interface would be less awkward (speaking as someone who hasn't really studied KCS or I2C). I would also like to get rid of other extraneous hardware (and software) on the compute components of a large system: VGA/graphics, audio devices and related connectors seem wasteful. Disk and RAID controllers (along with the related sheet metal) seem wasteful for diskless compute nodes. CPU, RAM, network, power and cooling are the primary needs. Video framebuffer support over the IMM just continues to support the expectation that graphical output is suitable for system interaction. I was hoping UEFI would have encouraged people to return to loggable interaction with the BIOS. I have this same problem with people who emulate a display device in most virtual machines. > To sum up my current take on what the DMTF guys are pushing for and > the compromise I would propose: The DMTF has done some good work and IPMI is very useful (if somewhat awkward). xCAT has good interfaces to most of what I find interesting about IPMI (although I do use ipmitool itself on occasion). The SOL interface with emulated and/or back-to-back serial ports seems awkward and a better character oriented interface might clean up some usability issues. The SOL network protocol also seems pretty awkward and could probably use some transition to a tcp based protocol. The "shared" mode 1G interface also is awkward for various reasons (and I get the impression Intel is making it even worse with their management engine). For newer equipment we are going with dedicated IPMI network interfaces and 10G (maybe 25G, IB and/or OPA) for the node networking. Some standardization of firmware loading, BMC/BIOS configuration variable setting and reading and LED sensors (rvitals leds) might be useful. Oh yeah, another complaint for the DMTF folks: the system clock should be in UTC, not "local time". Stuart Barkley -- I've never been lost; I was once bewildered for three days, but never lost! -- Daniel Boone ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ xCAT-user mailing list xCAT-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xcat-user ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ xCAT-user mailing list xCAT-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xcat-user
