jr-m4

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

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

@olivierlambert

Thanks again for your input and recomendations! I'll verify that this is solved by having the LUN expanded to 8GB instead. Afterwards I'll mark your answer as the solution!

@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 at the moment doing alot of test with V2V (applause on getting rid of the vddk-dependency btw )

However, what I'm noticing is that the migrated VMs don't automatically start when the import has completed. This is contrary to current documentation.

Is this a potential bug? Or am I missing something obvious?

PS: The imports are all sucessfull. It's just the auto-start part that I'm noticing doesn't work.

Cheers!

Commit: dc573

Template used for testig is: Rocky Linux 9

@florent & @poddingue

I have now uploaded two heap-snapshots for you to look at.
If there is anything else, big or small, that I can help out with. Just let me know

Thanks!

I just did a quick test to check. And it does indeed seem that this (small) issue has now been resolved.
Tested on Windows Server 25, Management agent 9.2.385-0.

Cheers!

@poddingue said:

On the tuning suggestion, my guess, untested and purely from reading your paste, is that if something is genuinely holding sockets then raising tcp_mem buys headroom rather than stopping the accumulation, and your post#4 about throughput coming back on an xo_server restart points the same way.

It might be worth a mention to @Team-XO-Backend, since they would know whether xo-server keeps sockets per pool.

This is why I'm not increasing the numbers quite yet. Since this would only mask a potential issue. If an underlying cause is responsible, then this would be of interest.

Thanks for chiming in!

@poddingue

I have done some more testing.
Windows Server 2022 is also affected. 9.1.145-77

I also tried the latest WindowsPV drivers from Vates, on Windows Server 2025. 9.1.200-0. And the "problem" still persists.

It is a very low impact and low importance "problem". Since it is afaik purely costmetical.