@MathieuRA

I noticed you merged https://github.com/vatesfr/xen-orchestra/pull/9787

I just tried it. And it does seem to fix my original issue!

Thank you! I am always impressed by you guys. Making testing and reporting upstream (to you guys) a good experience!

Elise-FZI opened this pull request in vatesfr/xen-orchestra

closed fix(xo6): remove dev routes from prod #9787

I submitted this as a GitHub issue last week.

TL;DR: Backblaze aparently doesn't support those flags that are enabled by default
"Backblaze does not yet accept these headers, so we recommend downgrading to AWS Javascript 3.x SDK version 3.728.0."

https://github.com/vatesfr/xen-orchestra/issues/8358

cloudrootab created this issue in vatesfr/xen-orchestra

open S3 Backup: "Unsupported header 'x-amz-checksum-mode' received for this API call." #8358

@olivierlambert
I've finally had time to sit down and do some more troubleshooting.
It seems that the issue is somehow tied to the backup-jobs themselves.
Deploying XOA and subsequently importing XO-config from my XOCE instance. I continued to see several issues between both instances.
These issues pretty much went away, when I re-did the backup-jobs from scratch. And are now much more in-line with what I'm excepting to see. This was done on both XOA Stable, Latest and XOCE

I am no longer able to repoduce this at all.
So my guess is that a bug of some sort got introduced with this being a constantly updated from source instance.

Marking as solved. As I don't believe there is much more to do at this time.

@McHenry
Differences could be things such as:

• Amount of cores between hosts for migrations
• Guarantee performance between guests. So that they don't affect each other as much.

Same with overprovisioning dynamic RAM

@MathieuRA
The sdn-plugin is back. I am amazed by that quick resonse and fix. THANKS!

However, the issue with @xen-orchestra/web/typed-router.d.ts being locally modified during compilation, is still present. Leading to have to git restore @xen-orchestra/web/typed-router.d.ts before being able to pull from github.

The build-script that I use is based on (then) official docs

#!/bin/bash
set -ex
set -o pipefail
git checkout .
git pull --ff-only
yarn
yarn build

Small discrepancy: VDIS or VDIs? Which one is it?

Red points out where it's called VDIS.
Green where it is called VDIs.

And as a bonus feedback/question. Why is it called "A VDIS" ?(marked with yellow)

Clicking through the different parts in the leftmost pane has (what feels like) inconsistent landing pages. When in reality, it lands on the previous tab visited for that item.

Example.
If I click on Xen Orchestra Appliance I would expect to land on the Dashboard tab. But if I had previously looked inside the Pools tab, then that is where I would land.

This behaviour is the same regardless of which item I click through. Be it Pool/Host/Guest..

I'll admit that it kind of makes a little bit of sense in thought. But it feel far more jarring and confusing when navigating. Since you never really know which tab you'll be met with when browsing. As each and every level/item is handled individually, separate from all others.

@robbie-c said:

I've searched for forum posts and can't see anything related to this.

The date format on our new XCP-ng interface only seems to show US dates (MM/DD/YY), which is pretty confusing for us here in Australia!
I can't see anything in the settings to change this, is there something I'm missing?

I'm guessing it's pretty confusing for most non-US people, including Swedes.

@MathieuRA

I noticed you merged https://github.com/vatesfr/xen-orchestra/pull/9787

I just tried it. And it does seem to fix my original issue!

Thank you! I am always impressed by you guys. Making testing and reporting upstream (to you guys) a good experience!

Elise-FZI opened this pull request in vatesfr/xen-orchestra

closed fix(xo6): remove dev routes from prod #9787

May I suggest adding @xen-orchestra/web/typed-router.d.ts to the .gitignore-file perhaps?

Update:
Not needed. This was aparently fixed properly in commit. Se my next post below.

I'm guessing this comes from commit https://github.com/vatesfr/xen-orchestra/pull/9700

As this one lists the rows in typed-router.d.ts I mentioned above.
But those lines are present in the latest commit?

I am super confused

Elise-FZI opened this pull request in vatesfr/xen-orchestra

closed fix(xo6): remove dev pages in prod #9700

@MathieuRA
The sdn-plugin is back. I am amazed by that quick resonse and fix. THANKS!

However, the issue with @xen-orchestra/web/typed-router.d.ts being locally modified during compilation, is still present. Leading to have to git restore @xen-orchestra/web/typed-router.d.ts before being able to pull from github.

The build-script that I use is based on (then) official docs

#!/bin/bash
set -ex
set -o pipefail
git checkout .
git pull --ff-only
yarn
yarn build

@mathieura
I will test it immediately and report back

@MathieuRA

Apr 29 11:27:48 w-v-xo-lab-0 xo-server[103260]: 2026-04-29T09:27:48.505Z xo:plugin INFO failed register sdn-controller
Apr 29 11:27:48 w-v-xo-lab-0 xo-server[103260]: 2026-04-29T09:27:48.505Z xo:plugin INFO Cannot find module 'api-errors.js'
Apr 29 11:27:48 w-v-xo-lab-0 xo-server[103260]: Require stack:
Apr 29 11:27:48 w-v-xo-lab-0 xo-server[103260]: - /opt/xen-orchestra/packages/xo-server-sdn-controller/dist/index.js {
Apr 29 11:27:48 w-v-xo-lab-0 xo-server[103260]:   error: Error: Cannot find module 'api-errors.js'
Apr 29 11:27:48 w-v-xo-lab-0 xo-server[103260]:   Require stack:
Apr 29 11:27:48 w-v-xo-lab-0 xo-server[103260]:   - /opt/xen-orchestra/packages/xo-server-sdn-controller/dist/index.js
Apr 29 11:27:48 w-v-xo-lab-0 xo-server[103260]:       at Module._resolveFilename (node:internal/modules/cjs/loader:1476:15)
Apr 29 11:27:48 w-v-xo-lab-0 xo-server[103260]:       at wrapResolveFilename (node:internal/modules/cjs/loader:1049:27)
Apr 29 11:27:48 w-v-xo-lab-0 xo-server[103260]:       at defaultResolveImplForCJSLoading (node:internal/modules/cjs/loader:1073:10)
Apr 29 11:27:48 w-v-xo-lab-0 xo-server[103260]:       at resolveForCJSWithHooks (node:internal/modules/cjs/loader:1094:12)
Apr 29 11:27:48 w-v-xo-lab-0 xo-server[103260]:       at Module._load (node:internal/modules/cjs/loader:1262:25)
Apr 29 11:27:48 w-v-xo-lab-0 xo-server[103260]:       at wrapModuleLoad (node:internal/modules/cjs/loader:255:19)
Apr 29 11:27:48 w-v-xo-lab-0 xo-server[103260]:       at Module.require (node:internal/modules/cjs/loader:1576:12)
Apr 29 11:27:48 w-v-xo-lab-0 xo-server[103260]:       at require (node:internal/modules/helpers:153:16)
Apr 29 11:27:48 w-v-xo-lab-0 xo-server[103260]:       at Object.<anonymous> (/opt/xen-orchestra/packages/xo-server-sdn-controller/src/index.js:17:1)
Apr 29 11:27:48 w-v-xo-lab-0 xo-server[103260]:       at Module._compile (node:internal/modules/cjs/loader:1830:14)
Apr 29 11:27:48 w-v-xo-lab-0 xo-server[103260]:       at Object..js (node:internal/modules/cjs/loader:1961:10)
Apr 29 11:27:48 w-v-xo-lab-0 xo-server[103260]:       at Module.load (node:internal/modules/cjs/loader:1553:32)
Apr 29 11:27:48 w-v-xo-lab-0 xo-server[103260]:       at Module._load (node:internal/modules/cjs/loader:1355:12)
Apr 29 11:27:48 w-v-xo-lab-0 xo-server[103260]:       at wrapModuleLoad (node:internal/modules/cjs/loader:255:19)
Apr 29 11:27:48 w-v-xo-lab-0 xo-server[103260]:       at loadCJSModuleWithModuleLoad (node:internal/modules/esm/translators:326:3)
Apr 29 11:27:48 w-v-xo-lab-0 xo-server[103260]:       at ModuleWrap.<anonymous> (node:internal/modules/esm/translators:231:7)
Apr 29 11:27:48 w-v-xo-lab-0 xo-server[103260]:       at ModuleJob.run (node:internal/modules/esm/module_job:437:25)
Apr 29 11:27:48 w-v-xo-lab-0 xo-server[103260]:       at runNextTicks (node:internal/process/task_queues:65:5)
Apr 29 11:27:48 w-v-xo-lab-0 xo-server[103260]:       at processImmediate (node:internal/timers:472:9)
Apr 29 11:27:48 w-v-xo-lab-0 xo-server[103260]:       at node:internal/modules/esm/loader:639:26
Apr 29 11:27:48 w-v-xo-lab-0 xo-server[103260]:       at Xo.registerPlugin (file:///opt/xen-orchestra/packages/xo-server/src/index.mjs:379:19) {
Apr 29 11:27:48 w-v-xo-lab-0 xo-server[103260]:     code: 'MODULE_NOT_FOUND',
Apr 29 11:27:48 w-v-xo-lab-0 xo-server[103260]:     requireStack: [
Apr 29 11:27:48 w-v-xo-lab-0 xo-server[103260]:       '/opt/xen-orchestra/packages/xo-server-sdn-controller/dist/index.js'
Apr 29 11:27:48 w-v-xo-lab-0 xo-server[103260]:     ]
Apr 29 11:27:48 w-v-xo-lab-0 xo-server[103260]:   }
Apr 29 11:27:48 w-v-xo-lab-0 xo-server[103260]: }

Also noticing now that the SDN-plugin is gone?

Will step through commits to try and find what has happened.

When building from source, it seems that there are local changes introduced. This makes it so further git checkouts and pulls fail.

The changes are happening in @xen-orchestra/web/typed-router.d.ts. And it seems to remove a bunch of lines

Output from: git diff @xen-orchestra/web/typed-router.d.ts

diff --git a/@xen-orchestra/web/typed-router.d.ts b/@xen-orchestra/web/typed-router.d.ts
index 14c7c20be..28df58897 100644
--- a/@xen-orchestra/web/typed-router.d.ts
+++ b/@xen-orchestra/web/typed-router.d.ts
@@ -31,11 +31,6 @@ declare module 'vue-router/auto-routes' {
     '/backup/[id]/configuration': RouteRecordInfo<'/backup/[id]/configuration', '/backup/:id/configuration', { id: ParamValue<true> }, { id: ParamValue<false> }>,
     '/backup/[id]/runs': RouteRecordInfo<'/backup/[id]/runs', '/backup/:id/runs', { id: ParamValue<true> }, { id: ParamValue<false> }>,
     '/backup/[id]/targets': RouteRecordInfo<'/backup/[id]/targets', '/backup/:id/targets', { id: ParamValue<true> }, { id: ParamValue<false> }>,
-    '/dev/': RouteRecordInfo<'/dev/', '/dev', Record<never, never>, Record<never, never>>,
-    '/dev/colors': RouteRecordInfo<'/dev/colors', '/dev/colors', Record<never, never>, Record<never, never>>,
-    '/dev/icons/': RouteRecordInfo<'/dev/icons/', '/dev/icons', Record<never, never>, Record<never, never>>,
-    '/dev/icons/[name]': RouteRecordInfo<'/dev/icons/[name]', '/dev/icons/:name', { name: ParamValue<true> }, { name: ParamValue<false> }>,
-    '/dev/token': RouteRecordInfo<'/dev/token', '/dev/token', Record<never, never>, Record<never, never>>,
     '/host/[id]': RouteRecordInfo<'/host/[id]', '/host/:id', { id: ParamValue<true> }, { id: ParamValue<false> }>,
     '/host/[id]/console': RouteRecordInfo<'/host/[id]/console', '/host/:id/console', { id: ParamValue<true> }, { id: ParamValue<false> }>,
     '/host/[id]/dashboard': RouteRecordInfo<'/host/[id]/dashboard', '/host/:id/dashboard', { id: ParamValue<true> }, { id: ParamValue<false> }>,

I don't really know what or why this happens.

Sometimes "# Disk Space" for VMs reports 0 in the central pane. But the assigned space is shown in the details (right) pane.

This is the same under Pool and Host-level. Sometimes it is shown, but after a reload of the page, it resets back to 0.

Marked the examples in red.