The `backup-archive` SSE collection (#10472) only announced a change when a client listed the
repository: XO never read one on its own, so a subscriber learnt of a backup created, merged or
deleted at the next listing by any client, and after a restart heard nothing from a repository
until a client listed it.
XO now reads the repositories itself:
- every enabled repository is listed once XO has started, one after another, and a repository
enabled later as soon as `updateRemote()` has stored it;
- the changes this XO makes are pushed at once, for a repository whose journal can be replayed: at
the end of each VM export to it (worker, no-worker mode and proxy alike), at the end of the job
and after a deletion. A read in progress when `refresh()` is called reads again, since it may
have missed the change, at most 3 times and never when that means listing the repository in full;
- the other changes (the size the merge worker rewrites, another XO sharing the repository) are
read by two timers, 2 repositories at a time and through the listing backoff: every minute from
the journal, every 10 minutes by a full listing for a repository whose journal cannot be read,
e.g. behind a proxy which does not expose it;
- a repository is listed in full again an hour after its entry was built, rather than when it
crosses a UTC day, which bounds the drift from what the journal does not record. The
`fullListingInterval` parameter of its URL sets this delay, in whole minutes; the XO 6 and XO 5
repository forms now keep it when the repository is edited.
The archives are registered through `registerCollection` like any other collection, which drops
the REST API special case for them. Their events now carry an array of archives (`add`, `update`)
or of ids (`remove`); SSE subscribers still receive one event per archive.
* feat(fs, backups): don't concatenate buffers but write them directly
maximum throughput with a perfect source and no write goes from
4.5 to 9.6GB/s
* fix: remove Buffer concat in qcow2 stream generationonly needed for last block
* feat(nbd-client): support nbd insecure networks
* feat(xo-web): support insecure nbd
also add a confirm on insecure enabling
The dialog is titled "Enable insecure NBD?" and says: "The disk data of the backups will travel unencrypted on this network. Only enable it on a network dedicated to backups and isolated from the VMs and the users (dedicated VLAN or physical network)." Both texts are new entries in messages.js, and the dialog itself is a new confirmInsecureNbd() helper in xo/index.js.
It appears in two places:
Pool Network tab (tab-network.js):
The dialog only appears when switching a network to insecure NBD. Reselecting it on a network that already has it, or switching to "NBD" or "No NBD", doesn't ask.
On cancel, nothing is sent and the drop-down keeps showing the network's current setting.
Network creation form (new/network/index.js):
The dialog appears on "Create" when insecure NBD is selected (bonded and private networks are never affected).
On cancel, the network isn't created and the form stays as is, with no error and no redirect.
* feat: update xo5,xo6 and lite ui for this settings
---------
Co-authored-by: MlssFrncJrg <119158464+MelissaFrncJrg@users.noreply.github.com>
Objects listeners are added to Xapi objects by the sdn-controller plugin, but
they are only removed at plugin `unload()` time.
Prefer to remove them at Xapi disconnect time.
When a pool's XAPI connection drops and reconnects, xo-server destroys the
old Xapi instance and creates a new one (same pool UUID, same XAPI object
$refs). The plugin tracked managed pools by pool UUID, so _manageXapi()
short-circuited on reconnect and never attached its add/update/remove
listeners to the new Xapi instance.
From then on the plugin was blind to XAPI events: re-applying VIF traffic
rules on VM start, handling VIF/PIF plug and star-center election all
stopped silently until the plugin was reloaded.
Track the managed Xapi instances instead of pool UUIDs, and drop a dead
instance on disconnect so its replacement is managed again.
When a XAPI connection drops and reconnects, xo-server creates a new
Xapi instance while the XAPI objects (and their $refs) are kept. The
ofChannels cache still held the controllers of the previous
connection, so traffic rule add/delete calls were silently skipped
without reaching the host.
Rework _getOrCreateOfChannel() to key the cache on the Xapi instance:
entries from a previous connection are dropped and the controller is
recreated, concurrent calls share the same instantiation, and a
failed instantiation clears the cache.
Also drop the cached controller when the host is disabled or its XAPI
is not connected, so it is recreated as soon as it comes back.
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
