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

Baronvaile

@acebmxer Correct, this is with XOA. While watching the journalctl and launching XOA in chrome, I get this output.

ph7

[17:00 30] xoa@xoa:~$ sudo journalctl -u xo-server -f
Apr 30 16:23:13 xoa xo-server[569]: 2026-04-30T14:23:13.264Z xo:main INFO Setting up / → /usr/local/lib/node_modules/@xen-orchestra/web/dist
Apr 30 16:26:27 xoa xo-server[569]: 2026-04-30T14:26:27.942Z xo:rest-api:error-handler INFO [GET] /users/370331c9-fe77-49db-b2a0-e38f776607bd (403)
Apr 30 16:26:28 xoa xo-server[569]: 2026-04-30T14:26:28.549Z xo:rest-api:error-handler INFO [GET] /pools (403)
Apr 30 16:26:28 xoa xo-server[569]: 2026-04-30T14:26:28.555Z xo:rest-api:error-handler INFO [GET] /hosts (403)
Apr 30 16:26:28 xoa xo-server[569]: 2026-04-30T14:26:28.563Z xo:rest-api:error-handler INFO [GET] /vms (403)
Apr 30 16:26:28 xoa xo-server[569]: 2026-04-30T14:26:28.627Z xo:rest-api:error-handler INFO [GET] /tasks (403)
Apr 30 16:26:28 xoa xo-server[569]: 2026-04-30T14:26:28.812Z xo:rest-api:error-handler INFO [GET] /alarms (403)
Apr 30 16:26:28 xoa xo-server[569]: 2026-04-30T14:26:28.812Z xo:rest-api:error-handler INFO [GET] /vm-controllers (403)
Apr 30 16:26:28 xoa xo-server[569]: 2026-04-30T14:26:28.813Z xo:rest-api:error-handler INFO [GET] /vdis (403)
Apr 30 16:26:28 xoa xo-server[569]: 2026-04-30T14:26:28.813Z xo:rest-api:error-handler INFO [GET] /srs (403)

acebmxer

I didnt refresh the page when i ran the blow command before.

xoa@xoa:~$ sudo journalctl -u xo-server -f
Apr 30 10:28:02 xoa xo-server[568]:     at new Promise (/usr/local/lib/node_modules/xo-server/node_modules/bluebird/js/release/promise.js:103:10)
Apr 30 10:28:02 xoa xo-server[568]:     at Peer.request (/usr/local/lib/node_modules/xo-server-xoa/node_modules/json-rpc-peer/src/index.js:139:12)
Apr 30 10:28:02 xoa xo-server[568]:     at JsonRpcWebSocketClient.call (/usr/local/lib/node_modules/xo-server-xoa/node_modules/jsonrpc-websocket-client/src/index.js:63:23)
Apr 30 10:28:02 xoa xo-server[568]:     at Xoa.apply [as _getCurrentChannel] (/usr/local/lib/node_modules/xo-server-xoa/src/index.js:704:45)
Apr 30 10:28:02 xoa xo-server[568]:     at Xo.<anonymous> (file:///usr/local/lib/node_modules/xo-server/src/xo.mjs:256:24)
Apr 30 10:28:02 xoa xo-server[568]:     at Config.getGuiRoutes (file:///usr/local/lib/node_modules/xo-server/node_modules/@xen-orchestra/mixins/Config.mjs:102:52)
Apr 30 10:28:02 xoa xo-server[568]:     at main (file:///usr/local/lib/node_modules/xo-server/src/index.mjs:1037:56)
Apr 30 10:28:02 xoa xo-server[568]: 2026-04-30T15:28:02.981Z xo:main INFO Setting up /v5 → /usr/local/lib/node_modules/xo-web/dist
Apr 30 10:28:02 xoa xo-server[568]: 2026-04-30T15:28:02.981Z xo:main INFO Setting up /v6 → /usr/local/lib/node_modules/@xen-orchestra/web/dist
Apr 30 10:28:02 xoa xo-server[568]: 2026-04-30T15:28:02.981Z xo:main INFO Setting up / → /usr/local/lib/node_modules/@xen-orchestra/web/dist
Apr 30 10:29:00 xoa xo-server[568]: 2026-04-30T15:29:00.487Z xo:rest-api:error-handler INFO [GET] /users/f1397281-6d64-442b-a78c-e53fea09aa76 (403)
Apr 30 10:29:01 xoa xo-server[568]: 2026-04-30T15:29:01.014Z xo:rest-api:error-handler INFO [GET] /pools (403)
Apr 30 10:29:01 xoa xo-server[568]: 2026-04-30T15:29:01.020Z xo:rest-api:error-handler INFO [GET] /hosts (403)
Apr 30 10:29:01 xoa xo-server[568]: 2026-04-30T15:29:01.027Z xo:rest-api:error-handler INFO [GET] /vms (403)
Apr 30 10:29:01 xoa xo-server[568]: 2026-04-30T15:29:01.044Z xo:rest-api:error-handler INFO [GET] /tasks (403)
Apr 30 10:29:01 xoa xo-server[568]: 2026-04-30T15:29:01.077Z xo:rest-api:error-handler INFO [GET] /alarms (403)
Apr 30 10:29:01 xoa xo-server[568]: 2026-04-30T15:29:01.079Z xo:rest-api:error-handler INFO [GET] /vm-controllers (403)
Apr 30 10:29:01 xoa xo-server[568]: 2026-04-30T15:29:01.082Z xo:rest-api:error-handler INFO [GET] /vdis (403)
Apr 30 10:29:01 xoa xo-server[568]: 2026-04-30T15:29:01.088Z xo:rest-api:error-handler INFO [GET] /srs (403)
Apr 30 10:29:13 xoa xo-server[568]: 2026-04-30T15:29:13.204Z xo:rest-api:error-handler INFO [GET] /users/f1397281-6d64-442b-a78c-e53fea09aa76 (403)
Apr 30 10:29:13 xoa xo-server[568]: 2026-04-30T15:29:13.748Z xo:rest-api:error-handler INFO [GET] /alarms (403)
Apr 30 10:29:13 xoa xo-server[568]: 2026-04-30T15:29:13.751Z xo:rest-api:error-handler INFO [GET] /vm-controllers (403)
Apr 30 10:29:13 xoa xo-server[568]: 2026-04-30T15:29:13.751Z xo:rest-api:error-handler INFO [GET] /srs (403)
Apr 30 10:29:13 xoa xo-server[568]: 2026-04-30T15:29:13.751Z xo:rest-api:error-handler INFO [GET] /vdis (403)
Apr 30 10:29:13 xoa xo-server[568]: 2026-04-30T15:29:13.753Z xo:rest-api:error-handler INFO [GET] /pools (403)
Apr 30 10:29:13 xoa xo-server[568]: 2026-04-30T15:29:13.778Z xo:rest-api:error-handler INFO [GET] /hosts (403)
Apr 30 10:29:13 xoa xo-server[568]: 2026-04-30T15:29:13.778Z xo:rest-api:error-handler INFO [GET] /vms (403)
Apr 30 10:29:13 xoa xo-server[568]: 2026-04-30T15:29:13.784Z xo:rest-api:error-handler INFO [GET] /tasks (403)

MathieuRA

Hello, I'm investigating the problem.

MathieuRA

Can someone open a support tunnel, so that i can test a fix?

PR: https://github.com/vatesfr/xen-orchestra/pull/9798

MathieuRA opened this pull request in vatesfr/xen-orchestra

closed fix(rest-api): early return for admin user in acl check #9798

Baronvaile

@MathieuRA

MathieuRA

Thanks @Baronvaile. Can i restart xo-server?

Baronvaile

Sorry, I was out for a bit. Yes, you can restart my xoa.

acebmxer

@MathieuRA

If you still are waiting i have opened a support tunnel - 35965 this is for my home lab. You may reboot XOA if needed.

MathieuRA

Thanks @Baronvaile, the fix seems to work.

@acebmxer i will also patch your XOA, It's better to have several confirmations

Baronvaile

Can confirm that XOA v6 looks good now.

MathieuRA

@acebmxer It also works on your XOA.

Thank you both for your availability for testing. I will see with the XO team when to release a fix.

We apologize for any inconvenience

Baronvaile

@MathieuRA Thank you for the team's and specifically your dedication to the project and the quick turn around time.

acebmxer

@MathieuRA

Confirmed Dashboard now loads correctly.

poddingue

@Baronvaile said:

After upgrading from 6.3.3 to the new 6.4.0 release, the dashboard page for xoa 6 is just spinning. v5 seem unaffected after the update. I have restarted the xoa vm. The xoa-updated show all up to date and xoa check shows healthy.

Thanks for the detailed report and the journalctl output, and to @acebmxer and @ph7 for the confirmations. I've filed this upstream as GitHub issue #9799 so the dev team can track it properly. The in-thread fix from @mathieura got your instances running again, but the root cause is worth investigating so it doesn't come back in a future update. I'll update the issue if anything changes on that front.

poddingue

@probain said:

probain said:

Unfortunately, commit https://github.com/vatesfr/xen-orchestra/pull/9727 doesn't fix this issue of the VM-console reloading constantly. With loss of focus as a result. At least not on XO6..

PR #9727 was supposed to fix this but it sounds like the problem is still there on XO 6 for you. I've filed it as GitHub issue #9800 so the team can take another look with fresh eyes. If you have any more details about when the reload triggers (for example, whether it happens more on certain browsers or VM types) adding them to the issue would probably help narrow it down.

pierre-briffaux opened this pull request in vatesfr/xen-orchestra

closed fix(vm/console): fix VNC reconnection causing focus loss #9727

poddingue

@Greg_E said:

@MajorP93

Before the LTS release UEFI worked extremely well, something kind of went sideways when it hit release. I only have a single UEFI VM, it was created under version 8.2 and does not give me trouble.

I guess I need to get my lab back up, had a UPS fail and shut everything off a few days ago. Then I need to test UEFI VMs and see what I can see. But back when it went LTS I reinstalled from scratch and tried to do everything through XO-lite to get the first VM running and found that Debian 13 or Windows Server 2022 would not boot if I created them with UEFI. Since then I haven't tested this again.

I'm also tempted to just move my whole lab to version 9, waiting for the next ISO to land and I may do this. I can run real testing workloads on Harvester for the time being and maybe play around migrating back and forth between both systems.

Logged this as GitHub issue #9801. The detail that 8.2-era UEFI VMs still work but new ones created through XO Lite don't is a useful clue for the team to narrow the scope. Worth checking if the same behavior shows up when creating the VM through XO 5 vs XO Lite, in case it's a frontend difference rather than hypervisor-level. Either way, the issue is now tracked.

poddingue

@escape222 said:

Slow booting on Debian 13 VM created from a template

I recently tried cloning a VM from a template (created from a full install of Debian 13). What was noticed was that the system takes forever to boot when the VM is created from XO-6. The issue does not happen in XO-5. The VM seems to hang at the TianoCore boot screen .

What I noticed is that when the VM is cloned with XO-6 the boot order somehow changes to Network boot as the first option

This does not happen (change of boot order) if the VM is cloned from XO-5 and there is no boot delay. The boot process seems to wait for more than 2 minutes before it fails network boot and then proceeds normally to boot from the Hard drive

Thanks

This one's filed as GitHub issue #9802. The clone inserting Network Boot as the first option is reproducible and @MajorP93 confirmed the extended boot time with spinlock messages too, which strengthens the report. Both symptoms are in the issue. If you find a workaround in the meantime (like manually reordering boot entries post-clone), adding it to the issue would be useful for others hitting the same thing.

MajorP93

@poddingue Hello, while I -as a user- appreciate that you coordinate these bug reports I do wonder: is the GitHub issues section of Xen Orchestra really the preferred way of reporting issues?
This is also a valuable information for me personally.
In the past I felt like issues at the XO github repository often did not get the level of attention by the developers compared to reporting the issues here on the forums.
I wrote some XO github issues in the past as well and noticed that some never got any response and/or update.
Reporting these things here on the forums mostly felt more "productive".
Looking forward to getting some insights in this regard.
Thanks and best regards

poddingue

@MajorP93: Thanks for expressing yourself regarding that, and I'll be transparent about the thinking behind it.

Filing those on GitHub isn't me asking anyone to stop using the forum, quite the opposite in fact.
The forum is where real conversations happen, and that's valuable in a way a GitHub issue never quite is. But forum threads scroll, get buried, and developers can't easily maintain a stable backlog out of them. GitHub gives the team a place where things don't disappear or get buried.

Think of it as belt and suspenders (which I need now that I'm getting old ). The discussion lives here, the tracking lives there. My goal as community manager is to be the relay between the two, so you don't have to worry about it.
File things here, talk about them here, and I'll make sure what matters makes it into the right repo.
Or at least, that's the plan. Mine.