* feat(xo-server,rest-api,xo-web/rpu): force-close an incomplete rolling pool update record
A pool whose previous rolling pool update left a recovery record refuses a
new run until that record is dealt with. Once the operator has reviewed the
pool, `pool.finalizeRollingUpdate` and
`POST /rest/v0/pools/{id}/actions/finalize_rolling_update` close it.
Without `force`, the finalization is refused (`incorrectState`, property
`unrestoredItems`) while the record says the run changed something the pool
still shows changed: HA, auto power-on, WLB, load balancer, backup
schedules, hosts left disabled, running VMs away from their home host,
pinned VMs shut down and not started again. A record that cannot be read
is refused too, with an unknown list.
With `force`, the record is deleted, the abandoned items are written to the
task and the trace, nothing is restored nor changed in the pool.
To tell what the run changed from what the operator did, the run now
persists, before each change, the settings it touches (strict write) and
whether each host was enabled before the run.
XO 5 shows a "Finalize" action on the incomplete update banner, which is
now also shown for a run that succeeded but whose record could not be
removed. Forcing asks for a second confirmation listing the items.
This commit removes the local `SECURITY.md` file from the Xen Orchestra repository.
The new global Vates security policy is now in place, so the local file
is no longer needed and should be replaced by the central policy:
https://github.com/vatesfr/.github/blob/main/SECURITY.md
This ensures consistent security reporting guidelines across Vates projects.
Signed-off-by: Thomas Moraine <thomas.moraine@vates.tech>
following the backend PR this PR implement the xo5 ui to use live mount for restoring a VM .
the popup is enlarged to ensure there is enough space
it fixes a ui feature where removing a VDI make it unrestorable without closing and reopening
A disk row is complete when its action has the destination it needs: Live mount → a host, Restore → its own SR or the main SR, Do not restore → nothing.
An incomplete row shows a red message under its selector, and since the rows sit in a collapsed panel, a red "Some disks have no destination yet" line is also shown outside it.
The restore SR selector's placeholder now reads "Use main SR" once a main SR is set, so an empty field reads as a deliberate fallback rather than an oversight.
For live moiunt the picker is prefilled with the host that can use the SR
* fix(@xen-orchestra/mcp): use undici fetch to fix Node 26 dispatcher crash
Node's global fetch is backed by Node's bundled undici and rejects a
dispatcher from the npm undici dependency with UND_ERR_INVALID_ARG on
some Node versions (e.g. Node 26), surfacing as "fetch failed". The MCP
passed an EnvHttpProxyAgent dispatcher to the global fetch, so it crashed
at startup.
Route every request through undici's own fetch (proxyFetch) so the
dispatcher and the fetch come from the same undici copy. Add a FetchFn
injection point so unit tests can mock the fetch instead of globalThis.fetch.
Fixes#10411
* feat(backups): implement backend for live mounting disk
when restoring a VM, the vdi to SR map is extended to support a
'live-mount' mode , additionaly to the now explicit 'restore'
and 'ignore' mode
live-mount will need the host. no check is done on backend to
ensure if the VM is bootable
add e2e test
implementation of an iscsi target and initiator in typescript
this will serve as a basis of 2 projects:
connecting directly to 3rd party san
exposing a disk from a backup archive to the host, effectively enabling direct mount to a running VM. Final target is to be able to boot completely the VM
@vates/iscsi/VALIDATION.md file is a journal of the additional test I run on my lab
@vates/iscsi/PROTOCOL.md describe the subset of the protocol implemented . For example we only support 1 LUN per target, not multiple connection , only one type of auth and keep alive
* feat(xo-server,rest-api,xo-web/rpu): safe start on a partially updated pool
A rolling pool update used to overwrite the recovery record left by the
previous run and to look only at the master to decide whether there was
anything to update. Both hid a pool left half updated: an interrupted run,
or updates applied by hand, could be silently completed or forgotten.
- `startRpuRecoveryRun` now refuses a new run while the pool still has a
record, whatever its status, with an `incorrectState` error (property
`rollingUpdateRecovery`). The RPU guard held by the caller makes the
check-then-write safe. A run which fails before any host was handled
drops its record instead of marking it failed: the orchestrator restores
what it changed on its way out, and a refused precondition (a guidance to
accept, a pinned VM to shut down) must not block the retry the operator
just consented to.
- The update refuses a pool whose master is already up to date while
another host is not (`incorrectState`, property `partiallyUpdatedPool`,
`actual` listing the outdated hosts) unless the new
`acceptCurrentStateAsBaseline` option is set. The option is exposed on
`pool.rollingUpdate` and on `POST /rest/v0/pools/{id}/actions/rolling_update`.
- XO5 enables the rolling pool update button as soon as any host of the
pool has missing patches, not only the master, disables it while a
recovery record exists, and asks for confirmation before accepting the
current state as the baseline.
Until the force-close operation ships, a leftover record can only be
removed by hand: it must land in the same release.
* feat(xo-server,rest-api,xo-web/rpu): changelog entry for #10394
* fix(xo-server/rpu): getRollingUpdateRecovery returns null on no record
* fix(xo-server/rpu): persist acceptCurrentStateAsBaseline, mark record succeeded on delete failure
* fix(xo-server/rpu): drop an empty record after the pool is restored, update LINSTOR only past the guards
listReplicatedVms() stopped excluding snapshots in c1e9b83 (#9524) so that new-style replication, where each transfer is a snapshot of the target VM, would be covered. But a backup snapshot of the source VM matches the very same filter: it carries xo:backup:schedule and xo:backup:vm, and setVmOtherConfig passes srUuid = null, which removes xo:backup:sr and therefore matches the srUuid = undefined argument of the "delete previous interrupted copies" sweep in FullXapiWriter._run.
A full backup job replicating to an SR of the source pool thus destroyed both the rolling snapshot retained from the previous run and the one it had just taken, silently: the sweep is fire-and-forget under ignoreErrors, and XAPI holds the destroy of the snapshot being exported until the transfer ends instead of refusing it.
A replication snapshot is a snapshot of a replica, so a snapshot of the VM designated by xo:backup:vm can never be one.
XO-2994
Customer reported that after a failed replication transfer, the next run was a full and a VM was left orphaned on the target.
This is due to _removeUnusedSnapshots() protecting the last snapshot irrelevant of if it was successfully transferred and thus, in the case of a failed transfer, breaking the delta chain
Document which Xen Orchestra versions receive security fixes
in the actual XO doc, not just in SECURITY.md.
Signed-off-by: Thomas Moraine <thomas.moraine@vates.tech>
Faster (25 GiB test VM: the map goes from 2.5s to 50ms) and fewer moving
parts: the vddk map needs nbdkit, the vddk library and nbdinfo, all
version-coupled, where CBT is a handful of documented calls every backup
product has relied on for years.
Checked on ESXi 8.0.1 that enabling CBT on a disk which already holds data
backfills the tracking file, so the first query reports what was already
written and not only what is written afterwards. Against `nbdinfo --map` the
two maps differ by 960 KiB which reads back as zeros: CBT reports the blocks
that were written where the vddk reports the ones VMFS allocated.
CBT must be enabled before the migration, it cannot usefully be turned on
during the run:
- powered off VM: nothing else to do, the reconfigure writes the tracking
file and the query answers straight away
- running VM: the query needs a snapshot, and tracking only starts at the
next stun (snapshot create/delete, power cycle, vMotion)
