sharkys said:
Thank you Terry, so on the systems you mentioned, there were mainly issues in case of hardware failure with iDRAC7?
I guess I wasn't clear. In the older (non-i versions), the DRAC was an add-in option and if you didn't have one, you didn't have any of the features it provides. Starting on the x10 systems (iDRAC6), some DRAC functionality is always present on the motherboard. This is tied to System Services and UEFI, among other things. Without adding the iDRAC6 Enterprise add-in card, the iDRAC6 can only share one of the system's LAN connectors and some functions (like remote console) are disabled. The iDRAC6 Enterprise add-in card also contains a SD slot for Dell's vFlash (a proprietary SD variant) and a dedicated network connector. According to the data I've seen (I haven't had any x20 systems come in for recycling yet) the x20 systems have all of the iDRAC Enterprise hardware factory-installed, but in order to use the Enterprise feature set, you have to enter a license key which you purchase from Dell.
Mostly. It provides a number of industry-standard software interfaces (IPMI, HTTP, etc.). However, Dell only supports some Windows, Linux, and hypervisors with their utilities to manage / configure the DRAC (and other hardware components). Many of Dell's utilities come on bootable Linux media (SDU / SUU for updating firmware, for example). However, for some of the things you might want to use under FreeBSD for day-to-day things, you'll need to get creative. It is possible to install the Dell
racadm utility and use it under the
emulators/linux_base-f10 port, but you can only use what Dell calls "remote racadm", where the utility talks over the LAN to [what it thinks is] a different system - the FreeBSD Linux emulation doesn't support the necessary Linux modules to use the local system management bus to talk to the card. There are certain functions that only work in local mode, like the DRAC picking up the OS name and version.
I had considered creating a
racadm port to make this easier for others, but Dell changes the interface nearly every generation (since they write the software on both sides) which means there isn't a "one-size-fits-all" solution. Way back on the DRAC III/XT, the local channel was a PPP session over an emulated COM port, and it was actually possible to run
racadm in local mode. As the internal communication has become more sophisticated, it's been harder and harder to keep local mode working.
Still would be interesting to hear about that workaround you mentioned although it's slightly off-topic. Also thanks for info about ipmitool, didn't know about that.
Do a web search for "R810 New memory: Replacement license" - there's a Dell Community post about it.
Anyway I would very appreciate, if anyone can share the latest experience mainly with network cards - Broadcom® 5720 and Broadcom® 5719 as I read about some potential conflicts with iDRAC7 on FreeBSD 9.1 and it looks like it's the only potential issue?
The R710 I'm using for testing has 4 BCM5709 ports on the motherboard. Dell probably changed (again!) on the x20's as they offer varying numbers/speeds of network ports depending on how the system is ordered.
The issue with the iDRAC using the same LAN port as FreeBSD wants to use is that the iDRAC "hides" its use of the port - it has a different IP address, etc. This means that when an operating system (FreeBSD or anything else) initializes the network hardware, this can disrupt the DRAC's use of the shared hardware. In some cases, you get a working FreeBSD network interface and a non-working DRAC one, or the DRAC fights back and you end up with the opposite, or sometimes neither will be able to use the port until a reboot. It depends on the hardware and drivers involved. I believe yongari@ is the FreeBSD maintainer for the Broadcom drivers, and is quite response to reports of this sort of issue. They've cropped up in the past, so a previous mitigation method may be able to be use for new hardware.
