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

ping @poddingue for visibility as I believe I've found the trigger for IPv6 expanding... Live Migrations

@olivierlambert said:

Ah sorry I read it too quickly. This panel is only there in some occasions, but I see the point of only displaying it when we click on a relevant element. Feedback for you @julienxovates

While on the topic of the tree-view panel.
Have you noticed that the indentation changes if there is a chevron indicating that there are VMs on a host? Making it so that the hosts no longer are alinged vertically

@olivierlambert said:

@jr-m4 do you know you can collapse the side bar? Use the hamburger icon just after "Xen Orchestra" title to do so.

Yes, but it is the rightmost pane that I'm not agreeing with.
The left most "tree-view"-sidebar is quite usefull. And has imho good potential.

@julienXOvates said:

@colomb said:

I really miss the description column XO5 has in the default/home view. I understand space is limited for the tree view, but maybe it could appear when a host is selected in the tree view?

In XO6, you will see it if you click on the eye at the end of the row, then on the right panel.
Is this OK ?

Personally I don't really find the rightmost pane/section all that usefull. It's to narrow to have any clear information. And it also leads to the other panels being smaller than they (imho) need to be able to show their base information as well.
This is especially noticable when using windows sizes narrower than 1080p.

The rightmost pane I hope will get either removed, and redone in UI v7. Because right now XO5 is far more informational than that is.

Sorry for jumping on with my two cents.

@poddingue

Thanks for your input.
Yes I'm aware that basically everything on the VM is incorporated into the snapshot. Including settings and metadata. This is acctually why I was surprised that the creation date wasn't preserved as part of that metadata. And as you say, if one uses that metric to track VM history. Then it can, and will, throw you off.

I'll gladly submit this as a feature request. But my gut feeling is that it is more akin to a bug than missing feature per se.

Thanks!

@TeddyAstie

I do not have Citrix ones. This VM was pretty much freshly installed to test Windows2025 on as pure Vates-maintained stack as possible.

Update: Please note my post above. Tha this seems to be triggered by live-migrating the vm

I believe I have a reproducible method to make it expand.
The trick aparently is Live migrating the VM.

After reboot

Pre live migration:

Post live migration:

I have now tried updating to the latest version included in the xcp-ng guest-tools.iso. Followed by a reboot.

At the moment, the zeroes are collapsed. But I won't count my chickens before they've hatched. So I will reply back if they expand out again (as seen before).

Thanks!

@dinhngtu said:

@jr-m4 Could you check if your VMs are using XenServer or XCP-ng tools?

They are using the vates provided xcp-ng guest tools.

After applying latest updates and commits, to both xcp and XO. The zeroes were still non-collapsed.

However. Rebooting the VM resulted in the zeroes now collapse properly as expected.

I had previously rebooted the VM, so I don't believe that was the solution. But I did not check inbetween pulling latest source, and updating XCP. So I'm unsure which update solved it.

But this then has been resolved.
Update: Not solved! Now on fully updated XCP & XO, and the VM being rebooted as per post-details above.