Shared storage for two-host XCP-ng pools, built from the local disks of the two hosts.
TwinStor turns a local disk on each host into one shared SR. Live migration, HA, snapshots, backups and Rolling Pool Updates work as they do with a SAN, without a SAN, a NAS or a third host.
Status: tech preview. Use it on lab pools and keep backing up your VMs. Feedback is welcome on the XCP-ng forum.
- A standard shared SR. VMs, disks, snapshots, backups and Xen Orchestra work as usual. Nothing in XCP-ng is patched.
- Every write on both hosts. A write is confirmed to the VM only once both hosts have it, so losing a host never loses a confirmed write.
- Local reads. Each VM reads from the disk of the host it runs on.
- No witness. The network gateway you already have is the tie-breaker.
- Self-healing. Failed hosts, disks and links are handled automatically, and the pool returns to full redundancy on its own.
- Simple to run. One command installs, one sets up, one removes.
twinstor statustells you where things stand, and every alert says what to do.
| Failure | What happens |
|---|---|
| A host dies | The other host keeps serving. HA restarts the lost host's VMs on it. When the host returns, it catches up and redundancy is back. |
| A disk dies | VMs keep running from the other host's copy. Replace the disk when convenient. |
| The network between the hosts is cut | The host that lost the network freezes and steps aside; the other keeps serving. No confirmed write is lost, and the pair resyncs when the link is back. |
| Power cut on both hosts | Both hosts boot, storage comes back and HA restarts the VMs, in about 3 minutes. |
| TwinStor itself restarts or is upgraded | Storage keeps serving and the VMs keep running. |
When TwinStor cannot be sure what is safe, it does not guess: it keeps both copies and raises an alert telling you what to decide. Waiting is always safe.
TwinStor asks how your hosts are connected:
- Fate-shared (default): the hosts and the gateway share the same network, one switch or a switch pair run as one. A host that loses its peer also loses the gateway, so it knows it is the one to step aside.
- Arbitrated: replication runs on a separate network. A direct cable between the two hosts carries it, with the switched network as backup.
The installation guide helps you choose.
- Exactly two hosts and two copies. While a host or a disk is down, the pool runs on one copy until the resync finishes.
- Long network cuts with HA on can reboot a host. After a cut of more than about a minute, XCP-ng HA may reboot one host once the link is back. No confirmed write is lost, and HA restarts that host's VMs.
- A double network failure can cost the writes made during it. If the two hosts lose each other completely while both still reach the gateway (in arbitrated mode, the direct cable and the switched path failing together), both keep serving. When they reconnect, the writes made on one side during the cut are discarded, and an alert names the VMs concerned. The longer the cut lasts, the more is lost.
- XCP-ng 8.3, x86_64.
Every release goes through real faults on two hardware pools, one per network mode: cables cut, power removed, hosts rebooted, with HA on and the guests writing checksummed data that is verified afterwards. The 0.7.1 release candidates went through about 340 such cases, and none lost a confirmed write. More than 700 unit tests cover the decision logic.
You need two XCP-ng 8.3 hosts in the same pool, each with a spare disk, partition or md-RAID device that TwinStor may erase.
- Get the bundle from the TwinStor deploy page and run
./install.shon each host. - Run
twinstor setupon the first host, then on the second, and answer the questions. - Check with
twinstor statuson both hosts.
The full procedure is in the installation guide.
The user documentation is on docs.vates.tech: installation, administration, failure behavior, updates and troubleshooting.
TwinStor is a single static Rust binary running in dom0.
rustup target add x86_64-unknown-linux-musl
cargo build --release --target x86_64-unknown-linux-musl
cargo testscripts/make-bundle.sh builds the installable bundle. See CONTRIBUTING.md.
Open an issue and attach the output of twinstor support-bundle from both hosts. For anything that could lose or corrupt data, or a security issue, follow SECURITY.md.
TwinStor is developed by Vates, the company behind XCP-ng and Xen Orchestra. It is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License, version 2 or (at your option) any later version; see LICENSE.