vpm and cluster state

Captured 2026-07-28 from a disposable CE used for the on-box command audit.

vpm is the agent that registers a Customer Edge with the tenant and supervises the platform containers. When a node will not come online, its state is the first thing to establish.

systemctl-status-vpm

execcli systemctl-status-vpm

● vpm.service - VP Manager service
     Loaded: loaded (/etc/systemd/system/vpm.service; enabled; preset: disabled)
     Active: active (running) since Tue 2026-07-28 18:07:43 UTC; 2h 36min ago
   Main PID: 11329 (docker)
      Tasks: 10 (limit: 204889)
     Memory: 14.9M
        CPU: 496ms
     CGroup: /system.slice/vpm.service
             └─11329 /usr/bin/docker run --rm --name vpm --net=host --privileged -v /dev:/dev -v /bin/udevadm:/bin/udevadm -v /etc/:/hostetc/:rw -v /opt/:/hostopt/:rw -v /:/hostos/:ro -v /usr/bin/:/hostusr/bin/:ro -v /e…

Jul 28 20:40:47 f5-xc-ce-vm-01 vpm[11329]: etcd.go:123: Holding dictator lock for path /_lock/dictator
Jul 28 20:41:44 f5-xc-ce-vm-01 vpm[11329]: module.go:84: Running intra-cluster, type: node
Jul 28 20:41:44 f5-xc-ce-vm-01 vpm[11329]: pinger.go:38: Stats for connectivity-check: <name: intra-cluster, type: intra-cluster, success: true>
Jul 28 20:42:44 f5-xc-ce-vm-01 vpm[11329]: module.go:84: Running intra-cluster, type: node
Jul 28 20:42:44 f5-xc-ce-vm-01 vpm[11329]: module.go:90: Running intra-cluster, type: fabric
Jul 28 20:42:44 f5-xc-ce-vm-01 vpm[11329]: pinger.go:38: Stats for connectivity-check: <name: fabric, type: fabric, success: true>
Jul 28 20:42:44 f5-xc-ce-vm-01 vpm[11329]: pinger.go:38: Stats for connectivity-check: <name: intra-cluster, type: intra-cluster, success: true>
Jul 28 20:42:50 f5-xc-ce-vm-01 vpm[11329]: etcd.go:123: Holding dictator lock for path /_lock/dictator
Jul 28 20:43:44 f5-xc-ce-vm-01 vpm[11329]: module.go:84: Running intra-cluster, type: node
Jul 28 20:43:44 f5-xc-ce-vm-01 vpm[11329]: pinger.go:38: Stats for connectivity-check: <name: intra-cluster, type: intra-cluster, success: true>

What to look for.

• Active: active (running) since … and the elapsed time. A vpm that restarted minutes ago on a node that has been up for hours is the signal — registration failures show up as restart loops long before they show up in the tenant.
• Main PID is docker. vpm runs as a privileged Docker container, not as a native process, launched with --net=host --privileged and a long list of host bind mounts including /, /dev and /etc. So vpm appears in docker-ps and never in crictl-ps — which is also why a three-entry docker-ps on a CE is complete rather than a symptom.
• The trailing journal lines. statusreporter.go: Status reporter loop has finished without error, sleeping for 5m… is the healthy steady state: vpm reports in on a roughly five-minute cycle. module.go: Running intra-cluster, type: node confirms it has joined the cluster rather than running standalone.

What it does not tell you. Nothing about whether the tenant accepted the registration. A perfectly healthy vpm will loop indefinitely against a control plane that is refusing it — read the journal lines for the reason.

systemctl-restart-vpm

execcli systemctl-restart-vpm

Disruptive, and not captured here

Restarting vpm tears down and re-establishes the node’s connection to the tenant. It is on the harvest harness’s refusal list, so it is documented from its catalog metadata and never run. Reach for it only when directed.

etcdctl-cluster-member-status

The etcd cluster backing the CE’s Kubernetes control plane, queried from the etcd pod on this node.

execcli etcdctl-cluster-member-status

+--------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
|         ENDPOINT         |        ID        | VERSION | DB SIZE | IS LEADER | IS LEARNER | RAFT TERM | RAFT INDEX | RAFT APPLIED INDEX | ERRORS |
+--------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
| https://etcd-0.etcd:2379 | dc946acaf076bc59 |  3.5.11 |  2.8 MB |      true |      false |         3 |       1981 |               1981 |        |
+--------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+

What to look for. IS LEADER, RAFT TERM, and whether RAFT INDEX and RAFT APPLIED INDEX agree. A persistent gap between those two means the member is applying behind the log. ERRORS empty is the healthy case.

One member, on a three-node deployment

This deployment runs three CE nodes, and the command reports a single member — https://etcd-0.etcd:2379, IS LEADER: true. That is what the command returned, and it is worth stating plainly because the natural assumption is that three CE nodes means a three-member etcd and that a one-row table means two members are missing.

What has not been established is why: whether each node runs its own single-member etcd, or whether the --cluster query only ever reaches the local pod. Both are consistent with this output. Do not read the one-row table as evidence of a degraded cluster without checking the other two nodes.