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

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.

Throwing my two cents into the hat, as well.

I had a similar situation. Snapshots would't be rotated out of retention, regardless of what I set on the retention setting (on a subset of VMs ie not all of the).. The thing that solved it for my, was to recreate the affected schedule.
Do note that this will mark the previous backups taken by that technically deleted schedule, as being abandoned/orphaned.

But after I did this, snapshots would be properly rotated as expected.

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)

@probain said:

said in ️ XO 6: dedicated thread for all your feedback!:

Windows guests Console - Reloads every 5-10s.

When trying to use the console for both my Windows 11 and Server 2025. The console reloads every 5-10s. This makes it borderline unusable. Since it resets the viewport/window scroll placement as well. Also the console seems to loose focus when this happens as well. Leading to have to click the console-section to get it in focus, to receive I am not seeing this behaviour in XO5 at all.

.
.
.
.
Unfortunately this is still present in commit 0a0ae5dc7ea6608612d105f6338ffe72d8bd9ed1 as well..

Update: I recorded the behaviour, for better clarification:
https://www.youtube.com/watch?v=PXpBFgSl31U

I'm noticing the same, or at least very similar, behaviour on some linux VMs now also.

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.

Noticed one smallish thing

When creating a new VM. It creates a Disk-name based on the template you use. However, if you were to change the template for some reason. Maybe you have shaky hands and accidentally chose the wrong list-item. Then the disk name isn't changed, but stays its original set value - based on the first template.

I'm expericing the same/similar behaviour with SAML, and submitted a Feature Request that it should be looked at.

https://xcp-ng.org/forum/topic/10430/feature-request-if-authenticated-don-t-stop-at-the-xo.company.net-signin-page

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

I'm seeing similar when trying to migrate a VM between hosts

Reverting to commit:

 a89c31c75b197fafab059d59f597cd3b98a175f1

@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

@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.