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 the new binary and unit
# systemctl restart twinstor
# twinstor status          # confirm ready before touching the peer

Notes:

  • install.sh deliberately does not restart a running service; the restart is your explicit step, so you control the one-node-at-a-time pacing. Finish one node (restart + twinstor status back to ready) before starting the other.
  • 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 would generate a newer format, twinstor status shows a config: line and the release notes state whether it matters for that release. When they do ask for it, twinstor regenerate-config brings the configuration up to the installed version (it prints a plan and runs dry by default; run it one node at a time on a healthy pool).
  • 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.