IPMI

A dedicated low-power processor on the motherboard, separate from the main CPU. Has its own network interface (typically a separate physical port labelled "MGMT" or "iLO" or shared with one of the regular NICs via a sideband channel), its own firmware, its own web UI, its own SSH/IPMI-over-LAN interfaces.

The key property: it operates independently of the host operating system. The host can be powered off, hung on a kernel panic, in BIOS, or mid-reboot — IPMI keeps responding. As long as the server has power (even just standby power, no actual boot), the management processor is alive and reachable.

The standard is IPMI 2.0 (from 2004, still current). Vendor implementations add proprietary features: HPE iLO, Dell iDRAC, Supermicro IPMI, Lenovo XCC. All speak the IPMI standard underneath but have richer web UIs and additional features on top.

Power control. Power on, power off, hard reset, graceful shutdown. The equivalent of pressing the physical power button or unplugging the server, done over network.

Remote console (KVM-over-IP). See exactly what the server displays on its physical VGA output. Type into the keyboard as if you were standing in front of it. Watch the BIOS boot, the GRUB menu, the kernel messages, the login prompt. This is the killer feature.

Virtual media. Mount an ISO file from your laptop as if you had physically inserted a DVD into the server's optical drive. Boot from it. Install a fresh OS without ever touching the physical hardware.

Hardware monitoring. Read temperatures, fan speeds, voltages, power consumption, drive SMART status, RAID controller state.

Logs. System event log (SEL) captures hardware events: thermal warnings, power supply failures, ECC corrections, drive predictive failures. Persists across reboots.

BIOS/UEFI configuration. Some implementations let you remotely change BIOS settings without needing to boot to the BIOS screen interactively.

Two common configurations:

Dedicated management port. The IPMI interface has its own physical NIC, separate from the host's regular network. Best practice: this NIC connects to an isolated management VLAN that visitors can reach only via VPN. Provides clean separation between management plane and data plane. More expensive (more switch ports, more cabling, more IPs).

Shared management. The IPMI shares one of the regular network ports via NC-SI sideband. Saves a cable and a switch port. Trade-off: management traffic flows on the same physical link as customer traffic. Acceptable for less security-critical deployments.

What we deploy: dedicated management port wired to an isolated VLAN. Customers reach their IPMI through our VPN. No exposure of IPMI directly to the public internet.

IPMI implementations have had a history of security vulnerabilities. Default passwords. Authentication bypasses. Buffer overflows in the web UIs. Remote code execution.

An attacker who compromises the IPMI controller owns the server completely: they can power it off, install a malicious OS via virtual media, capture everything typed at the console, and persist below the operating system level.

This is why putting IPMI directly on the internet is a serious mistake. The risk-reward is bad: convenience for the admin, catastrophic risk if anything goes wrong. Industry standard practice is to firewall IPMI to a management network reachable only through VPN.

For our customer base, we put IPMI behind VPN by default. Customer accesses VPN, then reaches IPMI on the management VLAN. Nobody else on the internet can even see that IPMI exists.

For dedicated server customers, IPMI access fundamentally changes the operational experience:

• OS installation: install whatever OS you want, whenever you want, without datacenter intervention. Mount an Ubuntu ISO, an AlmaLinux ISO, a custom OS image — boot from it, install, done.
• Recovery from misconfiguration: firewalled yourself out via iptables? Broken sshd? Bad kernel update? Boot single-user mode via IPMI console, fix it, reboot. No ticket required.
• Performance debugging: see kernel messages during boot. Monitor hardware sensors during load tests. Identify thermal throttling, PSU issues, drive failures before they become outages.
• Forensics: if the host is compromised, you can boot from a known-clean rescue image via virtual media, inspect the drives offline, recover data without relying on the potentially compromised OS.

What we include for all dedicated server customers: IPMI access via VPN, web UI for casual use, IPMI-over-LAN for scripted operations, virtual media for OS installs, console redirect for serial-console access during boot.

IPMI has limits. A few scenarios where IPMI alone does not help:

• Power supply hard failure: if both PSUs are dead, IPMI is dead too. Datacenter must physically swap the PSU.
• Network controller failure: if the NIC that IPMI uses dies, you lose IPMI access. Dedicated management port mitigates this.
• Physical hardware swaps: failed drive in a server without hot-swap bays, failed memory module, failed CPU. Datacenter hands required.
• Datacenter network issues: if the datacenter's switching or routing fails between you and the server, IPMI is unreachable along with everything else.

For these scenarios you need remote-hands service from the datacenter. Most reasonable providers include some remote-hands hours in their dedicated server packages, or sell additional remote-hands time hourly.