napalm-amt

NAPALM driver for Intel Active Management Technology (AMT), the management controller built into Intel vPro business desktops, mini PCs and notebooks, over DMTF WS-Management. Built on napalm-device-types. Written for netOrk.

Status: early development. One driver, amt (napalm_amt.AmtDriver), a ManagementControllerDriver from napalm-device-types like the server BMC drivers in napalm-redfish. It reads the machine's identity, hardware, firmware, power state and event log, reports what AMT listens on, and switches the machine's power. It is tested against Intel's published recordings of an AMT 12 (NUC9). Recordings of the first real test devices, two Lenovo ThinkCentre M910x (AMT 11.x), are still to come.

Why a driver of its own

AMT does the job of a server BMC (power control and inventory while the operating system is down or the machine is off), but speaks a different protocol: no Redfish and no IPMI, only WS-Management (SOAP, CIM classes) on port 16992, or 16993 with TLS. It shares nothing with napalm-redfish beyond the role, so it lives here.

Layout

optional_args: port (16992; 16993 means TLS), tls (overrides what the port implies), verify_ssl (True, a CA file path, or False), retries (1).

The WS-Management client in napalm_amt/wsman.py is self-contained (requests, and defusedxml to parse the answers). Neither pywsman (a C binding) nor python-amt (unmaintained, power only) is used.

What AMT knows, and what it does not

AMT reads the machine's SMBIOS: manufacturer, model, serial number, system UUID, CPUs, DIMMs, drives (sizes only), BIOS version. It has no temperature, fan or power-supply readings on client platforms, no core counts, and no drive models. Where it knows nothing, the driver says so (None, empty) and does not guess. See docs/amt-map.md.

AMT shares the machine's network controller. In DHCP mode it also uses the operating system's IP address. netOrk keeps one device per address, so give AMT a static IP address of its own in the MEBx (docs/lenovo-m910x.md).

Documents

• docs/amt-map.md: getters mapped to WS-Management classes
• docs/security.md: plain HTTP vs TLS, accounts, KVM, known CVEs
• docs/lenovo-m910x.md: first test devices, MEBx setup, what to verify
• docs/testing.md: fixtures, recording a real AMT
• docs/references.md

Development

The rules are in STANDARDS.md.

python -m venv .venv
.venv/bin/pip install -e '.[dev]'
.venv/bin/pytest --cov
.venv/bin/ruff format --check . && .venv/bin/ruff check . && .venv/bin/mypy napalm_amt

Conventions

These follow the other drivers in the NAPALM organisation:

• Role bases declare, they never implement. Generic logic goes into napalm-device-types, vendor mechanics stay here.
• Parsing lives in pure functions (napalm_amt/parsers/), tested on recorded responses under tests/fixtures/<source>/, with a COMMANDS.txt listing the request behind each file.