Quick summary
High Availability has been on SolusVM’s roadmap as a named priority since last year, and it’s now live for every customer, included in the platform’s existing flat licensing rather than gated behind a higher tier. When a Compute Resources fails, protected virtual servers automatically move to a healthy node in the same failover domain, without waiting for an administrator to manually initiate recovery.
Key takeaways:
– High Availability is live now and included for all customers at no additional cost.
– It protects KVM virtual servers on Shared LVM over iSCSI or NFS storage; OpenVZ containers aren’t covered.
– Detection relies on a shared-storage lock, not the SolusVM agent, which avoids false failovers from network blips.
– A failover domain needs at least two compute resources and supports up to 2,000.
– This builds directly on 2025’s Disaster Recovery and iSCSI Shared Storage releases, which laid the technical groundwork.
What shipped
SolusVM’s High Availability feature protects virtual servers by grouping compute resources that share storage into a failover domain. If a compute resource in that domain goes down, its protected virtual servers get restarted automatically on another healthy compute resource in the same domain, without anyone logging in to trigger it manually. The provider still gets notified. When a node fails, affected VMs restart automatically on a healthy node — customers notice a brief reboot, not a prolonged outage.
This isn’t a beta or a limited rollout. It’s live and included for every SolusVM customer under the platform’s existing flat, unlimited licensing, the same model that’s applied to the platform since it launched.
How failure actually gets detected
The mechanism matters as much as the outcome. SolusVM confirms a compute resource failure using the shared-storage lock each node holds, rather than relying on the connector or agent between the management node and the host. That choice avoids a specific failure mode common in less careful HA implementations: a node with a flaky network connection but a genuinely working storage lock doesn’t get mistaken for dead, so healthy workloads don’t get evacuated based on a false alarm.
There are real limits worth knowing before assuming HA covers everything. It supports KVM virtual servers only, on Shared LVM over iSCSI or NFS storage; OpenVZ containers aren’t eligible. A failover domain needs a minimum of two compute resources to function at all, a domain with just one reports as not protected, and scales up to 2,000 compute resources per domain.
The quiet groundwork that made this possible
High Availability didn’t ship in isolation. It’s the direct result of two feature releases from the year before: Disaster Recovery, which established restoring virtual servers from backup onto healthy compute resources, and iSCSI Shared Storage support, SolusVM’s first shared block storage option. Both were described as the technical foundation for HA specifically, and the sequencing shows in how the feature works: HA’s failure detection depends on the same shared-storage layer that iSCSI support introduced, and HA falls back to manual Disaster Recovery for cases automatic failover can’t resolve on its own.
For providers evaluating HA, that sequencing matters. The feature builds on storage and recovery capabilities delivered across multiple releases rather than introducing an entirely separate resilience architecture at once. The release also comes as providers are running increasingly important workloads on SolusVM, making automated resilience more relevant as deployments scale.
Who should turn this on first
Hosting providers should start with VPS plans where downtime has the clearest customer impact. That could include trading VPS, business-critical hosting, SaaS infrastructure, or other persistent workloads where customers expect services to remain available through infrastructure failures.
HA can also become part of the provider’s offering strategy. Providers don’t have to enable HA on every VPS plan at once. Start by piloting it on persistent workloads, then use it to build an SLA-backed or premium HA tier for customers who need stronger availability guarantees than a standard plan.
General-purpose and gaming VPS customers can benefit as well, particularly for persistent services where an unexpected interruption affects users. The priority should be based on workload requirements, available shared-storage infrastructure, and the provider’s service commitments.
Getting started
Enabling HA is a configuration task, not a purchase:
- Turn on High Availability in global settings.
- Group compute resources that share the same storage into a named failover domain.
- Explicitly protect the individual virtual servers you want covered — grouping compute resources into a failover domain doesn’t automatically protect what’s running on them.
- Test the failover in a controlled window before relying on it in production.
- Use maintenance mode for planned node work, so scheduled maintenance doesn’t get treated as an outage.
What existing customers should check first
Providers already running SolusVM don’t need to wait for a separate rollout window; the feature is available in current installations now. The main prerequisite is infrastructure, not licensing: HA needs Shared LVM over iSCSI or NFS storage already in place across the compute resources meant to form a failover domain. Providers without shared storage configured yet have a genuine setup step ahead of them before HA becomes usable, separate from anything related to cost or plan tier.
It’s also worth checking existing HA-adjacent configuration for conflicts before flipping the feature cluster-wide. A cluster already running custom, manually scripted failover logic should have that logic reviewed against SolusVM’s native HA behavior, since running both at once risks the two systems working against each other during an actual failure event.
Where to go from here
High Availability is live, included, and built on groundwork SolusVM has been laying for the past year rather than rushed out as a standalone feature. If failover has been the reason you looked at a different platform before, or the reason you’ve been running a manual recovery process alongside SolusVM, this removes that gap without changing what you pay for the license itself.
Full setup details are in the platform’s features overview, current licensing is on the pricing page, and if you’re not yet running SolusVM, the free trial includes the full HA workflow described here.
Frequently asked questions
Does High Availability cost extra? No. HA is included under SolusVM’s existing flat, unlimited per-node licensing. There’s no separate HA tier or add-on fee.
Does this apply to OpenVZ containers? No. High Availability currently protects KVM virtual servers only, running on Shared LVM over iSCSI or NFS storage. OpenVZ containers need a different resilience approach, such as scheduled backups.
How is a failure actually detected? Through a shared-storage lock each compute resource holds, not through the SolusVM agent or connector. This avoids treating a node with a temporary network issue as failed when its storage lock is still valid.
How many compute resources does a failover domain need? A minimum of two; a single-computer-resource domain reports as not protected, since there’s nowhere for a virtual server to fail over to. Domains scale up to 2,000 compute resources.
Is this related to the recent SolusVM pricing change? They’re related in narrative, not mechanically. HA is included at no additional charge under existing licensing. Separately, SolusVM has announced a rate increase for the Unlimited tier effective November 9, 2026, its first since launch, which it has described as supporting continued platform investment, HA among it, rather than as payment for the feature itself.
Do I need to reconfigure existing infrastructure to use HA? Only if shared storage isn’t already in place. HA requires shared LVM over iSCSI or NFS storage across the compute resources in a failover domain, so a cluster without that configuration has a setup step to complete before the feature becomes usable, independent of licensing or plan tier.