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

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.

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

Experimenting in the lab.
Using
XCP-NG: 8.3 (yum upgraded)
XO Source: a5967

I have Rolling Snapshots set. And it seems that regardless of what the retention is set too. Older snapshots are not cleaned up/removed.
In the screenshots below you'll see that I have set it to 2. But the number of [XO Backup Rolling Snapshot] are more than that.

Am I doing something wrong? Am I misunderstanding something on a fundamental level? Or is this just not working as expected?

I am all ears.

Good morning

Anyone with a working SAML configuration that uses Google as the IdentityProvider? Looking more specifically to what to enter each of the field with (on both XO Source and the SAML-section on Google Workspace SAML app).

I tried somewhat yesterday, but couldn't really get it to work.

I'll be trying more during the week. But if someone could help out, it would be greatly apreciated.

PS: I've decided to not use the auth-google plugin. Since this requires to setup via the GCP-console. And I'd like to keep my SSO's consolidated in (mostly) one place.