Lenovo XClarity Controller Setup and Updates

Every rack server carries a baseboard management controller, and on Lenovo ThinkSystem hardware that controller is XClarity Controller (XCC). It provides out-of-band console access, virtual media for operating system installs, firmware updates that do not depend on a running operating system, and a Redfish API that makes fleet-wide automation practical. Getting XCC configured correctly the first time — dedicated management network, correct certificate, firmware baseline — saves an enormous amount of time later, because a BMC is the only piece of a server you must be able to reach when the server itself is broken. This guide covers setup, updates and automation.

Initial setup

XCC has a default IPv4 address of 192.168.70.125 on the dedicated management port (DHCP if a DHCP server answers). The fastest path to a known state is a local console connection or the server's front panel, then a browser session.

1. connect the XCC management port to a management VLAN (never an in-band production VLAN)
2. browse to https://<dhcp-address-or-192.168.70.125>
3. log in with the factory credentials, then change them immediately
4. set a static address, mask, gateway and DNS
5. upload a proper TLS certificate (SAN matching the XCC hostname)
6. set the hostname to match your naming convention, e.g. srv-dc1-07-xcc

# the same configuration from the operating system, while it still boots
ipmitool -I lanplus -H 10.50.0.107 -U admin -P <password> lan print 1
ipmitool -I lanplus -H 10.50.0.107 -U admin -P <password> mc info
ipmitool -I lanplus -H 10.50.0.107 -U admin -P <password> sensor list | head -20
ipmitool -I lanplus -H 10.50.0.107 -U admin -P <password> sel list

The dedicated management port should live on a separate, firewalled network with access limited to administrators, the update server and the monitoring system. A BMC on a general-purpose VLAN is a standing remote-code-execution risk that no OS hardening addresses.

Redfish: automate instead of clicking

# discover the manager and its capabilities
curl -sk -u admin:<password> https://10.50.0.107/redfish/v1/Managers/1 | jq '.FirmwareVersion, .Model'
curl -sk -u admin:<password> https://10.50.0.107/redfish/v1/Systems/1 | jq '.PowerState, .Model'
curl -sk -u admin:<password> https://10.50.0.107/redfish/v1/Chassis/1/Thermal | jq '.Temperatures[] | {Name, ReadingCelsius, Status}'

# read firmware inventory
curl -sk -u admin:<password> https://10.50.0.107/redfish/v1/UpdateService/FirmwareInventory | jq '.Members[].@odata.id'

# apply a firmware update from an HTTP-hosted package
curl -sk -u admin:<password> -X POST https://10.50.0.107/redfish/v1/UpdateService/Actions/UpdateService.SimpleUpdate \
  -H "Content-Type: application/json" \
  -d '{"ImageURI":"http://update.example.com/firmware/lnvgy_fw_xcc_x.x.x.bin","TransferProtocol":"HTTP"}'

# power control
curl -sk -u admin:<password> -X POST https://10.50.0.107/redfish/v1/Systems/1/Actions/ComputerSystem.Reset \
  -H "Content-Type: application/json" -d '{"ResetType":"On"}'

Standard Redfish resource paths mean one script can cover XCC, iDRAC and iLO with almost no branching — the fleet-wide pattern described in the Redfish automation guide applies directly. Poll UpdateService for the task state rather than assuming a POST that returns 202 has finished.

Remote console and virtual media

• Remote console is HTML5 in current XCC versions (Java and ActiveX are legacy). Test it from the same network your administrators use — corporate proxy settings break the console more often than the BMC does.
• Virtual media mounts an ISO from your workstation, a share, or an HTTP URL. Keep a known-good boot ISO (firmware bootable media, a rescue environment, an OS installer) on the update server so it is available when a laptop is not.
• Mount virtual media before rebooting, and set the boot override to one-time so the server does not boot from a stale virtual CD three months later.

# mount an ISO from the network and boot it once
curl -sk -u admin:<password> -X POST https://10.50.0.107/redfish/v1/Managers/1/VirtualMedia/CD \
  -H "Content-Type: application/json" \
  -d '{"Image":"http://update.example.com/iso/lenovo-bootable-fw-x.x.iso","Inserted":true,"TransferProtocolType":"HTTP"}'

Firmware updates without downtime surprises

Update appliance workflow (fleet):
 1. define a firmware compliance policy per server model
 2. sync the repository from Lenovo's catalog
 3. run a compliance report before any update
 4. apply in maintenance windows, one server per cluster at a time
 5. verify the new versions in FirmwareInventory and check the SEL for errors

Per-server (XCC only, no OS involvement):
 curl -sk -u admin:<password> https://10.50.0.107/redfish/v1/UpdateService/FirmwareInventory | jq
 curl -sk -u admin:<password> https://10.50.0.107/redfish/v1/UpdateService | jq '.ServiceEnabled, .HttpPushUri'

Order matters when a firmware bundle covers XCC, UEFI, the RAID controller and network adapters: update XCC first (it performs the rest reliably), then UEFI, then the rest. A power loss during a UEFI or BMC flash can require a service call, so never flash both power supplies' feeds in the same maintenance window without a UPS and a fallback.

Verification checklist

1. XCC answers on its static address from the management network and nowhere else.
2. TLS certificate has no expiry warning and the SAN matches the hostname used in monitoring.
3. Redfish returns firmware inventory, thermal data and power state; the same credentials work for a second server.
4. An update task completes with a "Completed" state and the inventory shows the new version.
5. SEL is clear of new critical events after the update, and the OS boots with all expected devices present (persistent device names change more often than people expect after a NIC firmware update).
6. The inventory record — serial number, model, XCC address, firmware baseline — is stored in your CMDB or IPAM alongside the management address.

Operational practice

• Standardise credentials with a per-fleet account plus a documented break-glass account kept in your password manager.
• Monitor BMCs for reachability and log events; the same monitoring that graphs switch ports should graph XCC, iLO and iDRAC availability — see HPE iLO 5 setup for the equivalent configuration on the other vendor.
• Keep the firmware baseline documented per model and review it quarterly; "everything up to date" is not a compliance statement.
• Never leave a BMC on a default password, even on an isolated management network — the isolation is one misconfigured trunk away from being undone.
• Automate the inventory export, so a chassis replacement does not begin with discovering what the old node looked like.

原文链接：https://pubs.lenovo.com/xcc-webui/