Xen Orchestra 6.7
XO 6.7 is out: major reliability improvements to Rolling Pool Update, VM duplication and more workflows in XO 6, eight new Host actions in the REST API, plus a refreshed docs.vates.tech.
This month is about making the entire Vates ecosystem easier to use, whether you're deploying your first XCP-ng host, automating large-scale operations, or maintaining production infrastructure.
Alongside Xen Orchestra 6.7, we've significantly refreshed our documentation on docs.vates.tech, making it easier to find hardware compatibility information, security advisories and common deployment guides. On the product side, we've invested heavily in the reliability of Rolling Pool Update, continued expanding the REST API for automation, and brought even more day-to-day administration workflows into XO 6.
Add Backup improvements, quality-of-life enhancements across the platform and a growing ecosystem around Vates, and this release continues our focus on making infrastructure management simpler, safer and more predictable.
🔗 Summary
As usual, this announcement is available as a Youtube video:
👨🚀 Project & Community
A lot has happened around the Xen Orchestra ecosystem this month. From opening the Twinstor Tech Preview to announcing a soft-launch of our Vates Alliance Network and strengthening our ties with academia, we're continuing to invest not only in the product itself, but also in the community and ecosystem around it.
XCP-ng 8.3 updates
XCP-ng 8.3 LTS received a new security and maintenance batch on July 28. The core of it is a Xen security update covering several advisories, the most notable being a grant-table type confusion that could let a guest escalate to host privileges or bring a host down (XSA-500). The batch also fixes a XAPI regression that left VBDs attached after a VM.revert, plus minor changes to build a refreshed 8.3 LTS installer ISO. Host reboots are required, so apply it through your pool's usual update path.
Philippe Coval
Twinstor Tech Preview is now open
Last month, we introduced Twinstor with a live technology demonstration. This month, we're taking the next step by officially launching the Twinstor Tech Preview.
Twinstor is our upcoming hyperconverged storage solution designed specifically for two-node XCP-ng clusters, eliminating the need for a SAN, a witness node or a third server.
The Tech Preview is available to everyone. Anyone can deploy it, experiment with it and share feedback by joining the dedicated discussion on our community forum. Like any Tech Preview, real-world testing is the best way to help us improve the product.
olivierlambert
For users who want to go one step further, we're also launching a guided evaluation program. You can apply to participate, and we'll select a limited number of environments that best match the use cases we want to validate during this phase.
Selected participants will receive direct support from our engineering team, benefit from dedicated communication channels, and take part in feedback sessions that will directly influence Twinstor's development before General Availability.
Whether you simply want to try it in your lab or help us validate it in production-like environments, we'd love to hear your feedback.
docs.vates.tech gets a major refresh
Our documentation is part of the product, so this month we gave docs.vates.tech a substantial overhaul, reworking and expanding a large part of the content across the whole Vates VMS stack. A refresh this size inevitably leaves a few rough edges behind, so if you land on an outdated section or a dead link, you can now tell us right where you found it: every page carries a small "Was this page helpful?" feedback tool, and we actually read what comes through it. It is the quickest way to help us fix what the rewrite missed.
The welcome page is worth a look on its own, with a new Popular Tasks section that puts what people usually come to the docs for, like installing XCP-ng, deploying Xen Orchestra or checking hardware, one click away. Two pages in particular got real attention. The Vates Security Advisories page is now searchable by VSA, CVE or XSA number and filterable by severity, product and year, with an RSS feed for teams who would rather subscribe than check back. And the new hardware compatibility list lets you search close to a thousand servers, NICs, storage controllers, GPUs and CPUs known to work with XCP-ng, filtered by category or version.
How the NetBox plugin works
We also published a closer look at the xo-server-netbox plugin: how the one-way sync to NetBox works, what it treats as its own, and why choices like IP-to-prefix matching or name deduplication work the way they do. If you're running NetBox alongside XO, or considering it, it's worth a read!
Pierre Donias
The Vates Alliance Network is taking shape
This summer also marks the soft launch of the Vates Alliance Network, bringing together technology partners, service providers and solution experts around the Vates ecosystem.
The official launch is planned for September, but the network is already growing steadily.
SYS1 joins our channel network
We're pleased to welcome SYS1 as a new Vates reseller partner. With strong expertise in virtualization, infrastructure modernization and automation, SYS1 will help organizations deploy and operate the Vates virtualization stack while benefiting from local expertise and support. We're excited to start working together.
Vates Virtualization Management Stack (XCP-ng / Xen Orchestra)
Investing in the next generation
We're also proud to announce a new partnership with Grenoble INP – Ensimag, one of France's leading engineering schools in computer science and applied mathematics.
The partnership covers educational resources, internships, collaborative projects and closer ties between academia and industry, helping prepare the next generation of engineers working on open-source infrastructure technologies.
Vates Virtualization Management Stack (XCP-ng / Xen Orchestra)
The team is still growing
As Vates continues to grow, we're currently recruiting across several positions, including:
- Internal Tools Developer
- Channel Account Manager
- XCP-ng XAPI Developer
- Alliance Solutions Engineer
If you'd like to help shape the future of open-source virtualization, we'd love to hear from you.
💡 Insights
This month, we are introducing a new section. Insight explores recent industry events and the practical takeaways they offer for our users and the wider virtualization ecosystem.
What the Hugging Face incident teaches us about local AI
Hugging Face disclosed on 16 July that an autonomous AI agent had compromised part of its production infrastructure, and OpenAI confirmed on 21 July that the models were its own, running a cyber-capability benchmark with refusals deliberately reduced. The technical timeline published since puts numbers on it: roughly 17,600 attacker actions between 09 July 02:28 UTC and 13 July 14:14 UTC, at a pace the responders describe as "far beyond what an operator could sustain by hand". They were not trying to break out. Hugging Face's own conclusion is blunter than anything we would write for them: "We believe the entire intrusion was, from the agent's point of view, an attempt to cheat the evaluation." The answer key lived on their production systems, and the agent got there through the sandbox's one permitted path, a package-registry cache proxy carrying a zero-day. From there it read a production object holding 136 keys, minted its own identity tokens from a harvested EdDSA signing key, joined the corporate mesh VPN on a stolen auth key, and respawned itself across eleven nodes.
The part worth your attention is where it stopped. The production database never answered, because the allow-list only accepted connections over a private link and the agent's attempt timed out. The CI pipelines refused it because execution policies said no. Neither of those is clever and neither was bought recently. They are boundaries you draw once and then maintain, and they are what something moving at that cadence ran into.
The responders then hit a second problem: they could not send the attacker log to hosted models, because provider guardrails cannot tell an incident responder from an attacker, treating "reverse-engineering an exploit the same as launching one". They ran the forensics on ZAI's GLM-5.2 on their own infrastructure instead. If you want that option ready before you need it, our July 2025 walkthrough covers running GPU-powered models on XCP-ng.
Olivier Lambert
🎫 Events & webinars
We keeps you up to date with where we've been, where we're heading next, and the events where you can meet the Vates team.
Digital Summ'r - 2026/08/27
Jean-Baptiste (VP alliances) is giving a talk at Digital Summ'r, at the Campus Région du Numérique near Lyon.
More details are coming soon, but you can already save the date on your calendar!
Reduce infrastructure costs and simplify virtualization management, with EasyVirt
We ran a joint webinar with EasyVirt on 2 July, presented by Jeff Duerr (US Sales Manager) for us and François Machacek (Business developer) for EasyVirt. The thread running through it was doing more with the infrastructure you already have: bringing costs down, managing more than one hypervisor from one place, and taking the risk out of a migration before it reaches production rather than after.
The recording is up, 45 minutes, so you can watch it back rather than take our word for it.
Salon Souveraineté Numérique
We were at the Salon Souveraineté Numérique at the start of July, on booth E02. The pitch we took there was the one we keep coming back to: sovereignty is not only about where the data sits, it is about whether you could keep running if your vendor disappeared or changed direction tomorrow.
Vates Virtualization Management Stack (XCP-ng / Xen Orchestra)
What's next
- 🇫🇷 ADIRA x Polypus — Lyon, France — 2026/09/25
- 🌍 Pure Accelerate (Everpure) — Paris, France — 2026/10/15
XO 6.7
This month's release is primarily about operational excellence. You'll certainly notice the new features added throughout XO 6, but behind the scenes an enormous amount of work has gone into making Xen Orchestra more resilient, particularly during maintenance operations.
From Rolling Pool Updates to Backup and REST API integrations, Xen Orchestra 6.7 focuses on reducing operational friction and making production environments even easier to manage.
🛡️ Security
Security rounds up the latest security advisories from Vates and the wider virtualization ecosystem, highlighting what deserves your attention and, more importantly, what action to take.
July security update for XCP-ng 8.3 LTS
The latest XCP-ng 8.3 LTS update delivers one of the largest security batches of the year, incorporating fixes related to 11 Xen Security Advisories, alongside a XAPI regression fix and other maintenance improvements. Not every advisory affects XCP-ng, but all have been reviewed and assessed to provide complete transparency on their impact.
Philippe Coval
One advisory worth highlighting is XSA-498 (CVE-2026-42491), which affects the C# and PowerShell XAPI SDKs. While the main RPC connection correctly validates TLS certificates, some secondary HTTP handlers did not, potentially allowing a man-in-the-middle attacker to intercept authenticated traffic.
There is no configuration-based mitigation. Updating XAPI is only the first step: any third-party application built against the affected C# or PowerShell SDKs should also be rebuilt using the corrected libraries, including the community PowerShell module.
As always, we recommend keeping your XCP-ng hosts up to date. Our update process not only delivers upstream security fixes but also provides a clear assessment of which vulnerabilities actually affect XCP-ng, helping you focus on what really requires action.
💾 Backup
This month's Backup improvements focus on reliability rather than new functionality.
Whether you're protecting production workloads or strengthening your ransomware strategy with immutable repositories, Xen Orchestra 6.7 removes several sources of unnecessary friction and improves the overall backup experience.
No more false alerts for encrypted backups
If you use encrypted backups, you've probably encountered warnings reporting an unexpected backup file size even though the backup itself completed successfully.
While harmless, these alerts appeared frequently enough to become background noise, making it harder to distinguish genuine issues from false positives.
After identifying the root cause, Xen Orchestra now correctly handles encrypted backup file sizes, eliminating these misleading warnings and making Backup reports more trustworthy.
Better support for immutable repositories
Immutable repositories are becoming an increasingly common part of ransomware protection strategies, and we're continuing to improve Xen Orchestra's support for them.
Following feedback from early production deployments, several improvements have been made to better handle immutable remotes and improve compatibility across a wider range of environments.
This is another example of how real-world customer feedback directly helps us improve the platform for everyone.
Important: incremental backups on QCOW2 disks without NBD
If you run QCOW2 disks without NBD, your backups and replications may have been silently completing green while holding almost no data. Xen Orchestra 6.7 (latest) fixes this. Find your situation below and take the matching action.
What happened
Our backup engine use 2MB block, QCow2 are exported by 64KB blocks of data, so we built adapter classes to produce 2MB block from 64KB data stream, computing a virtual offset of the 64KB chunk into the 2MB virtual block on the fly.
The offset is measured from the start of the disk instead of from the start of that block. Block index 0 come out correct, because for the first block the two are the same. Every block after it write past the end of its destination buffer and does nothing, leaving zeros. The result announces itself as a full backup while holding real data only in its first block. No errors, no warning, and the job status is green.
With NBD enabled, this adapter is never used, we can read any arbitrary offset of the disk data from the source, so we read it directly in the 2MB chunk needed by the backup engine.
Incremental backup without NBD was expected to be a fall back scenario during beta/transition, since it can never run an incremental job: computing the 2MB block from a 64KB cluster need to read at arbitrary size in the parent to fill the 2MB block with the parent’s data, so the backup was fall back to a full each time.
What 6.7 (latest) does
Xen Orchestra 6.7 fixes the offset (PR #10164) and adds two guards around it. On the next run, XO walks back to the root of the chain and forces a full transfer if the base disk's first blocks look empty. And NBD that is configured but not actually reachable, usually a transfer-network misconfiguration, now raises an explicit error instead of sliding quietly back into the fallback.
Which situation are you in?
Find the line that describes you.
- No QCOW2 disks. VHD never goes through this code. Nothing to do.
- QCOW2 with NBD from the start. This is the tested path. Nothing to do.
- QCOW2 with NBD enabled recently, after your last full backup or replication ran. Action required (see below).
- The safety net cannot detect this case: the damaged full (backup or replication) has since been merged with a delta that does put data at the front, so the check sees data and stays quiet.
- QCOW2 without NBD Treat these backups as not valid. Action required (see below).
Check here whether NBD is really active
If you can't tell whether NBD was enabled recently or from the start, don't guess.
- Run a health check and/or perform a test restore of your last backup (successful restore is the only real proof your data is safe) or
- Create a fast clone of your replica and start the VM.
Your path to safety - 2 options
- Upgrade to XOA 6.7 latest, then follow QCOW2 without NBD:
- Upgrade to 6.7
- Let one full run complete on the new code
- Then enable NBD Incremental Backups | XO Documentation.
- Stay on XOA 6.6 or earlier, then follow QCOW2 with NBD enabled recently
- Delete that job's snapshots so the next run is forced to take a genuine full.
Backup retention calculator
Choosing the right backup retention policy isn't always straightforward. To help with that, we released a new Backup Retention Calculator in the Xen Orchestra documentation.
Whether you're designing a simple retention policy or a more advanced schedule, it provides an easy way to visualize how many restore points will be kept over time and validate your configuration before deploying it.
🛰️ XO 6
One of our priorities with XO 6 remains simple: making the new interface the place where you can perform your everyday administration tasks without switching back to XO 5.
More everyday workflows now available in XO 6
XO 6 continues to close the remaining feature gap with XO 5 by bringing more frequently used administration tasks directly into the new interface.
This release introduces:
- VM duplication
- VM export
- Creating a VM directly from the Host view
- Adding a VIF from the VM Network tab
- HA restart priority during VM creation
- New actions in the Tree View
- Better Traffic Rules filtering
- Improved task names through object resolution
- Estimated per-VM power consumption based on host IPMI metrics
Rather than introducing a single headline feature, these improvements remove many of the small reasons administrators still occasionally switched back to XO 5.
Highlights
A few of these improvements deserve a special mention.
Duplicate a VM
VM duplication is now available directly from XO 6. Whether you're preparing a risky upgrade, creating a test environment or replicating a manually configured appliance, you can now duplicate virtual machines without switching interfaces.
Create a VM directly from the Host view
Creating a virtual machine from a Host page now automatically selects the current host, reducing unnecessary navigation and making repetitive provisioning workflows smoother.
Estimated per-VM power consumption
Xen Orchestra can now estimate the power consumption of individual virtual machines using host IPMI power measurements combined with CPU utilisation. While not intended for billing, this provides a useful approximation when identifying the workloads that consume the most energy.
🔭 XO Lite
XO Lite is designed for homelabs, small infrastructures and environments where deploying a full Xen Orchestra appliance would simply be unnecessary.
More capabilities for lightweight infrastructure management
With every release, we're carefully expanding its capabilities while keeping the interface lightweight and focused on the most common administration tasks.
This release introduces several improvements, including:
- connecting or disconnecting a VIF directly from the VM's Network view;
- new Storage Repository management actions (connect, disconnect and delete);
- additional copy helpers for IP addresses, bonded interfaces and network information.
These additions make XO Lite even more practical for day-to-day administration, while preserving the simplicity that makes it a great fit for smaller deployments.
📡 REST API
Xen Orchestra keeps becoming more automatable.
Whether you're building your own self-service portal, integrating Xen Orchestra into an existing platform or simply automating repetitive administrative tasks, the REST API has become an essential part of the product.
This release continues expanding its capabilities with several new endpoints covering host management, storage and backup operations.
More control over hosts
Host management receives a significant expansion in this release.
Eight new Host actions are now available through the REST API, bringing it closer to feature parity with the Xen Orchestra interface and making infrastructure automation even easier.
Maintenance mode has also evolved. Hosts will now remain in Maintenance mode across reboots, making hardware interventions and planned maintenance operations much safer.
Better backup repository management
Backup repositories can now be validated directly through the REST API.
Two new endpoints allow applications to verify repository connectivity before saving a configuration and benchmark repository performance when investigating backup throughput.
These endpoints are particularly useful for custom portals, automation workflows and health checks, allowing problems to be detected before scheduled backups start.
More API parity
The REST API also continues closing the gap with the Xen Orchestra interface.
This release introduces support for updating Virtual Disks through a new PATCH endpoint, while Storage Repository probe endpoints provide additional tooling for storage-related integrations.
As always, complete endpoint documentation is available in the REST API reference.
🌐 SDN Controller
SDN Controller covers new capabilities that simplify network policy management and day-to-day SDN operations.
PATCH support for Traffic Rules
The SDN Controller now supports updating Traffic Rules through PATCH endpoints at both the VIF and Network levels.
Until now, modifying a rule required deleting and recreating it. With in-place updates now available, automating network policies becomes significantly simpler for configuration management and provisioning workflows.
This improvement originated directly from community feedback on the XCP-ng forum.
☸️ DevOps Tools
This month, we're making it easier to automate existing infrastructures, integrate with Kubernetes and build against Xen Orchestra through continued improvements across our DevOps tooling.
Terraform Provider Xen Orchestra v0.40.0
Importing existing Xen Orchestra VMs into Terraform is now supported, making it much easier to adopt Infrastructure as Code on existing environments without recreating resources.
While some import drift still exists, work is already underway to further improve the experience.
Kubernetes Cloud Controller Manager v1.1.1
This maintenance release includes Helm chart improvements, deployment manifest updates and dependency upgrades. If you deploy the Cloud Controller Manager through Helm, we recommend updating to this version.
Golang SDK v1.18.0
Two releases landed since we last covered this one. v1.17.0 added the network service to the v2 client, so you can create, get and delete networks directly from it, and fixed the template value in the VM struct params so the template ID can be read directly rather than worked around at the call site. v1.18.0 followed with a smaller change: the v2 client's HTTP timeout is now configurable.
Vates provider for the Kubernetes Cluster API keeps evolving
Two new tags landed this cycle, v0.2.0-alpha1 and v0.2.0-alpha2, alongside a new templates/ directory covering ClusterClass definitions, machine templates and Packer image builds, plus more documentation. It is not production-ready, but it is already in the hands of customers and partners who are evaluating it, testing it, and sending back questions and feedback, so this is being co-built alongside the people who will actually run it.
If you are looking at Kubernetes cluster lifecycle management on top of XCP-ng and Xen Orchestra, reach out. We want a close, fast line between your DevOps team and the people building this.
vatesfr
🆕 Misc
This month's misc updates focus on reliability and operational polish, making everyday administration more predictable, resilient and easier to troubleshoot.
Automatic Pool Master tracking
When a Pool Master changes, Xen Orchestra now automatically follows the new master instead of temporarily losing the pool connection. This removes one of the last manual recovery steps administrators occasionally encountered during maintenance operations.
Rolling Pool Update becomes more traceable, safer and resilient
Rolling Pool Update is one of Xen Orchestra's flagship features, allowing administrators to update an entire pool with minimal disruption. Because these operations are typically performed unattended on production infrastructure, reliability is just as important as new capabilities.
This release delivers a broad set of improvements focused on making Rolling Pool Updates more resilient, more predictable and easier to troubleshoot.
Better observability and recovery
Rolling Pool Update (and Rolling Pool Reboot) now keeps a persistent execution trace on disk. If xo-server restarts during the operation, administrators and our Support team can easily determine which step was interrupted instead of losing the operation's history.
To further improve safety, Xen Orchestra also prevents multiple Rolling Pool Updates from running simultaneously on the same pool.
Connection handling has also been improved. Following a temporary loss of connectivity, such as when the Pool Master reboots during an update, Xen Orchestra now reconnects automatically instead of requiring manual intervention.
Safer maintenance operations
Several changes reduce the chances of an update failing halfway through maintenance.
Before evacuating a host, Xen Orchestra now performs one final validation using the current state of the pool. If something has changed since the operation started, the update stops immediately with a meaningful XAPI error instead of failing later during the evacuation.
Rolling Pool Update now also temporarily disables Pool Auto Power-On and restores the original configuration once maintenance is complete. This prevents virtual machines from unexpectedly restarting during maintenance and consuming resources needed by subsequent evacuations.
Finally, workloads using PCI passthrough, SR-IOV or vGPU no longer prevent Rolling Pool Updates from running. After confirmation, Xen Orchestra gracefully shuts these VMs down before rebooting their host, then automatically powers them back on afterwards (requires Guest Tools).
Improved production resilience
Several additional improvements make Rolling Pool Updates behave more predictably on production infrastructures.
If the Load Balancer plugin is enabled, it now remains suspended until a configurable safety delay has elapsed after maintenance, giving the infrastructure time to stabilize before workload rebalancing begins.
LINSTOR environments also benefit from several improvements, including automatic retries when update plugins are temporarily busy and more accurate package installation progress reporting.
Finally, compatibility with older XAPI versions has been improved by eliminating misleading warnings when Xen Orchestra transparently falls back to a compatible host evacuation method.