Hyperconverged storage for two XCP-ng hosts. TWINSTOR turns their local disks into fully redundant, self-healing shared storage: live migration, automatic VM restart, rolling updates. No SAN, no witness node, no third host.
Every figure below was measured on real hardware: power cables pulled, a real power-strip cut, disks removed live.
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.
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.
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
health: ● healthy — serving, peer redundant
version: 0.5.0
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: active
✓ tiebreaker: 192.168.1.1 (gateway)Every failure behavior in TWINSTOR reduces to these four commitments. They are what actually protects your VMs when hardware and networks misbehave.
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.
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.
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 auto-discarded, whatever the control plane claims.
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 in the FAQ.
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 hosts | Isolated node steps aside, survivor continues | Automatic recovery and resync on rejoin |
| Software crash | Storage keeps serving while the service restarts itself | 0 s VM downtime |
| Split-brain (both sides writing) | Fails closed: one authoritative copy wins, 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 | One command re-run of the installer | 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.
Where TWINSTOR stands apart: no witness anywhere, no async data-loss window, no storage VM eating host RAM, no storage licensing layer, one command per node.
| TWINSTOR | vSAN 2-node | Proxmox VE 2-node | StorMagic SvSAN | |
|---|---|---|---|---|
| Third box / witness | None | Witness appliance, hosted off-site (required) | QDevice on a third machine (required for HA quorum) | Witness VM or cloud service (required for automated failover) |
| Synchronous replication | Yes: every acknowledged write is on both hosts | Yes | No: async ZFS replication at intervals (data-loss window on failover) | Yes |
| Split-brain tiebreaker | Your existing network gateway | Witness quorum | QDevice quorum vote | Witness quorum |
| Per-host footprint | One tiny program orchestrating stock components | In-kernel, licensed per core | Built-in, no storage VM | Storage VM per host (reserved RAM/CPU) |
| Setup | 1 command per node | Cluster + witness deployment | Manual: cluster + QDevice + per-VM replication jobs; DRBD/ZFS knowledge expected | Storage VM + witness deployment |
| Hypervisor | XCP-ng | ESXi only | Proxmox VE only | ESXi / Hyper-V / SvHCI |
Need 3+ nodes, 3-way replication, or storage tiers? That's XOSTOR's territory, not TWINSTOR's. vSphere Essentials-class deployments (the tier Broadcom discontinued) map one-to-one onto two XCP-ng hosts with TWINSTOR.
POS, inventory, surveillance on two small hosts per store. A direct replacement for 2-node vSAN hit by Broadcom licensing: no witness per store, no per-core tax, one golden script fleet-wide.
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.
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.
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.
Ships, wind farms, substations: places where "send a technician" means days. No remote hands needed for recovery; the whole stack is observable from shore.
A standardized, scriptable 2-node building block: identical setup at every client, alerts centralized in Xen Orchestra, zero-downtime updates during business hours.
Everything rides one network path. Ideal for ultra-simple, low-power edge boxes: a pair of mini-PCs on one switch. When the shared path fails, both halves fail together cleanly: no way to diverge, no split-brain to untangle. The most-tested path.
Needs: one link between the hosts. That's it.
Replication gets a dedicated back-to-back cable as its default path: synchronous writes and resync storms stay off the switch, which becomes the automatic, alerted fallback. Rides through switch-side gray failures that fate-shared cannot.
Needs: a second NIC per host and a crossover / DAC cable. Validated in the physical torture campaign.
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 and/or stacked switches recommended), and capacity exhaustion / silent bit-rot monitoring are on the documented backlog. Tech Preview status: it's a 0.x series, so read the release notes before upgrading a live pool.
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. Full docs ship with the preview: README, PRODUCT, FAQ, BEHAVIOR, TEST_PLAN, ARCHITECTURE.