Skip to main content
RunBook Academy

CephLXXXII · Hyper-Converged CephHyper-Converged Ceph

Maintenance on a hyper-converged node

Advanced⏱ ~18 mincephha-managerqm

What you'll learn

  • Sequence maintenance on a hyper-converged node
  • Choose the right flags and HA actions
  • Verify readiness before starting
  • Return the node to service correctly

Prerequisites

None — start here.

Verified against Ceph Tentacle 20.2.x · Ceph Squid 19.2.x (supported previous) · cephadm matches the verified Ceph release · podman 4.x · csi-rbd and csi-cephfs current · RBD / CephFS / RGW current (matches Ceph release) · Linux kernel 5.15+ (5.10 minimum) · Ubuntu 24.04 LTS (Ceph host baseline) · Debian 12 (Bookworm) (Ceph host baseline) · Rocky Linux / RHEL / AlmaLinux 9.x (Ceph host baseline) · Proxmox VE 9.x (cross-course integration) · Kubernetes 1.31+ (cross-course integration) · 2026-08-18

Not yet marked complete on this device.

Why this matters in production

Both layers must be prepared, in the right order, and the mistakes produce either unnecessary data movement or stopped VMs.

Readiness check

# the cluster must be healthy before starting
ceph -s
ceph health detail

# and able to absorb the node
ceph osd df tree | grep -A15 "$(hostname -s)"
pvecm status
ha-manager status
Do not start if:
  cluster health is not HEALTH_OK
  any PG is degraded or undersized
  another node is already out
  the surviving nodes cannot run this node's VMs

The sequence

# the node that will host the VMs during the maintenance:
TARGET_NODE=pve-02

# 1. move the VMs off first
for v in $(qm list | awk 'NR>1 && $3=="running" {print $1}'); do
  qm migrate "$v" "$TARGET_NODE" --online
done
# 2. verify no VMs remain
qm list
ha-manager status | grep "$(hostname -s)"
# 3. prepare Ceph — noout for a brief outage
ceph osd set noout
# or, for a longer one, enter maintenance mode
ceph orch host maintenance enter "$(hostname -s)"
# 4. stop the OSDs cleanly
systemctl stop ceph-osd.target
ceph -s
# 5. do the work, then reverse

VMs first, then Ceph. Stopping the OSDs while VMs are still running on the node means those VMs lose their storage path momentarily and may see I/O errors.

Choosing flags versus maintenance mode

DurationApproach
A reboot, minutesceph osd set noout
Hardware work, an hour or moreceph orch host maintenance enter
Permanent removaldrain the OSDs properly
ceph orch host maintenance enter pve-02
# ... work ...
ceph orch host maintenance exit pve-02

Maintenance mode handles the flags and daemon stops together and records the host’s state, which is why it is preferable for anything beyond a reboot.

Returning to service

# 1. bring Ceph back
ceph orch host maintenance exit "$(hostname -s)"
# or
systemctl start ceph-osd.target
ceph osd unset noout
# 2. wait for health before returning VMs
watch -n 30 'ceph -s | grep -E "health|pgs:"'
# 3. return the VMs
VMIDS=vmids
for v in ${VMIDS}; do qm migrate "$v" "$(hostname -s)" --online; done

Waiting for HEALTH_OK before migrating VMs back means the node is not serving guest I/O while its OSDs are still catching up.

Quiz

Knowledge check · 4 questions

  1. Q1. Why should VMs be migrated off a hyper-converged node before stopping its OSDs?

  2. Q2. OSDs are busy for a while after a planned maintenance window, even one covered by `noout`.

  3. Q3. Plan maintenance on a hyper-converged node.

    A node needs a memory module replaced, requiring roughly two hours of downtime. The cluster is four nodes, currently HEALTH_OK.

  4. Q4. When is `ceph orch host maintenance enter` preferable to `ceph osd set noout`?

Passing score: 75%. Answers are checked in this browser.

Production discipline

Migrate VMs off before stopping OSDs and wait for HEALTH_OK before migrating them back — both orderings avoid the node serving guest I/O while its storage path is unstable. Use ceph orch host maintenance for anything longer than a reboot; it handles the flags and daemons together and records the state.

Cross-course references

  • Kubernetes: draining a node before touching its storage daemons is the same order
  • Linux: quiescing consumers before stopping a service is standard practice