When free XCP-ng is enough and when a Vates subscription pays off
Vates describes the XCP-ng hypervisor and Xen Orchestra as open-source projects with no limits and no license fees, and says that commercial support subscriptions add SLAs. So the choice you face is not about software cost. It is about whether you are willing to carry support risk yourself. Free use is adequate when your team already owns the hypervisor operations: installing hosts, patching dom0, managing XAPI pools, restoring backups and reading release notes before upgrading. If you have engineers who can troubleshoot a Xen host at 2 a.m. and a tested rollback path, the unsupported route can be a sound operating model, especially for test, lab, development or non-critical workloads where an outage is tolerable.
The subscription becomes worth pricing when the cost of an outage or an unresolved fault exceeds the cost of a contract. That usually means production clusters with contractual uptime commitments, small teams with no spare Xen expertise, or environments where an auditor or board expects a named vendor you can escalate to. Vates publishes its VMS plans by host count and pool size, including Essential at $2,000 per year and Essential+ at $4,000 per year for up to 3 hosts, and Enterprise at $1,800 per host per year with a 4-host minimum and 24/7 support. Ask Vates which plan matches your host count, whether XOSTOR at $800 to $1,200 per host per year is needed, and which SLA response times each tier actually guarantees. Confirm current pricing on the Vates pricing and support page before you build a budget.
What the Vates subscription adds to free XCP-ng
This table sets the free XCP-ng hypervisor and Xen Orchestra against what a Vates VMS subscription adds, using only the items Vates documents. Read the rows marked for verification as questions to put to Vates before you decide, since the supplied sources do not confirm every detail.
| Item | Free XCP-ng and Xen Orchestra | Vates VMS subscription |
|---|---|---|
| Software license fee | No license fees, per Vates' description of the open-source projects | Vates describes the software as having no license fees; the subscription pays for support |
| Commercial support with SLAs | Not included; support depends on community resources and your own team | Commercial support subscription adds SLAs, per the Vates pricing and support page |
| 24/7 support | Not included | Documented on the Enterprise plan only; confirm response targets in writing |
| Plan structure | Not applicable | Essential, Essential+, Pro and Enterprise plans, with pricing that depends on host count or plan terms |
| XOSTOR hyperconverged storage | Not offered as a Vates add-on | Sold as an add-on at $800 to $1,200 per host per year, per the Vates pricing page |
| Xen Orchestra V2V migration | Included in Xen Orchestra, which uses warm migration from the ESXi API | Confirm with Vates whether V2V is covered by your plan's support scope |
| Upgrade and patch support | You plan and apply upgrades; XCP-ng 8.3 LTS is supported until November 30, 2028 | Confirm with Vates which fixes and upgrade help a plan covers |
Open-source terms and support terms for each edition
XCP-ng and Xen Orchestra are open source with no license fees, and Vates sells support subscriptions on top. The cards below separate what the open-source licenses permit from what a Vates plan adds, and what stays with your team either way.
Open-source XCP-ng and Xen Orchestra
The xcp repository is licensed GPL-2.0, and Vates describes both the XCP-ng hypervisor and Xen Orchestra as open-source projects with no license fees. You can run the platform without a subscription, but every patch, upgrade, backup check and failover test is your team's job. Before you commit, confirm which update channel you will use, who reviews release notes, and who is on call when a host fails.
Vates support tiers and SLAs
Vates sells commercial support subscriptions that add SLAs on top of the open-source software. Its VMS plans include Essential, Essential+, Pro and Enterprise, with pricing set by host count or a flat annual fee, and Enterprise adds 24/7 support. Ask Vates to confirm in writing what response times, escalation paths and named contacts each tier includes, and whether the tier covers Xen Orchestra as well as the hypervisor.
What support covers and what stays with you
A support subscription answers incidents and provides vendor guidance, but it does not patch your hosts, design your storage layout or test your disaster recovery plan. Your team still owns change windows, backup restores, capacity planning and the hardware and network under the pool. Ask for a written split of responsibilities, since a plan that looks complete on paper can leave backup verification and network changes unassigned.
XCP-ng 8.3 LTS support window
XCP-ng 8.3 LTS was released on October 7, 2024 and is supported until November 30, 2028. A long-term branch gives you a fixed horizon to plan around, so build your upgrade schedule and hardware refresh against that date rather than assuming updates will continue indefinitely. Confirm with Vates whether a support subscription extends coverage for a given branch and what the paid tier does after the public end date.
Teams still on 8.2 LTS
XCP-ng 8.2 LTS support ended September 16, 2025, so hosts still running that branch no longer receive the standard maintenance updates for that release. Treat this as an upgrade decision with a budget, a test plan and a rollback path, not a routine patch. Inventory every pool and host by version, and ask Vates what options exist for unsupported branches before you decide between upgrading and extending risk.
When unsupported use is acceptable
Running without a subscription can be reasonable for lab, development and non-critical workloads where an outage costs time rather than revenue or regulatory exposure. For production systems in regulated environments, check whether your change management, incident response and audit evidence requirements assume a vendor escalation path. If they do, the open-source build alone may not meet them, and you should price the subscription or a third-party support contract against that requirement.
What each Vates VMS plan costs per year
This table lists the published Vates VMS plan and XOSTOR add-on prices as the supplied vendor page states them, so you can work out the annual subscription line for your host count. Every figure is a list price per year, and the totals exclude your own staff, hardware and migration work.
| Plan or add-on | Published price | Basis and minimum | Source and what to confirm |
|---|---|---|---|
| Essential | $2,000 per year | Covers up to 3 hosts | Vates pricing page (vates.tech/en/pricing-and-support/); confirm current terms with Vates |
| Essential+ | $4,000 per year | Covers up to 3 hosts | Vates pricing page; confirm what support level differs from Essential |
| Pro | $1,000 per host per year | 3-host minimum | Vates pricing page; confirm whether the minimum applies per pool or per account |
| Enterprise | $1,800 per host per year | 4-host minimum, includes 24/7 support | Vates pricing page; confirm the response times included before budgeting |
| XOSTOR add-on | $800 to $1,200 per host per year | Recurs per host on top of a VMS plan | Vates pricing page; confirm whether the rate varies by host size or cluster |
| Staff, hardware and migration | Not included in the list prices | One-time and recurring internal effort | Ask your DeployOpen scope or internal team for estimates; list prices alone do not show total cost |
Which plan fits a 3-host cluster or a 4-host cluster
A cluster of up to three hosts can use the flat-fee plans. Essential is listed at $2,000 per year and Essential+ at $4,000 per year, both for up to 3 hosts, so the list price does not change as hosts are added within that limit. Pro is priced at $1,000 per host per year with a 3-host minimum, so a 3-host cluster qualifies for it. Enterprise requires at least 4 hosts and is not available at this size.
- Essential: $2,000 per year flat for up to 3 hosts. Illustrative: a 2-host cluster and a 3-host cluster both fall under this single published price.
- Essential+: $4,000 per year flat for up to 3 hosts. Confirm in writing how its support scope differs from Essential, since the pricing summary does not spell it out.
- Pro: Illustrative: 3 hosts × $1,000 = $3,000 per year, which is above Essential but below Essential+.
- Enterprise: Not eligible below the published 4-host minimum.
- XOSTOR add-on: Illustrative: 3 hosts × $800 to $1,200 = $2,400 to $3,600 per year, added on top of the base plan.
Confirm whether spare or lab hosts count toward the host limit before you choose between a flat plan and Pro.
Once a cluster reaches four hosts, per-host pricing becomes the main cost driver. The published Essential and Essential+ plans are listed for up to 3 hosts, so they fall outside the stated limit at this size. Pro ($1,000 per host per year, 3-host minimum) and Enterprise ($1,800 per host per year, 4-host minimum, with 24/7 support) are the published options that cover a four-host cluster.
- Pro at 4 hosts: Illustrative: 4 hosts × $1,000 = $4,000 per year.
- Enterprise at 4 hosts: Illustrative: 4 hosts × $1,800 = $7,200 per year. The gap from Pro is $3,200 per year at this size, and it reflects the 24/7 support tier published for Enterprise.
- Growth effect: Illustrative: a 6-host cluster would total $6,000 per year under Pro and $10,800 per year under Enterprise. Each added host raises the total by $1,000 under Pro or $1,800 under Enterprise.
- XOSTOR at 4 hosts: Illustrative: 4 hosts × $800 to $1,200 = $3,200 to $4,800 per year, on top of the base subscription.
- Support terms: The Vates pricing page describes commercial subscriptions as adding SLAs. Confirm response times, escalation paths and what 24/7 covers in the written terms.
Ask Vates to confirm which plans are eligible for your exact host count and to itemize the subscription and any add-ons in one quote.
Published list prices give a starting point for a budget, and the final invoice depends on the written quote. The illustrative figures above assume the per-host rates apply to every host you count and that the plan limits on the current pricing page still apply when you order.
- Host counting: Confirm whether management, test or cold-standby hosts count toward the host limit and the per-host charge.
- Add-ons: Confirm whether XOSTOR and other add-ons are priced on the same per-host basis as the base plan and whether any of them require a specific tier.
- Term and currency: The published figures are per year. Confirm the billing term, currency, taxes and renewal terms.
- Mid-term changes: Ask how adding hosts during a term is billed and whether you can move to a different plan without a new contract.
- Incident coverage: Ask what the subscription covers during an incident, including response times, and how that differs from running without a subscription.
Request the host count, plan, add-ons, term and support terms in one written quote from Vates pricing and support, then compare it against your budget.
How XOSTOR changes the storage decision
XOSTOR is a paid add-on, not part of the free XCP-ng and Xen Orchestra stack. Vates lists it at $800 to $1,200 per host per year, according to its pricing and support page. That recurring fee applies to every host that participates in the storage layer, so the cost scales with the cluster, while the hypervisor and Xen Orchestra remain open source with no license fees. Choosing XOSTOR therefore means adding a per-host line to the budget, on top of any VMS plan you buy for support. Ask Vates to confirm in writing which hosts count toward the add-on, whether the per-host rate changes with cluster size, and whether it renews on the same schedule as your VMS plan.
A hyperconverged layout puts compute and storage on the same hosts, so a host failure removes both. A shared storage array keeps the two separate, which changes who owns failure handling and how you plan capacity. Before you commit, put these questions to Vates: how XOSTOR replicates data across hosts and what happens to running VMs when one host or disk fails; what hardware it requires for network, disks and minimum host count; and what the support SLA covers for storage faults compared with hypervisor faults. Get the answers in writing and compare them with your recovery targets.
This page does not describe XOSTOR internals beyond what the supplied facts state: that it is a paid hyperconverged storage add-on priced per host per year. Replication design, supported hardware and failure behavior are vendor details you need to confirm directly, ideally with a test cluster that reproduces a host loss before production use. Teams that already run a SAN or NFS target may find that keeping shared storage avoids the add-on entirely, but that choice carries its own cost in separate storage operations and support.
Moving from free use to a Vates subscription and back
This sequence takes a team from a free XCP-ng and Xen Orchestra deployment to a paid Vates VMS plan with written support terms, and leaves a record that shows which branch and plan each host runs on. The reverse path, moving back to free use, is not covered by the supplied facts, so it needs a written answer from Vates before you rely on it.
Inventory hosts and pool layout
The platform team lists every XCP-ng host, the pools they belong to, and the Xen Orchestra instance that manages them. Count hosts per pool, because the plan limits are stated per host and per pool, and note any host that is planned but not yet joined. The inventory is done when the count is written down and a second engineer has checked it against the hypervisor console. Ask Vates how a host that is temporarily offline or in maintenance is counted.
Confirm host count against plan limits
Compare the inventory with the limits on Vates' pricing page. Essential and Essential+ cover up to 3 hosts, Pro requires a 3-host minimum, and Enterprise requires a 4-host minimum and includes 24/7 support. A cluster of 2 hosts therefore does not fit the Pro or Enterprise minimums as written, and a cluster that is expected to grow should be priced for its future size. The check is complete when the host count fits exactly one plan and the team has noted the reason. Confirm with Vates how the counts apply to your specific pool layout.
Choose plan and add-ons
The platform owner selects a VMS plan based on support level and host count, then decides whether any add-on is needed. XOSTOR hyperconverged storage is sold separately at $800 to $1,200 per host per year, according to Vates' pricing and support page, so a team that wants replicated storage should price it per host alongside the base plan. The decision is recorded in a short note listing plan, host count, add-ons and the annual amount quoted by Vates. Ask for the quote in writing so the recurring cost is visible to finance.
Confirm support contacts and SLA terms in writing
Procurement and the platform lead ask Vates to confirm, in the order or contract, the response levels, support hours, named contacts and escalation path that come with the chosen plan. Vates describes commercial subscriptions as adding SLAs, so the reader should obtain the actual SLA document rather than rely on marketing summaries. The step is done when the written terms are filed with the purchase record and the on-call team has the contact route. Ask what changes if the plan is later reduced or cancelled.
Check XCP-ng branch support status
The platform team compares each host's XCP-ng version against the release documentation. XCP-ng 8.3 LTS was released on October 7, 2024 and is supported until November 30, 2028, while XCP-ng 8.2 LTS support ended September 16, 2025. Any host still on 8.2 is outside its support window and should be scheduled for an upgrade before the subscription is relied on for that host. The check is complete when every host reports a supported branch in the inventory. Confirm with Vates whether it will support a host on an unsupported branch under a subscription.
Schedule upgrades to a supported branch
Hosts that are not on a supported branch are upgraded in a planned window, one pool at a time, with virtual machines moved or drained first. The upgrade plan records the target version, rollback approach and the owner for each host, and it is reviewed with Vates or the implementation partner if the team wants outside help. The step closes when every host reports the target version and the inventory is updated. Ask Vates for its written upgrade guidance and whether support covers upgrade problems.
Record the subscription state and review it
The platform owner stores the final host list, plan, add-ons, support terms and upgrade record in the configuration documentation, and schedules a periodic review that compares host count with plan limits as the cluster changes. The record is the evidence that the subscription matches the running environment. The facts supplied do not describe how a downgrade or plan change is handled, so before any reduction the team should ask Vates for its written process, including notice, pro-rating, host removal and any effect on support.
When running XCP-ng without vendor support is acceptable
Unsupported XCP-ng production use is defensible when the team already owns the skills that a vendor would otherwise supply. That means people who can read XAPI logs, diagnose a dom0 problem, recover a pool master and rebuild a host without outside help. The decision test is simple: if an outage happened at 2 a.m. on a Sunday, could your own engineers restore service within the recovery time your business has agreed to, using runbooks they have actually rehearsed? If the answer is yes for the workloads in question, the free stack with Xen Orchestra can be a reasonable operating model. Confirm the in-house depth by checking who holds the pool, storage and backup knowledge, and whether more than one person can act on it.
The strongest case is a lab, a development estate or non-critical workloads where downtime costs little and can be tolerated. Production use is harder to justify for tiers with contractual availability commitments, so separate those workloads from the rest rather than treating the whole pool the same way. Document the patching cadence for XCP-ng hosts against the supported release line, for example the XCP-ng releases documentation, and keep a written backup and restore procedure that has been tested on a recent backup, not just scheduled. A written record of these controls is what lets a reviewer see that unsupported use was a considered choice.
The factors that make the choice hard to defend are external. Customer contracts or service levels that promise uptime or response times usually assume a vendor escalation path, and an in-house team alone may not meet them. Regulated organizations often expect vendor support, or a documented equivalent, as part of how they demonstrate control over critical systems, so ask your compliance lead and auditors early rather than assuming. Also consider staff turnover, since a team that is comfortable today may not be in two years. Confirm with Vates what the paid tiers actually include in response times and escalation before deciding, using the Vates pricing and support page.
How the V2V migration path affects the edition decision
This sequence shows how a VMware to XCP-ng move runs through Xen Orchestra's V2V tool, and where the support decision has to be made before cutover. It ends with a documented state in which each migrated VM has been verified and the edition choice is settled for the production pool.
Confirm the source ESXi version is supported
Before any tooling is installed, the migration lead checks the exact ESXi version on every source host against the XCP-ng migration documentation. The documentation states that ESXi 6.x hosts are not supported by current Xen Orchestra versions for V2V, so any host on that version needs a different plan, such as upgrading the source first. The step is done when a written inventory lists each host, its ESXi version and whether V2V can be used for it.
Stand up Xen Orchestra and grant API access
The platform team deploys Xen Orchestra and gives it HTTP access to the ESXi API on each source host, which is the only network requirement the V2V tool needs. Access should use a dedicated read-capable account so the migration does not depend on a personal login. The step is done when Xen Orchestra can list the VMs on every in-scope source host from its V2V screen.
Run a warm migration on a test VM
Before any production workload moves, the team runs one non-critical VM through V2V's warm migration, which replicates data while the source VM keeps running and then syncs changed blocks after shutdown. This exercise shows how long the final cutover window is for that VM's disk size and change rate. The step is done when the test VM boots on XCP-ng and its application owner signs off on function and data.
Decide the edition before the production pool exists
The migration result feeds the support decision: the number of hosts that will be in each pool, whether shared storage such as XOSTOR is needed, and how quickly the team must reach a vendor for fixes. Because the Vates VMS plans are priced per host, per pool or as a flat tier, the pool design must be fixed first. The step is done when a written decision names the plan or the unsupported model for each pool, with the host count and add-ons attached.
Migrate production VMs in agreed waves
The team moves production VMs in batches, each with a documented owner, rollback point and cutover time agreed in advance. Dependencies such as databases, directory services and backup targets go first or are moved together, so that no application is split across platforms. The step is done when every wave has a signed cutover record listing the VMs moved, their verification results and any issues left open.
Verify support coverage against the live pool
Once VMs run on XCP-ng, the team confirms that the chosen support tier actually covers the running hypervisor, Xen Orchestra version and add-ons in use, and checks the vendor's support documentation for the XCP-ng branch in production. Any gap between the signed support scope and the live pool is recorded as a finding. The step is done when the platform owner has a support map that matches the pool inventory exactly.
Document backups and the upgrade path
The team records how backups run against the migrated VMs, where restore points are kept and how the pool will move to later XCP-ng releases, including the 8.3 LTS support window. It also records who approves upgrades and how a rollback is performed. The step is done when a runbook is stored with the platform documentation and a restore test has been completed on at least one migrated VM.
What buyers ask before paying for Vates support
How much does a Vates VMS subscription cost for my host count?
The price depends on the plan and the number of hosts, so start with the plan that matches your cluster size. Vates lists Essential at $2,000 per year and Essential+ at $4,000 per year for up to 3 hosts, Pro at $1,000 per host per year with a 3-host minimum, and Enterprise at $1,800 per host per year with a 4-host minimum and 24/7 support, according to the Vates pricing page. For a small cluster, a flat plan can cost less than a per-host plan, and for a larger cluster the per-host plans scale linearly. Check the current terms on the Vates pricing and support page and ask for the plan, host count, term and any add-ons in a written quote.
Can free XCP-ng run in production without a subscription?
Yes, the hypervisor and Xen Orchestra are described by Vates as open-source projects with no license fees, and the subscription adds commercial support with SLAs. Whether that is acceptable depends on your change control, your recovery commitments and whether your staff can handle vendor-level incidents alone. Teams with strong Linux and Xen skills and tested runbooks often run it without a contract, while regulated teams usually need a documented escalation path and a support commitment they can present to auditors. Confirm which XCP-ng release you will run, since XCP-ng 8.3 LTS is supported until November 30, 2028 and XCP-ng 8.2 LTS support ended September 16, 2025.
How much staff time does an unsupported XCP-ng cluster need?
The time depends on cluster size, how often you patch, how many people can troubleshoot the Xen stack and how complete your automation is. Budget time for patching hosts, maintaining backups, monitoring storage and network health, and keeping Xen Orchestra current, all of which recur. Ask whether your team has someone who can read dom0 logs, diagnose XAPI problems and recover a failed host without outside help. If the answer is no, price a support plan or an outside operator alongside the subscription, because the hidden cost of unsupported use is usually the engineer hours spent during an incident.
Can Xen Orchestra V2V move VMware workloads to XCP-ng?
Xen Orchestra includes a V2V tool that supports VMware to XCP-ng migration with warm migration, which replicates data while the source VM runs and then syncs changed blocks after shutdown. It needs only HTTP access to the ESXi API. Note that ESXi 6.x hosts are not supported by current Xen Orchestra versions for V2V, so confirm your source versions before planning. Test a representative VM from each guest OS family, record the downtime at cutover and check drivers and boot settings afterward. The XCP-ng migration documentation covers the supported paths.
What does a migration from VMware cost beyond the subscription?
The subscription is only one line item. Cost components include the time to inventory VMs and dependencies, the hardware or storage needed for parallel running, the migration engineering, testing and rollback planning, and the staff time after cutover. Warm migration reduces the downtime window for supported sources, but it does not remove testing effort. Ask any partner for a written scope that lists which VMs move, which are rebuilt, how cutover is staged and who signs off on acceptance. Compare that scope with the cost of the subscription tier you need, not with a list price alone.
Is XOSTOR worth buying, and what does it cost per host?
XOSTOR is Vates hyperconverged storage, sold as an add-on at $800 to $1,200 per host per year according to the Vates pricing and support page. It is worth evaluating when you want shared, replicated storage across hosts without a separate SAN, but it adds a recurring per-host cost on top of the platform subscription. Compare it with the storage you already own, the replication and failure behavior you need, and the skills required to operate it. Request a quote that states the per-host add-on, the platform plan it attaches to and whether support covers the storage layer.
Can an outside partner run XCP-ng and Xen Orchestra for us?
Yes, DeployOpen plans, implements, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, and most engagements are fixed-scope with deliverables and timelines agreed in writing before work starts. Ongoing support and upgrades are available as retainers. Vates support and an outside operator cover different things, so decide who answers the vendor-level question and who runs day-to-day operations. Ask any partner to state in the quote which systems are in scope, who holds the administrator credentials and how handover works.
How DeployOpen works on this
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so the XCP-ng pool, Xen Orchestra and any subscription decision are scoped against your hosts, networks and change process. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- The written scope lists host count, pool layout, storage design and whether Xen Orchestra runs as a self-managed appliance.
- We record which XCP-ng and Xen Orchestra versions are in use and which support window each one falls in.
- The scope states whether a Vates subscription is in or out, and which add-ons, such as XOSTOR, are covered.
How we build
- We install and configure XCP-ng hosts, pools and Xen Orchestra inside your cloud accounts, data centers or air-gapped networks.
- We set up backups, network segmentation, access control and patching procedures to match your change process.
- Where a V2V migration from VMware is in scope, we test warm migration on non-critical VMs before cutover.
How we hand over
- You receive documentation of the pool design, upgrade path, backup and restore steps and the support boundary.
- Runbooks cover what to do when a host fails, an upgrade is due and an update falls outside the support window.
- Handover includes a written record of which decisions depended on the subscription, so you can revisit them later.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- We can plan upgrades around the published XCP-ng release support dates, so your team sees each deadline in advance.
- Before requesting a quote, confirm with Vates which support level, SLA and add-ons your environment needs.
