What Redfish Must Expose Before You Rent a Dedicated Server

Our reproduced Redfish endpoint looked healthy: one powered-on system, one BMC manager, an OK health rollup, a standard reset target, GracefulRestart, PXE and CD boot choices, and two virtual-media resources. It still failed the strict reinstall policy because neither media resource exposed an InsertMedia action. The narrower reboot-only policy passed.

For a buyer, the split is the purchase decision. “Redfish included” does not say whether a customer can recover an unreachable operating system, attach installation media, use a remote console, or only request a reboot. A dedicated-server buyer should ask for an evidence receipt tied to the offered machine, firmware and account before the workload becomes dependent on it.

Infrastructure buyers and technical leads can run the Bash, curl and jq checks directly, or ask a provider to produce an equivalent read-only receipt. The safe lab uses DMTF’s public fictional rack-mount mockup at a pinned source commit. It listens only on 127.0.0.1, sends no POST, PATCH or DELETE request, uses no credential and never touches real power. The mock proves the acceptance method, not any provider’s hardware or security controls.

Define Recovery Before Comparing Server Prices

Out-of-band management uses a baseboard management controller, or BMC, that operates separately from the host operating system. Redfish exposes BMC and hardware resources through HTTPS and JSON on real systems. If Linux has crashed or the host firewall is wrong, a correctly designed management path can remain reachable.

Recovery is not one capability. Decide which outcome the workload requires, then make each dependency observable:

CPU, RAM, NVMe, RAID and network capacity remain separate purchase inputs. Size them with guidance in dedicated-server hardware inventory, then add this recovery receipt beside the quote. If the infrastructure model itself remains unsettled, compare models through dedicated server versus cloud workload choice before testing a machine-specific recovery path. A powerful server with no usable emergency path can still create a long hands-on recovery delay.

Microsoft’s Redfish Basic Tests treat out-of-band capability as a real client/server test with a target URI, credentials, logs and nonzero failures. The buyer-side contract below applies the same fail-closed idea to a smaller, non-destructive decision.

Pin a Disposable Redfish Service

DMTF’s commit-pinned Redfish Mockup Server README documents the static sample service used for development. The first block refuses an existing lab path instead of deleting unknown data, records a marker, checks out that exact commit and installs dependencies only inside a Python virtual environment. The source-file hash makes the server code attributable even if the repository later changes.

set -Eeuo pipefail
LAB=/tmp/voxfor-redfish-buyer-lab
MARKER="$LAB/.voxfor-redfish-buyer-lab"
REPO="$LAB/Redfish-Mockup-Server"
SOURCE_COMMIT=2d39eb14122337ceab0712a9610b1cd37c65f487

if [[ -e "$LAB" ]]; then
  printf 'Refusing existing path: %s\n' "$LAB" >&2
  exit 1
fi
install -d -m 0700 "$LAB"
printf '%s\n' voxfor-redfish-buyer-lab-v1 > "$MARKER"
command -v git python3 curl jq sha256sum >/dev/null

git clone -q https://github.com/DMTF/Redfish-Mockup-Server.git "$REPO"
git -C "$REPO" checkout -q "$SOURCE_COMMIT"
test "$(git -C "$REPO" rev-parse HEAD)" = "$SOURCE_COMMIT"
python3 -m venv "$LAB/venv"
"$LAB/venv/bin/pip" install -q -r "$REPO/requirements.txt"

SERVER_HASH=$(sha256sum "$REPO/redfishMockupServer.py" | awk '{print $1}')
test "$SERVER_HASH" = d4e712d4107c5778d82345f4d096e0cb64c08495735b5fd2233289877f6c0a01
printf 'source_commit=%s\nserver_sha256=%s\npython=%s\n' \
  "$SOURCE_COMMIT" "$SERVER_HASH" "$(python3 --version | awk '{print $2}')" \
  | tee "$LAB/source.receipt"

This is a lab endpoint, so it deliberately uses HTTP and no authentication on loopback. A real BMC should use HTTPS with a certificate identity you verify, restricted management-network reachability and a named least-privilege account. The Paessler Redfish overview usefully separates out-of-band from host-network access and describes basic versus session authentication; those controls must be checked on the live offer, not inferred from this mock.

Start the server on one fixed loopback port. The block records both the process ID and Linux process start time. Cleanup will require both values, preventing an unrelated process that later reused the same PID from being killed.

set -Eeuo pipefail
LAB=/tmp/voxfor-redfish-buyer-lab
MARKER="$LAB/.voxfor-redfish-buyer-lab"
REPO="$LAB/Redfish-Mockup-Server"
BASE=http://127.0.0.1:18048
test "$(<"$MARKER")" = voxfor-redfish-buyer-lab-v1

nohup "$LAB/venv/bin/python" "$REPO/redfishMockupServer.py" \
  -H 127.0.0.1 -p 18048 -S -D "$REPO/public-rackmount1" \
  > "$LAB/server.log" 2>&1 &
SERVER_PID=$!
printf '%s\n' "$SERVER_PID" > "$LAB/server.pid"
awk '{print $22}' "/proc/$SERVER_PID/stat" > "$LAB/server.starttime"

for attempt in $(seq 1 50); do
  curl -fsS "$BASE/redfish/v1" > "$LAB/root.json" && break
  sleep 0.1
done
test "$(jq -r .RedfishVersion "$LAB/root.json")" = 1.15.0
printf 'listener=127.0.0.1:18048 service_version=%s\n' \
  "$(jq -r .RedfishVersion "$LAB/root.json")"

Red Hat’s worked Redfish mockup tutorial is the strongest same-intent execution reference opened for this article. It starts at the service root and follows resource links. This guide continues from that foundation to a buyer acceptance policy.

Follow Links Instead of Guessing Vendor Paths

Redfish is a hypermedia API. The service root publishes links to collections, and each collection publishes member @odata.id values. HPE’s Redfish conformance primer warns that non-root URIs must be treated as opaque: an HPE path, a Dell path and a demonstration mockup may use different leaf identifiers.

Next, discover the first system and manager dynamically. Saving those opaque paths for later requests avoids hard-coding the mock system serial number.

set -Eeuo pipefail
LAB=/tmp/voxfor-redfish-buyer-lab
MARKER="$LAB/.voxfor-redfish-buyer-lab"
BASE=http://127.0.0.1:18048
test "$(<"$MARKER")" = voxfor-redfish-buyer-lab-v1

SYSTEMS_URI=$(jq -r '.Systems["@odata.id"]' "$LAB/root.json")
MANAGERS_URI=$(jq -r '.Managers["@odata.id"]' "$LAB/root.json")
curl -fsS "$BASE$SYSTEMS_URI" > "$LAB/systems.json"
curl -fsS "$BASE$MANAGERS_URI" > "$LAB/managers.json"
SYSTEM_URI=$(jq -r '.Members[0]["@odata.id"]' "$LAB/systems.json")
MANAGER_URI=$(jq -r '.Members[0]["@odata.id"]' "$LAB/managers.json")
test "$SYSTEM_URI" != null
test "$MANAGER_URI" != null
printf '%s\n' "$SYSTEM_URI" > "$LAB/system.uri"
printf '%s\n' "$MANAGER_URI" > "$LAB/manager.uri"
printf 'system_uri=%s manager_uri=%s\n' "$SYSTEM_URI" "$MANAGER_URI"

Collection count also matters. A chassis manager or rack aggregator may expose several systems. This lab intentionally selects one because the public mock has one member. On an offered endpoint, retain every member and map the serial number or asset tag to the exact quoted machine before accepting anything.

Separate Hardware Health From Recovery Control

System and manager health answer “what does the BMC currently report?” They do not answer “what can this customer account do?” Record both objects before examining actions so a receipt cannot substitute a healthy status for a recovery mechanism.

set -Eeuo pipefail
LAB=/tmp/voxfor-redfish-buyer-lab
MARKER="$LAB/.voxfor-redfish-buyer-lab"
BASE=http://127.0.0.1:18048
test "$(<"$MARKER")" = voxfor-redfish-buyer-lab-v1
SYSTEM_URI=$(<"$LAB/system.uri")
MANAGER_URI=$(<"$LAB/manager.uri")

curl -fsS "$BASE$SYSTEM_URI" > "$LAB/system.json"
curl -fsS "$BASE$MANAGER_URI" > "$LAB/manager.json"
jq -e '.Status.Health == "OK" and .Status.State == "Enabled"' \
  "$LAB/system.json" >/dev/null
jq -e '.ManagerType == "BMC" and .Status.Health == "OK"' \
  "$LAB/manager.json" >/dev/null
printf 'system_health=%s system_state=%s power_state=%s manager_health=%s\n' \
  "$(jq -r .Status.Health "$LAB/system.json")" \
  "$(jq -r .Status.State "$LAB/system.json")" \
  "$(jq -r .PowerState "$LAB/system.json")" \
  "$(jq -r .Status.Health "$LAB/manager.json")"

Contoso is a fictional manufacturer in DMTF’s public sample data, not a vendor benchmark. On real hardware, preserve manufacturer, model, serial, firmware and the collection URI in the receipt; otherwise a result from one BMC can be attached to another quote accidentally.

Inspect Actions Without Executing Them

A Redfish action target advertises where a client would send a POST. Its AllowableValues can say which reset or boot modes the implementation exposes. Reading those values is non-disruptive; executing them is not. The lab issues GET requests only.

Virtual media requires more precision than checking for a collection. A conforming implementation may link VirtualMedia from either the ComputerSystem or Manager resource, so the block checks both and records which one supplied the URI. It also removes the System link in a temporary JSON copy, places the same public mock link in a temporary Manager copy and requires the fallback to resolve as manager; the original resources remain unchanged. The DMTF mock advertises two media members and CD/DVD media types, but neither member publishes #VirtualMedia.InsertMedia. The block joins root, system, manager and media objects into one receipt and refuses to call any advertised action target.

set -Eeuo pipefail
LAB=/tmp/voxfor-redfish-buyer-lab
MARKER="$LAB/.voxfor-redfish-buyer-lab"
BASE=http://127.0.0.1:18048
test "$(<"$MARKER")" = voxfor-redfish-buyer-lab-v1

discover_virtual_media() {
  local system_json=$1 manager_json=$2 uri
  uri=$(jq -r '.VirtualMedia["@odata.id"] // empty' "$system_json")
  if [[ -n "$uri" ]]; then
    printf 'system\t%s\n' "$uri"
    return
  fi
  uri=$(jq -r '.VirtualMedia["@odata.id"] // empty' "$manager_json")
  test -n "$uri"
  printf 'manager\t%s\n' "$uri"
}

jq 'del(.VirtualMedia)' "$LAB/system.json" > "$LAB/system-no-vm.json"
jq --argjson vm "$(jq '.VirtualMedia' "$LAB/system.json")" \
  '.VirtualMedia = $vm' "$LAB/manager.json" > "$LAB/manager-with-vm.json"
IFS=$'\t' read -r TEST_OWNER TEST_URI < <(
  discover_virtual_media "$LAB/system-no-vm.json" "$LAB/manager-with-vm.json"
)
test "$TEST_OWNER" = manager
test -n "$TEST_URI"
rm "$LAB/system-no-vm.json" "$LAB/manager-with-vm.json"
printf 'manager_virtual_media_fallback=PASS\n'

IFS=$'\t' read -r VM_OWNER VM_URI < <(
  discover_virtual_media "$LAB/system.json" "$LAB/manager.json"
)
test -n "$VM_URI"
curl -fsS "$BASE$VM_URI" > "$LAB/virtual-media-collection.json"
: > "$LAB/media.ndjson"
while IFS= read -r uri; do
  curl -fsS "$BASE$uri" >> "$LAB/media.ndjson"
  printf '\n' >> "$LAB/media.ndjson"
done < <(jq -r '.Members[]["@odata.id"]' "$LAB/virtual-media-collection.json")
jq -s '.' "$LAB/media.ndjson" > "$LAB/media.json"

jq -n \
  --arg vm_uri "$VM_URI" \
  --arg vm_owner "$VM_OWNER" \
  --slurpfile root "$LAB/root.json" \
  --slurpfile system "$LAB/system.json" \
  --slurpfile manager "$LAB/manager.json" \
  --slurpfile media "$LAB/media.json" '
  {
    service: {redfishVersion: $root[0].RedfishVersion},
    system: {
      id: $system[0].Id,
      manufacturer: $system[0].Manufacturer,
      model: $system[0].Model,
      health: $system[0].Status.Health,
      state: $system[0].Status.State,
      powerState: $system[0].PowerState
    },
    manager: {
      id: $manager[0].Id,
      type: $manager[0].ManagerType,
      health: $manager[0].Status.Health,
      firmware: $manager[0].FirmwareVersion
    },
    recovery: {
      resetTarget: $system[0].Actions["#ComputerSystem.Reset"].target,
      resetAllowable: $system[0].Actions["#ComputerSystem.Reset"][("ResetType" + "@" + "Redfish.AllowableValues")],
      bootAllowable: $system[0].Boot[("BootSourceOverrideTarget" + "@" + "Redfish.AllowableValues")],
      virtualMediaUri: $vm_uri,
      virtualMediaOwner: $vm_owner,
      virtualMediaMembers: ($media[0] | length),
      mediaTypes: ([$media[0][] | .MediaTypes[]?] | unique),
      insertMediaTarget: ([$media[0][] | .Actions["#VirtualMedia.InsertMedia"].target?] | map(select(. != null)) | first // "")
    }
  }' > "$LAB/capability-receipt.json"

jq -e '.recovery.resetAllowable | index("GracefulRestart") != null' \
  "$LAB/capability-receipt.json" >/dev/null
jq -e '.recovery.bootAllowable | index("Cd") != null' \
  "$LAB/capability-receipt.json" >/dev/null
printf 'graceful_restart=yes boot_cd=yes virtual_media_owner=%s virtual_media_members=%s insert_media_action=%s\n' \
  "$(jq -r .recovery.virtualMediaOwner "$LAB/capability-receipt.json")" \
  "$(jq -r .recovery.virtualMediaMembers "$LAB/capability-receipt.json")" \
  "$(jq -r 'if .recovery.insertMediaTarget == "" then "no" else "yes" end' "$LAB/capability-receipt.json")"

The current DMTF Redfish Utility guide separates getting resources from committing changes. Preserve that boundary during procurement. A discovery account should not need broad configuration rights merely to show that recovery features exist.

Make the Workload Policy Fail Closed

Different workloads justify different minimums. A stateless compute node rebuilt by the provider may need customer-visible health and restart control. A remotely administered single server with no hands-on contract may require customer-operated virtual-media insertion and boot override. One generic “Redfish pass” would hide that difference.

Two declared policies drive the evaluator below. Both require an enabled, healthy system. remote-reboot additionally requires a reset target and GracefulRestart; strict-reinstall also requires CD boot, at least one virtual-media member and an advertised InsertMedia action.

set -Eeuo pipefail
LAB=/tmp/voxfor-redfish-buyer-lab
MARKER="$LAB/.voxfor-redfish-buyer-lab"
test "$(<"$MARKER")" = voxfor-redfish-buyer-lab-v1

cat > "$LAB/evaluate-receipt.sh" <<'BASH'
#!/usr/bin/env bash
set -Eeuo pipefail
MODE=${1:?policy required}
RECEIPT=${2:?receipt required}

jq -e '.system.health == "OK" and .system.state == "Enabled" and .manager.health == "OK"' \
  "$RECEIPT" >/dev/null || { echo 'REJECT reason=health-or-state'; exit 1; }
jq -e '(.recovery.resetTarget | type == "string" and length > 0) and (.recovery.resetAllowable | index("GracefulRestart") != null)' \
  "$RECEIPT" >/dev/null || { echo 'REJECT reason=reset-target-or-graceful-restart-missing'; exit 1; }

case "$MODE" in
  remote-reboot)
    echo 'ACCEPT policy=remote-reboot'
    ;;
  strict-reinstall)
    jq -e '.recovery.virtualMediaMembers > 0' "$RECEIPT" >/dev/null \
      || { echo 'REJECT reason=virtual-media-missing'; exit 1; }
    jq -e '.recovery.bootAllowable | index("Cd") != null' "$RECEIPT" >/dev/null \
      || { echo 'REJECT reason=cd-boot-missing'; exit 1; }
    jq -e '.recovery.insertMediaTarget != ""' "$RECEIPT" >/dev/null \
      || { echo 'REJECT reason=insert-media-action-missing'; exit 1; }
    echo 'ACCEPT policy=strict-reinstall'
    ;;
  *) echo 'REJECT reason=unknown-policy'; exit 2 ;;
esac
BASH
chmod 0700 "$LAB/evaluate-receipt.sh"
bash -n "$LAB/evaluate-receipt.sh"

jq '.recovery.resetTarget = null' "$LAB/capability-receipt.json" \
  > "$LAB/missing-reset-target.json"
set +e
"$LAB/evaluate-receipt.sh" remote-reboot "$LAB/missing-reset-target.json" \
  > "$LAB/missing-reset-target.out" 2>&1
STATUS=$?
set -e
test "$STATUS" -eq 1
grep -qx 'REJECT reason=reset-target-or-graceful-restart-missing' \
  "$LAB/missing-reset-target.out"
rm "$LAB/missing-reset-target.json" "$LAB/missing-reset-target.out"
printf 'evaluator=ready policies=remote-reboot,strict-reinstall\nmissing_reset_target=REJECT status=%s reason=reset-target-or-graceful-restart-missing\n' \
  "$STATUS"

The evaluator’s negative control sets the reset target to JSON null while retaining GracefulRestart. Acceptance still fails, proving that an allowable value without a nonempty action target cannot satisfy the reboot policy.

Challenge the stronger policy first. A failure is the useful result: media objects alone do not meet the declared reinstall requirement.

set -Eeuo pipefail
LAB=/tmp/voxfor-redfish-buyer-lab
MARKER="$LAB/.voxfor-redfish-buyer-lab"
test "$(<"$MARKER")" = voxfor-redfish-buyer-lab-v1

set +e
"$LAB/evaluate-receipt.sh" strict-reinstall "$LAB/capability-receipt.json" \
  > "$LAB/strict.out" 2>&1
STATUS=$?
set -e
test "$STATUS" -eq 1
grep -qx 'REJECT reason=insert-media-action-missing' "$LAB/strict.out"
printf 'strict_reinstall=REJECT status=%s reason=insert-media-action-missing\n' "$STATUS"

Now apply the narrower reboot policy to the unchanged receipt. This is not a repair to make the endpoint look better; it represents a different buyer outcome. A workload that genuinely needs customer-led reinstall must still reject the offer or obtain a provider commitment that closes the gap.

set -Eeuo pipefail
LAB=/tmp/voxfor-redfish-buyer-lab
MARKER="$LAB/.voxfor-redfish-buyer-lab"
test "$(<"$MARKER")" = voxfor-redfish-buyer-lab-v1

"$LAB/evaluate-receipt.sh" remote-reboot "$LAB/capability-receipt.json" \
  > "$LAB/reboot.out"
grep -qx 'ACCEPT policy=remote-reboot' "$LAB/reboot.out"
printf 'remote_reboot=ACCEPT status=0\n'

One representative receipt contains the central decisions from the exact run:

source_commit=2d39eb14122337ceab0712a9610b1cd37c65f487
server_sha256=d4e712d4107c5778d82345f4d096e0cb64c08495735b5fd2233289877f6c0a01
listener=127.0.0.1:18048 service_version=1.15.0
system_uri=/redfish/v1/Systems/437XR1138R2 manager_uri=/redfish/v1/Managers/BMC
system_health=OK system_state=Enabled power_state=On manager_health=OK
manager_virtual_media_fallback=PASS
graceful_restart=yes boot_cd=yes virtual_media_owner=system virtual_media_members=2 insert_media_action=no
missing_reset_target=REJECT status=1 reason=reset-target-or-graceful-restart-missing
strict_reinstall=REJECT status=1 reason=insert-media-action-missing
remote_reboot=ACCEPT status=0
cleanup=ABSENT scope=marker-owned-lab-only

The buyer receipt is verified only when the source commit and server hash match, the service is loopback-only, system and manager URIs are discovered through @odata.id, VirtualMedia is discovered from either System or Manager and its owner is recorded, both health objects are enabled/OK, reset and boot choices are read without executing an action, the strict reinstall policy rejects the missing InsertMedia action, and the unchanged receipt passes the narrower reboot policy. The reproduced run met every criterion.

Repeat the Receipt on the Offered Machine

A mockup cannot prove a provider’s endpoint, firmware, customer role, TLS certificate, management VLAN, console path or action authorization. Before signing, replace the loopback base URL with the offered read-only endpoint and authenticate through an approved secret mechanism; do not paste a password into shell history or an article receipt. Ask the provider to identify which fields are standard Redfish and which are OEM extensions.

Dell’s current iDRAC Redfish page points readers to generation-specific API guides and vendor scripting. That is why a brand name alone cannot close the gate. Preserve the BMC firmware, schema version, tested account role, certificate fingerprint, serial number and collection paths with the result.

Then schedule a controlled recovery drill before production data arrives:

1. Prove the management endpoint remains reachable when the host OS network is unavailable.
2. Confirm the named customer role can perform the approved reset type and that the action is audited.
3. Mount a disposable ISO or provider test image, select a one-time boot target and verify the remote console displays it.
4. Exit without overwriting disks, restore the normal boot target and have the provider confirm no lingering media session.
5. Record who handles a failed BMC, locked account, broken console or required hands-on intervention, including response targets and cost.

No article should tell a buyer to reboot an unknown production system merely to fill a checklist. Use a new server, a provider sandbox or an agreed maintenance window. If the workload also faces bandwidth billing, retain a separate 95th-percentile commit receipt because management access and commercial network measurement answer different risks. Coordinate endpoint isolation using DDoS protection response path; an emergency interface should not become an exposed bypass around normal controls.

For a multiplayer workload, compare CPU, location and attack protection before reviewing current game dedicated server offers. Apply the same recovery checklist to any shortlisted plan, and verify Redfish, virtual media and customer-operated power control for the exact machine because those capabilities are not implied by dedicated hardware.

Close the Lab Without Touching Another Process

Keep the JSON receipt only when it belongs to an authorized procurement record. The disposable lab has no provider evidence, so the final block verifies the recorded PID start time, terminates only that process, checks the fixed marker and removes only the exact lab path.

If an offered endpoint fails, make no state-changing request: retain the sanitized read-only receipt, reject or narrow the recovery requirement only with an explicit workload decision, and ask the provider to repair access or supply a controlled drill. The lab rollback stops the process identified by both PID and start time and deletes only /tmp/voxfor-redfish-buyer-lab; it cannot reverse a BMC action on real hardware.

set -Eeuo pipefail
LAB=/tmp/voxfor-redfish-buyer-lab
MARKER="$LAB/.voxfor-redfish-buyer-lab"
test "$LAB" = /tmp/voxfor-redfish-buyer-lab
test "$(<"$MARKER")" = voxfor-redfish-buyer-lab-v1
SERVER_PID=$(<"$LAB/server.pid")
EXPECTED_START=$(<"$LAB/server.starttime")
test -r "/proc/$SERVER_PID/stat"
test "$(awk '{print $22}' "/proc/$SERVER_PID/stat")" = "$EXPECTED_START"
kill "$SERVER_PID"
for attempt in $(seq 1 50); do
  test ! -e "/proc/$SERVER_PID" && break
  sleep 0.1
done
test ! -e "/proc/$SERVER_PID"
find "$LAB" -xdev -depth -delete
test ! -e "$LAB"
printf 'cleanup=ABSENT scope=marker-owned-lab-only\n'

One label—Redfish—became two honest results: suitable for an approved reboot-only recovery model, insufficient for the declared unattended reinstall model. Carry that exact distinction into the quote and contract. It is cheaper to reject a missing capability before rent begins than to discover it while the operating system is already unreachable.