11.5 Out-of-Band Management and Remote Console Access

11.5 Out-of-Band Management and Remote Console Access

The last knowledge statement under Objective 3.2 is "identify use cases for OOB management," and the blueprint backs it with three references — Prepare Bare-Metal Nodes for Imaging, Configuring Out-of-Band Management Credentials, and Remote Console IP Address Configuration — plus Deploying Power Monitor Application. Those four titles tell you exactly what the exam expects: what OOB is for, how it is addressed, how it is secured, and what else Nutanix reads from the hardware.

In-Band vs. Out-of-Band

In-band management reaches a server through its running operating system — SSH to the host, the CVM command line, the Prism interface. It works only while the host is up and on the network.

Out-of-band management reaches the server through a dedicated microcontroller on the motherboard — the baseboard management controller (BMC) — which has its own network interface, its own firmware, and its own power domain. It operates whether or not the host operating system is running, and as long as the server has power it is reachable even when the server is switched off.

That is the entire point: OOB works precisely when in-band does not.

The Vendor Names

One capability, several brand names. Nutanix runs on multiple hardware platforms, so you should recognize all of these as the same thing:

Strictly, IPMI is the standard protocol and the others are vendor implementations with their own web interfaces, but in Nutanix documentation and conversation "the IPMI address" is commonly used for whichever one a platform has.

The Use Cases

Four scenarios cover essentially every OOB question.

1. Remote power control

Power a node on, power it off, or issue a hard reset without anyone in the datacenter. This is what you reach for when a host has hung so thoroughly that it no longer responds to any in-band method — the alternative is somebody physically pressing a button. It is also how a node is brought back up after a full cluster shutdown when the hosts were powered off rather than left running, which connects this section directly to the shutdown sequence in section 11.3.

2. Console access before the operating system exists

The BMC provides a remote console showing exactly what a monitor plugged into the server would show. That matters at moments when nothing else can help:

• Watching POST and hardware initialization.
• Entering BIOS or UEFI setup.
• Watching an operating system install or a Foundation imaging run progress.
• Seeing why a host fails to boot at all.

SSH cannot show you a BIOS screen. The remote console can.

3. Hardware health and sensor data

The BMC reads hardware sensors directly: temperatures, fan speeds, power supply status, voltages, and the hardware event log. It reports these independently of the operating system, which is why hardware alerting survives an OS failure. Nutanix also surfaces much of this through Prism's hardware views and through NCC checks, but the BMC is the origin of the data.

4. Virtual media for imaging and recovery

The BMC can mount an ISO image from your workstation as if it were a physical drive in the server. That is how a bare-metal node is imaged or recovered remotely, and it is the mechanism behind the blueprint reference "Prepare Bare-Metal Nodes for Imaging." It connects directly to the Foundation workflow from section 10.2: Foundation needs a reachable BMC on each target node in order to boot it into the imaging environment.

Getting an Address onto the BMC

A BMC that has no IP address cannot help you, and a factory node does not arrive with one that matches your network. Nutanix documents three ways to set it:

1. From the BMC's own web interface, if it already has a reachable address you want to change.
2. From the hypervisor host command line, using the ipmitool utility to set the LAN parameters on the local node.
3. From BIOS/UEFI setup, reached through the console at boot — the fallback when neither of the first two is available, and the only option on a node that has never been configured.

Addressing: Three Per Node, Two Per Cluster

The practical planning consequence: each node normally needs three IP addresses, and the cluster needs two more on top.

Foundation configures the three per-node addresses during imaging, and the Expand Cluster workflow asks for all three when adding a node. Forgetting to plan the third is a common cause of an expansion stalling. Note also that the OOB interface is not required for day-to-day operations and does not have to be reachable from the CVM — it can sit on a completely isolated management VLAN, which is exactly where it belongs.

Credentials and Security

The BMC is powerful in a way that deserves respect: it can power-cycle hardware, watch the console, and mount media. Two consequences follow.

Change the default credentials. On older Nutanix NX hardware, every node shipped with the same well-known ADMIN / ADMIN pair. From BMC firmware 7.08 onward, NX nodes ship with a unique per-node password — the node's serial number in capital letters — printed on a sticker on the chassis, with ADMIN still the username. Either way, unchanged factory credentials on a management interface are among the most reliably exploited findings in any infrastructure audit, and the blueprint reference "Configuring Out-of-Band Management Credentials" exists for exactly this reason.

Put OOB interfaces on a restricted management network, segregated from general user and workload traffic. An out-of-band interface reachable from a user VLAN hands an attacker console access and virtual media on every node.

Redfish: The Modern Path LCM Uses

Redfish is the HTTPS/REST successor to the original IPMI protocol, and it is the reason OOB shows up in software maintenance as well as hardware maintenance. On supported platforms the Life Cycle Manager drives BMC and BIOS firmware updates through Redfish rather than the legacy method of booting each node into a Phoenix ISO:

On platforms where Redfish is not available, LCM falls back to the Phoenix procedure. The exam-level takeaway is the direction of travel: fewer reboots and shorter maintenance windows, achieved by talking to the same out-of-band controller this section is about.

Power Monitor: Reading the Hardware from Prism Central

The blueprint's fourth reference under this objective, Deploying Power Monitor Application, covers a Prism Central application that charts real power consumption at cluster and node level. It is deployed from Admin Center → Marketplace in Prism Central rather than being enabled with a checkbox, requires a recent Prism Central release running against AOS 7.0 or later on a Large or X-Large Prism Central instance, and is supported on a subset of hardware vendors. Its metrics are also available through the API for external reporting. Recognize it as the sustainability and capacity-planning counterpart to the BMC's raw sensor data.

What Out-of-Band Management Is Not

Two traps worth memorizing:

• A guest VM console is not an OOB console. When a scenario asks how to reach the screen of a virtual machine, the answer is the VM console in Prism, not IPMI. The BMC shows the physical host's screen only.
• OOB does not fix cluster problems. It gives you hardware control, not data-path control. A degraded storage container, a failed service, or a resiliency warning is diagnosed with Prism, NCC, and Logbay — not with the BMC.

[!TIP] Exam shortcut: if the host operating system is down, unreachable, or not yet installed, the answer involves out-of-band management. If the host is up and reachable, the answer is an in-band tool such as Prism, SSH, or NCC.