When privateNetwork.addNetwork() fails during xapi connection, the network is
already inserted in privateNetwork.networks and a center may have been set
without being recorded in _starCenters, leaving a broken PrivateNetwork
registered.
After the registration loop, remove the network that failed to register, drop
the orphaned center, and delete the PrivateNetwork once it has no network left,
like _handleDisconnectedXapi already does.
Also defer pushing to noVniNetworks until the network is registered, so a failed
network gets no VNI and does not trigger _electNewCenter outside of any
try/catch.
Wrap the entire per-network registration body (after the privateNetwork creation
check) in a try/catch so one network's failure doesn't affect others.
Reorder `xo:sdn-controller:vni` to after `privateNetwork.addNetwork()` call to
manage more easily the undo.
The value stored for preferred-center could be wrong or out-of-date. If no XAPI
object exists with such uuid (the host designed as preferred center was
removed from XAPI), avoid to hard fail, and consider the value is absent.
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(xo6): add actions on BRs
* change monitorTask
* actions jobs ok
* fix monitorTask and add actions buttons on detail and side panel
* action bar wip
* table actions change state ok
* multi test speed ok
* add type to confirm modal
* forget ok and create new component bulk
* fix tests
* refacto for PR
* refacto for PR
* refacto for PR ok
* refacto for merge
* add and update tests
* last refacto
Introduced by #8491
See #10201 (same workaround)
`VM.set_VCPUs_at_startup` ran concurrently and re-added `cores-per-socket`
between its removal and its re-addition, making the VM creation fail.
The deploy form now offers Small (2 vCPUs, 4 GiB), Medium (4 vCPUs,
8 GiB) and Large (8 vCPUs, 16 GiB, default) presets. Update the sizing
table to match, and drop the manual --max-old-space-size procedure:
since 6.8, xo-server sets its heap limit to 70% of the VM RAM.
Signed-off-by: Olivier Lambert <olivier.lambert@vates.tech>
* fix(@vates/iscsi): only replace the session once the newcomer has logged in
A new TCP connection used to tear down the active session as soon as it
was accepted, before sending anything. Any peer able to reach the port,
a port scan, a failed CHAP login or a Discovery session, interrupted the
disk in use.
New connections are now kept aside until they establish a Normal session
(CHAP included when configured), and only then replace the active one.
That keeps the ability to recover from a stale connection, which is why
connections are replaced rather than refused.
Connections without a session are bounded in time (`loginTimeoutMs`,
15 s by default, also closing lingering Discovery sessions) and in number
(`maxPendingConnections`, 8 by default, oldest dropped first).
* chore: add PR number to changelog
* fix(@vates/iscsi): refuse extra connections and guard the login race
Review follow-up:
- let net.Server refuse connections past maxPendingConnections (+1 for
the one serving the LUN) instead of evicting the oldest pending one
- a connection destroyed while its final Login Response is being written
must not go on and replace the current session
* feat(@vates/iscsi): bound what a peer can make the target do
- allowedAddresses: close connections from other initiators as soon as
they are accepted, so that they cannot take the pending connection
slots and block a legitimate login
- reject a PDU whose data segment exceeds 8 KiB during login, or the
declared MaxRecvDataSegmentLength afterwards, before reading it
- maxTransferLength (8 MiB by default): advertised in the block limits VPD
page, longer READ/WRITE refused, which also bounds the WRITE buffer
- BlockDevice.readOnly: report the LUN write-protected and refuse WRITE
with DATA PROTECT before soliciting any data; DiskBlockDevice sets it
* chore: add PR number to changelog
* feat(@vates/iscsi): rename allowedInitiatorAddresses, report refused connections
`allowedAddresses` did not tell whose addresses: these are the source
addresses of the initiators. `onConnectionRefused` reports each refused
one, e.g. so that a caller can tell that an initiator connects through a
NAT.
---------
Co-authored-by: Florent BEAUCHAMP <florent.beauchamp@vates.tech>
The CHAP interop test failed on CI with ENXIO on /dev/sdb (master 641f98878,
and #10549), right after waitForDevice() returned the disk.
waitForDevice() took a nonzero /sys/class/block/<name>/size as proof the disk
was ready, but the sd driver sets the size before device_add_disk(), which
creates the sysfs entry, then the /dev node, then registers the block device:
open() fails with ENOENT or ENXIO until then. Polling sysfs in a tight loop
after login hit that window in 15 of 100 logins.
isDeviceReady() now opens the device, and treats ENXIO and ENOENT as not ready
yet.
* 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>
* feat(xo6): add edit form BR
* type disable
* wip
* fix post rebase
* form initial data ok
* form ok
* add tests dans finalize edit
* refacto for PR
* refacto for RP
* rebase ok
* feedback
* PR ok
* add changelog
cargo deny fails on master since RUSTSEC-2026-0346, 0347, 0348 and 0349
were published against rustls 0.23.45. 0.23.46 fixes all four.
vectura has no custom session store, no ECH and no brotli feature, so
only 0349 (later connections downgraded to classical key exchange through
the resumption cache) applies, in theory.
vectura 0.1.3, bumped and rebuilt with scripts/release.sh patch.
The binary in git is now the build of its sources. build.sh keeps the paths
of the machine out of the binary and refuses another zig or cargo-zigbuild
version, and the Vectura workflow fails when its build differs from the
committed binary. The binary is rebuilt with this build.sh: only its paths
change, the version stays 0.1.2.
vectura is no longer released on its own. release.sh runs once at the end of
the pull request which changes vectura and no longer commits. bump-pkg,
gen-deps-list.js and check-changed-pkgs.js drop the vectura pseudo-package: a
change under vectura/ requires a release of @xen-orchestra/vmware-explorer,
which ships the committed binary as is. release.sh puts Cargo.toml and
Cargo.lock back when the build or the check of the binary fails.
* feat(vmware-explorer): implement attaching and detaching disks
* feat(vmware-explorer): implement a check to see if a disk can be attached to a VM
* feat(vmware-explorer): implement a method to detect what host are candidates to deploy a satellite
* refactor: computing the datastore of a datapath
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.
When overriding the pool master with `?master=<host>`, XO Lite kept the page's
protocol and port and only swapped the hostname (e.g. `https://proxy:8443` +
`?master=192.168.1.10` → `https://192.168.1.10:8443`). Requests sent directly to
hosts also always used the page's protocol, regardless of the master's.
Everything now follows the XAPI connection (one commit each):
1. **Master override** (`xen-api.store.ts`): the value is parsed as a URL,
`https://` by default, port and protocol allowed. An invalid value falls back
to the default host instead of crashing XO Lite.
2. **RRD stats** (`xen-api.ts`, `getResource`): use the XAPI protocol.
3. **VM and host consoles**: `wss:` if XAPI is `https:`, `ws:` otherwise.
4. **Unreachable hosts check**: pings hosts with the XAPI protocol, so the
certificates modal checks the right URLs.
Introduced by #8317
`VM.set_HVM_boot_params` replaces the whole map, so setting the boot order for a
network install or a VM without disk dropped the firmware set just before, and
the VM booted in BIOS mode.
* feat(web-core,web,lite): add UiPanelCardTitle component
Figma's "Panel title v3" describes three formats — plain text, linked
title, title with an id — which the existing VtsCardObjectTitle only
covered partially, and which several cards had reimplemented inline with
their own flex/gap rules.
Rather than three components, the parts are independent and optional: a
`to` or `href` makes the title a link, an icon or an id is shown when
passed, and `size` replaces Figma's `level`, which described the
appearance in terms of hierarchy.
Adopting it in the side panel cards drops their local title styles, and
brings them back to the 0.8rem title-to-content gap the design system
specifies.
* chore(lite): add the ui-panel-card-title story route
The generated route-map entry was omitted when the story was added.
* fix(web): address review feedback
Task infos and warnings are arrays, so their counters read `length`
directly instead of going through `Object.keys` and a non-null assertion
that only held thanks to the parent's `v-if`.
Add the changelog entries for the side panel card titles.
See XO-2885
* feat(web-core,web,lite): migrate side panel cards to UiPanelCardTitle
Replace the remaining `UiCardTitle` usages in side panel cards with
`UiPanelCardTitle`, so every panel card title shares the same layout.
To cover the cases the old titles handled, `UiPanelCardTitle` gains
`label`, `action` and `more-actions` slots, and tighter spacing between
the title and its id.
See XO-2885
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
* update changelog file
* feedback one
* feat(host): add action reboot on host
* feat(lite): add forget action on host
* feat(host): Add restart toolstack action for hosts with HA disabled
* feat(icon status): Add a power status icon to the treeview and to the host header
* update changelog files
* fix rebase
* feedback
* fix(backups): properly throw an error if a disk is missing from a chain to merge
but accept it if the merge was interrupted at the cleanup phase
* fix(backups): a merge with 0 or 1 disk is a warning
* fix(backups): don't try to merge chain that are out of retention
this fix will allow broken to recover after a while ( depending on
retention and full backup interval )
* fix: defense in depth against deletion
every path this class compares it against is normalized (disk paths, alias targets), so
it must be too: a raw path would e.g. make #cleanOrphanDataFiles fail to exclude the VDI
directory from the data directories it sweeps, and delete every unclaimed file in it
* fix(backups): better handling of missing disks during a merge
* ensure we never delete ancestries of a differential disk
* feat(xo6): create and edit backup repository form
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* fix post rebase
* add tests
* feedback
* feedback
* rebase ok
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* 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.
* 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)
* feat(xo-server,rest-api,xo-web/rpu): persist a recovery record across restarts
A rolling pool update now writes a `rpuRecovery` record (LevelDB, one per
pool) before its first side effect and keeps it updated during the run:
operator options, update variant, host order, initial VM placement, per-host
step statuses, last filtered error, and the pinned VMs shut down for their
host's reboot (previously only tracked in memory, so an xo-server crash left
them halted with nothing to restart them). A record left in a live status at
xo-server boot is flipped to `interrupted`; a successful run deletes its
record; an unreadable or unknown-version record is reported as `blocked`
without touching the stored value.
The status is exposed through `pool.getRollingUpdateRecovery` and
`GET /rest/v0/pools/{id}/rolling_update_recovery` (filtered view: never the
raw intent, reusing the existing pool permissions), and the pool Patches tab
in XO5 shows a warning with per-host progress, the last error and the pinned
VMs still halted.
First card of the RPU resume-after-failure spike: the record only reports
for now, resuming an interrupted run comes separately.
* docs(changelog): entry for the RPU recovery record (#10331)
* fix(xo-server,rest-api,xo-web/rpu): updates after review
* test(xo-server/rpu): cover the recovery record during the migrate back phase
The migrate back phase now retries the rejected migrations before giving
up, so a host is only recorded as failed once the retry passes are over,
and a pool which opted out of the phase must still close its `restoreVms`
steps, otherwise a finished run reads as still running in the record.
Both are asserted through a recorder spying on the step transitions.
* fix(xo-server/rpu): keep per-key reads in the recovery reconciliation
* test(xo-server/rpu): stub the recovery recorder in the rolling pool update tests
Since #10313, XenServers.rollingPoolUpdate runs the backup guard itself and
its tests drive it with a fake app. With the recovery record, the run also
calls app.startRpuRecoveryRun, which the fake app did not have.
The stub records its call, so the tests also check that a refusal from the
backup guard leaves no record behind.
* fix(xo-server/rpu): do not fail a successful run when its record cannot be deleted
* docs(docusaurus.config.ts): fix redirection inconsistencies
A few page redirections were missing, some were duplicates, and some pointed to the wrong URLs.
This commit cleans up redirections, updates the target URLs and adds the missing redirections.
This branch is a reliability overhaul of the ESXi/vSphere source side of V2V, plus a scope reduction of the package. The SOAP plumbing is rewritten:
VimClient wraps @vates/node-vsphere-soap in a promise API with one emitter per call (no more cross-talk between concurrent calls, no listener leak) and a pTimeout;
vim25 faults are now parsed (_parseFault.mjs) so callers get a real fault type instead of task execution failed;
the library no longer throws from async callbacks (which killed xo-server) and its beforeExit logout hook is per-client instead of removeAllListeners.
Request specs are built in explicit schema order (soap/specs.mjs) with xsi:type, and property values are normalized (soap/normalize.mjs) so search() and the new #retrieveProperty share one shape.
search() now paginates, cancels the retrieval and destroys the container view.
Datastore HTTP downloads get session-cookie reuse, retry with jittered backoff, a headers-only timeout, and range-honouring validation.
Task waiting polls with backoff and per-operation timeouts (6 h for snapshot consolidation).
nbdkit servers are memoized by a key that includes the export options, the readiness wait races the process death instead of sleeping 2 s
the password file is 0600 and unlinked
the thumbprint is read over TLS in-process instead of two openssl spawns.
The old VHD-over-datastore readers (VhdEsxi*, Datastore*, openDeltaVmdkAsVhd) are deleted, hence the majo, rleaving the vddk/NBD path with a COWD grain-directory parser as data-map fallback.
~1.7k lines of unit tests are added.
* fix(xo-server,rest-api): apply the backup guard to rolling pool operations started over REST
The JSON-RPC methods pool.rollingUpdate and pool.rollingReboot refused to run
while a backup job targets the pool, but the REST actions
POST /pools/:id/actions/rolling_update and rolling_reboot called the
orchestrators directly and skipped that check.
The guard now lives in XenServers.rollingPoolUpdate and Pools.rollingPoolReboot,
so every entry point (JSON-RPC, REST, scheduled jobs) applies the same rule.
The bypass moves into backupGuard(poolId, { bypassBackupCheck, operation }),
which logs a single warning with the operation and the user, and the other
callers (host.restart, host.restartAgent, host.stop, sr.reclaimSpace and their
REST counterparts) use it instead of their own if/else and log.
The REST rolling actions accept bypassBackupCheck in their body and record the
body in the task params, like the host actions do.
* fix(xo-server,rest-api): pass the targeted object ID to the backup guard
* feat: add setChainToParent in order to point header/footer to a new parent
* feat: add getCompressionType and use it in isMergeableParent in RemoteAdapter
* feat: use openDisposableDisk instead of openVhd
* fixup! feat: add setChainToParent in order to point header/footer to a new parent
* feat: add tests for setChainToParent
* fix: from review
* feat: make isMergeableParent contained in remoteDisk
* fix: remove chainToParent now useless
* feat: remove compressionType and isMergeableParent where unneeded
* feat: update test
* feat: handle compressionType in remoteAdapter and fs
* fix: use remoteHandler as config getter
* feat: remove useless isDirectory in remoteDisk
* fix: small change on mode option
* docs(xo): add page redirections
Since we changed how the sidebar was generated,
many page URLs changed in the process,
but redirections weren't implemented yet.
This broke several links to the documentation.
This commit adds redirections so the links don't result in 404 errors anymore.
Signed-off-by: Thomas Moraine <thomas.moraine@vates.tech>
* docs(xo): update outdated URLs in the XO app
Following the recent overhaul of the documentation URLs, some links in the XO app were still pointing to obsolete pages.
This commit updates them to use the current URLs and prevents 404 errors.
Signed-off-by: Thomas Moraine <thomas.moraine@vates.tech>
* docs(intro.md): update link to V2V migration guide
Signed-off-by: Thomas Moraine <thomas.moraine@vates.tech>
---------
Signed-off-by: Thomas Moraine <thomas.moraine@vates.tech>
Since the XO documentation structure was changed recently,
so did the URLs to each documentation pages.
This broke multiple links in the XO app,
which pointed to the XO doc.
This commit updates the links to the current URLs,
so that the link work as intended.
Signed-off-by: Thomas Moraine <thomas.moraine@vates.tech>
* fix fbeauchamp comments
* feat(backups): add a journal
* fix cache writing on immutable remotes
* add typing
* feat(backups): shard the journal per UTC day, one entry per time
`readBackupJournal()` listed the whole `xo-backup-log/` and filtered the names
client-side, so the cost of a read grew with the whole history of the repository.
Store the entries as `/xo-backup-log/<YYYYMMDD>/<HHMMSS.mmmZ>-<rand>-<event>-<vmUuid>-<file>`
and list only the days which can hold entries newer than `since`: a read now costs one
listing of the journal root plus one listing per day it is missing — normally a single
day, at most two, since a reader rebuilds from scratch when its watermark crosses a UTC
day. Purging old entries also becomes a directory removal instead of a per-object sweep.
The day is not repeated in the entry name, so `since` bounds the time of its own day
only; every later day is taken whole.
* fix pipeline
---------
Co-authored-by: All-Ki <killian.allegrain@vates.tech>
* feat(qcow2): improve generation speed
the idea is to build a bit index of the clusters to store them efficiently instead
of going through all the possible blocks 3 times at different phases of the generation.
The memory consumption is 2MB/TB of disk
this index generation can still be quite long , so we use setImmediate from
time to time to le the rest of the nodejs event loop run
also make this index phase abortable
* fix(xo-server): keep localhost proxy targets on wildcard binds
Since 82f047ef9 (#9572), [http.proxies] targets pointing at localhost are
rewritten to the hostname of the HTTPS listen config. With the default XOA
config (hostname = '0.0.0.0') this produced targets such as
http://0.0.0.0:9004/metrics and, worse, routed these internal requests
through the proxy-aware HTTP agent: with an httpProxy configured,
/openmetrics scrapes left the appliance for the corporate proxy and were
denied there.
Only rewrite when the bind address is a specific one (the #9500 case, where
localhost is not reachable) and pick the agent from the original target
locality, so requests to the machine itself never go through the HTTP proxy.
Seen in support ticket 7763112.
* chore(CHANGELOG.unreleased): entry for #10335
* chore(CHANGELOG.unreleased): clarify localhost targets always bypass the HTTP proxy
Opening the form in a new tab reloaded the whole app, so every object
was fetched again from scratch. Until that fetch finished, the form
could not be properly auto-filled. Navigating in the same tab reuses
the already loaded objects, so the form is populated right away.
docs(xo): fix wrong page order and restore missing links
After ve changed how the sidebar
was generated (from manual declarations to automatic generation)
Some pages went out of order and didn't
have the proper sidebar title.
This commit fixes that.
Also, the external links in the sidebar disappeared.
We can't add them in an auto-generated sidebar, so we circumvent
that by creating dedicated pages for external resources
and re-adding the links there.
Signed-off-by: Thomas Moraine <thomas.moraine@vates.tech>
We now generate the sidebar automatically (based on the documentation folder structure and _category.json files), instead of declaring the doc structure manually in sidebars.ts.
Simpler management
This makes the sidebar easier to understand and maintain. It is now managed the exact same way as the sidebars for the Vates VMS and XCP-ng documentations.
Clickable breadcrumbs
The autogenerated sidebar also creates category index pages, which makes breadcrumb categories clickable, as they already are in the Vates VMS and XCP-ng documentations.
Preview
Capture d'écran 2026-09-08 094848
Unlisted pages
Pages that should remain accessible but be hidden from the sidebar are now hidden using the unlisted: true metadata, instead of simply being omitted from sidebars.ts.
Internal links and redirection
Finally, the PR updates internal links and redirects to reflect the new folder structure and URLs.
* don't rearm after a fatal error before connection setting changed ( does not affect the normal route on non fatal error like newtork issue)
* serialize error correctly in database to ensure the "avoid a database write per auto-reconnect" corectly trigger
a lot of more cleanup to ensure that the connection is really dropped even if the host changed its id
* fix a mishnalding in the grace period before marking a pool disconnected . this will keep the ui in sync AND not redownload all the xapi object for a transient issue
* fix an error transmitted as raw, so the user was only seeing {}
[XO-2789]
* Extracts the backup migration logic into backup-archive and adds a cache guard for future performance improvements
* don't generate or read cache file on immutable backup repository
* clean cache file on immutable backup repository
* fix(backups): fetch failed
disable compresion between xoa on proxy on xoa side
* fix(xo-proxy): disable compression on the proxy
it was disable with hrp, replaced by #10038 since it was never
sending accept-encoding header
compression can be put back later on a route by route basis after
careful checks ( for example : file restore, backup listing )
* fix(backups): task label NBT->NBD
* fix: still force a list block only call for NBD + stream scenario , that was failing to transfer disk on fallback
* fix(openmetrics): keep the Prometheus secret across xo-server restarts
The `secret` property of `configurationSchema` used a random `default`. That
expression is re-evaluated every time the module is loaded, and xo-server never
persists the values ajv fills in from schema defaults, so each restart handed
the metrics endpoint a brand new bearer token and Prometheus started getting
401s.
Drop the default and generate the secret in `load()` instead, saving it through
`xo.configurePlugin()` so it survives a restart.
Introduced by #9323
See https://xcp-ng.org/forum/topic/12415
* chore(changelog): add openmetrics secret entry
* fix(xo-server-openmetrics): generate a 256-bit Prometheus secret
Buffer.from(getRandomValues(new Uint32Array(8))) coerces each 32-bit
element to a single byte, so the generated secret held 64 bits of
entropy instead of 256. Use randomBytes(32) instead.
Introduced by fe29bd0d4
* feat(lite): add create network and network bonded actions
* remove vlan required and info message
* feedback number one
* feat(lite): add create network and network bonded actions
* feat(lite): add action create internal network
* update changelog file
* fix rebase
* feedback number one
* remove as const in cancelRoute
* feedback number two
* feat(xo6): rebase detach
* add redirect when detach ok
* fix post rebase
* remove dev route
* returns from MR
* add check master host
* use linked translation
* rebase ok
* fix(backups): timeout was not used correctly for NBD transfers
* fix(nbd-client): evict a dead client in multi instead
actual code was retrying 5 times, each time with a 60s timeout
multi also have its own retry on conneciton
since the client used is determnistic for a block, any stalled client
will be hammerred for a lot of time before giving up
this PR evict a nbd client that is failing to read a block (with its
retry logic)
* fix(nbd-client/multi): better spread read accross client
the actual code derivate the clientId from the block index
we have no information on the block distribution, only hopes that
it's random enough
this PR introduce a mechanism to use a round robin to select
the next client
* fix: correct fall back to full with /without nbd on qcow2
* docs(xo): refine page titles and navigation structure
Make page titles clearer and more consistent with their content and
purpose. Reorder some pages (and sections) and align their sidebar labels with
their titles to make the documentation easier to navigate and
understand.
Signed-off-by: Thomas Moraine <thomas.moraine@vates.tech>
* docs(sidebars.ts): move discover xo category back to where it was
Applying the change suggested by olivierlambert.
The 'Discover Xen Orchestra' category now follows
the 'Getting started' category.
The 'architecture' page/ 'How XO 6 is organized' stays
at the end of the Getting Started category.
Signed-off-by: Thomas Moraine <thomas.moraine@vates.tech>
* docs(xo): specify navbar titles
Applying changes suggested by olivierlambert.
Some titles in the navigation bar were made too long,
in an attempt to make them identical to the titles in the corresponding doc pages.
Having different titles in the navbar and in the actual page
is not a defect, and can indeed help readers scan the
document structure quicker.
As a result, we're (re-)adding sidebar_label metadata
to specify a navbar title where the page title was too long.
Signed-off-by: Thomas Moraine <thomas.moraine@vates.tech>
* docs(xo): revert individual page renames
Applying changes suggested by olivierlambert, following,
the reasoning he explained in the pull request.
Signed-off-by: Thomas Moraine <thomas.moraine@vates.tech>
* docs(intro_support.md) change title to 'support'
Apply change suggested by olivierlambert.
'Support' instead of 'Support options' is shorter and
carries the same meaning overall.
Signed-off-by: Thomas Moraine <thomas.moraine@vates.tech>
* docs(xo): update outdated internal link labels
A few commits ago, some page titles were changed.
This did not break any internal links, but it left some link labels outdated. This commit updates those labels to match the current page titles.
Signed-off-by: Thomas Moraine <thomas.moraine@vates.tech>
* docs: convert page titles to sentence case
Applying changes suggested by olivierlambert
Some page titles were still using title case, even though we use sentence case throughout the XO documentation.
This commit updates those titles to follow the same convention.
Signed-off-by: Thomas Moraine <thomas.moraine@vates.tech>
* docs(xo): switch gerund titles to noun forms
Some page titles used gerunds (the -ing form), while others used nouns or noun phrases, resulting in an inconsistent style.
This commit changes the gerund titles to noun-based titles for consistency.
The "Troubleshooting" title is kept as-is because it is a noun, despite ending in -ing.
Signed-off-by: Thomas Moraine <thomas.moraine@vates.tech>
---------
Signed-off-by: Thomas Moraine <thomas.moraine@vates.tech>
Adds a synchronizedSnapshot backup setting. When enabled, all of a job's VM snapshots are taken up front in a batch before any transfer begins, and each VM's backup then reuses its pre-taken snapshot instead of snapshotting again.
Settings:
synchronizedSnapshot:
false (default)
true (synchronize every VM in the job)
<tag> (synchronize only VMs carrying that tag, others are backed up normally).
snapshotConcurrency: max concurrent snapshots during the batch phase (default 2).
A batch member that fails to open is silently dropped from synchronization and backed up normally.
Unit tested where applicable and e2e tests added in qa-test.
Checkbox added in xo5 backup jobs to synchronize snapshots, tags not supported yet.
* feat(lite): add create network and network bonded actions
* update changelog file
* remove vlan required and info message
* feedback number one
* feedback number two
* feat(xo6): add disable and enable host button
* Add button enable disable
* remove route map file
* Refacto for PR
* Add modal
* refacto for PR
* fix i18n
* fix route map
* change modale to VtsActionModale
* refacto for MR
* fix type VtsActionModal
* refacto for MR
* add enable disable un treeview
* refacto treeview
* wip
* add shutdown and start button and job
* Update changelog and remove route map
* wip i18n
* tests ok
* fix build
* refacto for mr
* refacto for PR
* add check pending action
* add check host not halted
* feat(xo6): add disable and enable host button
* Add button enable disable
* Refacto for PR
* Add modal
* refacto for PR
* change key i18n
* change modale to VtsActionModale
* refacto for MR
* fix type VtsActionModal
* refacto for MR
* refacto treeview
* wip
* Update changelog and remove route map
* wip
* wip forget
* test and refacto for PR
* fix error rebase
* fx rebase missing
* fix rebase
* fix rebase
* wip
* add shutdown and start button and job
* tests ok
* refacto for mr
* add check host not halted
* wip
* rebase for PR
* fx rebase missing
* wip
* change order button
* wip
* wip forget
* wip
* button and job ok
* add modal disable host and evacuate vm but tests not done
* refacto for PR
* fix fr json and route map
* fix rebase
* fix PR
* remove route map
* last fix
* Returns from PR
* Returns from PR
* Add ? on confirm i18n
* Fix job disable and enable running message
* Fix enable job
* Fix enable job
* Returns from PR
* Fix post rebase
* Fix post rebase
* Fix post rebase
* fix from rebase
* Returns from PR
* Returns from PR
* rebase ok
The Pools -> Security tab in Xen Orchestra was
recently renamed as 'Traffic rules'.
This commit updates the XO documentation (screenshots included) to reflect that change.
Signed-off-by: Thomas Moraine <thomas.moraine@vates.tech>
The console tab kept its own `minimalLayout` state to track whether the page header was collapsed, separate from the VM page's `collapsedHeader`. The two desynced because the tab remounts on navigation while the VM page stays mounted.
Fix:
- Single source of truth `collapsedHeader` in the parent index.js
- Pass it to the child tab-console.js along with `setCollapsedHeader`
- Replace the `_toggleHeader` toggle with an explicit `_setCollapsedHeader(value)` setter
- Remove the duplicate local `minimalLayout` state that could get out of sync and use `collapsedHeader` instead
- Force off on VM shutdown (console no longer displayed) and on unmount (user changed page)
The docs on devops tools and kubernetes was moved
from the Vates VMS doc to the Xen Orchestra doc.
As a result, one link to the kubernetes page broke in the XO doc.
This commit fixes that broken link.
Signed-off-by: Thomas Moraine <thomas.moraine@vates.tech>
* add more details in task log
* fix an issue with VM with more than 10 snapshot, add unit test for this parsing
* fix the real bug: vmware do not update the vmdk description file before the next VM reboot. It means that the uid of the snapshot and vm are the same, thus finishing the transfer with " nothing to transfer" . We are now using the path on source as key + add unit test + add compatibiliy with legacy VM migrated with the uid.
* add e2e test for v2v
Customer imported large VM from VMWare (> 3 To), import switched to Qcow2 automatically but the process was stuck while building the qcow2 L1/L2 address tables, where the NbdDisk's hasBlock is called for each l2 table entry which iterated over the disk dataMap which contained ~113,528 ranges. This froze the process for more than 18 minutes after which it was either killed or died due to OOM error.
This fix improves the NbdDisk by:
Updating processDatamap to throw on overlapping ranges and merge touching extents.
Override default getBlockIndexesCount with optimized Nbd one.
Improve hasBlock with a built in cursor to improve performance.
Test file added to cover the new function and updated code.
from ticket 59505
node-tar >= 7 returns a Minipass stream: it has `pipe()` but is not a `node:stream`
instance. xo-proxy serves this stream through Koa, which pipes only bodies passing
instanceof Stream` and JSON-serializes anything else — so a file restore through a
proxy answered a JSON dump of the tar object instead of the archive. Wrapping it in a
real node stream also propagates tar errors to the consumer and aborts the tar job
when the client disconnects.
The load balancer did not take into account that hosts may be in disabled state, which means it's impossible to migrate a VM to it.
This PR fixes that by ignoring these hosts instead.
Fixes ticket 62077
* feat(xo-server): serve doc locally
* the doc is already distributed from the mono repo
* add a build phase to the global yanr build that build a doc with the
right prefix
* add a http mount doc => embed build
* doc(backups): add a space calculator
* estimate the space needed for backups
* compute the duration protected by immutability
introduced by #10058
the current method assumes that source block are full but they can
be sparse. In the worst case getBlockIndexesCount can be the same as
the source
the offset must be relative to the start of THIS large block, not to the
start of the disk — otherwise every large block after index 0 lands past
the end of destinationBlock and copy() silently writes nothing (zeroed block).
affect qcow2 incremental backup with NBD disable
NBD + qcow2 and Vhd backups don't go through this code path
The previous static/js/matomo.js snippet never loaded the tracker
script, so nothing was ever recorded; it also pointed at site 5, the
XO website. Replace it with the client module from the Vates VMS docs
on the new dedicated docs site (23): cookieless page-view tracking that
follows SPA navigations, and instrumentation of the lunr search box
reporting each settled query with its suggestion count, so zero-result
searches surface missing content. The feedback widget mirrors votes and
thumbs-down reasons as doc_feedback events.
Also fills in the Formbricks IDs for the "XO Docs page feedback"
survey, enabling the feedback widget.
Swizzles DocItem/Footer to show a 'Was this page helpful?' widget under
every doc article, ported from the Vates VMS docs. Votes post to the
self-hosted Formbricks instance via its public client API; a thumbs-down
asks why (outdated, unclear, missing info, inaccurate) plus optional
free text. The vote is recorded on click so it survives the visitor
leaving before the follow-up. Page path rides along as a hidden field
for per-page filtering.
* ensure cache is generated completely at the end of the backup job
* ensure a broken cache is regenerated even without merge during the cleanup phase
* ensure a broken cache is regenerated on request
add new option and script to launch a load test :
number of vm is configurable
concurrency is configurable
number of backup run is configurable
will do multiple run, then a restore
- Show only traffic rules of VMs. Don't include `vm-snapshot` or `vm-template`
- For VM selection, display all VMs and disable those without a VIF, with a
message displayed
A VM backup log status is calculated depending on its subtask status. Previously, we made that it would be a failure if at least one of its subtask is a failure.
However, in case of successful retries, the intended behaviour is to have failed subtasks, which should not affect the parent task status. The first commit of this PR fixes that.
The second commit simplifies the getStatus function and its usage.
---------
Co-authored-by: Florent BEAUCHAMP <florent.beauchamp@vates.tech>
A server left enabled but without a Xapi instance was never retried by anything in
xo-server. Three paths lead to that state:
a failed explicit connect: xo-server boots while a pool is down, a user clicks
"connect" during an outage, or the host-eject path exhausts its 5 attempts;
a SESSION_INVALID teardown after a pool master restart (_sessionCall calls
disconnect(), and nothing listens to server:disconnected);
fixing a server's credentials/address while it is disconnected (server.set never
triggers a connection).
Once there, the server stays disconnected forever, showing an error that can be
minutes or hours old. Support ends up chasing false "pool is dead" reports, typically
right after a rolling pool update, which is exactly when hosts reboot by design.
* 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.
when hrp get a 404, the stream stay ready to be consumed, for example to get
more information on the error
but most of the usage won't handle this case, and will keep the stream in memory
(for example a failing XC patches check) leaking memory
This fixes the calls from xo, and also identifies and fixes the point where we
need body content on 4xx code
relevant code in hrp is here:
https://github.com/JsCommunity/http-request-plus/blob/master/index.js#L149
setting undefined is a no ops, we need to use null to clean a value
this don't have any visible or functionnal impact, but complexify
the build of a filter to look for any non completely migrated VM
* fix(configuration.md): remove trailing spaces
* feat(sdn-controller.md): explain traffic rules migration path: from OpenFlow Protocol to XAPI Plugin
- add sdn-migration.py python script
- in configuration.md, refer to sdn_controller.md for changing `useDirectChannel`
- in sdn_controller.md, provide documentation on migration path
XCPNG-3260
report an error if we detect that the runtime configuration doesn't match the of-rules format stored in xapi database.
the admin is expected to ran migration script by hand to fix it.
This commit creates a new, refreshed tree structure
for the XO 6 documentation, which we intend
to be more helpful for readers and XO 6 users.
New sections are created, to be completed later.
Additionnally, the ACLv2/RBAC page has been
moved from the Support section to the Security section.
Signed-off-by: Thomas Moraine <thomas.moraine@vates.tech>
Adds rest api endpoints testing for the sdn controller.
Don't forget to set the required SDN_CONTROLLER_VM_ID to a vm that has both a vif and a network.
Run @xen-orchestra/qa-test yarn qa:sdn-controller for testing.
Add a message if you try to leave the page during XOA deployment.
Unfortunately, it is not possible to have a custom info box for the
`beforeUnload` event. So for homogeneity, `onBeforeRouteLeave` is
`window.confirm` too.
Use XO Tasks in the load balancer so users can see on the task page what the load balancer does. Now, it creates a task (with no progress) for each VM migration.
The task has a description explaining the reason of the migration, which can be accessed by opening the task log.
XO-992
Reduce memory consumption up to 700MB / TB of data ( 300-350Mb per call of getBlockIndexes().length , called twice).
Ticket: 59102
Tested in client environment. Works for a 7TB import
this enable the test to run using from and to shared storage ( nfs/samba/s3/azure)
the local path is only used for export tests
tested with a remote garage (object storage) provider, full suite is passing
this is an async bug leading to the full size not really sumed, thus
depending on the async and concurrency leading to a size 0 even if another
disk has data
* fix(backups): tolerate ENOENT when deleting missing backups
* fix(xo-server): propagate content-length in VM import
* fix(qa-test): retry REST API calls on transient 401
* fix(qa-test): harden cleanup against stale cache files
* fix(qa-test): fail fast on misconfigured test environment
Assert that source and mirror repositories are distinct before running
any backup steps, giving an actionable error when both env vars resolve
to the same remote ID. Also improve the mkdir failure message in the
export test to include the exact path and the remediation command.
* feat(qa-test): make source vm runs to ensure there is content to transfer
* fix: harden job deletion
* fix(qa-test) don't use a deprecated route for authent
* fixup! feat(qa-test): make source vm runs to ensure there is content to transfer
* fixup! fix(backups): tolerate ENOENT when deleting missing backups
* fixup! fix(backups): tolerate ENOENT when deleting missing backups
Implements XO-2155. The OpenMetrics plugin now ships XOSTOR-specific metrics so operators can build a Grafana dashboard for XCP-ng Hyperconverged Infrastructure.
All metrics use the xcp_xostor_* prefix:
Cluster status: xcp_xostor_up, xcp_xostor_node_status (master / satellite roles + raw state from linstor-manager.healthCheck), xcp_xostor_resource_total.
Storage pool health: xcp_xostor_resource_state_count — replica counts per disk-state (UpToDate, Inconsistent, Outdated, Diskless, Unknown), aggregated per cluster.
Performance filter: a new sr_type label on every SR-tagged metric (xcp_host_disk_iops_*, xcp_host_disk_throughput_*, latency, xcp_sr_*, xcp_vdi_*, xcp_vm_disk_*). Dashboards can filter sr_type="linstor" without changing existing queries.
Active alarms: xcp_xostor_alarms_count aggregated by alarm_name (ALARM, BOND_STATUS_CHANGED, MULTIPATH_PERIODIC_ALERT) and target_type (sr / host).
Disk SMART: xcp_xostor_disk_smart_status per (host, device) with the overall-health string in a status label, sourced from smartctl.py.
Pending updates: xcp_xostor_package_update_available for xcp-ng-linstor, linstor-satellite, linstor-controller, xcp-ng-release-linstor, and xcp-ng-xapi-plugins.
Each collector caches at its own TTL (60 s for cluster and alarms, 5 min for SMART, 1 h for updates) and exposes an xcp_xostor_<feature>_up gauge so silent collection failures still show up on dashboards. A TtlCache<T> helper encapsulates the cache-plus-coalescing pattern shared by the three caching collectors.
Replace the hard-coded CONFIRM_PATTERNS list in the MCP server with a per-endpoint exposure decision carried by an x-mcp-exposure OpenAPI vendor extension. Each REST endpoint now declares its MCP exposure (allow / confirm / deny) with @Extension('x-mcp-exposure', ...) next to its HTTP method decorator. A new local ESLint rule mcp/require-mcp-expose makes the decision mandatory: any new @Get/@Post/@Put/@Patch/@Delete method without an exposure tag fails lint.
The MCP parseSwagger now reads the extension and applies a default-deny policy:
'allow' → exposed as a query/action tool
'confirm' → exposed only when XO_MCP_ENABLE_ACTIONS=1, with confirm-token round-trip
'deny' / absent → never exposed
Defense in depth is preserved: route-filter regex (binaries, streams, stats) is applied before the exposure check, so a binary endpoint mistakenly tagged 'allow' still stays out of the MCP surface. The confirm_token UUID + TTL machinery in risk-config.mts is untouched.
All 248 endpoints across 34 controllers have been annotated with conservative defaults (GET → allow, destructive POST/DELETE/PUT/PATCH → confirm, binary exports → deny).
the number of snapshots will be as high as the retention selected, but this is not really
an issue since those VM will be run only when a disaster occurs. In this case, degraded
performance is an accepted tradeoff
Introduced by 7a8ca
When creating an HVM VM from a template that already has a disk attached, the boot order was being incorrectly modified to put the network first, resulting in the VM attempting a PXE boot before eventually falling through to the disk.
The boot order was modified whenever vdis and existingVdis were both empty, since no new disk needs to be provisioned. This caused network to be put first in the boot order regardless of whether a network install was actually requested.
Boot order modification now depends exclusively on installMethod:
Network: network (n) moved to the front of the string, this is unchanged.
CD: DVD-drive (d) moved to the front of the string, this is a fix to another issue where HVM + CD installs did not update the boot order string at all.
Everything else: String is unchanged, preserving the template's original order
Also, previously creating a diskless HVM VM with no install repository would get the network moved to the front of the boot order, that implicit behavior is gone, now diskless VMs now inherit the template's boot order.
This means that if in the template boot order, the network is last, the BIOS will try to find the disk and the cd first before trying the network. This is acceptable as these steps are fairly short.
following the symmetrical backup PR
reuse any snapshot in common between the source and destination if
* using incremental replication
* only one target
* a common snapshot exists between source and destination , even from another job, based on the CONTENT_KEY
The same rule of reuse the existing VM target / create a new one of symmetrical backups applies
if the destination don't have any data between the snapshot and the active disk
update an existing VM
else create a new VM but chain disks
When a Redis entry has an ID but no corresponding data key, undefined was returned which caused errors when new data was added.
Error case was the configuration of a plugin failing to save.
Move ipmi sensor discovery to it's own plugin and removed old logic, ships with a default configuration with the same behaviour as the old system.
The plugin can be configured via the UI, accepts an exact match for the vendor and regexes for the ipmi matching.
Tested via unit tests.
Tested with R620-L1 host on xo-lab by adding and removing Dell from configured vendors
- Add `getRequiredEnv()`: replaces all `process.env.X || 'default'` fallbacks
with a hard throw so a missing or typo'd .env key fails immediately with a
diagnostic message instead of silently operating on wrong defaults
- Add `logSetup.js`: dual-transport logging — console filtered by $DEBUG,
plus a full debug-level file in /tmp for post-mortem inspection
- Add `assertRepositoryMatchesConfig()`: fails fast when a named repository
in XO points at a different path than the one declared in .env
- Make `getAllowedCleanupPaths()` lazy so env vars are read after .env is
loaded, not at ESM module evaluation time
- Pass full error objects (not `.message`) to all structured log calls
- Add retry logic on flaky operations and surface more detail on failures
- Fix: only purge non-empty backup repositories
- Fix: backup jobs no longer skipped under some conditions
- Fix: missing `backuprepository.delete` function
- Add `.USAGE.md` and update `README.md`
add xo-server-ssh executable that ease a connection to the hypervisors
Without parameters it list the pool uuid/master ip
With a pool uuid parameter it opens a sshg connection to the pool master
With a pool uuid and ip, it will reuse the pool credentials to connect to the slave host
* feat(mcp): support HTTP_PROXY, HTTPS_PROXY, NO_PROXY env vars
* chore(changelog): mention MCP proxy env var support
* refactor(mcp): delegate proxy env handling to undici
the cleanVm script was a monolith in charge of cleaning the backup,
detecting any corrupted data, deleting the irrecoverable one, removing
and merging older backups
this PR do a complete rewrite, using the RemoteDisk abstraction and add
tests
The transport-nagios plugin lets users monitors backup jobs from the Nagios interface.
This was previously documented only in a Xen Orchestra blog post.
This commit completes the existing Backup reports page, by explaining how
to get backup reports in Nagios, using that plugin.
Signed-off-by: Thomas Moraine <thomas.moraine@vates.tech>
This PR contains several commits to do some code cleanup in xo-server-sdn-controller.
They doesn't belong to any specific tasks, but it was done while working in the code.
They will be better upstreamed than in my local worktree.
unify createLogger inside xo-server-sdn-controller package : it simplifies filter usage in configuration to have debug output of the sdn-controller
in openflow-plugin.js, avoid using log.error() for a not fatal error but use log.warn(). reorder a bit the throw code to make it more readable (the error is throw only if no plugin call successed)
Fixes:
* better support of localized systems
* types
* add a retry on chattr error, selinux and / or xfs seems to need a little more time before locking it
* force a complete check on startup to remove immutables files that should not be froma previous run
* don't try to lock deleted files
docs(sdn_controller.md): fix error in code sample
As reported by Jon Sands, the previous version of the code sample showed the script executing line by line. It works as expected after removing the -xe
Signed-off-by: Thomas Moraine <thomas.moraine@vates.tech>
docs(aclv2): fix broken links
The ACLv2 page was created and merged at roughly the same time we split the documentation pages into two sections (XO6 and XO5), so the change in file structure broke some links to and from that ACLv2 page.
This commit fixes the links so that the Docusaurus build can complete without errors.
Signed-off-by: Thomas Moraine <thomas.moraine@vates.tech>
XO6 has become the default interface for Xen Orchestra,
but not all features have been ported to XO5 yet
and they don't work the same way.
To make the documentation easier to maintain
and prevent confusion,
we're moving the current pages to a new section called 'XO 5'
and create a new section for XO6-specific documentation. The XO 6 section will be completed gradually.
On top of that, this commit updates internal links and redirections
to adapt to this new doc architecture.
Finally, most of the pages in the Support category
have been moved to a new section called General support,
since these pages apply the same way to XO 5 and XO 6.
Signed-off-by: Thomas Moraine <thomas.moraine@vates.tech>
- ancestor (blocks 1, 3) merged into child (blocks 1, 2) -> 3 blocks
- cleanAncestor merged into clean -> 0 blocks
grandchild is not merged so its size is not counted here
* fix(backups): record actual incremental VHD size
* fix(backups): record merged VHD size from merge result
* fix(backups): only rewrite metadata after actual merge
* fix(backups): record actual incremental VHD size
it will be used by xapi to know if the OpenFlow channel is used and so if port 6653 needs to be opened or not.
it might also be used later to know how to interprete of-rules in the migration path from channel to xapi-plugin, if needed.
XCPNG-2470
XO-2282
It could happens if xapi database is out-of-sync with filesystem.
As the purpose of this block is to decide if the certificate should be installed,
assume that on CERTIFICATE_DOES_NOT_EXIST you need to install the new certificate.
For strong passwords, you need a good source of entropy (true randomness).
lodash.sample's randomness relies on the JavaScript runtime's PRNG, which might
not have enough entropy.
on topology changes (VM started/stopped/migrated/...), network rules needs to be
refreshed as they are installed on each port of virtual switch.
add the same logic than VIF rules to refresh them.
Enable the usage of `cookie` parameter exposed by sdn-controller xapi plugin
- https://github.com/xcp-ng/xcp-ng-xapi-plugins/pull/58
It fixes several cases where OF rules where leaked and left behind.
Upgrade notes (apply to Network Rules only, VIF Rules are not impacted):
- a new xapi-plugin with old XO is compatible (and no behaviour change)
- an old xapi-plugin with new XO will fail to communicate
XO will try to use `cookie` but xapi-plugin will complain about invalid parameter
- a new xapi-plugin with new XO will use new behaviour
and existing OF rules will migrate smoothly from old to new behaviour
When VM_destroy is called on a default template, it is first converted to a simple template (and then to a VM).
After converting a default template to a simple template, the object received after the xapiObjectToXo transformation has a different ID (the default template's ID = pool.uuid + template.uuid, and non default template ID = template.uuid).
Since this object does not already exist in the XO server cache(because the ID is new), XO treats it as a new object and not as an update, so the old object with ID pool.uuid + template.uuid stay in the cache
* fix(backups): use a delta transfer even if the VM is modified
* test(backup): fix date test without timezone
* refactor(backups): extract method that check which snapshot can be reused for replica target
* reset before launching the replication
xo-server uses two libraries for its web server:
http-server-plus — a multi-protocol server facade that multiplexes HTTP and HTTPS listeners behind a single EventEmitter interface ( introduced here JsCommunity/http-server-plus@ec63f3f )
stoppable — wraps the server to track open connections for graceful shutdown, using an internal reqsPerSocket Map (server._pendingSockets) (introduced here : 782505b )
Fix
@vates/http-server-plus (fork of JsCommunity/http-server-plus): add 'secureConnection' to the forwardedEvents list so that webServer.on('secureConnection', handler) is propagated to underlying https.Server instances at listen() time.
xo-server/src/index.mjs: register the missing handler that stoppable was supposed to add but never did:
Change the backups so they stop using their own task system, and use the same system as XO Tasks.
For the moment, it shouldn't affect the users, but when the previous backup logs will be old enough to be erased, this will allow us to have shorter loading times for backup logs.
XO-52
* test(replication): test the new snapshot based replication
* fix(tests): use mergeBackupsSynchronously to ensure the backups don't fails with lock already heled error
* fix: ensure the repository that will be purged start empty
* test(backup): add test for full mirror backups
* fix compression not used on front whe copying a VM
* ensure the first bytes are ready before starting to import the VM
---------
Co-authored-by: Florent BEAUCHAMP <florent.beauchamp@vates.tech>
Fixes#7773
See Zammad#53857
On Netbox >= 4.4 (which introduced platform hierarchies):
- If the major version number is available: create a versioned child platform (e.g. "Debian 12") with the distro-only platform (e.g. "Debian") as its parent, and assign the child to the VM
- Otherwise: keep previous behaviour and assign the VM to the distro-only platform
* chore: upgrade dependencies with known security vulnerabilities
* Update Node.js version in CI workflow
* chore: upgrade additional security dependencies
* chore: stabilize yarn.lock path-to-regexp entry
* chore: bump minimum version ranges for security-patched dependencies
* chore: update CHANGELOG.unreleased.md with security upgrades
* chore: revert vite upgrade to 6.4.1 (6.4.2 breaks vue-tsc)
* chore: fix vite upgrade and pin vue to 3.5.28
* feat(mcp): add list_srs and get_sr_details tools for storage
repositories
* docs(mcp): add list_srs and get_sr_details to documentation
* fix(mcp): extract expected tool names into a constant in tests
* docs(mcp): add link to live filter syntax documentation for all filter
parameters
* feat(disk-cli): implement disk cli tooling
* changelog
* fix test path
* fix following review
* fix following rebase
* ci
* fix following rebase
* more tests
* fix(backups): use the snapshot of the source
introduced by 9524
use only the vdi from the source VM as the source on backup
this bug could only occurs if the replication was intra pool, if
not the different xapi was filtering the results
When editing VM RAM, the high-level `memory` field dispatches to `memoryMax` or
`_memory` depending on whether the VM uses DMC. Both paths need `limitName:
'memory'` on their spec so the resource set quota counter is correctly updated,
but `_memory` was missing it, causing memory resizes on non-DMC VMs to silently
create a stale `_memory` counter instead of updating the actual memory quota.
Fixes out of range error during merge that was happening on delta backups when the child disk was bigger than the parent disk but no blocks where written in the "new" space.
Also added a test for this error.
Fix npx @xen-orchestra/mcp failing with "Permission denied".
tsc does not preserve the executable bit on compiled files, so bin pointing to ./dist/index.mjs (mode 644) caused the error. This adds a bin/xo-mcp.mjs wrapper tracked by git with mode 755, following the same pattern as other packages (@xen-orchestra/xapi, @xen-orchestra/proxy, etc.).
Add optional transient parameter (boolean) to host.disable API endpoint.
When transient=true, passes auto_enable=false to XAPI, keeping the host disabled across reboots and toolstack restarts (requires XAPI >= 25.31.0). Default behavior unchanged (backward compatible).
XAPI 25.31.0 introduced a new auto_enable parameter to Host.disable (xen-api#6652). When set to false, the host stays disabled regardless of toolstack restarts, host reboots, or consider_enabling_host calls. Only an explicit Host.enable can re-activate it.
This PR adds the new @xen-orchestra/mcp package — an MCP (Model Context Protocol) server that enables AI assistants (Claude Desktop, Claude Code, or any MCP-compatible client) to query a Xen Orchestra infrastructure in read-only mode.
The size is computed from the blocksize * nb allocated blocks during the backups
which is not aligned with the real size on disk
Checking the file on disk is too costly for vhd directory
This will be eventually reimplemented by the next cleanVm rework
This pull request documents the manual steps that will be needed for the SDN controller, with the incoming March 2026 update of XCP-ng that will include OpenSSL3.
OpenSSL-3 (on xcp-ng) requires CA set to true in basicConstraints.
"All CAs should have the CA flag set to true."
For context, here are additional resources:
- https://docs.openssl.org/3.0/man1/openssl-verification-options/#basic-constraints
- https://docs.openssl.org/1.0.2/man1/x509v3_config/#basic-constraints
- https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.9
To connect to OpenSSL 3, certificates should be re-generated if they
already exist (just remove xo-server/data/sdn-controller).
Renewed certs were tested on XCP-ng host on "OpenSSL 1.0.2k-fips"
without regression, so it is safe to assume those ext are designed to
be backward compatible.
Observed issue:
openssl verify \
-CAfile .../xo-server/data/sdn-controller/ca-cert.pem \
.../xo-server/data/sdn-controller/client-cert.pem
C=XX, L=Default City, O=Default Company LTD
error 79 at 1 depth lookup: invalid CA certificate
error .../xo-server/data/sdn-controller/client-cert.pem: \
verification failed
The expected output is now:
.../xo-server/data/sdn-controller/client-cert.pem: OK
The expected output is now:
.../xo-server/data/sdn-controller/client-cert.pem: OK
It was tested along ovsdb-server (Open vSwitch) 2.17.7 :
openssl s_client \
-connect 10.1.75.62:6640 \
-cert .../xo-server/data/sdn-controller/client-cert.pem \
-key .../xo-server/data/sdn-controller/client-key.pem
(...)
CONNECTED(00000003)
Can't use SSL_get_servername
(...)
verify error:num=18:self-signed certificate
(...)
SSL handshake has read 2713 bytes and written 3799 bytes
Verification error: self-signed certificate
(...)
New, TLSv1.2, Cipher is AES128-GCM-SHA256
(...)
{"id":"echo","method":"echo","params":[]}
Extra info at:
- https://xapi-project.github.io/new-docs/design/pool-certificates/
Origin: https://github.com/vatesfr/xen-orchestra/pull/9507
Relate-to: XCPNG-2710
Relate-to: XO-1986
Signed-off-by: Philippe Coval <philippe.coval@vates.tech>
permit to have working traffic rules when a pool is in a 'degraded' mode (for
example, one host temporary down or unreachable).
currently, exceptions occurs and nothing happens (no rules added or deleted).
with it, unreachable hosts are ignored and reachable hosts properly updated.
The deletion of old backups is done globally
For Full backups/replication:
* retention is computed on the total of the target
* choose the storage with the most free size ( if possible, since some backup repositories don't have any size used/ free )
* one vm is written on the same target ( xva, index, checksum )
* healthcheck ( if enabled ) will run only on the target that received the data
* the cleanup of old backups/replication is done on the right target ( but considering the full lenght across all the targets )
For incremental:
* delta chain are continued on the same target
For mirror :
if a vm has multiple backups to transfer during the same run, then
they will all go to teh same remote
UX :
* show a toggle on remote/sr selectors
* toggle is disabled if 1 or less targets are selected
* for backup and mirror backup forms
* show the details in the job list
More details on the PR page
this merge code leverage the new classes introduced to handle qcow2, improving our flexibility, and future uses.
this also improve the performance on "block mode" backups (s3/ azure and other storage with the option), since it reliably updates the block allocation table only at the end of the merge instead of each time a new block is detected
when the connection to the host break between the snapshot() and
the update of other config
this could leave snapshot that will never be cleaned by any backup job
The fix is that the snapshot will be named with a specific name, it
will cause an issue if a user reuse this name
* fix(backup-reports): prevent succesfull backups being sometimes reported as interrupted
* increase delay after user feedback
* change comment according to delay change
---------
Co-authored-by: Florent BEAUCHAMP <florent.beauchamp@vates.tech>
* feat(xo-server-openmetrics): add SR capacity metrics
* fix(xo-server-openmetrics): refactor SR types and add host labels for
local SRs
---------
Co-authored-by: Florent BEAUCHAMP <florent.beauchamp@vates.tech>
In some cases, when converting an xapi object into an xo object, the xapi.is_a_snapshot param may be set to false even tho the xapi.snapshotOf refers to another xapi object. Handle this case better.
Add Affinity rule option to the load balancer plugin.
This options ensures some VMs are positioned on the same host, when it's possible.
It's important to be careful while configuring the Affinity tags and Anti-affinity tags fields, otherwise it may lead to conflicts between the two behaviours. In such case, affinity takes precedence over anti-affinity.
This commit renames and updates the **Docker management** section in the Xen Orchestra documentation. We explain a but better how containers are supported in Xen Orchestra, and remove links and references to the now-removed Docker support section, which was triggering a Docusaurus warning at build time.
Signed-off-by: Thomas Moraine <thomas.moraine@vates.tech>
Add two new API methods to download XCP-ng/XenServer system status (bug reports) via xo-cli:
host.getSystemStatus - Download system status from a single host
pool.getSystemStatuses - Download system status from all hosts in a pool in parallel
---------
Co-authored-by: Mathieu Piton <mathieu.piton@vates.tech>
* feat(xo6): added loader in treeview when search is triggered
* update changelog file
* fix(xo6): code cleanup following PR feedback
* fix order packages in changelog file
* feat(xo6): added new links in the user menu and customized it
* udpate Changelog file
* fix(xo6): code cleanup following PR feedback
* fix order packages in changelog file
docs: upgrade docusaurus from version 3.8 to 3.9
The onBrokenMarkdownLinks option is deprecated and has been replaced by siteConfig.hooks.onBrokenMarkdownLinks. However, since the option was configured to 'warn' and is the default behavior for this option, deleting the onBrokenMarkdownLinks seems like easier
Signed-off-by: Thomas Moraine <thomas.moraine@vates.tech>
- State to use a single XOA instance with SDN Controller plugin enabled
- Cleanup existing OpenFlow documentation
- Document XAPI plugin usage, including xo-cli commands
- Add configuration to toggle between direct channel and XAPI plugin
* feat(xo6): add loader on input search treeview when is triggered
* udpate Changelog file
* fix(xo6): removed condition on props icon in UiInput
* fix(xo6): removed debounced on clear
Several sections of the Xen Orchestra Appliance documentation mention modifying the config file, without specifying the actual file path. This commit updates those references to explicitly include /etc/xo-server/config.toml, which helps users locate and edit the correct configuration file more easily.
Signed-off-by: Thomas Moraine <thomas.moraine@vates.tech>
Changing the value of a `Size` component by editing the field and pressing
'Enter' was executing twice the `_save()` function in parallel (which calls the
`onChange` function).
In some cases like editing a running VM memory limit, this caused errors (trying
to open two modals at the same time, and trying to restart the VM twice)
* docs(xo): change link to the xcp-ng docs, add some infos in HA section
* Update docs/docs/manage_infrastructure.md
Co-authored-by: Thomas Moraine <thomas.moraine@vates.tech>
* Update docs/docs/manage_infrastructure.md
Co-authored-by: Thomas Moraine <thomas.moraine@vates.tech>
* Update docs/docs/manage_infrastructure.md
Co-authored-by: Thomas Moraine <thomas.moraine@vates.tech>
---------
Co-authored-by: Thomas Moraine <thomas.moraine@vates.tech>
docs(manage_infrastructure.md): remove content related to xscontainer, which is deprecated
Since XSContainer is no longer supported on XCP-ng 8.3 or XenServer and
we currently have no alternative, instructions related to XScontainer in
the XO doc are removed
Signed-off-by: Thomas Moraine <thomas.moraine@vates.tech>
Updating the `Toggle` component to avoid throwing an error coming from a
`confirm` modal, which ends up appearing in the console.
This also changes a bit the behaviour of the `Toggle` component, which now
awaits its `onChange` function.
See Zammad#45442
Wrap "Copy to clipboard" button with a span to make the hoverable zone
continuous between the copiable element and the button. Without this, the 1ex
gap between the 2 was sometimes enough to make the button disappear before the
user had a chance to click it.
Adds a page to the Xen Orchestra documentation to list the compatible S3-based
storage support providers for Xen orchestra, with the different support tiers
and appropriate caveats.
* feat(sdn-controller): use XCP plugin to manage open switch
try to instantiate the plugin and fall back to direct query
if it fails
The plugin allow to define and target multiple bridges in parallel
* feat(sdn-controller): implement network wide rules
this introduce 2 new API method sdnController.addNetworkRule
and sdnController.deleteNetworkRule
Theses methods will only work with the plugin, and can't work with
the legacy ( direct channel) approach
Since the 5.110 release of Xen Orchestra, the Vmware to Vates (V2V) process has been updated, with a whole new backend. This commit documents this new process, in the XO documentation
Signed-off-by: Thomas Moraine <thomas.moraine@vates.tech>
Pass the license object to isTrialRunning instead of passing the parent object.
See Zammad#44878 Zammad#44755 Zammad#44431 Zammad#43526 Zammad#44556 ...
Introduced by #8557
See #8523 → #8551 → #8557
The modal to activate HA used to suggest SRs from all pools, but selecting a SR from another pool would result to an error. This change makes that modal only suggest SRs from the correct pool.
* fix(nbd-client): better handling of error during getMap
* fix(xo-server): esxi check errors are objects instead of text
* fix(xo-web): V2v/check improve alignment
* feat(xo-web): add button to install nbdinfo/nbdkit if needed
Added a new section to the Incremental backups documentation to explain why some deltas can be unexpectedly large. Covers common causes and includes tips for investigation and mitigation.
This helps clarify expected behavior and avoids confusion when backup sizes seem too large.
add tips for 2tb+ disks and qcow disks
Signed-off-by: Thomas Moraine <thomas.moraine@vates.tech>
---------
Signed-off-by: Thomas Moraine <thomas.moraine@vates.tech>
* docs(xo): explain the usage reports plugin more explicitly
Previously, it wasn't clear what the toggle called All did. This commit makes the documentation more clear about how it works.
Signed-off-by: Thomas Moraine <thomas.moraine@vates.tech>
* Update docs/docs/manage_infrastructure.md
Co-authored-by: Pierre Donias <pierre.donias@gmail.com>
---------
Signed-off-by: Thomas Moraine <thomas.moraine@vates.tech>
Co-authored-by: Pierre Donias <pierre.donias@gmail.com>
Make the load balancing documentation clearer, better structured, with more illustrations, so that users can follow the process of creating or editing a load balancing plan without friction or hassle
Signed-off-by: Thomas Moraine <thomas.moraine@vates.tech>
The README now specifies that Xen Orchestra documentation updates are deployed automatically once per day. This makes it clearer for users that the online docs are always up to date without requiring manual intervention.
Signed-off-by: Thomas Moraine <thomas.moraine@vates.tech>
Network bonding was absent from the Xen Orchestra documentation. Information about this feature was previously only available in a blog article on XCP-ng.
This commit updates the XO doc so that it properly documents this feature, and remains the single source of truth in this topic. XO users won't have to dig through blog posts to find the relevant information, making the documentation more useful and trustworthy.
Signed-off-by: Thomas Moraine <thomas.moraine@vates.tech>
* feat(lite/release): check that version matches build version
1. Let Vite's build get the last commit hash instead of passing an env variable
2. Emit a build file containing the current commit hash and package version
3. Before releasing a new version, compare hash and version with current git commit and version passed by user
* readJson
In the REST API, we generally work on authenticated requests. getCurrentUser can therefore be a bit tedious, as it can return undefined | XoUser. So, whenever we need the current user in an authenticated request, we need to add a check:
if user === undefined throw for typescript to be happy
So now: getCurrentUser returns XoUser (throw if no user) and getCurrentUser({throwUnauthenticated: false}) returns undefined | XoUser
Enhancements:
Fixed @vates/types
Added limitAndFilterArray in utils.helper to easily handle user filter/limit everywhere
Enhance getObject type in rest-api
makeObjectMapper can take a function to define the path (for path based on the object type)
add getVmVdis in vmService to get VDIs from a VM
Endpoints:
/vms/:id/vdis
/vm-snapshots/:id/vdis
/vm-controllers/:id/vdis
/vm-templates/:id/vdis
* docs(xo): deduplicate acls content
The ACLs page in the XO documentation wasn't listed in the navigation bar and had content that duplicated the ACLs section of the Users page.
This commit removes the standalone page and updates the valid section with minor improvements (presentation, some missing info from the lone ACLs page) so that it becomes the only source of information on the topic.
Signed-off-by: Thomas Moraine <thomas.moraine@vates.tech>
* docs(xo): remove obsolete administration page
The Administration page duplicates content in the VMs section of the Infrastructure management page.
Although the Administration page seemingly refers to itself as a 'section', it contains no subsections or extra content, so this might as been a draft for a bigger page, and was never elaborated upon.
In any case, this page isn't accessible from the navigation bar and doesn't seem to add much value to the doc, so I suggest we remove it from the tree view.
Signed-off-by: Thomas Moraine <thomas.moraine@vates.tech>
* docs(xo): deduplicate backups and disaster recovery content
The 'Backups and Disaster Recovery' page in the XO documentation wasn't listed in the navigation bar and had content that was already present in other pages in the doc.
The last section of that page dealt with scheduled snapshots and completes the existing content on 'rolling snapshots'. That content has been added to the rolling snapshots section, so that everything can be grouped in a single location.
Finally, since the Backups and disaster recovery page is now obsolete, it has been deleted.
Signed-off-by: Thomas Moraine <thomas.moraine@vates.tech>
* Update docs/docs/users.md
Co-authored-by: Laure S. <laure.souai@vates.tech>
---------
Signed-off-by: Thomas Moraine <thomas.moraine@vates.tech>
Co-authored-by: Laure S. <laure.souai@vates.tech>
The Xen Orchestra documentation moved to a new domain name a while ago. This commit updates the last remaining links in the XO doc and app that pointed to the old domain name
Signed-off-by: Thomas Moraine <thomas.moraine@vates.tech>
* docs: deduplicate delta_backups page
Previously, the content of the Incremental Backups page (filename: delta_backups.md) was duplicated by the page titled "Incremental Backups (formerly: Continuous Delta backups)", which was not referenced in the sidebar and had the filename incremental_backups.md.
We don't want duplicate content, as it is troublesome to maintain and may cause confusion for the reader.
Also, since Delta backup is outdated terminology and we now talk about Incremental backups, the lone incremental backups.md page has been deleted, and the current "Incremental Backups" page with the filename delta_backups.md has been renamed as the new incremental_backups.md
Signed-off-by: Thomas Moraine <thomas.moraine@vates.tech>
* docs: deduplicate full_replication page
Previously, the content of the Full Replication page (filename: disaster_recovery.md) was duplicated by the page titled "Full Replication (formerly: Disaster recovery)", which was not referenced in the sidebar and had the filename full_replication.md.
We don't want duplicate content, as it is troublesome to maintain and may cause confusion for the reader.
Also, since Disaster recovery is outdated terminology and we now talk about Full Replication, the lone full_replication.md page has been deleted, and the current "Full Replication" page with the filename disaster_recovery.md has been renamed as the new full_replication.md
Signed-off-by: Thomas Moraine <thomas.moraine@vates.tech>
---------
Signed-off-by: Thomas Moraine <thomas.moraine@vates.tech>
* fix(nbd-client): handle unreachable VM through nbd
when the user select nbd but don't have any way to reach
the storage/host of the VM (for example no NBD enabled network,
or a NBD enabled network unreachable by xo/proxy it was timing out
and blocking the start of the backup
This error was blocking the fallback to export stream mechanism
* fix(xapi): respect the config file setting for preferNbd
* fix(xapi): don't close export stream if nbd failed to connect
* fix(xapi):respect vhd/qcow2 when faling back to a full if delta exports fails
doc(configuration) document let's encrypt support in xoa
Add documentation explaining how to configure Let's Encrypt in Xen Orchestra Appliance (XOA). This feature was mentioned in the XO 5.73 release blog post but was not included in the technical documentation for Xen Orchestra.
* feat(xo6/lite): update side panel behavior for mobile view
* feedback & improvement
* feedback
* feedback
* fix issue with sticky side panel when datatable has a lot of data
* feedback and fix issue
* add changelog
* update icon
* review feedback
* update vts copy button icon
This PR implement a limited support of generating and reading qcow2 . The support is limited since it only handles qcow2 with 64KB cluster size, with this structure :
header
refcount table
refcount blocks
L1 table
L1 tables
data clusters
generated by a9cd5bc639/scripts/qcow2-to-stdout.py
Add safety functions in abstract instead of s3 and azure. A new function "withTimeout" allows to handle timeout and success/failure after timeout.
It should help for better debug and it can be used in several situations.
XO6 is translated into languages, not existing for XO5. And as it is not
possible to select language in XO6 yet (is inherited from XO5 settings), interim
solution is to add these new languages into XO5 user settings, to make them
actually accessible in XO6. It will not affect XO5, because it will simply
fallback into English in case of not existing language.
Add a step-by-step guide for creating VM templates with cloudbase-init
support, including master VM creation, template branching, customization,
reseal and VM instantiation.
Include best practices, tips and visual aids for each step.
Signed-off-by: Tu Dinh <ngoc-tu.dinh@vates.tech>
remove a value that was only used for backup reports, and was no longer used since we use the template system
avoid the backup report content to differ when the backup job has reportWhen = false, which also caused differences between regular backup reports and backup reports generated with the "test plugin" button. To make sure the users can still have the previous behavior, we add parameter in the backup job configuration that allows short failure reports by not displaying all successful VMs in error reports.
rewording "successful VMs" to "successful items" so it also makes sense for metadata backups
Introduced by #6684
If sub-properties are required but the parent property is not, then omitting
the parent property passes the validation, which is not what we want.
The Viridian setting in Xen Orchestra was mentioned in a release blog (XO 5.79) but not in the XO technical documentation.
This improvement explain what Viridian is and how to enable it for VMs and templates, from within XO.
Signed-off-by: Thomas Moraine <thomas.moraine@vates.tech>
The documentation for mutliple plugins was updated or moved outside the general Plugins page over time.
As a result, the links contained in various plugin's Readme or Usage files got obsolete, as they all point to the general Plugins page, instead of the specific plugin documentations.
This commit updates those links with the relevant location.
Signed-off-by: Thomas Moraine <thomas.moraine@vates.tech>
Previously, the Readme and Usage files related to the server-usage-report plugin contained links pointing to a general page on plugins.
The server-usage-report plugin has since been documented in the Management → Manage infrastructure management page of the Xen Orchestra documentation. As a result, these links have become obsolete.
This commit make the obsolete links point to the actual, new documentation on the server-usage-report plugin.
Signed-off-by: Thomas Moraine <thomas.moraine@vates.tech>
See xoa#234
Prevent importing hub templates that are actually not templates.
Importing an incorrect template previously created a VM without any way to know it.
The Alerts page was not listed in the sidebar and duplicated content from the Alerts section in the Advanced page. This commit removes the standalone Alerts page and redirects all links pointing to it to the Alerts section of the Advanced page. This change also fixes a broken anchor warning in Docusaurus, which could prevent new documentation builds from succeeding.
Signed-off-by: Thomas Moraine <thomas.moraine@vates.tech>
* doc(XO): Explain VIFs and Network locking mode
VIFs and the Network locking mode were previously missing in the Xen Orchestra technical documentation, with details scattered across XO blog posts, CLI references in the XCP-ng doc, and other sources.
This commit adds information on VIFs and the network working modes to the XO documentation, making it a more complete and reliable reference for users.
Signed-off-by: Thomas Moraine <thomas.moraine@vates.tech>
* Update manage_infrastructure.md
---------
Signed-off-by: Thomas Moraine <thomas.moraine@vates.tech>
Co-authored-by: Julien Fontanet <julien.fontanet@vates.tech>
Fixes Zammad#38602
Introduced by #7247
Avoid immediately falling back to a hard shutdown when calling `VM.stop`,
especially in cases where a clean shutdown was requested explicitly by the user
like in `VM.setAndRestart`.
Rolling pool update (RPU) scheduling was introduced in Xen Orchestra 5.102 and mentioned in the corresponding blog post, but it was not included in the XO technical documentation.
This commit explains how to schedule RPUs, so users no longer need to refer to blog posts for instructions.
Signed-off-by: Thomas Moraine <thomas.moraine@vates.tech>
As mentioned in the XO 5.104 release blog post, we're gradually documenting the Xen Orchestra REST API using Swagger.
The REST API page in our technical documentation already has a 'Future Improvements' section, which seems like a good place to mention Swagger, even though the documentation process is still ongoing.
This way, users won't need to check the XO blog to learn about this feature.
Signed-off-by: Thomas Moraine <thomas.moraine@vates.tech>
The GitHub link in the footer was the default one used by the Docusaurus template.
This commit changes the link so that it points to the Xen Orchestra GitHub repository.
Correct a malformed link to the Support -> XOA Support -> XOA check section in the XO documentation, ensuring Docusaurus builds the doc properly.
Signed-off-by: Thomas Moraine <thomas.moraine@vates.tech>
The General Troubleshooting page is not listed in the sidebar and contains minimal content, making it suitable to be merged into the existing Troubleshooting page, which is already accessible. Consequently, the standalone General Troubleshooting page is no longer needed and is being removed.
Signed-off-by: Thomas Moraine <thomas.moraine@vates.tech>
While Software RAID is provided as-is, Xen Orchestra allows users to monitor the health of their software RAID arrays.
This includes a dedicated status interface and alert messages for any issues.
This information was previously documented in the Xen Orchestra 5.102 release blog post, and is now integrated into the XO technical documentation.
This update ensures users have a single reference point for technical information, eliminating the need to search through blog posts.
Signed-off-by: Thomas Moraine <thomas.moraine@vates.tech>
Differential restores were mentioned in the XO blog (release 5.89)
but not in the XO technical documentation.
This commit explains in the technical doc what differential restores are
and how to perform one from the XO interface.
Signed-off-by: Thomas Moraine <thomas.moraine@vates.tech>
Fixes Zammad#37604
Introduced by 36b94f745d
Since version 4, Redis' Node library doesn't support passing multiple flat
arguments to its methods to perform an action on multiple entries. It expects
an array instead.
we must compute a relevant partSize when uploading a file bigger than 50G
bigger partSize means more memory consumption, but we are limited to
upload 10K chunk of partSize bytes
this commit will ensure there is an estimate of the size from encrpted remote
and pass this estimate to the FullRemoteWriter
from ticket 38031
The usage-reports plugin was not covered at all in the Xen Orchestra technical documentation.
This improvement explains how to get usage reports from your resources, by enabling and setting up the plugin.
Signed-off-by: Thomas Moraine <thomas.moraine@vates.tech>
The XCP-ng doc has been recently updated with more details on how to migrate from VMware to a Vates environment,
with a choice of methods including V2V within Xen Orchestra.
As a result, a mention of V2V is added to the XO doc, with a link to the relevant section in the XCP-ng doc.
Signed-off-by: Thomas Moraine <thomas.moraine@vates.tech>
from ticket 37120
an EPERM error during a rmtree , called by the cleanup at the end
of a metdatadat backup, will trigger a ENOTDIR error
this can be caused by a misconfigured/failing immutable backup
remote without any VM ( either empty remote of config only remote)
are flooding the logs with errors like
Error: ENOENT: no such file or directory, scandir '/run/xo-server/mounts/f0952d37-294a-4d5e-8ba5-565e9932b4a7/xo-vm-backups'
I have checked the source code, and it uses a "Contains" and not some kind of "StartsWith" to check whether the disk name should be excluded.
I think it is important to clarify that it is possible to place the "[NOBAK]" label after the disk name, which might help some to maintain their naming convention.
- Updated VM creation code to match the TS typing and remove errors in `type-check`
- Refactored code
- Simplified and improved business logic
- Improved naming
Introduced by #3774
Introduced by #8412
ACLs feature is only available for XOA plans Enterprise and Premium. The
feature is properly disabled on the main ACL config page but was still
available from a VM's Advanced page and from the VM creation form.
Implement the mecanism to expose non XAPI object endpoints:
Added a new type, NonXapiXoRecord, which represents all XO objects that are not XAPI objects (e.g., users, servers, groups, etc.).
Split XapiXoController to create BaseController, allowing code reuse between XapiXoController and the new XoController.
BaseController exposes sendObjects and createAction (unchanged) and enforces subclasses to define the getObject and getObjects methods.
XoController requires subclasses to implement getAllCollectionObjects and getCollectionObject, as these are used in its getObjects and getObject methods.
filter and limit are handled by xo-server for XAPI objects. XoController implements its own filter and limit mechanisms for all non XAPI object in getObjects
And finally expose /rest/v0/servers and /rest/v0/servers/<server-id>🥳
Fix `Unsupported header 'x-amz-checksum-mode' received for this API call.`
on backblaze/cloudlfare object storage
from version 3.729, aws sdk send headers that aren't supported yet by backblaze
it happens when the source disk is not aligned with the vhd block size ( 2MB)
this PR will read more data into the grain directory / grain tables, but
this data won't be used since we use the virtual size to compute which
grain to read
from ticket 33018
doc(XO): Add Amazon S3 to list of supported remotes
Amazon S3 remotes have been supported for a while,
but there was no section mentioning it in the Backups → Remotes doc.
This is now fixed
Signed-off-by: Thomas Moraine <thomas.moraine@vates.tech>
Also, replace the screenshot of the file restore feature with an example that uses Linux instead of a Microsoft/NTFS resource
Signed-off-by: Thomas Moraine <thomas.moraine@vates.tech>
Introduced by 4eed730a09
Due to an issue with bump-pkg script, some packages were previously published on
NPM before their dependencies' versions were updated. This commit simply bumps
the versions of those packages to publish the correct list of dependencies.
@vates/types Added an export to the root of the lib because TSOA requires importing the type from the root library to generate the OpenAPI specification
@vates/types Tuples ([number, number]) throw errors when generating the OpenAPI specification. They have been updated to number[]
@vates/types Created a XapiXoRecord to be able to differentiate between XO types that come from xapi-object-to-xo and XO types that come from XO collections
xo-server Added getObjectsByType to avoid iterating over all XAPI objects when we know what type of object we want
Branded is not a valid type for the OpenAPI spec. I created a Unbrand type, that convert all Branded to string . (Use Unbrand only for OpenAPI specification definition to maintain Branded type safety)
Added another error middleware to catch TSOA errors and throw XO errors
Added a README.md to have consistency of order in the use of decorators
Document how to restore a file from a VHD with fuse-vhd CLI.
This will allow users to restore by themselves large files that make the restore fail when done from the UI.
Configure dependency injection + configure authentication middleware for openapi (copy of what actually exists in the current REST API. Will be improved later when implementing ACL/resource set)
A forum user suggested changes for better understanding of VM templates.
A new page has been created just for templates,
with Create, Read, Update, Delete (CRUD) sections.
Also, the Cloud-init/Cloudbase-init section of the Advanced page has been moved
to this new page.
This should make it easier for users to get all useful information on templates
in a single document.
Signed-off-by: Thomas Moraine <thomas.moraine@vates.tech>
Update the Xen Orchestra documentation to guide users
on transitioning from AES-256-GCM to ChaCha20-Poly1305 encryption,
solving an issue where users could encounter warnings due to mixed
encryption algorithms in remote storage.
Fix [this]((https://xcp-ng.org/forum/topic/10453/remote-encryption-algorithm)
Some users weren't able to sync all LDAP groups with XO.
Adding what to check to troubleshoot the issue.
Also, refreshing the style and presentation of the LDAP section in the Users page
XCP-ng 8.0 and 7.6 are references in multiple sections.
These versions are obsolete, nobody should be using SDN Controller on anything older than XCP-ng 8.2.
As a result, references to XCP-ng 8.0 and older can be removed safely.
Signed-off-by: Thomas Moraine <thomas.moraine@vates.tech>
Sometime, the name does not provide enough information about the VM, adding more with Description, we will know more which VM has issue with backup.
Co-authored-by: b-Nollet <150058367+b-Nollet@users.noreply.github.com>
Since XOSAN is now legacy and XOSTOR has taken its place, we are removing XOSAN from the Xen Orchestra doc.
Links to XOSAN docs are replaced with links to XOSTOR (from the XCP-ng doc).
Signed-off-by: Thomas Moraine <thomas.moraine@vates.tech>
Remember server's pool name and description, and display the pool name as server default label. The server label can be deleted (since 81e7e07) to get back to the default pool name value.
We did multiple commits to keep the original changes around, but I would advise not to review by commit.
XO-437
* feat(backups): don't use checksum if not needed
encrypted backups are already authenticated, this guarantee that
a readble file has not been modified
thus, no need to compute a relatively slow hash is encryption is already done
In some failure cases, backup reports were not sent because of an error during handlebars compilation.
The `formatDate` function was incorrectly passed from partial to partial causing the `executeFunction` helper to execute `undefined` as a function (the `vmFailure` helper used default `formatDate=./formatDate` instead of `formatDate=../formatDate`, the `..` being necessary because of the `#each` loop)
Introduced by aa9c49ce6a
Xen Orchestra now supports Cloudbase-init (for Windows VMs),
on top of the already-supported Cloud-init (for Linux VMs).
The Cloud-init section is therefore expanded to mention Cloudbase-init,
and we explain how to create a template for Windows VMs using Cloudbase-init.
* Introduced by 21f0643
* change padding and add class layout to fix issue with persistent scrollbar
* reduction of the size of the icon (in the center of the nav bar), when reducing the screen, to avoid the double scrollbar
New Job System that provides handling of asynchronous operations with built-in state management and identity-based concurrency control.
- Type-safe job definitions with typed arguments
- Concurrency control through identity tracking
- Built-in state management (`isRunning`, `canRun`, `errorMessage`)
- Argument validation
[host.setMaintenanceMode(true)] Allow bypassing blocked migration
in the UI
detect the error
display a modal indicating which VM cannot be migrated and asking if it should be bypassed
if it should, retry the call and pass vmsToForceMigrate
in xo-server
unblock migration for VMs in vmsToForceMigrate
XO-390
* feat(backups): implement long terme retention
long term retention sometimes called GFS ( Grand Father / Father / Son)
is a way to promote some backup to be kept on a long time
that way , the user can use the find the best equilibrium between
storage and security
This commit add the code mechanics to identify backup that
can be deleted safely. It is intended to use with a form
that ask the user for the number of day, week, month, and year
for which XO will keep the most recent
It extends the actual system of keeping the n most recent backup
Keep in mind that the backup promoted by week and month can be decaled
XO-375
In "remotes", fix nfs port if specified.
The problem : port was specified in url, when it should be specified as an option.
Options already exist. It should continue to work as before.
Set a minimum width for the "Patches" and "Status" cards to align with the design system and allocate enough space for displaying data when it is being loaded.
The goal of this new feature is to help developers investigate issues by
allowing them to easily gather more information.
When enabled, all logs emitted in a given API call are stored in a file
(`${tmpdir}/xo-api-${date}-${method}.log`).
Administrators can use the special `_log` param to request it:
```sh
xo-cli vm.start id=$id _log=json:true
xo-cli vm.start id=$id _log=failure
```
Or it can be enabled for all calls to a method in xo-server's configuration:
```toml
[api.logs]
'vm.start' = 'failure'
```
Migrate docs from VuePress wich is not maintained anymore, to Docusaurus, which is maintained and also used fro XCP-ng docs.
---------
Co-authored-by: Thomas Moraine <thomas.moraine@vates.tech>
- Update Vue `3.4` to `3.5`
- Update TypeScript `5.3` to `5.6`
- Update Pinia `2.1` to `2.2`
- Update `vite.config.ts` to import paths with `fileURLToPath` and `URL` instead of `resolve`
- Update `size.util.ts` to use named imports from `human-format`
- Fix TS error in `vite.config.ts`
- Fix TS error in `story-param.ts`
- Fix TS error in `UiCardNumbers.vue`
- Fix TS error in `tree-node-base.ts`
Replaces #8088
Introduced by f2fe7731d
This commit introduce two new `Collection/Redis` protected async methods:
- `_beforeAdd(model)`: called before a new model is added
- `_beforeUpdate(model, previous)`: called before a model is updated
If the method throws, the corresponding operation is aborted.
XO-386
When adding a nfs remote with encryption, the remote directory must be empty, then we create metadata.json and encryption.json on it.
If not, we fail to test these json files and the user receive an error "file not found: metadata.json" which is not understandable.
In this case, this PR return a message explaining the problem.
this lead to failing transfer when powering off the VM , since this is the
first api call after the export, that can take hours. The error code is a 500
We do a dummy vmware api call every 15 minutes, to ensure the session stays
up.
ticket 25980 and 29939
before this commit checkbasevdis is not called if there are no disks
this leads to an erronous error message `checkbasevdi must be called
before updateUuidAndChain for incremental backups` instead of a
message on the missing vhd
this wille trigger 'A differential VHD must have a parent' instead
Previously it failed with a similar error:
```
✖ TypeError [ERR_INVALID_URL]: Invalid URL
at new NodeError (node:internal/errors:405:5)
at new URL (node:internal/url:676:13)
at Object.exec (file:///usr/local/lib/node_modules/xo-cli/rest.mjs:188:21)
at COMMANDS.<computed> (file:///usr/local/lib/node_modules/xo-cli/rest.mjs:151:29)
at async main (file:///usr/local/lib/node_modules/xo-cli/index.mjs:434:14) {
code: 'ERR_INVALID_URL',
input: 'localhost'
}
```
Due to the way React works, `props.children` always change even if it will
resolve to the same DOM node.
The implementation is therefore updated to check equality on DOM nodes directly.
This makes the REST API more closely resemblethe JSON-RPC API and addresses
several issues such as the broken _Rolling Pool Update_ pool action.
Fixes https://xcp-ng.org/forum/post/82867
- waitObjectState already throw if timeout is reached
- gives more details to help user understand the issue
- timeout reached while waiting for ${refOrUuid} to be running
- timeout reached while waiting for ${refOrUuid} to report the
driver version through the xen tools.
This applies to both XML-RPC transport and results of XAPI tasks.
Before this commit, all whitespaces (spaces, new lines, etc.) were reduces to
a single whitespaces and leading and trailing whitespaces where removed.
This led to malformed values such as the result of `host.get_server_certificate`.
Prevent Vue upgrade to 3.5 and fix ESLint error in the demo story.
- The recent upgrade of XO Lite / 6 to Vue 3.5 broke the CI due to typing errors (778362d8db)
- Temporarily blocks Vue from upgrading beyond 3.4 to avoid CI failures
- Fixes an attribute case mismatch in the demo story that was causing an ESLint error
Backup job's speed limit (`maxExportRate`) had values `0` and `undefined`
leading to the same behaviour, but the values were both accepted, which could be
confusing. 0 values are now replaced by `undefined` when creating or editing a
backup job.
Fixes#7826
Sometimes XAPI takes too long to detach the VDI,
in this case, the timeout is fixed at 4s, non modifiable
when the timeout is reached the xapi raise a VDI_IN_USE error
This commit adds a retry on XO side to give more room for XAPI
to work through this process, as XO already does it on VDI destroy
bug not reproducted on our lab
apply the same patch as commit d2a897c3b88d478a04fef0fb75b809cacc80b97a
The disk attached to dom0 is a xapi internal process, this commit ensure
it is not taken into account when choosing a stratrgey to disable CBT
this commit also ensure the process is not stuck in infinite loop if the
xapi fail to disable CBT
disks could still be attached to dom0 after the transfers given the caches and the asynchronous nature of the operation.
This PR ensure the cache are fully up to date before running the destroy code and also will let the XAPI handle the disk attached to dom0, as it was before the refactoring
If the user defined a filter and the filter only match part of the full
backups, then we'll only transfer the matched backups
If the user is using incremental backup, then we'll trnsfer the full chain
if at least only one match
the algorithm sorting the backup to transfer do not take into account multiple
job writing to the same remote
It can lead to additional VM being transferred
Fixes https://xcp-ng.org/forum/post/81327
`allowed_operations` are currently not updated correctly when `blocked_operations` are modified, which causes backup jobs to remove `migrate_send` and `pool_migrate` from VM's `allowed_operations`. This commit fixes that, until `allowed_operations` updates correctly again.
Add storage repository info in the dashboard endpoint for the XO6 dashboard
replications and other data will be calculated in another PR as there is no trivial way to do it
```ts
{
// ...
"storageRepositories": {
"size": {
"available": number,
"other": 0,
"replicated": 0,
"total": number,
"used": number
}
}
}
```
The components `/host/[id]/index.vue` and `pool/[id]/index.vue` only use
`definePage()` macro.
The macro is removed during the build, leaving an empty script tag that causes
the build to fail.
This PR addresses this issue by adding a comment in the components to avoid
empty content in `<script>` tags at build time.
- `StateHero`, `LoadingHero` and `ComingSoonHero` can now be used inside a card by passing `type="card"` or inside a page by passing `type="page"`
- `LoadingHero` has now a `disabled?: boolean` prop and can now take a slot which will be displayed when `disabled` is `true`
- Added stories for `StateHero`, `ComingSoonHero`, `ObjectNotFoundHero` and `LoadingHero`
- Remove the responsibility to exclude branches with no children from `branch.ts`
- `PoolTreeItem` and `HostTreeItem` no longer create a sublist if they have no children
See https://xcp-ng.org/forum/topic/9392
`xo-server` has a config setting `http.publicUrl` that allows the user to force
XO to report a custom URL in the pool's other_config (along with the
`networkInterfaces` fallback). With this change, the "Access XOA" button in
XO Lite will open that URL if it exists and fallback to `networkInterfaces`
otherwise.
This shows a working example of how to connect XO SAML-plugin with Google Workspace SAML.
It's a rough example, with simple screenshots. And I've mentioned the caveat that a successfull authentication points the user to the login screen. Needing to browse into the bare URL, for access into the dahsboard. But at least it works!
* Update index.html
Rebased on latest commits.
* Create manifest.webmanifest
The initial PWA web manifest but rebased for latest commits.
* Update CHANGELOG.unreleased.md
Rebased on the latest commits as the conflicts were too major.
* Update CHANGELOG.unreleased.md
* Update CHANGELOG.unreleased.md
* Make URLs relative and remove changelog entry
---------
Co-authored-by: Pierre Donias <pierre.donias@gmail.com>
Fixes https://xcp-ng.org/forum/post/79769
This code, only used for running VMs, triggered `VDI_IN_USE` errors and left the
created VM snapshot with all the VDIs.
`debounceWithKey` should not be used because the API method will always be called with a different
empty object as param which will render the cache useless.
Fortunately `lodash.throttle` can be used here as `sr.getAllUnhealthyVdiChainsLength` is synchronous
and has no meaningful parameter.
* when using CBT backup, no rolling snapshot and NBD
* this will delete the snapshot data , thus limiting the pressure on the SR
* snapshot won't be listed in the UI
* snapshot won't be usable to revert a VM
Enable CBT for all backups
* enable cbt each time a VM should be backuped by nbd
* if there are no rolling snapshot on a job =>
the snapshots data are only kept during the transfer.
Snapshot data deletion is behing a config flag 'purgeSnapshotData' (default false )
adverse effect:
* rolling back to previous XO version will make full backups
* removed read ahead in nbd , performance gain was low with concurrency
and it make code more complex
- `[core]` Created a StateHero component
- `[core]` Created a `ComingSoonHero` component
- `[core]` Created a `LoadingHero` component
- `[core]` Created an `ObjectNotFound` component
- `[core;lite]` Moved `object-not-found` translation from Lite to Core
- `[core]` Updated `CoreLayout` to remove panel-related code
- `[web]` Renamed `DefaultLayout` to `AppLayout`
- `[web]` Wrap `RouterView` with `AppLayout` in `App.vue`
- `[web]` Removed all slots from `App.vue` but `default` one
- `[web]` Created `web/pages/vm/[id].vue` which handle layout around all `/vm/*` pages
Enable CBT for all backups
* enable cbt each time a VM should be backuped by nbd
* if there are no rolling snapshot on a job => the snapshots data are only kept during the transfer. Snapshot data deletion is behing a config flag 'purgeSnapshotData' (default false )
adverse effect:
* rolling back to previous XO version will make full backups
* removed read ahead in nbd , performance gain was low with concurrency and it make code more complex
Change Block Tracking (CBT) is blocking VDI migration from one storage to another
The migration errror is computed at the VM level on the xapi, that mean that we need to disable CBT for any disk of the VM that use a VDI
We don't enable CBT after the migration : any client / backup software that need this will need to enable it on demand, and a migration force a full transfer
host.evacuate don't move the vdi ,it can't generate a VDI_CBT_ENABLED error
See Zammad#24458
`xo-server-netbox` uses `response.text` which has been added in
http-request-plus@1.0.3. Therefore, the dependency version in `xo-server` needs
to be `^1.0.3` to ensure that `response.text` can be used.
- Add new i18n guidelines
- Remove nested keys: `"foo": { "bar": "..." }` ➡️ `"foo.bar": "..."`
This makes code cleaner (and as a side-effect, it now allows to use `foo` + `foo.bar` keys)
- Lite/6 shared translations are no longer prefixed with `core.`
- Duplicated keys across translation files are no longer accepted.
This will prevent accidental overwrite of missing common translations
- `fr.json` and `en.json` now required to contains the same keys
- Raw text is no longer accepted in template to prevent forgetting a translation
Raw text is still accepted in dev-related files (stories, dev pages...)
- Remove useless `alt` on `img`
- Display of percentage now uses `$n(value, 'percent')`
- Removed legacy `lite/src/i18n.ts`
- Add missing translations
- Added visual indicator for missing translations while in dev env: `🌎❗⟨i-am-missing⟩`
feat(backup): remove temporary VHD before backups run
- cleanVm can only delete files when backup job is successful
- an interrupted transfer leave the temp file in place
- the temp file don't change name in a mirror backup since we transfer exactly the same file
- outputStream method use, by default, a flag that create the file if not exists and fail otherwise
=> EEXIST error
- This PR change the behaviour of cleanVM to delete temporary files on the pass before the transfer, thus removing any dot file
---------
Co-authored-by: Julien Fontanet <julien.fontanet@isonoe.net>
Preparing for CBT backup that will only keep a part of the VDI snapshot, and remove the VM
* extract most of the other_config operation to a file as constants/methods
* name the constants
* set the relevant metadata values to the vm AND all its attached VDIs
* use the VDI as the base to search and update snapshots/replica/backup
Info, properties and warnings should be set on a specific/known task instead of relying on the async context.
For instance, this permits updating the progress of a task from the code on one of its subtasks.
Add `vue/define-macros-order` ESLint rules to ensure consistency across components.
Macros will require to be defined in the following order:
1. `defineOptions`
2. `defineProps`
3. `defineEmits`
4. `defineModel`
5. `defineSlots`
Also ensures `defineExpose` to be the last statement of `<script setup>`
web-core is published as a library so its dependencies need to be installed
when web installs its own dependencies
- packages that are (or will be) used by lite and web are declared as
dependencies in lite and web and as peerDependencies in web-core
- other packages that are only used in web-core are declared as dependencies in
web-core
This component is a grey line (hr). When its parent is a flexbox with
`flex-direction: column`, it is horizontal, and with `flex-direction: row`, it
is vertical.
Add `vue/define-emits-declaration` ESLint rule to ensure consistency in `defineEmits` syntax across the components.
It uses the new Vue 3.3+ more succinct syntax.
* make one query per host instead of one per object (VM or host ) per counter ( Memory/CPU)
* fix(xo-server-perf-alert): handle VM without guest tools that does not have memory used metrics
---------
Co-authored-by: b-Nollet <150058367+b-Nollet@users.noreply.github.com>
when a backup job does delta replication + backup and the replication
fails to find the base VM, the backup job does not proceed
This commit force the stream to continue to flow after unpiping a
descendant stream
Update stats instead of using cache when cache is exactly one step old. It avoids the stats to be twice the same in a row when fetching it every step.
Introduced by 8347ac6ed8
When XOA is connected to a pool, it adds information about itself on the pool's
other_config. We can use that in XO Lite to find the XOA's IP address and add a
link to open Xen Orchestra.
- Context now stores the selected/expanded/active IDs instead of the `TreeNode` to allow easy manipulation and initial hydration.
- Rename `activable` option to `selectable`
- Rename `labelClasses` to `statuses`
- Add `hasChildren` on `Branch`
- `predicate` now takes the `TreeNode` as argument instead of `TData`
- Add a `meta` option, to pass additional arbitrary data
This change allows to properly separate options and subcommands,
which opens the door to global options.
Previous syntax is still supported for now but will show a deprecation
message.
```sh
xo-cli --register
xo-cli --createToken
xo-cli register
xo-cli create-token
```
- Implement subscribable store on XO 6
- Fetch data from REST API
- Display infrastructure tree view
- Updated README
- Added dev pages:
- **index.vue**: empty page for component development
- **token.vue**: form to register or clear a token cookie
Add a helper which allow to easily create a subscribable store (store that return its context only after calling a subscribe method and handle what happen on subscribe/unsubscribe)
App-agnostic, to be used with XO Lite and XO 6.
this method internally calls the web service method ExportVM :
https://developer.vmware.com/apis/196/vim.VirtualMachine.html#exportVm
which can export all the disk of a stopped VM, regardless of the
datastore used, including VSAN
The disks are exported in stream optimized VMDK , with their
grain directory ( level 1 adressing table) at the end, and
all the data are stored in comrpessed grains with markers
New layout system with a default `CoreLayout` component which handle header +
resizable sidebar + content header + content + right panel header/content.
- Move i18n configuration from Lite to Core
- Add keyboard shortcuts (toggle lang / theme) to XO 6
- Add locales to Core
- Import Core locales into Lite and XO 6
use the currently mounted and enabled remote instead of mounting them
also this respect the mount point defined in config ( /run/xo-server/mount for xoa)
introduced by bb8c3c18e6
`undefined` CPU and memory thresholds were used in density plan to decide if a host can receive a VM or not, which made the host always accept it.
Introduced by 5a825bd459
This gives more detailed information (start, end, errors) and also adds support for subtasks.
Before:
```
2024-04-14T13:50:16.749Z xo:proxy:api WARN call error {
method: 'test.throw',
params: { message: 'foo' },
error: Error: foo
at Api.addMethods.test.throw.params.message.type (file://<...>/@xen-orchestra/proxy/app/mixins/api.mjs:227:19)
at m (file://<...>/@xen-orchestra/proxy/app/mixins/api.mjs:253:28)
at Api._call (file://<...>/@xen-orchestra/proxy/app/mixins/api.mjs:310:12)
at file://<...>/@xen-orchestra/proxy/app/mixins/api.mjs:90:44
at Zone.run (<...>/node_modules/node-zone/index.js:80:23)
at file://<...>/@xen-orchestra/proxy/app/mixins/api.mjs:90:29
at processTicksAndRejections (node:internal/process/task_queues:95:5)
at compressMiddleware (<...>/node_modules/koa-compress/lib/index.js:56:5)
}
```
After:
```
2024-04-14T13:49:17.102Z xo:proxy:api WARN call error {
id: 'qxhdytrtmvk',
properties: [Object: null prototype] {
method: 'test.throw',
params: { message: 'foo' }
},
start: 1713102557102,
status: 'failure',
end: 1713102557102,
result: Error: foo
at Api.addMethods.test.throw.params.message.type (file://<...>/@xen-orchestra/proxy/app/mixins/api.mjs:227:19)
at file://<...>/@xen-orchestra/proxy/app/mixins/api.mjs:264:39
at AsyncLocalStorage.run (node:async_hooks:346:14)
at Task.runInside (<...>/@vates/task/index.js:175:41)
at Task.run (<...>/@vates/task/index.js:158:31)
at m (file://<...>/@xen-orchestra/proxy/app/mixins/api.mjs:264:29)
at Api._call (file://<...>/@xen-orchestra/proxy/app/mixins/api.mjs:327:12)
at file://<...>/@xen-orchestra/proxy/app/mixins/api.mjs:92:44
at Zone.run (<...>/node_modules/node-zone/index.js:80:23)
at file://<...>/@xen-orchestra/proxy/app/mixins/api.mjs:92:29
at processTicksAndRejections (node:internal/process/task_queues:95:5)
at compressMiddleware (<...>/node_modules/koa-compress/lib/index.js:56:5)
}
```
this can happens when the xo-server is slow to update a faster XO
xapi.getObject throw a " no object with UUID or opaque " error during healtcheck phase
The normal upgrade is using the API call, the force upgrade is using the reboot workflow.
Also, we should not fallback to the reboot workflow automatically on API call failure
because it can be normal due to xoa-updater and/or XO Proxy being rebooted and rebooting
the VM may break the current upgrade and leave npm in an broken state.
This error should be log as well.
It does not break anything because it does prevent from fetching the state.
It should not happen a lot because the version of XO Proxy released alongside
this version of xo-server does provide this method.
- Migrate VM to NFS on VMWare side
- mount NFS in XO , named [VMWARE]{datastoreName}
- launch import and it will read through the direct NFS instead of using the soap access layer
### Description
To merge alongside https://git.vates.tech/vates/xoa/pulls/196
This is a change to remove the addition of `-00` that was used to reference packages installed via APT.
1. The [new apt repository](https://kubernetes.io/blog/2023/08/15/pkgs-k8s-io-introduction/) version number do not even match this convention anymore
2. We do not install Kubernetes packages with apt anymore, we install the binaries directly. The package versions number listed in GitHub are an exact match of the various binaries version we want to install
- international standard intended to be unambiguous and universal
- more compact than previous implementation
- alphabetic order is the same as temporal order
- easier to compare lines in a table
- uncoupled from the language selection: English speaking users are not forced to use US format
Fixes zammad#23139
Implement own parsing instead of `@sindresorhus/df` which breaks when headers
and values are not correctly aligned (i.e. big sizes).
This simple parsing should be good enough.
See @sindresorhus/df#13
Fixes#7477#7490#7496#7499#7502
Introduced by 6c16055a1
`putResource()` is not using `undici` for the moment because it needs
work to make it work with the work-around for chunked encoding not
supported in XAPI.
When a console connection fails, we wait before trying again. While waiting,
the user may open another console, which creates a new VNC Client, and renders
the console. Therefore, when we're done waiting, we must first check that
`vncClient` is `undefined` so that we don't create 2 instances of `VncClient`.
* fix(xen-api): various undici fixes
Fixes#7465
Introduced by bfb8d3b29
- don't use single Client as it allows a single parallel request by default
- fix HTTP proxy support (for all methods but `putResource()`
- follow redirects
- `getResource` respect configured protocol
- properly throws on non 2xx responses
New way to manage collections and sub-collections of items.
It handles different informations (id, label, depth, css classes etc.), status
(active, selected, expanded, etc.), filtering, actions (activate, select, select
children etc.), optional multi-select and generation of selection label (`Foo`,
`Foo, Bar, Baz`, `5 items selected`)
This file contains documentation to help people contributing to the project,
either by participating on the community forum, reporting issues, or creating
a PR on the documentation or the code.
Most of it was created by https://generator.contributing.md/
Fixes zammad#21585
Previous implementation was only parsing the scsi part of the vm metadata file ( .vmx).
This commit also looks at the ide part and add them to the disk list to be handled ( transferred to XCP) ,while ignoring the cdrom
The previous implementation only considered version upgrades and did not take into account the installation of missing patches.
See zammad#21487
Introduced by 85ec261
This leads to a retransfer and a EEXIST error while writing the metadata.
It can happen when a mirror transfer to multiple remotes, fails on one remote and is restarted/resumed.
Introduced by 1da05e239
Since task data were moved into properties, the relation between an object and
its tasks was incorrectly checked which led to an abnormal empty tasks list.
In Settings/Logs modals : transform objects UUIDs into clickable links, leading
to the corresponding object page.
For objects that are not found, UUID can be copied to clipboard.
Introduces `@xen-orchestra/web`, which will be the home for the new incoming
Xen Orchestra v6.
It uses `@xen-orchestra/web-core` as a foundation.
Upgraded common dependencies of Lite/Web/Core.
Fixes#7059
In case a slave host requires a reboot to apply updates and the master is using
the same version as the slave host, a confirmation modal is triggered.
This PR introduces `@xen-orchestra/web-core`, which will be the common base for
XO Lite and XO 6.
This package is not meant to be distributed and will be used as-is in other
packages thanks to Yarn Workspace. This mean that the files of XO Web Core will
not be built by themselves but by either the package which use it.
Styles have been moved from XO Lite to XO Web Core.
Colors variable have been renamed and updated according to the new Design
System. XO Lite has been updated accordingly.
- `extra-blue` → `purple`
- `green-infra` → `green`
- `orange-world` → `orange`
- `red-vates` → `red`
- `blue-scale` → `grey`
⚠️ A new intermediate shade has been introduced (`--color-grey-400`). So
`--color-blue-scale-400` is now `--color-grey-500` and `--color-blue-scale-500`
is now `--color-grey-600`.
PostCSS color function plugin is used to generate the shades of color like it is
done on the Figma mockup (with blending the base color with black or white at
different degrees).
PostCSS custom media are now loaded globally thanks to a plugin and no longer
require to import `_responsive.pcss` file manually in each file where a custom
media was needed.
The initial support added in #7055 to support terraform resource support doesn't provide read access to a VM's state.
Since Tterraform's model requires read and write access to the resource it's managing, this PR implements the missing piece for terra-farm/terraform-provider-xenorchestra#261.
Expired certificates are not automatically detected, which is not a big deal for user certificates because they can still be used and it's their responsibility to update them.
But automatic certificates must be regenerated in that case which was not the case until now.
This commit unifies certificate/key reading, checking and generation for both xo-server and xo-proxy.
This change follows a discussion with Marc Pezin and Yannick on Mattermost.
As Yannick pointed out, the doc refers to a remote while there is no such option in XO GUI.
Based on #7258 developed by @fbeauchamp.
- use inline blocks to respect all paddings/margins
- main settings are in easily modifiable variables
- text color is either black or white based on the background color luminance
- make sure tags and surrounding action buttons are aligned
- always display value in black on white
- delete button use tag color if dark, otherwise black
- Tag component accept color param
@@ -16,7 +16,7 @@ Returns a promise wich rejects as soon as a call to `iteratee` throws or a promi
-`concurrency`: a number which indicates the maximum number of parallel call to `iteratee`, defaults to `10`. The value `0` means no concurrency limit.
-`signal`: an abort signal to stop the iteration
-`stopOnError`: wether to stop iteration of first error, or wait for all calls to finish and throw an `AggregateError`, defaults to `true`
-`stopOnError`: whether to stop iteration of first error, or wait for all calls to finish and throw an `AggregateError`, defaults to `true`
@@ -34,7 +34,7 @@ Returns a promise wich rejects as soon as a call to `iteratee` throws or a promi
-`concurrency`: a number which indicates the maximum number of parallel call to `iteratee`, defaults to `10`. The value `0` means no concurrency limit.
-`signal`: an abort signal to stop the iteration
-`stopOnError`: wether to stop iteration of first error, or wait for all calls to finish and throw an `AggregateError`, defaults to `true`
-`stopOnError`: whether to stop iteration of first error, or wait for all calls to finish and throw an `AggregateError`, defaults to `true`
* @param {Array|Buffer|string} data1 - The first data array or buffer to compare.
* @param {T} data2 - The second data array or buffer to compare.
* @param {(index: number, diff: T) => void} [cb] - The callback function to invoke for each difference. If not provided, an array of differences will be returned.
* @returns {Array<number|T>|undefined} - An array of differences if no callback is provided, otherwise undefined.
* @returns {Array<number|T>|undefined} - An array of differences if no callback is provided; otherwise, undefined.
A standalone FAT16/FAT32 implementation that takes in a block-access interface and exposes something quite similar to `require('fs')` (i.e. the node.js built-in [Filesystem API](http://nodejs.org/api/fs.html)).
## Installation
`npm install fatfs`
## Example
```js
varfatfs=require('fatfs'),
fs=fatfs.createFileSystem(exampleDriver)// see below
fs.stat('autoexec.bat',function(e,stats){
if(e)console.error(e)
elseconsole.log(stats)
})
// TODO: open a file and write to it or something…
```
## API
-`fs = fatfs.createFileSystem(vol, [opts], [cb])` — Simply pass in a block driver (see below) mapped to a FAT partition somewhere, and get back an instance of an [`fs`](http://nodejs.org/api/fs.html). An options dictionary can be provided, details are in the next section. You may also optionally provide a callback `cb(err)` which will be automatically registered for the on `'ready'` or `'error'` event.
-`'ready'` event — fired on `fs` when initial volume information has been determined and the API is ready to use. It is safe to call other `fs` methods before this fires **only if** you are sure the first sector will be readable and represents a valid FAT volume.
-`'error'` event — fired if initialization fails for whatever reason.
### Filesystem options
The `opts` dictionary you pass to `fatfs.createFileSystem` can contain any of the following options:
-`ro` — Enables readonly mode if `true`. It defaults to `false`, but if your volume driver does not provide a `writeSectors` method it will be overridden to `true`.
-`noatime` — The FAT filesystem can track the last access time (just a date, actually) but this means every read operation would also incur some write overhead. Defaults to `true`, meaning by default access times will **not** be updated on reads. Set this to `false` to track access times.
-`modmode` — chooses how `fs.chmod` (and the mode field from `fs.stat`–family calls) should map FAT attributes to POSIX permissions. Set to the number `0111` to map the readonly flag to the user's write bit being unset, and the archive/system/hidden flags to the user/group/other executable bits respectively. Set to the number `07000` to map the readonly flag to _all_ write bits being unset, and the archive/system/hidden flags to the sticky/setgid/setuid bits respectively. Set to `null` for readonly mapping. Defaults to `0111`.
-`umask` — any bits _set_ in this octal number will be _unset_ in the 'mode' field from `fs.stat`–family calls. It does not affect anything else. Defaults to `process.umask()`, or `0022` if that is unavailable.
-`uid` — This value will be returned as the 'uid' stat field. It does not affect anything else. Defaults to `process.getuid()`, or `0` if that is unavailable.
-`gid` — This value will be returned as the 'gid' stat field. It does not affect anything else. Defaults to `process.getgid()`, or `0` if that is unavailable.
(Note that these are similar to the options you could use with a POSIX `mount` operation.)
And that's it! The [rest of the API](http://nodejs.org/api/fs.html) (`fs.readdir`, `fs.open`, `fs.createReadStream`, `fs.appendFile`, etc.) is as documented by the node.js project.
Well, sort of…
## Caveats
### Temporary
- **BETA** **BETA****BETA**. Seriously, this is a _brand new_, _from scratch_, _completely unproven_ filesystem implementation. It does not have full automated test coverage, and it has not been manually tested very much either. Please, please, please, **make sure you have a backup** of any important drive/image/card you unleash this upon.
- A few methods are not quite implemented, either: `fs.rename`, `fs.unlink` and `fs.rmdir`, as well as `fs.watchFile`/`fs.unwatchFile` and `fs.watch`. These are Coming Soon™.
- There are several internal housekeeping items (redundant FAT tables, extra FAT32 information, etc.) that are not done. These do not seem to affect interop, but you may see warnings when repairing a filesystem written by this module.
- Oh, and not to scare you, but if an IO error happens while writing, the library usually just bails — bubbling an error up to your callback as if it were a hot potato. Although some attempt has been made to do separate writes in the safest order (e.g. allocating an additional file cluster, then appending data into it, and then finally updating the file's size), but this behavior has not been thoroughly audited for all operations. There's certainly no attempt to retry/cleanup/rollback if a multi-step change runs into trouble partway through.
### As-planned
Some of the differences between `fatfs` and the node.js `fs` module are "by design" for architectural simplicity and/or due to underlying FAT limitations.
- There are no `fs.*Sync` methods. (The volume driver is async, not to mention that supporting a separate \*Sync codepath would be an enormous duplication of effort of dubious value.)
- This module does [almost] no read/write caching. This should be done in your volume driver, but see notes below.
- You'll need multiple `createFileSystem` instances for multiple volumes; paths are relative to each, and don't share a namespace.
- The FAT filesystem has no concept of symlinks, and hardlinks are not really an intentional feature. You will get an ENOSYS-like error when trying to create either type of link.
## "Volume driver" API
To use 'fatfs', you must provide a driver object with the following properties/methods:
-`driver.sectorSize` — number of bytes per sector on this device
-`driver.numSectors` — count of sectors available on this media
-`driver.readSectors(i, dest, cb)` — Fill `dest` with data starting at the `i`th sector and notify `cb(e)` when finished. You may assume `dest.length` is a multiple of `driver.sectorSize`.
-`driver.writeSectors(i, data, cb)` — (optional) Write `data` starting at the `i`th sector and notify `cb(e)` when finished. You may assume `data.length` is a multiple of `driver.sectorSize`.
If you do not provide a `writeSectors` method, then `fatfs` will work in readonly mode. Pretty simple, eh? And the 'fatfs' module makes a good effort to check the parameters passed to your driver methods!
**TBD:** to facilitate proper cache handling, this module might add an optional `driver.flush(cb)` method at some point in the future.
Here's an example taken from code used to run this module's own tests:
```js
// NOTE: this assumes image at `path` has no partition table.
// If it did, you'd need to translate positions, natch…
The `remoteUrl` can be found using the following command from the XOA CLI, and then picking the right `url` property:
`xo-server-db ls remote`
The `vhdPathInRemote` follows a file structure described in [VM backups](https://github.com/vatesfr/xen-orchestra/blob/master/%40xen-orchestra/backups/docs/VM%20backups/README.md).
## Restore a file from a VHD using `fuse-vhd` CLI
1. Mount a VHD to the Filesystem (see **Usage**).
2. Verify the VHD is Correctly Mounted:
`mount | grep fuse`
3. Get the `START` and `SIZE` of the disk whose file you want to restore. Multiply `START` by 512 (block size) to get the offset value. (`mountedVhdPath` is the `mountPoint` value from earlier, followed by `/vhd0`, for example). Depending on the partition type, you may need to do some additional setup to discover the partitions.
4. Mount the disk. Depending on the partition type, you may need to add some additional options. The `norecovery` option is used for ext3/ext4/xfs file systems; otherwise, remove this option.
The `remoteUrl` can be found using the following command from the XOA CLI, and then picking the right `url` property:
`xo-server-db ls remote`
The `vhdPathInRemote` follows a file structure described in [VM backups](https://github.com/vatesfr/xen-orchestra/blob/master/%40xen-orchestra/backups/docs/VM%20backups/README.md).
## Restore a file from a VHD using `fuse-vhd` CLI
1. Mount a VHD to the Filesystem (see **Usage**).
2. Verify the VHD is Correctly Mounted:
`mount | grep fuse`
3. Get the `START` and `SIZE` of the disk whose file you want to restore. Multiply `START` by 512 (block size) to get the offset value. (`mountedVhdPath` is the `mountPoint` value from earlier, followed by `/vhd0`, for example). Depending on the partition type, you may need to do some additional setup to discover the partitions.
4. Mount the disk. Depending on the partition type, you may need to add some additional options. The `norecovery` option is used for ext3/ext4/xfs file systems; otherwise, remove this option.
wrap a source async generator to have it respect a max speed ( in bytes per seconds).
speed is either a strictly positive number or a function returning a strictly positive number. A speed change will be used for the next emitted packet.
The source generator must yield object with a length property.
Optimized for small yields regarding to the speed, since it won't split incoming packet.
If the generator reached the max speed it will be paused, limiting memory consumption.
wrap a source async generator to have it respect a max speed ( in bytes per seconds).
speed is either a strictly positive number or a function returning a strictly positive number. A speed change will be used for the next emitted packet.
The source generator must yield object with a length property.
Optimized for small yields regarding to the speed, since it won't split incoming packet.
If the generator reached the max speed it will be paused, limiting memory consumption.
Creates a new server instance. `opts` may contain `createServer` and `createSecureServer` factories (defaults to `http.createServer` and `https.createServer`). `requestListener` is registered as a `request` event listener.
```js
import{create}from'@vates/http-server-plus'
constserver=create(functiononRequest(req,res){
res.end('Hello')
})
```
### `server.listen(opts)`
Starts listening. Returns a promise that resolves to a human-readable address string, or rejects with `error.niceAddress` set.
```js
// HTTP on a specific port
awaitserver.listen({port:8080})
// HTTPS — detected automatically when cert+key are provided
awaitserver.listen({
port:443,
cert:fs.readFileSync('certificate.pem'),
key:fs.readFileSync('private_key.pem'),
})
// Unix socket
awaitserver.listen({socket:'/var/run/http.sock'})
// File descriptor
awaitserver.listen({fd:3})
// Systemd socket activation
awaitserver.listen({systemdSocket:0})
```
> As a convenience, if `hostname` is `'localhost'`, it will listen on both `127.0.0.1` and `::1`, similar to what Node does when no hostname is provided.
Multiple endpoints can be started on the same instance:
> Augmented `http.Server`, HTTP/HTTPS/HTTP2 and multiple ports on the same instance
## Install
Installation of the [npm package](https://npmjs.org/package/@vates/http-server-plus):
```sh
npm install --save @vates/http-server-plus
```
## Usage
### `create([opts], [requestListener])`
Creates a new server instance. `opts` may contain `createServer` and `createSecureServer` factories (defaults to `http.createServer` and `https.createServer`). `requestListener` is registered as a `request` event listener.
```js
import{create}from'@vates/http-server-plus'
constserver=create(functiononRequest(req,res){
res.end('Hello')
})
```
### `server.listen(opts)`
Starts listening. Returns a promise that resolves to a human-readable address string, or rejects with `error.niceAddress` set.
```js
// HTTP on a specific port
awaitserver.listen({port:8080})
// HTTPS — detected automatically when cert+key are provided
awaitserver.listen({
port:443,
cert:fs.readFileSync('certificate.pem'),
key:fs.readFileSync('private_key.pem'),
})
// Unix socket
awaitserver.listen({socket:'/var/run/http.sock'})
// File descriptor
awaitserver.listen({fd:3})
// Systemd socket activation
awaitserver.listen({systemdSocket:0})
```
> As a convenience, if `hostname` is `'localhost'`, it will listen on both `127.0.0.1` and `::1`, similar to what Node does when no hostname is provided.
Multiple endpoints can be started on the same instance:
| Connections per session | `MaxConnections=1`, enforced | opens exactly one |
| Session reinstatement | **no** — no ISID tracking; once a new connection has established a Normal session (CHAP included), it tears down and replaces whatever connection currently exists, rather than RFC 7143's ISID-matched reinstatement (see `index.mts`'s class doc for the reasoning: safe here because the target is ephemeral, single-consumer, and CHAP-guarded). Until then it does not affect the current one, and is bounded by `loginTimeoutMs` and `maxPendingConnections` | n/a (single connection) |
| Multiple LUNs | **no** — exactly one LUN, always LUN 0 | reads are hardcoded to LUN 0 |
| `ErrorRecoveryLevel` | `0` only | requests `0` |
| Header/data digests | `HeaderDigest=None`, `DataDigest=None` — no CRC32C on the wire | same |
| Markers (`IFMarker`/`OFMarker`) | not offered (RFC-deprecated) | not offered |
## Login / text negotiation
**Target** (`login.mts`) reactively answers whatever the initiator proposes, fixed to:
| `INQUIRY` | standard + EVPD `0x00`/`0x80`/`0x83` (vendor/product/revision/serial from `identity`) and `0xb0` (block limits: `maxTransferLength`) |
| `REPORT LUNS` | |
| `READ CAPACITY` | `(10)` and `(16)` |
| `READ` | `(10)` and `(16)`; longer than `maxTransferLength` → `INVALID FIELD IN CDB` |
| `WRITE` | `(10)` and `(16)`; longer than `maxTransferLength` → `INVALID FIELD IN CDB`; on a `readOnly` LUN → `DATA PROTECT` / `WRITE PROTECTED`, without soliciting data |
| `TEST UNIT READY` | |
| `REQUEST SENSE` | |
| `MODE SENSE` | `(6)` and `(10)`; `WP` set on a `readOnly` LUN |
| `SYNCHRONIZE CACHE` | `(10)` and `(16)` — flushes the backing `BlockDevice` |
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
