Two hosts.
Zero compromise.
Full HA.
Hyperconverged storage for two XCP-ng hosts. TWINSTOR turns their local disks into redundant, self-healing shared storage, with live migration, automatic VM restart, and rolling updates.
Tech Preview · For lab evaluation
Animated introduction · English captions availableOpen video in a new tab ↗
The numbers from our lab
Measured on our two test pools: power cables pulled, a power strip cut, network cables cut, disks removed live.
Two servers alone can't give you HA
Every small site faces the same dilemma: you need two servers for redundancy, but high availability needs shared storage, and every traditional answer adds cost and complexity.
- Hardware SAN / NAS: a third box to buy, power, and maintain (and a new single point of failure)
- Clustered storage: a witness or a third node somewhere else, and a steep learning curve
- No shared storage: no live migration, no HA, manual disaster recovery
Shared storage from the disks you already have
Both hosts hold an identical, continuously synchronized copy of every byte. Both serve storage at all times: there is no passive node and no failover delay, because there is no failover.
- Reads are local. Every VM reads from its own host's disk: zero network hop, full NVMe/SSD performance.
- Writes are safe. Acknowledged only once stored on both hosts. Lose a server at any instant: not a single acknowledged write is lost.
- No witness. TWINSTOR uses the network gateway you already have as the tie-breaker.
- Zero patches to XCP-ng. A standard shared SR on XCP-ng 8.3; your support path stays standard.
Everything, at a glance
twinstor status opens with a one-line health verdict and colors only the values that carry state: green while the pair is whole, amber or red the moment something needs you.
twinstor status
● healthy: serving, peer redundant
version: 0.7.4
daemon: running
host: twinstor-1 (this node), peer twinstor-2
pool master: twinstor-1 (this node)
pool HA: enabled
✓ drbd
disk: UpToDate
connection: Connected
peer disk: UpToDate
✓ readiness: ready (local serving, peer redundant)
✓ iscsi: activeFour commitments, in plain terms
Every failure behavior in TWINSTOR reduces to these four commitments. They are what actually protects your VMs when hardware and networks misbehave.
A write your VM was told is safe is never silently destroyed
A host cut off from the network freezes instead of serving, so a network cut does not lose confirmed writes. In the rare case where both hosts wrote apart, the writes that must go are announced: an alert names the VMs concerned.
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. It never silently picks a side it cannot justify.
Decisions follow the data
When a copy has to be chosen, TWINSTOR reads DRBD's own record of which copy holds which writes. The VMs on the other host are stopped before its copy is discarded, then restarted on the kept one.
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 the documentation.
Every failure heals itself or fails closed
Designed to run unattended for years at sites with no IT staff. Every scenario below was exercised on real hardware; the numbers are measured, not estimated.
| Failure | What happens | Measured result |
|---|---|---|
| Host power loss | Survivor keeps serving, VMs auto-restart | 0 dropped pings; victim's VMs back in ~2 min |
| Total site power outage | Both hosts boot, storage converges, VMs restart | ~3 min from power cut to all VMs running, unattended |
| Local disk / RAID array failure | VMs keep running, transparently served from the other host's copy | Workloads never missed a beat; full redundancy 23 s after the disk returned |
| Network cut between the hosts | The cut-off host freezes and steps aside; its VMs restart on the other host | 0 confirmed writes lost in testing; resync on rejoin |
| A host loses its client network (arbitrated) | The isolated host stands its storage down; its VMs restart on the reachable host | Unattended failover, then resync on rejoin |
| Dead access switch (both hosts isolated at once, arbitrated) | Both hosts hold and keep running: no pointless failover to an equally unreachable peer | VMs stay up, no reboot; auto-resumes when the switch returns |
| Software crash | Storage keeps serving while the service restarts itself | 0 s VM downtime |
| Split-brain (both sides writing) | Fails closed: the copy with the newest writes wins (by DRBD generation, not by guess), loud alert; if undecidable, it refuses to discard anything | Validated end-to-end on a real crash |
| Rolling Pool Update | Fully transparent, no special commands | Real RPU via Xen Orchestra: ~7 min, VMs uninterrupted |
| TWINSTOR upgrade | install.sh, then twinstor upgrade-apply, one host at a time | Zero downtime: storage keeps serving during the update |
Recovery times include the servers' own boot time. TWINSTOR's share is tiny: in the power-outage test, storage was serving 22 seconds after the OS booted. Safe even on consumer SSDs: TWINSTOR detects volatile write caches and disables them, so an acknowledged write is on persistent media before the ack.
Built for the millions of sites that need exactly two servers
Retail & franchise networks
POS, inventory, surveillance on two small hosts per store. No witness per store, no extra licence, the same setup at every site.
Remote & branch offices
File services, AD replicas, local apps with no IT staff on site. The ~3-minute unattended power-outage recovery means the site is back before anyone arrives in the morning.
Industrial & manufacturing edge
MES, SCADA historians, line supervision on the factory floor. Local reads give predictable latency; synchronous replication means a host failure never loses an acknowledged write.
Hospitality & healthcare
PMS/EMR systems that must stay up, in buildings with a network closet rather than a server room. Two short-depth hosts and a switch is the entire footprint.
Maritime, energy, disconnected sites
Ships, wind farms, substations: places where "send a technician" means days. No remote hands needed for recovery; the whole stack is observable from shore.
MSPs
A standardized, scriptable 2-node building block: identical setup at every client, alerts centralized in Xen Orchestra, zero-downtime updates during business hours.
Pick your topology at setup; both keep your data safe
Fate-shared (default)
Replication and the clients share one network, so the two hosts always fail together, cleanly: no way to diverge, no split-brain to untangle. From a pair of mini-PCs on one switch up to a redundant MLAG pair run as a single segment, where you also drop the switch as a single point of failure. The simplest, most-tested path whenever storage and clients ride the same network.
Needs: one shared network between the hosts (single switch, or one redundant L2).
Arbitrated (dedicated storage network)
For enterprise builds where storage runs on its own network, separate from the clients and gateway (a storage plane on its own switches or fabric: spine/leaf, a separate 25/40/100G storage VLAN). Replication gets a back-to-back cable as its default path with that fabric as the automatic, alerted fallback, and the hosts stop depending on the gateway to tell isolation apart. Rides through switch-side gray failures that fate-shared cannot, and a dead access switch keeps VMs running (both hosts hold) instead of a compute outage.
Choose when your storage network can fail independently of the gateway. Needs a dedicated replication path (crossover / DAC direct cable).
Honest limits
TWINSTOR keeps exactly two synchronized copies on exactly two nodes. If you need 3+ nodes, 3-way replication, or multiple storage tiers, use XOSTOR or a SAN. The two hosts should share a reliable network (bonding or stacked switches recommended). There is no background scrub: silent corruption on one disk is only found when it is read. Tech Preview status: it's a 0.x series, so read the release notes before upgrading a live pool.
Two commands. That's the whole setup.
The interactive wizard auto-detects the pool peer, lists candidate disks with model and serial, generates credentials, creates the storage, and enables HA. twinstor uninstall reverses everything.
Requirements: 2 XCP-ng hosts in a pool, a free local disk on each, a network link between them (1 Gbps works, 10 Gbps recommended), BIOS set to power on after AC loss. No SAN, no witness, no special wiring.
# Node A: run the wizard, follow the prompts
twinstor setup
# Node B: same wizard; it detects node A
twinstor setup
# Live status anytime
twinstor statusTwo commands later you have shared storage, live migration, and automatic VM restart on host failure. The documentation is on docs.vates.tech, and the source on GitHub.