CephLXXXII · Hyper-Converged CephHyper-Converged Ceph
Maintenance on a hyper-converged node
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
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
| Duration | Approach |
|---|---|
| A reboot, minutes | ceph osd set noout |
| Hardware work, an hour or more | ceph orch host maintenance enter |
| Permanent removal | drain 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
Q1. Why should VMs be migrated off a hyper-converged node before stopping its OSDs?
Q2. OSDs are busy for a while after a planned maintenance window, even one covered by `noout`.
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.
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