Olivier Lambert b078d3d42d feat(xen-api): reconnect to a surviving pool member when the master is unreachable (#10016)
* 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
2026-07-15 11:04:16 +02:00
2025-07-23 11:50:46 +02:00
2025-02-18 16:45:23 +01:00
2023-08-03 17:56:24 +02:00
2023-09-21 10:28:31 +02:00
2022-03-02 17:49:53 +01:00
2023-04-05 11:22:10 +02:00
2026-07-09 16:50:11 +02:00
2023-09-21 10:28:31 +02:00
2023-09-26 14:34:47 +02:00
2026-06-17 10:02:00 +02:00
2024-06-14 11:43:38 +02:00
2026-06-17 10:02:00 +02:00

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:

Translation status

Help us translate Xen Orchestra in more languages!

📸 Screenshots

License

AGPL3 © Vates

Description
The global orchestration solution to manage and backup XCP-ng and XenServer.
Readme 189 MiB
Languages
JavaScript 61.2%
TypeScript 22.6%
Vue 14.8%
CSS 0.5%
SCSS 0.3%
Other 0.4%