🛰️ XO 6: dedicated thread for all your feedback!

[julienXOvates]

@jr-m4 said:

@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

Hi @jr-m4, it took some time but we corrected the identation in 6.7 (latest)

[vuanhson]

Will XO6 implement chart resize feature? The chart view is break on device with small screen, can't drag drop or resize the chart

[olivierlambert]

Yes, charts rendering is not optimal yet. IIRC, it's planned to get better card organization in the future. Stay tuned!

[coolsport00]

I made it through the whole year's updates on this thread. Took me a while

I never saw if the VM UEFI issue was resolved in a patch to XO? (I'm on "sources")

Also, I scrolled around my XO6 UI...saw several changes since my last logon. You all are making progress! Glad to see. Would like to see some of the Pool ("Cluster") configs make it to XO6 sooner than later if possible (i.e. Load Balancing, HA, etc). Also, would like a "cleaner" config interface for those things than what's shown in XO5. BTW...if I'm missing those configs in XO6, apologies, but I hadn't seen them yet.

Appreciate all your efforts thus far!

Oh, and for those who are not aware, Veeam now officially supports XCP-ng for backup. Looking forward to them also enabling Replication like they just did for Proxmox.

Thanks!

[poddingue]

Depends which one you mean, because there are two different problems tangled together in this stretch of the thread and they have opposite answers.

If you mean @escape222's report at #177, where a VM cloned from XO 6 sits at the TianoCore screen for a couple of minutes, then yes, that was an XO bug and it is fixed. PR #9867, merged 26 May, shipped in XO 6.5.0 on 28 May. The boot order was being rewritten whenever no new disk needed provisioning, so an HVM VM created from a template that already had a disk got network pushed to the front whether or not anyone asked for a network install, and the VM burned the PXE timeout before falling through to the disk. It now follows the install method only. Since you are on sources, anything past 6.5.0 has it.

If you mean the slow UEFI boot @MajorP93 described at #182, with the installing Xen timer and spinlock lines, that one is not an XO bug and no XO patch will touch it. It is a regression in the Linux guest kernel introduced in 6.12.5. The cost lands per secondary vCPU, so the wider the VM, the worse it looks. There is a separate thread with the per-vCPU numbers: Ubuntu cloud images on XCP-ng 8.3 UEFI. Worth noting its title blames console=ttyS0, which we now think amplifies the same bug rather than being a second one.

I measured that one here this week on a single host, changing only the guest kernel between runs and leaving everything else alone. Ubuntu 7.0.0-30 came in at 50 and 59 seconds across two runs. 7.0.0-31 came in at 0.4. Wall clock reboot to sshd went from 78 seconds to 31.

The awkward part is the timing. The upstream fix is f24df84cbe05, in stable 6.12.97 and later, 6.18.y, 7.1.4 and later, and 7.2, but no default channel carries it yet. I re-checked the archives this evening: Debian trixie still ships 6.12.94-1, with 6.12.100-1 sitting in proposed-updates for the next point release, and Ubuntu 26.04 still ships 7.0.0-30 in updates, published today, while 7.0.0-31 has been in proposed since 10 August. Rocky and el10 I could not confirm either way. So keep whatever workaround you are on until a named version lands for your distro.

There is arguably a third one at #183, where @Greg_E had Debian 13 and Windows Server 2022 refusing to boot at all when created through XO-lite with UEFI. As far as I know nobody has retested that since.

If it is the kernel one you are hitting, this says which version you are waiting for:

uname -r
dmesg -T | grep -iE "installing Xen timer|spinlock event"

[coolsport00]

@poddingue said:
Depends which one you mean

Thanks for the update! I meant the one where the VM was hanging because of incorrect boot order; but, good to know about the other issues. I'm moderately ok on Linux, but not so much so to where I fully understand the long boot time you go into (& divinni in the other thread)

I had an issue in XO-Lite myself last yr. That sounds a bit like I had; or, I believe the issue was BIOS vs UEFI. If I created the VM with BIOS, I could boot/set it up...but not able to with UEFI.

Thanks!

[poddingue]

On the XO Lite one, there's an issue open that sounds like what you're describing, https://github.com/vatesfr/xen-orchestra/issues/9801, filed off @Greg_E's report in this thread.
It says UEFI VMs created through XO Lite don't boot since the LTS release, with Debian 13 and Windows Server 2022 both failing, while VMs built under 8.2 with UEFI still work.

Your timing may not line up, since you're saying last year and that issue is scoped to since the LTS release, so I'd rather ask than assume.
If it does look like yours, a comment on it would carry more than anything I can add, because it hasn't had one since May and I don't think anyone has picked it up.

[Greg_E]

@poddingue I haven't had time to get back and check this, my lab hasn't even had power on it for about 4 months.

[coolsport00]

@poddingue maybe it was this yr? Heck...the days & months just run together on me anymore I'll check that out. Appreciate it!

[poddingue]

Thanks!

[coolsport00]

Maybe I missed this somewhere...but in XO6 > Quick Actions, is it planned to add a Migration option there? I think that is a needed high action item. I don't see Migrate anywhere in XO6 (yet). BTW, I'm going through all the XO 6.x updates posts. I've not yet finished reading through them, so apologies if it was mentioned in one that I haven't read yet

[julienXOvates]

@coolsport00 you mean migrate VM ? it's not yet there in XO6, but we'll bring it soon (hopefully in the next 2 months).

[coolsport00]

@julienXOvates Ok, great. Sounds good...thank you Julien!

Also, do you all have GPU passthrough yet? I'm really needing that function for a VDI setup i have. Thanks!

[MihaiAmbrosie]

@coolsport00 It looks like it is supported https://xcp-ng.org/forum/topic/11034/gpu-passthrough/19#

[pdonias]

Hello everyone! We need you!

We're currently designing the XO 6 UI for non-admin users, and some choices are genuinely hard to make. If you'd like to give us your opinion, here's a 30-second survey with 2 questions we couldn't settle ourselves: https://survey.vates.tech/s/cms4nrqb4005wrw01021ru6dy

Thanks!

[acebmxer]

@pdonias said:

Hello everyone! We need you!

We're currently designing the XO 6 UI for non-admin users, and some choices are genuinely hard to make. If you'd like to give us your opinion, here's a 30-second survey with 2 questions we couldn't settle ourselves: https://survey.vates.tech/s/cms4nrqb4005wrw01021ru6dy

Thanks!

Thank you with presenting us with a choice. I have made my comments and offered a 3rd option.

[rcolzen]

Hello, I hope this is the correct place to report this issue.

Short version:

When an XO-managed NFS remote became unreachable, XOA Web UI would not become operational. Once the NFS server became reachable again, the UI immediately recovered.

Investigation and Findings

We just updated our XOA to ver. 6.8.2, and discovered that if an NFS remote becomes unavailable, XOA Web UI does not load correctly and appears unavailable to users. This has not been an issue with previous versions.

We had some network changes in our environment, and because of that the network to one of our NFS remotes broke for some time. The XOA UI would not load at all, despite being up before our network broke the connection to the NFS.

Checking logs, we observed repeated warnings such as:

TimeoutError: operation timed out

for the remote.

Additionally, XOA reported:

Setting up /v5
Setting up /v6
Setting up /

and:

Web server listening on http://[::]:80
Web server listening on https://[::]:443

which suggests the web service itself started.

Also, xoa check reported all fine.

However, as long as our NFS was unreachable, no user could not access a functional Web UI, either v6 or v5.

Root Cause

One of the configured NFS remotes was unavailable:

172.24.44.140:/mnt/Storage01/vm-iso-store

After connectivity to the NFS server (172.24.44.140) was restored, the Web UI immediately became operational again.

Before connectivity was restored:

• df -h was hanging for an extended period.
• XOA Web UI was unavailable.
• xoa check did not identify the problem.
• Multiple remote timeout errors appeared in the logs.

After NFS connectivity returned:

• df -h completed immediately.
• XOA Web UI became available again.
• No manual XO intervention was required.

We expect an unavailable NFS remote (an ISO repository) should mark the remote as unavailable, and allow XO/XOA Web UI to load normally.

If this is not the correct place for this type of bug report, please feel free to move it or point me to the appropriate location. I wanted to make sure the issue was reported and documented.

Thanks.

[coolsport00]

@MihaiAmbrosie Sorry Mihai...just now seeing your response. I'm looking at this now. I'll need to test it all out. I hope it works!

[coolsport00]

@pdonias Filled out Pierre! Thanks for allowing us to provide feedback!

[coolsport00]

And sadly...the documentation for GPU passthrough states currently, due to proprietary code in Xenserver (blah!), NVIDIA is not (yet) supported