mirror of
https://github.com/vatesfr/xen-orchestra.git
synced 2026-09-10 22:14:48 -05:00
b078d3d42dcd6e59bbdaa24207c4d45aa73b7f1a
* feat(xen-api): reconnect to a surviving pool member when the master is unreachable XO follows a pool master change only through HOST_IS_SLAVE redirection, which needs the contacted host to be up and answering. That covers a graceful master hand-over (the old master stays up as a slave and redirects us), but not the case where the master host itself becomes unreachable while another host takes over as master: HA automatic failover, or a manual emergency transition. The stored URL then points at a host that no longer responds, login fails with a transport error instead of HOST_IS_SLAVE, the existing retry never redirects, and the connection stays stuck on the dead master. Maintain a set of pool-member addresses (seeded from the configured target and optional opts.candidateHostnames, refreshed from host.get_all_records on every session open) and, when the current target is unreachable at the transport level, probe the other members in parallel. The first to answer wins; if it is a slave, its login redirects us to the current master through the existing HOST_IS_SLAVE retry. XapiError responses (including auth failures) are not failed over, so wrong credentials still fail fast. * feat(xo-server): persist pool-member addresses so master failover survives a restart The xen-api failover relies on an in-memory set of pool-member addresses, which is lost when xo-server restarts: it then only knows the configured host. That is exactly the address that is dead when XO runs on the very pool whose master just failed and was HA-restarted onto a survivor, leaving XO unable to reconnect. Persist the member addresses on the server record (Redis, JSON-encoded like the existing error field), refresh them whenever the pool object is seen via the xen-api candidateHostnames getter, and feed them back as opts.candidateHostnames when (re)building the connection. After a restart the connection can then probe the surviving members and reconnect to the new master. * chore(changelog): reconnect to a surviving pool member on master failure Add the user-facing changelog entry and list xen-api in the packages to release for the master-failover reconnect feature. * fix(xen-api): prune ejected hosts from pool-member failover candidates host.get_all_records is authoritative current membership, so replace the candidate set on refresh instead of unioning into it. An ejected host is typically still alive as its own standalone master with the same credentials, so leaving it in the set could make a failover probe silently connect to the wrong pool. The currently-connected target is preserved since host.address may differ from the address XO used to reach it. * fix(xen-api): harden surviving-member failover per review - reject failover probes on sessionId-based connections (no reusable credentials to open a session on another host) - bracket bare IPv6 addresses (host.address / HOST_IS_SLAVE) before using them as URL hostnames - log the probe session out even when the host answers after the probe timeout, to avoid leaking a session - abort the mid-session failover loop when the connection was torn down or replaced while waiting (e.g. user disconnected the server) - xo-server: drop persisted pool-member addresses when the connection identity (host/credentials) changes, so a stale slave list can't send a failover to the wrong pool See #10016
Xen Orchestra
Manage, Backup and Cloudify your XCP-ng/XenServer infrastructure
XO (Xen Orchestra) is a complete solution to visualize, manage, backup and delegate your XCP-ng (or XenServer) infrastructure. No agent is required for it to work.
It provides a web UI, a CLI and a REST API, while also getting a Terraform provider among other connectors/plugins.
⚡️ Quick start
Log in to your account and use the deploy form available from the Vates website.
📚 Documentation
The official documentation is available at https://docs.xen-orchestra.com/
Documentation updates are deployed automatically once per day.
🚀 Features
- Centralized interface: one Xen Orchestra to rule your entire infrastructure, even across datacenters at various locations
- Administration and management: VM creation, management, migration, metrics and statistics, XO proxies for remote sites… XO will become your best friend!
- Backup & Disaster Recovery: The backup is an essential component for the security of your infrastructure. With Xen Orchestra, select the backup mode that suits you best and protect your VMs and your business. Rolling snapshot, Full backup & replication, incremental backup & replication, mirror backup, S3 support among many other possibilities!
- Cloud Enabler: Xen Orchestra is your cloud initiator for XCP-ng (and XenServer). Group management, resource delegation and easy group administration. The Cloud is yours!
🌍 Translations
Status of XO Lite & XO 6:
Help us translate Xen Orchestra in more languages!
📸 Screenshots
License
AGPL3 © Vates
Description
Languages
JavaScript
61.2%
TypeScript
22.6%
Vue
14.8%
CSS
0.5%
SCSS
0.3%
Other
0.4%


