* feat(xo-server-openmetrics): estimate per-VM power consumption from CPU
usage
* refactor(xo-server-openmetrics): move hostPowerWatts undefined guard to
caller
* fix(xo-server-openmetrics): log IPMI power read failure as info
* 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
* fix(fs): compute the output stream precisely when encrypted
the current encryption add 12 byte of initialization vector at
the start + 16 bytes of authentication tag at the end
thus, the destination stream can be bigger than the source stream,
and this length is used to compute the optimal chunk size for s3/
azure
from https://xcp-ng.org/forum/topic/12328/error-mirroring-full-backups-to-backblaze-b2
---------
Co-authored-by: Pierre Brunet <pierre.brunet@vates.tech>
* docs(xo): overhaul navbar to create a unified doc ecosystem
- Clean up the navbar by dropping the redundant GitHub link (retained in footer).
- Relocate "Blog" to the "What's new in XO 6" sidebar.
- Introduce direct navbar links for XCP-ng and Vates VMS.
- Rename "Documentation" to "Xen Orchestra".
This aligns the navigation layout across our three documentation sites, allowing readers to smoothly transition between ecosystems with a fully unified experience.
Signed-off-by: Thomas Moraine <thomas.moraine@vates.tech>
* docs(xo): move home link from header to footer
To make the navbar cleaner and make space
for the links to the other documentation websites
We're moving the Home link from the header to the footer
and renaming the link to 'About Xen Orchestra'.
Also, we're displaying the 'What's new in XO 6' section again
which now contains a link to the XO blog
Signed-off-by: Thomas Moraine <thomas.moraine@vates.tech>
Recently we've introduced new sections for the xo6 category of the XO doc.
These categories were meant to be filled later with new pages.
The pages were created as placeholders, but didn't actually contain any text, just titles.
These made readers confused, so this commit
Hides the sections from the sidebar until we update them
With actual content.
Signed-off-by: Thomas Moraine <thomas.moraine@vates.tech>
Introduced by #9765
When a backup merge fails on a VHD file, the footer might be missing. This caused a footer1 !== footer2 error and triggered a full backup while not deleting the previous chain and resulted in all further backup jobs to be displayed as failures even though the new backup chain was working properly.
The fix allows the cleanVm to resume the merge where it stops even if the VHD file footer is missing.
