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

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.

@john-c
well, me too. But since it gets neither at the moment. And being realistic in that they can't be excpected to keep up with every distro in existance. I'll take what I reasonably can get

Update: Let me clarify. If there could be Distro specific logos, then that would be awesome. However, if we could get a generic Tux for Linux in general. Then that would cover a large part of the variants out there.

Hi

Sorry for necroposting this one.
But it felt relevant, to ask if maybe we could put some Rocky in there are well?

On my lab VMs I'm running Rocy8.9 at the moment. But If we could just get "rocky" in general with a generic Tux as the symbol, then that would be more than good enough.

xe vm-param-list uuid=LARGESTRING | grep distro
                            os-version (MRO): name: Rocky Linux release 8.9 (Green Obsidian); uname: 4.18.0-513.11.1.el8_9.0.1.x86_64; distro: rocky; major: 8; minor: 9

@olivierlambert
I am

Update:
Correction.. I run this script I pasted above. That builds the entire code AFAIK. As to what specific portions of the code that acctually get recompile. I do not know.