> Still I don't understand how conceptually this approach works : what's the > purpose : to extract node mac address from the BMC ? If so, how do you know > this BMC is for this node on this switch/port without powering the node on ?
When the node is plugged in, the BMC powers up. From there, discovery happens similar to pxe-driven, but net.switch and net.switchport are defined as where the BMC can be found rather than the node's provisioning port. Since the BMC is already powered up, there's no need to manually power on the node. Once the BMC is discovered, the id.uuid attribute is automatically populated. This is used to respond to HTTP- and PXE-boot requests going forward. In the case of dense systems, the SMM has net.switch & net.switchport defined (or enclosure.extends if SMMs are daisy-chained), while the nodes in the chassis have enclosure.manager and enclosure.bay defined. Regards, Christian Caruthers Lenovo Professional Services Mobile: +1 757-289-9872 -----Original Message----- From: Thomas HUMMEL <thomas.hum...@pasteur.fr> Sent: Thursday, October 24, 2024 6:02 AM To: xcat-user@lists.sourceforge.net Subject: Re: [xcat-user] [External] Re: xCAT Consortium Update On 10/23/24 5:18 PM, Jarrod Johnson via xCAT-user wrote: > So, for now, I'll put aside all the BMC discovery and just consider the > xCAT-style PXE based discovery, to have a common reference point. Same > capabilities, same limitations. > > When PXE goes, the dynamic range is not needed because the following packet > is emitted by a node doing PXE boot: Hello, thanks for this explanation. This is a pretty nice feature (I did not understand at first because I was missing the concept that conflent kink act as a "clever" dhcp server for that matter) > The 'can do it off' relies on the BMC first approach, in which all the > multicast IPv6/IPv4 trickery potentially involving IPv6 link local addresses > to overcome messed up IPv4 comes in, and requires a supported BMC with either > preconfigured user/password or firmware default user/password to be vaguely > alive on a connected network. Still I don't understand how conceptually this approach works : what's the purpose : to extract node mac address from the BMC ? If so, how do you know this BMC is for this node on this switch/port without powering the node on ? In any case, confluent indeed seem to be a superset of xCAT for this kind of use cases Thanks for your help -- Thomas HUMMEL HPC Group Institut PASTEUR Paris, FRANCE _______________________________________________ xCAT-user mailing list xCAT-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xcat-user _______________________________________________ xCAT-user mailing list xCAT-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xcat-user
