* feat(lite): add searchbar in the treeview
* improve open close treeview, and a pool dashboard that displays a scrollbar when the screen is minimized
* add changelog and improvement
* feedback
* feedback
* review feedback
* feedback add story
GitHub filters a push on the diff with the previous push of the branch: after
a rebase on `master`, or a merge of it, this diff contains the vectura changes
landed on `master` meanwhile, and the workflow rebuilds vectura on branches
which do not touch it.
A pull request is filtered on the diff with its merge base instead, i.e. the
changes of the branch only. Pushes still run the workflow on `master`.
The review process was documented both here and in the internal PR process
doc, and the two had drifted apart. Keep the internal doc as the single
source of truth and only give external contributors what they need.
`AggregatedIncrementalXapiWriter.checkBaseVdis()` didn't forward
`contentKeys` to its sub-writers, so the second run of a multi-SR
replication failed with `Cannot read properties of undefined (reading 'get')`.
Also adds QA tests for distributed replication and copyRetention.
Introduced by 680b81088
XOA appliances still run Debian 11, whose glibc is 2.31. The vectura binary
bundled with @xen-orchestra/vmware-explorer was linked against glibc 2.34,
so it did not start there (`GLIBC_2.32 not found`): the prerequisite check
of the VMware import page failed and V2V imports could not run.
zig now links it against glibc 2.31. Below 2.34, libpthread and libdl are
libraries of their own, so check-binary.sh allows them. The bundled binary
is rebuilt with the same version, and the docs say Debian 11 and Ubuntu
20.04 instead of Debian 12 and Ubuntu 22.04.
Introduced by dc57333f5
The 6.9.0 entry for the VDDK removal said a vCenter address is no longer
supported. vectura reads the disks through a vCenter as well as directly
from an ESXi host; only ESXi 6.x is refused, because its data port does not
announce "SHA256 supported".
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
* fix(backups): actually delete interrupted replication transfers on next run
IncrementalXapiWriter#_prepare's "delete previous interrupted copies" cleanup
was dead code: `vm => vm.$destroy` never called the method, and it filtered
with `srUuid: undefined`, which can never match since every replica has had
REPLICATED_TO_SR_UUID set since c610951450. So a transfer interrupted mid-way
(process crash, killed job, ...) left its VM/VDI on the target SR forever,
still carrying decorateVmMetadata's DATETIME epoch sentinel.
Fix the filter to use the real srUuid and match only entries still carrying
that sentinel, then actually call $destroy(). Exclude this._targetVmRef: when
checkBaseVdis (which runs earlier) already validated the same VM as reusable
for this run, it must survive to be chained onto, not be destroyed under it.
