|
|
Post by lorbus on Aug 17, 2022 18:43:06 GMT
This request was inspired by a twitter post made by systemd author Lennart Poettering, I'll be copying/paraphrasing it here. For the original post, see:
--- This is a request for enhancing Redfish with support for configuration of SMBIOS Type 11 OEM strings.
The popular systemd system and service manager for Linux has recently started to read fields of SMBIOS Type 11 natively, to allow for provisioning/bootstrapping of Linux systems with secrets/parameters/configuration. systemd exposes the fields through its "credentials" logic, propagating them down to the Linux user space.
This functionality could replace software like cloud-init and ignition for bare metal installations using Redfish.
Thank you for your consideration |
|
|
|
Post by mraineri on Aug 18, 2022 12:36:35 GMT
Just letting you know I've seen your post and I'm still reading through some of your pointers to wrap my head around things. One thing I'd like to avoid is simply having an "SMBIOSType11Strings" type of property in Redfish and focus more on what the external user is trying to accomplish.
|
|
|
|
Post by mraineri on Aug 23, 2022 15:48:11 GMT
From reading the documentation a bit more, I don't know how making additions to Redfish can help address this issue. From the use cases I see where SMBIOS Type 11 entries are being used to supply credentials, this is done in the context of a hypervisor building SMBIOS tables for a virtual machine. When we consider typical hardware management with Redfish, a BMC wouldn't be able to directly provide this information to a virtual machine; the hypervisor would need to actively extract this information from a BMC and still build up the SMBIOS Type 11 entries.
I think there's a wider problem with setting up and passing credentials from a hypervisor to a virtual machine, and unfortunately I'm not savvy enough in this space to formulate a good solution that is both easy to use and keeps credentials safe.
|
|
|
|
Post by lorbus on Aug 24, 2022 20:38:06 GMT
Thank you for looking into this!
I probably should've provided some more context on how I'd envision this to work. Importantly, I'm not interested in hypervisors and VM provisioning here at all.
That is, instead of passing the SMBIOS tables from Hypervisor to VM, it would be the redfish-enabled BMC passing it to the physical machine (no hypervisor/vm involved). From there systemd could pick up the tables and configure the bare-metal Linux system it's running on.
Unfortunately I have a rather limited understanding of both Redfish and SMBIOS, so I'm not sure if this makes any more sense?
|
|
|
|
Post by mraineri on Sept 15, 2022 14:53:54 GMT
Sorry for the late response; we've been discussing this a bit and trying to see how the functionality best fits in Redfish.
Putting the hypervisor and VM aspect aside, one of the concerns we have is how this could be mapped into the SMBIOS Type 11 entry. SMBIOS implementations expect BIOS to initialize the table as it sees fit. So, while the Type 11 entry has worked in the examples in the link, that only seems to go as far as VM usage where the hypervisor instantiates the SMBIOS table the VM will be able to view. In a bare metal case, only the system vendor would be able to fill in the table. While it's possible that the system BIOS can interact with the BMC to set up various entries, Type 11 is pretty open-ended and existing vendors might have their own usage defined for it. So, even if we establish a new property (or set of properties) to allow a user to configure it in Redfish, it may not be adopted widely.
To date, we don't have anything structured in Redfish directly to pass info between a management console and the OS. However, most systems have virtual media capabilities that can be managed through Redfish. One thought that came to mind is using this as a method to pass whatever info you need to the OS. So, you'd use Redfish to mount an image containing your OS data, the BMC presents the media as a CD/DVD/other media, and the OS could find the media and consume it as it needs to. Would this type of usage model work in your environment?
|
|
|
|
Post by champtar on Jan 2, 2024 6:50:59 GMT
Reviving this old RFE, here is my use case, automated servers deployment in someone else infrastructure (no internet access, no control over the DHCP).
Generating virtual media on the fly can solve everything, but you need an HTTP server you can push to, and this is a way bigger ask than please just put this static ISO on an HTTP server.
Today I have a custom provisioning ISO that I boot over http with query params,
and during boot I use HP/Dell tools to get the URL I'm booting from, parse the query params and configure a static IP from that.
From there I can configure the hardware further and kexec into Alma/RHEL install.
I would really like a standard way to pass a small blob of initial config data, like userdata in the cloud.
Using the redfish virtual NIC would be ok, using some SMBIOS entries might be better in the long run (or both).
Another solution to my use case would be to be able to push a small ISO or a small EFI to the BMC.
Generating small iPXE images on the fly is pretty easy, the problem is where do you host them.
|
|
|
|
Post by mraineri on Jan 8, 2024 13:50:39 GMT
Thanks for the feedback on that; we'll take this and discuss this further.
|
|
