IPMI-DCMI(8)

📦
version 1.6.20 · 14 versions
, in arch rolling, centos-stream 10, centos-stream 9

🎀 NAME 🎀

ipmi-dcmi — the IPMI DCMI utility, aka the page you're reading right now, aka IPMI-DCMI(8) if we're being formal about it (we're not 💅).

✨ SYNOPSIS ✨

ipmi-dcmi [OPTION...]

🌸 DESCRIPTION 🌸

Okay so picture this: ipmi-dcmi runs Data Center Manageability Interface commands — you'll also hear people call it DCM or DCMI — which are basically IPMI extension commands. What's in the DCMI extensions bag? Asset management 🏷️ and power usage management ⚡. And ngl, most people are here for the power management part. The whole idea: you set up an exception action, a power limit, and a correction time limit, and boom — power usage across a data center gets managed way more effectively. If that's your vibe, go peek at the --set-power-limit option below, it's the main character of that whole story.

You can also configure DCMI through the dcmi category in ipmi-config(8), if that's more your thing 🫶.

Real talk though: the DCMI specification covers a ton of traditional IPMI features that this tool does not implement directly. So don't come for ipmi-dcmi asking for those. Instead:

Listed below you'll find general IPMI options, tool specific options, troubleshooting info, workaround info, examples, and known issues — the whole squad. And for a general introduction to FreeIPMI, go read freeipmi(7) ✨.

💜 GENERAL OPTIONS 💜

These are the general options for setting up IPMI communication and running the usual tool commands. The OGs, basically.

  • -D IPMIDRIVER, --driver-type=IPMIDRIVER — Pick the driver type yourself instead of letting auto selection do its thing. Currently available out-of-band drivers: LAN and LAN_2_0, which do IPMI 1.5 and IPMI 2.0 respectively. Currently available in-band drivers: KCS, SSIF, OPENIPMI, SUNBMC, and INTELDCMI.
  • --disable-auto-probe — Don't probe in-band IPMI devices for default settings. Leave them alone, they're fine 🙈.
  • --driver-address=DRIVER-ADDRESS — Set the in-band driver address manually instead of using the probed value. Prefix DRIVER-ADDRESS with "0x" for a hex value and '0' for an octal value. Literally please remember the prefixes, bestie.
  • --driver-device=DEVICE — Set the in-band driver device path instead of the probed path.
  • --register-spacing=REGISTER-SPACING — Set the in-band driver register spacing instead of the probed value. The argument is in bytes (i.e. 32bit register spacing = 4).
  • --target-channel-number=CHANNEL-NUMBER — Set the in-band driver target channel number where IPMI requests get sent.
  • --target-slave-address=SLAVE-ADDRESS — Set the in-band driver target slave number where IPMI requests get sent.
  • -h IPMIHOST1,IPMIHOST2,...,, --hostname=IPMIHOST1[:PORT],IPMIHOST2[:PORT],... — Tell it which remote host(s) to talk to. Multiple hostnames can be separated by commas, or you can use a range format — see HOSTRANGED SUPPORT below 👀. You can slap an optional port on each host, which is lowkey useful for port forwarding and similar situations. And if you're specifying an IPv6 address and a port, use the format [ADDRESS]:PORT.
  • -u USERNAME, --username=USERNAME — The username to use when authenticating with the remote host. If you don't specify one, a null (i.e. anonymous) username is assumed. Heads up: the user must have at least ADMIN privileges for this tool to operate fully. No shortcuts.
  • -p PASSWORD, --password=PASSWORD — The password for authenticating with the remote host. If not specified, a null password is assumed. Maximum password length is 16 for IPMI 1.5 and 20 for IPMI 2.0.
  • -P, --password-prompt — Get prompted for the password, so it never ends up listed in process lists. Iconic security behavior, honestly 🔥.
  • -k K_G, --k-g=K_G — The K_g BMC key to use when authenticating with the remote host for IPMI 2.0. If not specified, a null key is assumed. To input the key in hexadecimal form, prefix the string with '0x'. E.g., the key 'abc' can be entered with either the string 'abc' or the string '0x616263'.
  • -K, --k-g-prompt — Get prompted for k-g, again so it never shows up in process lists 🙈.
  • --session-timeout=MILLISECONDS — Session timeout in milliseconds. Defaults to 20000 milliseconds (20 seconds) if you don't specify.
  • --retransmission-timeout=MILLISECONDS — Packet retransmission timeout in milliseconds. Defaults to 1000 milliseconds (1 second) if you don't specify. Important: the retransmission timeout cannot be larger than the session timeout. That's a hard no.
  • -a AUTHENTICATION-TYPE, --authentication-type=AUTHENTICATION-TYPE — Which IPMI 1.5 authentication type to use. Currently available: NONE, STRAIGHT_PASSWORD_KEY, MD2, and MD5. Defaults to MD5 if not specified.
  • -I CIPHER-SUITE-ID, --cipher-suite-id=CIPHER-SUITE-ID — Which IPMI 2.0 cipher suite ID to use. A Cipher Suite ID is basically a bundle: it identifies a set of authentication, integrity, and confidentiality algorithms for IPMI 2.0 communication. The authentication algorithm handles session setup, the integrity algorithm handles session packet signatures, and the confidentiality algorithm handles payload encryption. Defaults to cipher suite ID 3 if not specified. Currently supported cipher suite ids, in all their glory:
    • 0 — Authentication Algorithm = None; Integrity Algorithm = None; Confidentiality Algorithm = None
    • 1 — Authentication Algorithm = HMAC-SHA1; Integrity Algorithm = None; Confidentiality Algorithm = None
    • 2 — Authentication Algorithm = HMAC-SHA1; Integrity Algorithm = HMAC-SHA1-96; Confidentiality Algorithm = None
    • 3 — Authentication Algorithm = HMAC-SHA1; Integrity Algorithm = HMAC-SHA1-96; Confidentiality Algorithm = AES-CBC-128
    • 6 — Authentication Algorithm = HMAC-MD5; Integrity Algorithm = None; Confidentiality Algorithm = None
    • 7 — Authentication Algorithm = HMAC-MD5; Integrity Algorithm = HMAC-MD5-128; Confidentiality Algorithm = None
    • 8 — Authentication Algorithm = HMAC-MD5; Integrity Algorithm = HMAC-MD5-128; Confidentiality Algorithm = AES-CBC-128
    • 11 — Authentication Algorithm = HMAC-MD5; Integrity Algorithm = MD5-128; Confidentiality Algorithm = None
    • 12 — Authentication Algorithm = HMAC-MD5; Integrity Algorithm = MD5-128; Confidentiality Algorithm = AES-CBC-128
    • 15 — Authentication Algorithm = HMAC-SHA256; Integrity Algorithm = None; Confidentiality Algorithm = None
    • 16 — Authentication Algorithm = HMAC-SHA256; Integrity Algorithm = HMAC_SHA256_128; Confidentiality Algorithm = None
    • 17 — Authentication Algorithm = HMAC-SHA256; Integrity Algorithm = HMAC_SHA256_128; Confidentiality Algorithm = AES-CBC-128
  • -l PRIVILEGE-LEVEL, --privilege-level=PRIVILEGE-LEVEL — Which privilege level to use. Currently available: USER, OPERATOR, and ADMIN. Defaults to ADMIN if not specified. Go big or go home 👑.
  • --config-file=FILE — Point at an alternate configuration file.
  • -W WORKAROUNDS, --workaround-flags=WORKAROUNDS — Workarounds for vendor compliance issues, because vendors gotta vendor 😭. Multiple workarounds can be specified separated by commas. There's a special command line flag of "none", which means no workarounds at all (useful for overriding configured defaults). See WORKAROUNDS below for the list of available workarounds.
  • --debug — Turn on debugging. Chaotic but useful.
  • -?, --help — Output a help list and exit.
  • --usage — Output a usage message and exit.
  • -V, --version — Output the program version and exit.

🌈 IPMI-DCMI OPTIONS 🌈

Now the actual DCMI-specific ones. This is where it gets good, bestie.

  • --get-dcmi-capability-info — Get DCMI capability information ✨.
  • --get-asset-tag — Get the asset tag 🏷️.
  • --set-asset-tag=STRING — Set the asset tag.
  • --get-management-controller-identifier-string — Get the management controller identifier string tag.
  • --set-management-controller-identifier-string=STRING — Set the management controller identifier string tag.
  • --get-dcmi-sensor-info — Get DCMI sensor information 🌡️.
  • --get-system-power-statistics — Get system power statistics ⚡.
  • --get-enhanced-system-power-statistics — Get enhanced system power statistics, because regular wasn't enough 💅.
  • --get-power-limit — Get power limit information.
  • --set-power-limit — Set the power limit configuration. You can specify the config via the --exception-actions, --power-limit-requested, --correction-time-limit, and --statistics-sampling-period options listed below. If one or more of those options below aren't specified, the current configuration will be utilized. So it fills in the blanks for you, slay.
  • --exception-actions=BITMASK — The exception actions for the set power limit configuration. Special case allowable values: NO_ACTION, HARD_POWER_OFF_SYSTEM, LOG_EVENT_TO_SEL_ONLY. Other values (e.g. 0x02 through 0x10) are OEM dependent. Used with the --set-power-limit option.
  • --power-limit-requested=WATTS — The power limit for the set power limit configuration. Input is specified in watts. Used with the --set-power-limit option.
  • --correction-time-limit=MILLISECONDS — The correction time limit for the set power limit configuration. Input is specified in milliseconds. Used with the --set-power-limit option.
  • --statistics-sampling-period=SECONDS — The management application statistics sampling period for the set power limit configuration. Input is specified in seconds. Used with the --set-power-limit option.
  • --activate-deactivate-power-limit=OPERATION — Activate or deactivate the power limit. Allowed values: ACTIVATE, DEACTIVATE.
  • --interpret-oem-data — Attempt to interpret OEM data — think event data, sensor readings, or general extra info, etc. If an OEM interpretation isn't available, the default output gets generated instead. And real talk: correctness of OEM interpretations cannot be guaranteed, because OEM vendors may change stuff in products, firmware, etc. Not our fault, we warned you 💀. See OEM INTERPRETATION below for confirmed supported motherboard interpretations.
Heads up bestie: the ipmi-dcmi show continues — there's more page coming, so don't go anywhere 🦋

⏰ TIME OPTIONS ⏰

ok so here's the tea bestie: by IPMI definition, all IPMI times and timestamps are stored in localtime. but like… in sooo many situations they actually aren't stored in localtime 💀 whether or not a system truly stored the timestamps in localtime varies on a whole bunch of factors — think vendor, BIOS, operating system, the whole vibe. so the options below let you adjust how the stored timestamps get interpreted and how they get output. slay.

  • --utc-to-localtime — assume literally all times are reported in UTC time, and convert them to localtime before they get output.
  • --localtime-to-utc — flip it: convert all localtime timestamps to UTC before being output.
  • --utc-offset=SECONDS — specify a specific UTC offset in seconds to be added to timestamps. the value can range from -86400 to 86400 seconds. defaults to 0.

🎀 HOSTRANGED OPTIONS 🎀

these options manipulate hostranged output. peep HOSTRANGED SUPPORT below for the extra info on hostranges, iykyk.

  • -B, --buffer-output — buffer hostranged output. for each node, buffer standard output until that node has completed its IPMI operation. when you specify this option, data may appear to output slower to you, because the entire IPMI operation has to complete before any data can be output. see HOSTRANGED SUPPORT below for more.
  • -C, --consolidate-output — consolidate hostranged output. the complete standard output from every node specified gets consolidated so that nodes with identical output aren't output twice. a header will list those nodes with the consolidated output. when this option is specified, no output can be seen until the IPMI operations to all nodes have completed. and if you break out of the program early, all currently consolidated output will be dumped. see HOSTRANGED SUPPORT below for more.
  • -F NUM, --fanout=NUM — specify multiple host fanout. a "sliding window" (or fanout) algorithm is used for parallel IPMI communication so that slower nodes or timed out nodes won't impede parallel communication. the maximum number of threads available at the same time is limited by the fanout. the default is 64.
  • -E, --eliminate — eliminate hosts determined as undetected by ipmidetect. this attempts to remove the common issue of hostranged execution timing out because several nodes got removed from service in a large cluster. the ipmidetectd daemon must be running on the node executing the command.
  • --always-prefix — always prefix output, even if only one host is specified or communicating in-band. this option is primarily useful for scripting purposes. the option will be ignored if specified with the -C option.

🌈 HOSTRANGED SUPPORT 🌈

multiple hosts can be input either as an explicit comma separated list of hosts, or as a range of hostnames in the general form: prefix[n-m,l-k,...], where n < m and l < k, etc. okay but do not confuse the latter form with regular expression character classes (which are also denoted by []). for example, foo[19] does not represent foo1 or foo9 — it represents a degenerate range: foo19. okay?? 🙈

this range syntax is meant only as a convenience on clusters with a prefixNN naming convention, and specification of ranges should not be considered necessary — the list foo1,foo9 could be specified as such, or by the range foo[1,9]. literally the same thing.

some examples of range usage follow:

foo[01-05] instead of foo01,foo02,foo03,foo04,foo05
foo[7,9-10] instead of foo7,foo9,foo10
foo[0-3] instead of foo0,foo1,foo2,foo3
friendly reminder bestie: some shells will interpret brackets ([ and ]) for pattern matching. depending on your shell, it may be necessary to enclose ranged lists within quotes. don't get got 💅

when multiple hosts are specified by you, a thread gets executed for each host in parallel up to the configured fanout (which you can adjust via the -F option). this allows communication to large numbers of nodes far more quickly than if it were done in serial. speed queen fr.

by default, standard output from each node specified will be output with the hostname prepended to each line. although this output is readable in many situations, it may be difficult to read in other situations — for example, output from multiple nodes may be mixed together 😭 the -B and -C options can be used to change this default.

in-band IPMI Communication will be used when the host "localhost" is specified. this lets you add the localhost into the hostranged output. cute.

🩹 GENERAL TROUBLESHOOTING 🩹

most often, IPMI problems are due to configuration problems. like, it's almost always the config, bestie.

IPMI over LAN problems involve a misconfiguration of the remote machine's BMC. double check to make sure the following are configured properly in the remote machine's BMC: IP address, MAC address, subnet mask, username, user enablement, user privilege, password, LAN privilege, LAN enablement, and allowed authentication type(s). for IPMI 2.0 connections, double check to make sure the cipher suite privilege(s) and K_g key are configured properly. the ipmi-config(8) tool can be used to check and/or change these configuration settings. use it, it's iconic.

inband IPMI problems are typically caused by improperly configured drivers or non-standard BMCs.

in addition to the troubleshooting tips below, please see WORKAROUNDS below to also if there are any vendor specific bugs that have been discovered and worked around.

listed below are many of the common issues for error messages. for additional support, please e-mail the <freeipmi-users@gnu.org> mailing list. they're nice, promise 🫶

  • "username invalid" — the username entered (or a NULL username if none was entered) is not available on the remote machine. it may also be possible that the remote BMC's username configuration is incorrect.
  • "password invalid" — the password entered (or a NULL password if none was entered) is not correct. it may also be possible that the password for the user is not correctly configured on the remote BMC.
  • "password verification timeout" — password verification has timed out. either a "password invalid" error (described above) or a generic "session timeout" (described below) occurred. during this point in the protocol, it can't be differentiated which one happened. frustrating, i know 💀
  • "k_g invalid" — the K_g key entered (or a NULL K_g key if none was entered) is not correct. it may also be possible the K_g key is not correctly configured on the remote BMC.
  • "privilege level insufficient" — an IPMI command requires a higher user privilege than the one you authenticated with. please try to authenticate with a higher privilege. this may require authenticating to a different user that has a higher maximum privilege.
  • "privilege level cannot be obtained for this user" — the privilege level you're attempting to authenticate with is higher than the maximum allowed for this user. please try again with a lower privilege. it may also be possible the maximum privilege level allowed for a user is not configured properly on the remote BMC.
  • "authentication type unavailable for attempted privilege level" — the authentication type you wish to authenticate with is not available for this privilege level. please try again with an alternate authentication type or alternate privilege level. it may also be possible the available authentication types you can authenticate with are not correctly configured on the remote BMC.
  • "cipher suite id unavailable" — the cipher suite id you wish to authenticate with is not available on the remote BMC. please try again with an alternate cipher suite id. it may also be possible the available cipher suite ids are not correctly configured on the remote BMC.
  • "ipmi 2.0 unavailable" — IPMI 2.0 was not discovered on the remote machine. please try to use IPMI 1.5 instead.
  • "connection timeout" — initial IPMI communication failed. a number of potential errors are possible here, including an invalid hostname specified, an IPMI IP address that cannot be resolved, IPMI not being enabled on the remote server, a bad network connection, etc. please verify configuration and connectivity.
  • "session timeout" — the IPMI session has timed out. please reconnect. if this error occurs often, you may wish to increase the retransmission timeout — some remote BMCs are considerably slower than others 🐌
  • "device not found" — the specified device could not be found. please check configuration or inputs and try again.
  • "driver timeout" — communication with the driver or device has timed out. please try again.
  • "message timeout" — communication with the driver or device has timed out. please try again.
  • "BMC busy" — the BMC is currently busy. it may be processing information or have too many simultaneous sessions to manage. please wait and try again.
  • "could not find inband device" — an inband device could not be found. please check configuration or specify a specific device or driver on the command line.
  • "driver timeout" — the inband driver has timed out communicating to the local BMC or service processor. the BMC or service processor may be busy or (worst case) possibly non-functioning. yeah, this one's a different "driver timeout" than the one above — same name, different drama 🙃
  • "internal IPMI error" — an IPMI error has occurred that FreeIPMI does not know how to handle. please e-mail <freeipmi-users@gnu.org> to report the issue.

🛠️ WORKAROUNDS 🛠️

Okay bestie, so here's the tea ☕: so many different vendors have implemented their own little IPMI solutions, and some of them implement their IPMI protocols... incorrectly 💀. Below is the whole list of workarounds currently available to handle the compliance issues people have discovered. When possible, workarounds are implemented so they're totally transparent to you — but some of them you have to specifically ask for with the -W option. Iykyk.

The hardware listed under each one might only be the hardware the problem was discovered on. Newer versions of that hardware may have fixed the problems indicated below. Similar machines from those vendors may or may not exhibit the same problems. And get this — different vendors may license their firmware from the same IPMI firmware developer, so it may be worth trying the workarounds listed below even if your motherboard isn't listed. 👑

If you think your hardware has an additional compliance issue that needs a workaround implemented, please contact the FreeIPMI maintainers at <freeipmi-users@gnu.org> or <freeipmi-devel@gnu.org>. They'd love to hear from you 🫶.

  • assumeio — this workaround flag assumes inband interfaces communicate with system I/O rather than being memory-mapped. It works around systems that report invalid base addresses. If you're hitting this you might see "device not supported" or "could not find inband device" errors. Issue observed on HP ProLiant DL145 G1.
  • spinpoll — this workaround flag tells some inband drivers (most notably the KCS driver) to spin while polling instead of putting the process to sleep. This may significantly improve the wall clock running time of tools, because an operating system scheduler's granularity may be much larger than the time it takes to perform a single IPMI message transaction ✨. But heads up — by spinning, your system may be doing less useful work, since it's not contexting out the tool for a more useful task.
  • authcap — this workaround flag skips the early checks for username capabilities, authentication capabilities, and K_g support, and just lets IPMI authentication succeed. It works around multiple issues where the remote system doesn't properly report username capabilities, authentication capabilities, or K_g status. If you're hitting this you might see "username invalid", "authentication type unavailable for attempted privilege level", or "k_g invalid" errors. Issue observed on Asus P5M2/P5MT-R/RS162-E4/RX4, Intel SR1520ML/X38ML, and Sun Fire 2200/4150/4450 with ELOM.
  • nochecksumcheck — this workaround flag tells FreeIPMI to not check the checksums returned from IPMI command responses. It works around systems that return invalid checksums because of implementation errors, where the packet is otherwise valid. Users are cautioned on the use of this option 🚨, because it removes validation of packet integrity in a number of circumstances. That said, it's unlikely to be an issue in most situations. If you're hitting this you might see "connection timeout", "session timeout", or "password verification timeout" errors. On IPMI 1.5 connections, the "noauthcodecheck" workaround may be needed too. Issue observed on Supermicro X9SCM-iiF, Supermicro X9DRi-F, and Supermicro X9DRFR.
  • idzero — this workaround flag allows empty session IDs to be accepted by the client. It works around IPMI sessions that report empty session IDs to the client. If you're hitting this you might see "session timeout" errors. Issue observed on Tyan S2882 with M3289 BMC.
  • unexpectedauth — this workaround flag allows unexpected non-null authcodes to be checked as though they were expected. It works around an issue where packets contain non-null authentication data when they should be null because per-message authentication is disabled. If you're hitting this you might see "session timeout" errors. Issue observed on Dell PowerEdge 2850,SC1425. Confirmed fixed on newer firmware.
  • forcepermsg — this workaround flag forces per-message authentication to be used no matter what the remote system advertises. It works around an issue where per-message authentication is advertised as disabled on the remote system, but it's actually required for the protocol. If you're hitting this you might see "session timeout" errors. Issue observed on IBM eServer 325.
  • endianseq — this workaround flag flips the endian of the session sequence numbers so the session can continue properly. It works around IPMI 1.5 session sequence numbers that are the wrong endian. If you're hitting this you might see "session timeout" errors. Issue observed on some Sun ILOM 1.0/2.0 (depends on service processor endian).
  • noauthcodecheck — this workaround flag tells FreeIPMI to not check the authentication codes returned from IPMI 1.5 command responses. It works around systems that return invalid authentication codes because of hashing or implementation errors. Users are cautioned on the use of this option 🚨, because it removes an authentication check verifying the validity of a packet. But honestly, in most organizations this is unlikely to be a security issue. If you're hitting this you might see "connection timeout", "session timeout", or "password verification timeout" errors. Issue observed on Xyratex FB-H8-SRAY, Intel Windmill, Quanta Winterfell, and Wiwynn Windmill.
  • intel20 — this workaround flag handles several Intel IPMI 2.0 authentication issues. The issues covered include padding of usernames, and password truncation if the authentication algorithm is HMAC-MD5-128. If you're hitting this you might see "username invalid", "password invalid", or "k_g invalid" errors. Issue observed on Intel SE7520AF2 with Intel Server Management Module (Professional Edition).
  • supermicro20 — this workaround flag handles several Supermicro IPMI 2.0 authentication issues on motherboards w/ Peppercon IPMI firmware. The issues covered include handling invalid length authentication codes. If you're hitting this you might see "password invalid" errors. Issue observed on Supermicro H8QME with SIMSO daughter card. Confirmed fixed on newerver firmware.
  • sun20 — this workaround flag works around several Sun IPMI 2.0 authentication issues. The issues covered include invalid lengthed hash keys, improperly hashed keys, and invalid cipher suite records. If you're hitting this you might see "password invalid" or "bmc error" errors. Issue observed on Sun Fire 4100/4200/4500 with ILOM. This workaround automatically includes the "opensesspriv" workaround.
  • opensesspriv — this workaround flag slightly alters FreeIPMI's IPMI 2.0 connection protocol to work around an invalid hashing algorithm used by the remote system. The privilege level sent during the Open Session stage of an IPMI 2.0 connection is used for hashing keys instead of the privilege level sent during the RAKP1 connection stage. If you're hitting this you might see "password invalid", "k_g invalid", "bad rmcpplus status code", or "privilege level cannot be obtained for this user" errors. Issue observed on Sun Fire 4100/4200/4500 with ILOM, Inventec 5441/Dell Xanadu II, Supermicro X8DTH, Supermicro X8DTG, Intel S5500WBV/Penguin Relion 700, Intel S2600JF/Appro 512X, Quanta QSSC-S4R/Appro GB812X-CN, Dell C5220, and the OpenIPMI software BMC. This workaround is automatically triggered with the "sun20" workaround.
  • integritycheckvalue — this workaround flag works around an invalid integrity check value during an IPMI 2.0 session establishment when using Cipher Suite ID 0. The integrity check value should be 0 length, but the remote motherboard responds with a non-empty field 🙈. If you're hitting this you might see "k_g invalid" errors. Issue observed on Supermicro X8DTG, Supermicro X8DTU, and Intel S5500WBV/Penguin Relion 700, and Intel S2600JF/Appro 512X.
  • No IPMI 1.5 Support — some motherboards that support IPMI 2.0 have been found to not support IPMI 1.5. If you're hitting this you might see "ipmi 2.0 unavailable" or "connection timeout" errors. This one can be worked around by using IPMI 2.0 instead of IPMI 1.5 — just specify --driver-type=LAN_2_0. Issue observed on a number of HP and Supermicro motherboards.

🔍 OEM INTERPRETATION 🔍

The following motherboards are confirmed to have atleast some support by the --interpret-oem-data option. It's highly probable the OEM data interpretations would work across other motherboards by the same manufacturer, but there are no guarantees. Also, some of the motherboards below may be rebranded by vendors/distributors. 🧚

Currently None

🌸 EXAMPLES 🌸

# ipmi-dcmi --get-power-limit

Get power limit of the local machine. Easy. Local queen behavior 👑.

# ipmi-dcmi -h ahost -u myusername -p mypassword --get-power-limit

Get power limit of a remote machine using IPMI over LAN. Long distance relationship but it's working 💖.

# ipmi-dcmi -h mycluster[0-127] -u myusername -p mypassword --get-power-limit

Get power limit across a cluster using IPMI over LAN. Whole squad, all at once, slay 🌈.

🩺 DIAGNOSTICS 🩺

Upon successful execution, exit status is 0. On error, exit status is 1. Simple as that, no cap.

If multiple hosts are specified for communication, the exit status is 0 if and only if all targets successfully execute. Otherwise the exit status is 1. No partial credit bestie 💅.

⚠️ KNOWN ISSUES ⚠️

On older operating systems, if you input your username, password, and other potentially security relevant information on the command line, this information may be discovered by other users when using tools like the ps(1) command or looking in the /proc file system. It is generally more secure to input password information with options like the -P or -K options. Configuring security relevant information in the FreeIPMI configuration file would also be an appropriate way to hide this information. Please don't leave your creds out in the open like that 🙈.

In order to prevent brute force attacks, some BMCs will temporarily "lock up" after a number of remote authentication errors. You may need to wait awhile in order for this temporary "lock up" to pass before you may authenticate again. It's not ghosting you, it's just protecting itself 😭.

🐛 REPORTING BUGS 🐛

Report bugs to <freeipmi-users@gnu.org> or <freeipmi-devel@gnu.org>. They'll appreciate it fr fr 🫶.

Copyright (C) 2009-2015 Lawrence Livermore National Security, LLC.

This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 3 of the License, or (at your option) any later version.

👀 SEE ALSO 👀

freeipmi(7), ipmi-chassis(8), ipmi-config(8), ipmi-sel(8), ipmi-sensors(8), ipmiconsole(8), ipmipower(8)

http://www.gnu.org/software/freeipmi/

✨ And that's the whole page, bestie! This iconic piece of documentation is ipmi-dcmi version 1.6.20, dated 2026-10-05, filed under IPMI-DCMI(8). Go forth and get those power limits 💜🎀

📦 where this page comes from