The cache now announces what a listing finds and what a journal replay
changes, as `add`, `update` and `remove` events carrying the archive and its
previous value, on an emitter the app exposes as `app.vmBackupArchives`. What
was last announced for a repository outlives its entry, so a repository read
again from scratch only announces what really changed. A repository which is
removed or disabled goes through the new `forgetVmBackupRepository()`, which
announces all its archives as removed. A listener which throws is logged and no
longer fails the listing.
The REST API adds `backup-archive` to the SSE collections. It is bound to
`app.vmBackupArchives` the way `task` is, and filtered by `backup-archive:read`
through the same path as every other non-XAPI collection.
Nothing polls the repositories: changes are pushed whenever any client lists a
repository. The first listing after a restart sends every archive it already
holds as `add`.
XO-2992
XO-2993
only open the specific route from source to xo / xo-proxy
port openned only live in memory : restarting ufw will drop them, thus making all the live-mount disk unavailable
doc updated
the live mount feature create a lot of SR , each with 1 disk
this PR introduce an automatic cleanup that will forget a SR as soon as the disk is removed, thus removing any user action needed to cleanup thins in the nominal case
crashing XO can leave SR pluggued
Phase 4 of the journal-replayed VM backups cache: brings proxy-attached repositories onto the same fast/fresh listing path as directly-attached ones, so a proxy repository is also listed once and then kept up to date by replaying its journal, instead of being re-listed in full on every refresh window.
What changes
RemoteAdapter#readBackupJournalEvents() reduces a journal read to the last event of each backup and resolves the added/changed ones back to their current metadata, so a listing can be brought up to date from a single call. A backup rewritten several times costs one metadata read; one written then deleted costs none.
VmBackupsCache no longer knows how a repository is read: that now lives entirely behind a new VmBackupsSource, which reads a directly-attached repository through the local adapter and a proxy-attached one through backup.listVmBackups (cold build, reused as-is) and the new backup.listVmBackupsJournal RPC (journal replay).
The proxy exposes backup.listVmBackupsJournal, returning its journal events with the backups already formatted, so XO gets a listing update in one round-trip instead of one metadata read per file. A proxy too old to know the method is warned about once and falls back to a full listing, same as before this change; it starts being replayed as soon as it's upgraded, with no restart needed on the XO side.
The cache's staleness check now compares its own clock only against when this process last refreshed an entry (refreshedAt), never against the watermark returned by a journal read (cursor), which is stamped by whichever process wrote it — proxy or not. Comparing the two directly would silently over- or under-refresh a repository depending on clock skew.
An entry also rebuilds from scratch if its repository moves to or from a proxy, or if the source reports it can no longer be replayed (e.g. an old proxy), rather than being purged outright.
The old proxy-only listing path in BackupNg (_listVmBackupsOnProxy, bypassing the cache) is removed: proxy and local repositories now go through the exact same cache.
A single corrupt/unreadable metadata no longer fails a whole journal read; it's kept behind the watermark so only that entry is retried on the next call instead of the caller falling back to listing the whole repository until the file is fixed.
The backup repository cache is now also invalidated on remote update/delete (previously only handled for backup repositories proper).
No behavior change for directly-attached repositories — this phase only extends the existing cache to proxy-attached ones.
XO-2852
* 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.
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
