TwinStor

Hyperconverged storage for two XCP-ng hosts. TwinStor turns the local disks of a 2-host pool into fully redundant, self-healing shared storage: live migration, automatic VM restart (HA), and Rolling Pool Updates all work, with no SAN, no witness node, and no third host.

Tech Preview

TwinStor is currently distributed as a Tech Preview: a pre-release test build meant for lab pools, not production. Run it on hardware you can afford to break, and keep backing up your VMs (with Xen Orchestra or the tool of your choice) whether you use TwinStor or not. To get the current build and the guided track, join the Tech Preview or follow the TwinStor thread on the XCP-ng forum.

The problem it solves

A 2-node XCP-ng pool with local disks cannot do live migration, HA, or anything else that requires shared storage. The traditional answers all add cost and complexity:

• Hardware SAN / NAS: a third box to buy, power, and maintain, and a new single point of failure.
• Other 2-node storage solutions: a witness appliance or quorum device that must run somewhere else, plus a licensing layer.
• Scale-out storage clusters (including XOSTOR): a third node as arbiter, which is more infrastructure than a small office, remote site, or edge deployment can justify.
• No shared storage at all: no live migration, no HA, manual disaster recovery.

TwinStor removes the dilemma: install it on both hosts, point it at a free local disk on each, and you get a fully functional shared Storage Repository. Nothing besides the two hosts.

How it works, from a user's point of view

Both hosts hold an identical, continuously synchronized copy of every byte, and both serve storage at all times. There is no passive node and no failover delay, because there is no failover.

Both hosts active · one replicated storagesynchronous replicationlocal I/O

• Reads are local. Every VM reads from its own host's disk: zero network hop, full NVMe/SSD performance.
• Writes are safe. A write is acknowledged to the VM only once it is stored on both hosts (synchronous replication). Lose a server at any instant: not a single acknowledged write is lost.
• No tiebreaker infrastructure. Where competitors need a witness node, TwinStor uses the network gateway you already have.
• Zero patches to XCP-ng. The storage appears as a standard shared SR, so live migration, snapshots, backups, XO and the whole existing stack work unmodified, with any XCP-ng version. Your support path stays standard.
• Safe on commodity drives. TwinStor detects volatile write caches on consumer SSDs and disables them (re-applied at every boot), so an acknowledged write is on persistent media before the ack. Enterprise drives with power-loss protection keep their full cache performance.

Under the hood, TwinStor is a single small service in dom0 orchestrating battle-tested standard components (DRBD for replication, iSCSI with multipath for the data path, XHA for fencing). You never interact with those components directly: one command installs, one command sets up, one command tears down.

The data promise

Every failure behavior in TwinStor reduces to four commitments:

1. A write your VM was told is safe is never silently destroyed. If the two copies ever diverge, TwinStor only ever discards writes that no VM received a completion for. The losing side of a partition freezes instead of serving, so diverged history never accumulates.
2. When the evidence is ambiguous, it stops and asks. No verdict means no action: both copies are kept, an alert names the decision that is yours, and waiting costs nothing. TwinStor never silently picks a side it cannot justify.
3. Decisions are made on evidence, not a single glance. A winner verdict requires the pool's answer to be stable across a 45-second sampling window, and a host that is actively running your VMs is never discarded automatically, whatever the control plane claims.
4. Everything is accountable. Every incident is a numbered episode in the logs from open to close, every resolution names the VMs it touched, and every state that waits for a human is listed in one table (see Failure behavior).

When not to use TwinStor

• You need more than 2 nodes. TwinStor is strictly a 2-node product. For scale-out, use XOSTOR or a SAN.
• You need more than one level of redundancy. TwinStor keeps 2 copies of your data. One failed disk means running without redundancy until it is replaced and resynced; if you need 3-way replication, use XOSTOR.
• You need multiple storage tiers. TwinStor exposes a single SR. There is no fast-SSD tier plus slow-HDD tier.
• Your network is a single unreliable switch and you cannot add a direct link between the hosts. See the topology discussion in Installation.

In this section

• Installation: prerequisites, topology choice, install and setup wizard, verification, uninstall.
• Administration: day-to-day usage, CLI, monitoring and alerts, planned maintenance.
• Failure behavior: what heals itself, what fails closed, and the few states that wait for your decision.
• Updates: updating TwinStor and the hosts under it.
• Troubleshooting and feedback: logs, support bundles, and how to report what you find.