Upgrading

Three things version independently: the per-host agent, the server, and cloud-hypervisor. None of them touch running VMs.

Agents, from the console

The fleet overview shows each host's agent version. When the server knows a newer release (it polls https://eitri.sh/dl/latest/manifest.json daily), an ↑ button appears next to hosts that are behind. Clicking it tells that one agent to upgrade itself:

  1. The agent downloads the new binary from eitri.sh and verifies its sha256 against the release manifest.
  2. It swaps the binary in place—the old one is kept next to it as eitri-agent.prev—and re-execs. The process keeps its PID; running VMs are untouched and stay under the agent's care throughout.
  3. The host reports its new version on the next sync, and the button disappears.

If a download fails, nothing is swapped; click again to retry. To roll back by hand, stop the agent, move eitri-agent.prev back over the binary, and start it again.

Requirements. The button lights up only when the running agent reports a release version (vX.Y.Z) or a pre-release of one (vX.Y.Z-pre.N, which orders below the release it leads to)—agents built from an untagged or dirty tree report a git hash instead and are never offered upgrades. The server needs release_manifest_url reachable; set it to "" in the server config to disable upgrade checks entirely.

The server

The console banner links here when the published release differs from the running server's version. Server upgrades are manual and downtime is fine—agents keep reconciling and VMs keep running while it's away:

  1. Stop eitri-server.
  2. Replace the binary with the new release.
  3. Start it. The schema is applied idempotently on boot (existing tables are left as-is), and agents reconnect on their own.

A newer server with older agents is safe: new fields in the sync protocol are ignored by agents that predate them.

cloud-hypervisor

Swap /usr/local/bin/cloud-hypervisor on the host. New and restarted VMs use the new binary; running VMs keep their old process until they stop. There is no live handover for running guests.

Operations

The agent runs under systemd (eitri-agent.service). The unit sets KillMode=process—that line is load-bearing: the default would kill every cloud-hypervisor guest in the unit's cgroup whenever the agent stops. Logs: journalctl -u eitri-agent.

Related