Learn › BMC & Server Management › First Day on the Floor

Power Control

The server in Bay 14 ignored a re-energized circuit and stayed dark. Learn standby power, the Dell serveraction power verbs, and cycle versus reset with interactive diagrams, then power a real BMC-managed server on from its iDRAC shell, cycle it, and prove every transition with captured getsysinfo evidence.

It is 05:47 at the DC-EAST facility in Ashburn, Virginia, and Bay 14, Row 7 is the only dark slot in the row.

Overnight, the facilities team updated firmware on the PDU that feeds this row. A PDU (Power Distribution Unit) is the rack's power strip, industrial grade: it takes facility power and feeds every outlet in the rack. Your R750xs was shut down cleanly at 01:47 for the window. At 05:12 facilities re-energized the circuit, and every server on it woke up and rejoined the pool.

Every server except yours. The Dell in Bay 14 is still dark. The nearest engineer is 40 minutes away, and the NOC wants this box serving by the 07:00 shift change.

Work Order DC-EAST-WO-1005: power the server on from the BMC, cycle it once to certify the new PDU feed, and prove every state change with captured evidence.

Here is the puzzle. There is a power button on that front panel, and nobody is standing in front of it. How do you press a button from 2,000 miles away?

This is a Practice Zone. The diagrams below react to you: click the boxes, flip the switches. The real machine comes at the end, under Ready to practice.

Start with a secret about that front-panel button: it is not a switch. It does not carry the server's power. It is a doorbell wired to the BMC, and the BMC decides what the power supplies do.

When the rack has power, each PSU generates a small standby rail (a few watts at 5 volts) that never turns off. The BMC lives on that rail. "Chassis off" only means the main rails, the heavy power feeding the CPUs and drives, are down. The little computer that manages the box stays awake the whole time, listening on the management network.

Flip the chassis power below and watch what actually goes dark.

{ "height": 420, "caption": "Chassis off is not power off. Flip the switch and see who stays awake.", "nodes": [ { "id": "pdu", "label": "Rack PDU", "kind": "psu", "x": 0, "y": 60, "detail": "Power Distribution Unit: takes facility power and feeds every outlet in the rack. Its firmware is what facilities updated overnight." }, { "id": "psu1", "label": "PSU1", "kind": "psu", "x": 240, "y": 20, "detail": "One of two redundant power supplies. Makes the heavy main rails, and also a small always-on 5V standby rail." }, { "id": "psu2", "label": "PSU2", "kind": "psu", "x": 240, "y": 150, "detail": "The redundant twin. Either PSU alone can carry the server." }, { "id": "host", "label": "Host system", "kind": "host", "x": 700, "y": 40, "detail": "Main board, CPUs, drives. Only alive when the main rails are up. This is the part that is dark in Bay 14 right now." }, { "id": "bmc", "label": "BMC", "kind": "bmc", "x": 470, "y": 260, "detail": "Runs on the standby rail. Alive the moment the rack has power, even with the chassis off. This is who answers you." }, { "id": "you", "label": "You (NOC)", "kind": "admin", "x": 0, "y": 330, "detail": "Remote hands, no cart. Everything you do rides the management network." }, { "id": "msw", "label": "Mgmt switch", "kind": "net", "x": 240, "y": 330, "detail": "The management switch for this row. Every BMC port in the row uplinks here." } ], "edges": [ { "from": "pdu", "to": "psu1", "kind": "power" }, { "from": "pdu", "to": "psu2", "kind": "power" }, { "from": "psu1", "to": "host", "label": "main rails", "kind": "power" }, { "from": "psu2", "to": "host", "kind": "power" }, { "from": "psu1", "to": "bmc", "label": "5V standby rail", "kind": "power" }, { "from": "bmc", "to": "host", "label": "power button signal", "kind": "power" }, { "from": "you", "to": "msw", "kind": "mgmt" }, { "from": "msw", "to": "bmc", "kind": "mgmt" } ], "toggle": { "label": "Chassis power:", "on": "ON", "off": "OFF (standby)", "dimOff": ["host", "e:psu1-host", "e:psu2-host"] } }

That is the answer to the puzzle. The button was never a switch. Pressing power on a modern server sends a signal to the BMC, and the BMC drives the rails. Your workstation can send the same signal over the management network, which puts the front panel of Bay 14 on your desk.

Ops discipline, rule one: never act on a power state you have not read. The work order says the server is off. The controller can say for certain. So your first move is not to press anything. It is to open the BMC's own shell and ask it.

This is the Dell iDRAC shell you met in your first work order: an SSH session straight to the management processor at $BMC_IP, credentials ADMIN / ADMIN. Once you are inside, one command prints the system readout, and near the top of it sits the single line you came for. Type getsysinfo:

prompt: /admin1-> answer: getsysinfo output:

System Information ============================================================ System Model: PowerEdge R750xs Manufacturer: Dell Inc. Service Tag: SVC1234567 Hostname: bay14-r750xs Power State: OFF

Processor Information ------------------------------------------------------------ CPU Count: 2 CPU Model: Intel Xeon Gold 6338 hint: At the /admin1-> prompt, the Dell command that prints System Information is a single word: getsysinfo

There it is, straight from the controller: Power State: OFF. The paperwork and the iDRAC agree. The box is genuinely down, main rails and all, and now you may touch it.

On a real Dell iDRAC the same readout comes from racadm getsysinfo. Inside this BMC shell you type it without the racadm prefix, but it is the identical command and the identical Power State line. The muscle memory carries straight to physical hardware.

Inside the Dell shell, everything you do to server power is serveraction plus one word. The controller turns that word into rail work. getsysinfo is the question that changes nothing; these are the actions:

These are the exact verbs a real Dell iDRAC speaks: racadm serveraction powerup, powerdown, graceshutdown, powercycle, hardreset. The universal IPMI standard names the same physics with different words (chassis power on, off, soft, cycle, reset), but on Dell hardware, in the Dell shell, serveraction is the native tongue.

The distinction that matters most is graceshutdown versus powerdown. Flip the verb below and watch which path lights up.

{ "height": 340, "caption": "graceshutdown asks the OS. powerdown cuts the rails. Flip the verb.", "nodes": [ { "id": "you", "label": "You (NOC)", "kind": "admin", "x": 0, "y": 170 }, { "id": "bmc", "label": "BMC", "kind": "bmc", "x": 300, "y": 170, "detail": "Receives the serveraction verb and decides which wire to pull: the polite request into the OS, or the rails themselves." }, { "id": "os", "label": "Host OS", "kind": "host", "x": 650, "y": 40, "detail": "Only a running OS can flush caches, stop services, and unmount filesystems. A graceful shutdown needs someone home to hear it." }, { "id": "rails", "label": "PSU main rails", "kind": "psu", "x": 650, "y": 300, "detail": "Cutting these mid-write is how filesystems get corrupted. powerdown and powercycle live here." } ], "edges": [ { "from": "you", "to": "bmc", "label": "serveraction verb", "kind": "mgmt" }, { "from": "bmc", "to": "os", "label": "graceshutdown: ACPI request", "kind": "oob" }, { "from": "bmc", "to": "rails", "label": "powerdown: cut the rails now", "kind": "power" }, { "from": "rails", "to": "os", "kind": "power" } ], "toggle": { "label": "Shutdown verb:", "on": "graceshutdown", "off": "powerdown", "dimOn": ["e:bmc-rails"], "dimOff": ["e:bmc-os"] } }

graceshutdown is a request: the OS hears it, flushes caches to disk, stops services, unmounts filesystems, then powers down on its own terms. powerdown is not a request, it is the rails going dead mid-sentence. When an OS is running, graceful first, always. Bay 14 has no OS installed yet, so there is nobody aboard to hear a graceful request; its transitions are pure rail work, which is exactly what this work order calls for.

The work order does not just say power it on. Facilities asked for one full power cycle on the new PDU feed. Why not a reset? Because they are different operations, and only one proves what facilities needs proven.

{ "height": 300, "caption": "Two ways to restart. Only one re-proves the power path.", "nodes": [ { "id": "bmc", "label": "BMC", "kind": "bmc", "x": 0, "y": 170, "detail": "Takes the powercycle or hardreset verb and pulls a very different lever for each." }, { "id": "rails", "label": "PSU main rails", "kind": "psu", "x": 360, "y": 40, "detail": "A powercycle drops these, waits, restores them. The whole power path gets exercised, including the upstream PDU feed." }, { "id": "host", "label": "Host + POST", "kind": "host", "x": 720, "y": 170, "detail": "A cold start runs the full Power-On Self-Test. A hardreset restarts the machine without the rails ever moving." } ], "edges": [ { "from": "bmc", "to": "rails", "label": "powercycle: drop rails, pause, restore", "kind": "power" }, { "from": "rails", "to": "host", "label": "cold start, full POST", "kind": "power" }, { "from": "bmc", "to": "host", "label": "hardreset: pulse the reset line", "kind": "oob" } ], "toggle": { "label": "Verb:", "on": "powercycle", "off": "hardreset", "dimOn": ["e:bmc-host"], "dimOff": ["e:bmc-rails", "e:rails-host"] } }

A powercycle takes the rails all the way down, pauses, and brings them back. The entire power path, from the new PDU firmware through the PSUs to the board, is re-proven end to end, and the machine cold-starts through its full POST (Power-On Self-Test). A hardreset only pulses the reset line; the rails never blink, so it proves nothing about the feed. After PDU work, a cycle is the certification.

One ordering rule the controller enforces: a powercycle needs a running server. Ask a powered-off box to cycle and the shell refuses, because there are no live rails to drop. So the sequence is fixed: power it up first, confirm it is on, then cycle. Here is the up verb in the shell. Type serveraction powerup:

prompt: /admin1-> answer: serveraction powerup output: Server power operation initiated: Power Up Server is powering on... Operation completed successfully. hint: Inside the shell, the verb family is serveraction, and the word that raises the rails is: powerup

That reply is the controller acknowledging the order. An acknowledgment is not a state. Ask the controller again and read the real answer:

prompt: /admin1-> answer: getsysinfo output:

System Information ============================================================ System Model: PowerEdge R750xs Manufacturer: Dell Inc. Service Tag: SVC1234567 Hostname: bay14-r750xs Power State: ON hint: The same one-word question as before: getsysinfo. Watch the Power State line flip.

The NOC does not close work orders on your word. It closes them on captured output: the state before you acted and the state after, filed where an auditor can find them. In six months, when someone asks who verified Bay 14 after the PDU window, the answer is a file with your timestamp on it, or it is nobody.

Here is the trick that makes this fast. You do not have to sit inside the interactive shell to capture its output. You can feed a command to the BMC shell and redirect what comes back, all in one line from your workstation, so the readout lands straight in a file:

echo getsysinfo | connect-to-the-bmc > ~/evidence.txt

Capture the state before a transition. Act. Capture the state after. Every transition in the work order ahead follows that rhythm, and the challenge at the end asks you to file the final proof with no help.

One honest line about this lab: the BMC is a standards-faithful emulator, and its power state machine is real (the shell's power verbs drive it and getsysinfo reads it back, sharing one state), but no operating system boots behind it, so power-on is instant with no POST and no OS to receive a graceful shutdown. Every command you type is the real Dell command; only the hardware behind it is simulated.

Time to do it for real. Work Order DC-EAST-WO-1005, Bay 14, Row 7. The BMC address is preset in $BMC_IP, credentials ADMIN / ADMIN. Everything happens in the Dell iDRAC shell. Five objectives stand between now and the 07:00 shift:

1. File the before state. Ask the controller for its system readout and capture the proof it is OFF to ~/power-before.txt. 2. Bring Bay 14 back up. Send the power-up verb to the controller and capture its acknowledgment to ~/power-on-action.txt. 3. Prove it came up. Ask the controller again and capture the readout showing ON to ~/power-after.txt. 4. Certify the new feed. Send one full power cycle and capture its acknowledgment to ~/power-cycle-action.txt. 5. CHALLENGE: close the order. Capture one final system readout, proving the box is up on the new feed, to ~/wo-1005-proof.txt. No structure given.

The workspace shows no commands. It hands you one objective at a time, and you recall the move. That recall is the point: it is how last hour's reading becomes your skill.

Stuck is normal. Hit Request a signal on any objective for a nudge, or ask Daemon. It knows exactly which task you are on and will nudge, not spoil.

Your workstation dc-east-ws01 is booting in the bay below, with the Dell BMC beside it on the management network. The server in Bay 14 is dark and waiting for its human. Launch, and close DC-EAST-WO-1005 before the shift change.

Practice Power Control in a real Linux terminal at The Linux Camp. Progress is verified automatically as you type commands on the machine.