Learn › BMC & Server Management › Power Control
Final test: the whole Power Control chapter. The power state machine over the network with ipmitool, chassis power status, on and off, the escalation from a graceful request to reset to cycle, watching node01 boot on the console over SOL, the power restore policy, and the vendor power verbs, restart cause and diagnostic interrupt a real Dell BMC adds. 25 objectives on a real workstation called mgmt with a real IPMI 2.0 controller at 10.100.0.2 that owns a real QEMU guest your power commands really move.
This chapter covers the following topics:
What you already know. Chapter 1 established the RMCP+ session and the -I lanplus -H -U -P -C 3 command form, and read chassis status and chassis power status on a host that had never been powered. This chapter uses the same session against a host that is running, and the commands in it control the emulated lab host. The same commands can disrupt a physical server when used there.
Objectives. After this chapter you can:
The machine. The software controller manages a QEMU virtual machine. Supported power actions can start, restart or stop that guest; status commands only read, and an accepted graceful request may leave it running. The console output quoted below came from that machine booting. Boot takes about 3 minutes. This chapter is free; the machine is yours for 60 minutes and stops itself after 20 minutes idle. The dark boxes below provide guided command checks. In the live lab, the machine and its evidence files are assessed separately.
This chapter uses a real Linux workstation and software-emulated IPMI hardware. The protocol requests and replies are real; controller identity, sensor values and host behavior may be seeded or emulated. Supplied physical-hardware captures are labeled separately.
These five questions establish whether you need this chapter in full. Each explanation names the section that covers the point.
>>> The reply echoes the request the controller accepted. It is not a report of the host's state, and it is identical whether the host obeyed or ignored it. The state has to be re-read with chassis power status. Section 2.5.
>>> Reset drives the hardware reset line: the machine restarts without power ever being removed. Cycle is a true power off followed by a power on, but it does not necessarily remove standby power or clear every device and fault record. Section 2.4.
>>> The response establishes that the controller accepted the request. A graceful shutdown also depends on platform support, host software and policy. Check the host and read its power state again; the reply alone does not prove delivery or shutdown. Section 2.3.
>>> The power restore policy is stored on the controller and takes one of three values: always-off, always-on, or previous, which restores whatever state the host was in when power was lost. It is read from chassis status. Section 2.6.
chassis power resetchassis power cyclechassis power diagchassis power soft repeated until it takes effect>>> chassis power diag requests a diagnostic interrupt. A dump depends on the platform, kernel panic handling, crash kernel and capture storage. A reset or cycle can lose volatile evidence; a dump already saved to persistent storage may survive. Section 2.11.
The chassis device is the part of the controller that owns the host's power circuit. It is one of the capabilities mc info lists, and it is what makes a controller able to start a machine that has no operating system.
Before changing a state, read it. chassis power status prints one line:
prompt: ops@mgmt:~$ answer: ipmitool -I lanplus -H 10.100.0.2 -U ADMIN -P ADMIN -C 3 chassis power status output: Chassis Power is off hint: chassis power takes a status subcommand.
The host is off. That reading is the baseline every later command in this chapter is compared against, and recording it before touching anything is what makes the comparison possible.
This is objective 2 in the lab, and it is produced by appending > ~/power/before.txt to the command above. Section 1.4 established that pattern; most objectives in this chapter use it.
chassis status reports the same power state alongside the fault flags and the restore policy.
prompt: ops@mgmt:~$ answer: ipmitool -I lanplus -H 10.100.0.2 -U ADMIN -P ADMIN -C 3 chassis status output: System Power : off Power Overload : false Power Interlock : inactive Main Power Fault : false Power Control Fault : false Power Restore Policy : always-off Last Power Event : Chassis Intrusion : inactive Front-Panel Lockout : inactive Drive Fault : false Cooling/Fan Fault : false hint: chassis has a status subcommand of its own.
Two fields matter for this chapter.
Power Restore Policy : always-off is what happens after a supply interruption. Section 2.6 returns to it.
Last Power Event records what caused the most recent power transition. It is blank here because nothing has caused one yet. On a machine that restarted unexpectedly, this field and the event log are the two places the cause is written down.
Fault indications such as Power Overload, Main Power Fault and Power Control Fault need the platform documentation for interpretation. Their retention and clearing behavior can differ. Read and save them before a reset or cycle, which may change the evidence.
chassis power on closes the host power circuit. It is the equivalent of pressing the power button, except that it does not require anyone to be in the building.
prompt: ops@mgmt:~$ answer: ipmitool -I lanplus -H 10.100.0.2 -U ADMIN -P ADMIN -C 3 chassis power on output: Chassis Power Control: Up/On hint: chassis power takes an on subcommand.
Read the reply carefully, because the shape of it is the single most important habit in this chapter.
Chassis Power Control: Up/On echoes the request the controller accepted. It does not say the host started. It does not say the host exists. A controller wired to an empty slot returns the same line.
A successful power-action reply identifies the accepted request; it does not establish the resulting host state. An action can also fail, so inspect the error and exit status. The status subcommand is a separate read, not a power action.
prompt: ops@mgmt:~$ answer: ipmitool -I lanplus -H 10.100.0.2 -U ADMIN -P ADMIN -C 3 chassis power status output: Chassis Power is on hint: The same status command as section 2.1.
Chassis Power is on. The reply in the previous step said the request was accepted; this says the host acted on it. Those are two different facts. Record both the accepted request and the later state observation so the sequence is clear.
If the expected transition is still absent after the platform's documented response time, investigate rather than assuming success. Check the request result, supply and interlock conditions, and platform logs. An unchanged state alone does not identify the cause.
The controller can also relay the host's serial port, which means the boot can be watched from the same session. sol activate attaches to it. Chapter 7 covers Serial over LAN properly; here it is evidence.
prompt: ops@mgmt:~$ answer: ipmitool -I lanplus -H 10.100.0.2 -U ADMIN -P ADMIN -C 3 sol activate output: [SOL Session operational. Use ~? for help] [ 4.906841] tsc: Refined TSC clocksource calibration: 2000.009 MHz [ 4.907808] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x1cd436d3a67, max_idle_ns: 440795276593 ns [ 4.908909] clocksource: Switched to clocksource tsc [ 5.362891] loop: module loaded [ 5.399861] scsi host0: ata_piix [ 5.411059] scsi host1: ata_piix [ 5.412011] ata1: PATA max MWDMA2 cmd 0x1f0 ctl 0x3f6 bmdma 0xc0c0 irq 14 [ 5.412583] ata2: PATA max MWDMA2 cmd 0x170 ctl 0x376 bmdma 0xc0c8 irq 15 [ 5.427738] tun: Universal TUN/TAP device driver, 1.6 [ 5.428979] PPP generic driver version 2.4.2 [ 5.431499] VFIO - User Level meta-driver version: 0.3 [ 5.436122] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [ 5.436843] ehci-pci: EHCI PCI platform driver [ 5.437387] ehci-platform: EHCI generic platform driver [ 5.437796] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver [ 5.438263] ohci-pci: OHCI PCI platform driver [ 5.442936] ohci-platform: OHCI generic platform driver ... (SOL stream trimmed; VOLATILE, different every boot) hint: sol has an activate subcommand and takes no channel argument here.
Your output will differ, because a boot is different every time and the moment you attach decides where in it you land. The shape does not differ: kernel messages with a timestamp in brackets, counting seconds since the kernel started.
This is the proof that chassis power on did something. A power state that reads on says the circuit is closed; a console carrying kernel messages says the machine on the end of it is running.
To leave a console session, type ~. at the start of a line. Inside an ssh session it is ~~., because ssh consumes the first tilde. Getting this wrong closes the ssh session instead, which is startling and harmless.
There are two ways to stop a running machine, and the difference is whether its operating system is given the chance to finish first.
chassis power soft sends an ACPI power-button event to the host. It is a request: the controller signals the host, and software on the host decides what to do about it. The host can perform an orderly shutdown if its software and power-button policy support that action. A handler may instead ignore the event or apply another configured policy.
prompt: ops@mgmt:~$ answer: ipmitool -I lanplus -H 10.100.0.2 -U ADMIN -P ADMIN -C 3 chassis power soft output: Chassis Power Control: Soft hint: chassis power takes a soft subcommand.
Chassis Power Control: Soft, the same shape of reply as every other power command. The controller accepted the request. The reply alone does not prove host delivery or a completed shutdown.
prompt: ops@mgmt:~$ answer: ipmitool -I lanplus -H 10.100.0.2 -U ADMIN -P ADMIN -C 3 chassis power status output: Chassis Power is on hint: The same status command again.
Still on. The controller accepted the request, but this later observation does not show a shutdown. These two observations alone do not prove delivery to the host.
The documented lab fixture runs a minimal host without a handler that performs this shutdown, so the lab calls this an ignored request. On another platform, an unchanged state could reflect host policy, a hung system, delivery failure or a transition still in progress. Investigate the host and platform before choosing a cause.
Two lessons follow. The polite option is tried first because it is the only one that lets the operating system flush its work. And it is followed by a state read, because success from the controller means nothing about the host.
Objective 8 in the lab records this: the state, and a sentence saying the host ignored the request. A file holding only the state does not record the finding.
If an approved recovery procedure calls for a harder action, chassis power reset requests a hard reset without relying on an orderly OS shutdown. It can lose work in progress. Inspect the response and confirm the restart separately.
A hard reset restarts the host without the requested off/on power cycle. Which memory and device state is reset or retained depends on the platform and firmware. Do not assume all latched state survives a reset.
prompt: ops@mgmt:~$ answer: ipmitool -I lanplus -H 10.100.0.2 -U ADMIN -P ADMIN -C 3 chassis power reset output: Chassis Power Control: Reset hint: chassis power takes a reset subcommand.
The same reply shape as every other power command. What the reset actually did has to be established separately, and the next two steps are the two places to look.
prompt: ops@mgmt:~$ answer: ipmitool -I lanplus -H 10.100.0.2 -U ADMIN -P ADMIN -C 3 chassis power status output: Chassis Power is on hint: The same status command again.
Chassis Power is on, which is what it read before the reset as well.
That is the point, and it is the trap. A reset never removes power, so the power state is identical either side of it. A state read confirms a power on and a power off; it confirms nothing at all about a reset. An engineer who checks the state, sees on, and concludes the reset worked has checked nothing.
The evidence has to come from the machine itself. Attaching to the console after a reset catches the boot:
prompt: ops@mgmt:~$ answer: ipmitool -I lanplus -H 10.100.0.2 -U ADMIN -P ADMIN -C 3 sol activate output: [SOL Session operational. Use ~? for help] [ 0.000000] Linux version 5.15.0-71-generic (buildd@lcy02-amd64-044) (gcc (Ubuntu 11.3.0-1ubuntu1~22.04.1) 11.3.0, GNU ld (GNU Binutils for Ubuntu) 2.38) #78-Ubuntu SMP Tue Apr 18 09:00:29 UTC 2023 (Ubuntu 5.15.0-71.78-generic 5.15.92) [ 0.000000] Command line: LABEL=cirros-rootfs ro console=tty1 console=ttyS0 [ 0.000000] KERNEL supported cpus: [ 0.000000] Intel GenuineIntel [ 0.000000] AMD AuthenticAMD [ 0.000000] Hygon HygonGenuine [ 0.000000] Centaur CentaurHauls [ 0.000000] zhaoxin Shanghai [ 0.000000] x86/fpu: x87 FPU will use FXSAVE [ 0.000000] signal: max sigframe size: 1440 [ 0.000000] BIOS-provided physical RAM map: [ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable [ 0.000000] BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved [ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000001ffdcfff] usable [ 0.000000] BIOS-e820: [mem 0x000000001ffdd000-0x000000001fffffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000fffc0000-0x00000000ffffffff] reserved ... (SOL stream trimmed; VOLATILE, different every boot) hint: The same console attach as section 2.3.
The timestamps start again from [ 0.000000]. That is a kernel that has just started, and it is the proof the reset took effect.
The first line names the kernel version and the compiler that built it. The second is the kernel command line, and console=ttyS0 on it is what makes this output appear on a serial port at all. A machine whose kernel was not given a serial console produces a silent SOL session, which is a configuration finding rather than a fault.
Your output will differ in the timings and in where the attach lands.
chassis power cycle is a true power off followed by a power on. The circuit opens, the machine loses power, and the circuit closes again.
prompt: ops@mgmt:~$ answer: ipmitool -I lanplus -H 10.100.0.2 -U ADMIN -P ADMIN -C 3 chassis power cycle output: Chassis Power Control: Cycle hint: chassis power takes a cycle subcommand.
The difference from a reset is what loses power. A cycle requests host power off and on; a reset requests a restart without that power cycle. Standby-powered components, the BMC and nonvolatile logs may remain. Consult the platform procedure when a full removal of auxiliary power is required.
That makes a cycle the tool for hardware that is stuck in a state a restart does not clear, and it makes a cycle destructive of exactly the evidence you would want if you were investigating why. Read the fault flags before cycling.
On this machine the difference is visible in the process table on the host that runs it: a reset keeps the same process, and a cycle produces a new one. On physical hardware, both actions can start a boot sequence. Their exact reset scope and self-test behavior depend on the platform.
Objective 12 asks for the difference in writing. printf writes a formatted string and \n is a newline:
prompt: ops@mgmt:~$ answer: printf 'reset reboots the SAME machine in place: the qemu process stays, the console shows a fresh boot.\ncycle is a true power off then on: a NEW process, the machine goes away and comes back.\n' > ~/power/reset-vs-cycle.txt output: hint: printf with the two sentences and a newline escape between them, redirected into the file.
The file reads:
reset reboots the SAME machine in place: the qemu process stays, the console shows a fresh boot.
cycle is a true power off then on: a NEW process, the machine goes away and comes back.The grader reads for the distinction, not for this wording. Any file that says a reset restarts the same machine in plac
Practice Power Control in a real Linux terminal at The Linux Camp. Progress is verified automatically as you type commands on the machine.