The short answers that matter for a 2-node edge/ROBO box: how to update, what happens when hardware fails, and how to swap a dead drive. If it isn't here, ask on the TWINSTOR thread.
One host at a time, and never touch the second until the first is back and healthy. You cannot half-update it into an unsafe state — see the note at the end.
On the first host, in turn:
tar xzf twinstor-test-<version>.tar.gz
cd twinstor-test-<version> && sudo ./install.sh
systemctl restart twinstor
twinstor status # wait for: health: healthy (ready, Connected, UpToDate/UpToDate)Repeat on the second host only once the first is healthy again. Then, once both are updated and healthy, make the new settings survive a reboot — on each host in turn:
twinstor regenerate-configYou can't get it half-done. The update is active the moment you restart the service — the daemon applies the new storage-safety settings live on every start, whether or not you have run regenerate-config. That last step only persists them across reboots, and until you run it TwinStor keeps reminding you in the log, in an XO alert, and in twinstor status.
The whole point of a 2-node box is that a single failure is a non-event. Here is what TWINSTOR does on its own, with nobody on site:
The classic ROBO power blip. The other host was already serving every VM's storage, so storage never stops. XHA restarts the lost host's VMs on the survivor (typically a few minutes). When the host powers back on it rejoins and resyncs by itself — nothing to do.
Both hosts down at once. Both boot, agree on which copy is current (no coin-flip, no split-brain), and bring the VMs back automatically. Your job is to wait for them to boot.
That host fences itself and evicts; its VMs restart on the survivor. Reconnect it and it rejoins and resyncs.
Absorbed. A flap shorter than the timeout stays Connected — no resync, no VM impact, no drama.
The VMs don't even notice: TWINSTOR drops the dead disk and keeps serving from the peer's copy (a little more latency, no failover). See "a drive died" below.
Storage keeps serving — the replication and the iSCSI target live in the kernel; systemd just restarts the service. Your VMs see nothing.
In every case the rule is the same: keep serving if it is safe, fail closed if it is not, and heal automatically once the hardware is back. If TWINSTOR ever needs a human it raises an alert in XO.
Not urgent. Nothing is down. When a data disk fails, the node keeps serving every VM from the peer's copy — so no VM stops and nothing fails over. You have simply lost the second copy on that one host until the disk is replaced. Fix it whenever it's convenient:
twinstor status shows the progress and tells you when both copies are current again. (A one-command replace-backing helper and a "backing device not found" alert make a device swap even simpler.)A failed disk is a "fix it this week" errand, not a 2 a.m. page — which is exactly the point of holding a full second copy on the other host.
Run twinstor status on both hosts. You want readiness: ready, connection: Connected, and disk UpToDate/UpToDate. Green on both = you are fully protected.
Usually nothing — it heals itself and raises an XO alert only if it genuinely needs a human. When in doubt, check twinstor status.
Every write is mirrored to the second host and only acknowledged once both hosts have it (synchronous replication, DRBD protocol C). Both hosts always hold a complete, current copy, so a single failure never loses committed data.
Only while you are running on a single node — the other one down or with a failed disk. That is why you fix a failed node or drive promptly: to get back to two copies. And keep your backups — replication protects against hardware failure, not against a deleted VM or ransomware.