Skip to main content

Updates

Three kinds of updates touch a TwinStor pool: updating TwinStor itself (zero downtime), updating the XCP-ng hosts under it (a standard Rolling Pool Update), and the rare update that ships a new storage kernel module (also an RPU). During the Tech Preview, read the release notes of each build before upgrading a live pool: treat every release as potentially behavior-changing.

Updating TwinStor​

A TwinStor update is a zero-downtime binary swap: storage keeps serving from the kernel while the service restarts. There is no RPM yet; the Tech Preview distribution is the tarball. On each node, one at a time:

root@twinstor-1 — update TwinStor
# verify before extracting (aborts if it does not match):
# echo "<published sha256>  twinstor-test-<version>.tar.gz" | sha256sum -c
# tar xzf twinstor-test-<version>.tar.gz
# cd twinstor-test-<version>
# ./install.sh             # preflight + installs (stages) the new binary and unit
# twinstor upgrade-apply   # safe, gated restart; waits until this node reconverges

Then, only after the first node prints that it is safe to proceed, run the same two steps on the second node.

Notes:

  • Use twinstor upgrade-apply to activate the new binary. It is the safe way to restart the daemon: it refuses unless it is safe on this node right now (replication Connected and both copies UpToDate, no recovery in progress, and the peer's daemon alive and not itself mid-restart), then restarts only the local daemon and blocks until this node has reconverged before returning. Because a restarting daemon signals itself as down, running it on the second node refuses until the first is healthy again, so the two nodes can never restart at once (the one situation that can briefly fork the pool into a dual-master). Do not run it on both nodes in parallel; upgrade one node at a time.
  • install.sh deliberately does not restart a running service; upgrade-apply is the explicit, gated restart step. To pre-check without changing anything, twinstor upgrade-apply --check exits success only when it is safe to restart this node.
  • Manual fallback: if you prefer, or if upgrade-apply refuses and you have confirmed the pool is healthy, systemctl restart twinstor does the same activation. The rule is unchanged either way: one node at a time, and twinstor status back to ready before the next.
  • Replication and the storage target survive the service restart, so VMs experience zero I/O interruption.
  • No VM evacuation and no HA disable are needed for a binary swap: the host does not reboot and its patch level does not change.
  • The update refreshes TwinStor's helper scripts and log rotation automatically. The generated storage configuration keeps its setup-time settings; if a new build ships a newer format, twinstor status shows a config: line and twinstor upgrade-apply notes it in its summary. This is expected and safe to leave as-is: the daemon applies the current split-brain safety policies live on every start, regardless of the on-disk configuration version, so an older config file never means an unprotected pool. Refreshing the file is optional — it clears the status line and closes a small window at boot. On a healthy serving pool both copies are Primary and UpToDate, and DRBD will not reset the live peer connection to apply a new format, so twinstor regenerate-config defers rather than forcing the change: it keeps the working file and tells you so (it never leaves a half-applied configuration). To adopt the new format, do it in a maintenance window, one node at a time — twinstor regenerate-config --persist-only --yes stages it, then reboot that node so the new file loads cleanly at boot; wait for twinstor status to show Connected with both copies UpToDate before doing the other node.
  • There is no runtime version handshake between the nodes: a version or kernel-module mismatch that prevents reconnection just looks like a peer that never comes back (serving-without-redundancy on one side). If the peer has not reconnected shortly after you upgrade the first node, stop and compare twinstor --version on both sides before touching the second; always finish by bringing both nodes to the same build.

Updating the XCP-ng hosts​

Host updates follow the standard Rolling Pool Update procedure, and RPU is fully transparent for TwinStor: both nodes always serve storage, so rebooting one has no impact on the other.

The rule that matters: never patch and reboot a host with HA still armed. A pool member cannot run a different version from the master, so update via RPU (HA off, evacuate and reboot one node at a time, HA back on). Xen Orchestra's Rolling Pool Update automates the whole sequence. No TwinStor-specific commands are needed at any point; the service stops and starts with the host automatically. A real RPU on the preview pools measured about 7 minutes with VMs uninterrupted.

When re-enabling HA manually, run the exact commands from Administration: a bare pool-ha-enable silently resets the timeout to an overly aggressive default, so always pass it explicitly.

Updates that include a new DRBD kernel module​

A kernel module swap requires a reboot, so follow the RPU procedure above rather than the zero-downtime binary swap. The release notes of the build say when this applies.