Hi, I think I've identified the issue. The OIDC plugin assumes the identity provider will always return the requested profile fields, but it doesn't handle the case where they're missing. Error 1 (Expected 'undefined' to be 'string' with usernameField: uid): passport-openidconnect only maps standard OIDC fields (displayName, username, emails) onto the profile object. Custom fields like uid are only available in the raw claims (profile._json), but the plugin doesn't look there. Error 2 (Cannot read properties of undefined (reading '0') with usernameField: email): The plugin tries to access profile.emails[0].value without checking that profile.emails exists first. If your provider doesn't return the email claim (which SURF/SRAM doesn't by default — only openid is provided), it crashes. I've opened a draft PR that fixes both issues by falling back to raw OIDC claims and giving a clear error message when the field is genuinely missing: https://github.com/vatesfr/xen-orchestra/pull/9648 Could you test it? You'd need to build from that branch. If the fix works, you should either get a successful login (if the field exists in the raw claims) or a clear error message telling you exactly which field is missing — instead of the current cryptic crashes. Also, it would help to confirm what your provider actually returns. You can check by temporarily adding this line in packages/xo-server-auth-oidc/index.js at line 136 (before the registerUser2 call): console.log('OIDC profile:', JSON.stringify(profile, null, 2)) Then check the xo-server logs after a login attempt. olivierlambert opened this pull request in vatesfr/xen-orchestra draft fix(xo-server-auth-oidc): handle missing profile fields in username resolution #9648

Est que si imaginons mes hote sont sur eth0 et ma vm xoa sur eth1 sa joue ? ou pas

@Danp Sorry for the late reply – I was in fits of laughter and completely forgot to ask my question. My question is: when I want to shut down a node with VMs on it, the HA will cause the following: [image: 1774855043154-033232c1-b000-4854-acea-171eed970a70-image.jpeg]

Good moaning... The solution was pretty simple: a toolstack restart on the master (xcp83) did get all back on track and it now allows me to move the systems with a simple shutdown/start.

Not sure the issue, but rebooted the host and everything is fine again. I definitely had rebooted the host twice though after applying the patches and physically unplugged and moved the host.

@olivierlambert & @mathieura thanks for the speedy response. Duly noted, very much appreciated.

@bvivi57 Hello ! Déjà bravo pour le travail d'écriture, faire plusieurs articles aussi long, avec screenshot et commandes CLI intégré, c'est un boulot de fou ! J'ai rapidement parcouru tous tes articles, je prendrais le temps de tout relire pour te faire un feedback complet avec quelques tips, si tu le souhaites ! Sur le dernier article, j'ai vu que tu as redémarré xo-serveur parce que tu n'arrivais pas à te reconnecter au master: tu peux (dans XO5, pas encore XO6) juste aller dans setting server, et cliquer sur le bouton "disconnect" et "reconnect". Ça va forcer une reconnexion à la XAPI, et si elle est disponible, ça va reconnecter ton pool instantanément à ton XO. Redémarrer un XO, surtout si tu as plusieurs pools, peut avoir certaines conséquences : Si tu as des backups en cours, ça va les kill instantanément, pareil pour les migrations entre deux pools différents. Il faut y aller doucement avec un systemctl restart xo-server En tout cas merci pour ces articles, je suis heureuse de voir que la communauté francophone s'intéresse de plus en plus à l'écosystème XCP-ng/XO (et je dit ça en tant qu'"early" qui utilise la solution depuis... longtemps ! )

@AlexanderK The ronivay script requires you to select an option (#2 to update). I look at things this way, it's good to have more people working on scripts like this.

There's no small contributions, every one of them are great & welcome!

Yes indeed, that's expected. XAPI affinity is on VM boot, not in the VM life. Then, it's the work of the load balancer.

@MathieuRA sudo journalctl -u xo-server -n 50 Mar 27 19:27:10 xo-ce xo-server[55210]: 2026-03-27T19:27:10.657Z xo:rest-api:error-handler ERROR Cannot read properties of undefined (reading 'vms'> Mar 27 19:27:10 xo-ce xo-server[55210]: error: TypeError: Cannot read properties of undefined (reading 'vms') Mar 27 19:27:10 xo-ce xo-server[55210]: at BackupLogService.isVmInBackupLog (file:///opt/xen-orchestra/@xen-orchestra/rest-api/dist/backup-lo> Mar 27 19:27:10 xo-ce xo-server[55210]: at filter (file:///opt/xen-orchestra/@xen-orchestra/rest-api/dist/vms/vm.service.mjs:228:40) Mar 27 19:27:10 xo-ce xo-server[55210]: at Array.filter (<anonymous>) Mar 27 19:27:10 xo-ce xo-server[55210]: at Xo.getBackupNgLogsSorted (file:///opt/xen-orchestra/packages/xo-server/src/xo-mixins/backups-ng-lo> Mar 27 19:27:10 xo-ce xo-server[55210]: at VmService.#getBackupsInfo (file:///opt/xen-orchestra/@xen-orchestra/rest-api/dist/vms/vm.service.m> Mar 27 19:27:10 xo-ce xo-server[55210]: at promiseWriteInStream (file:///opt/xen-orchestra/@xen-orchestra/rest-api/dist/helpers/utils.helper.> Mar 27 19:27:10 xo-ce xo-server[55210]: } Mar 27 19:27:10 xo-ce xo-server[55210]: 2026-03-27T19:27:10.657Z xo:rest-api:error-handler INFO [GET] /vms/138538a8-ef52-4d0a-4433-5ebb31d7e152/das> Mar 27 19:27:24 xo-ce xo-server[55210]: 2026-03-27T19:27:24.056Z xo:rest-api:error-handler ERROR Cannot read properties of undefined (reading 'vms'> Mar 27 19:27:24 xo-ce xo-server[55210]: error: TypeError: Cannot read properties of undefined (reading 'vms') Mar 27 19:27:24 xo-ce xo-server[55210]: at BackupLogService.isVmInBackupLog (file:///opt/xen-orchestra/@xen-orchestra/rest-api/dist/backup-lo> Mar 27 19:27:24 xo-ce xo-server[55210]: at filter (file:///opt/xen-orchestra/@xen-orchestra/rest-api/dist/vms/vm.service.mjs:228:40) Mar 27 19:27:24 xo-ce xo-server[55210]: at Array.filter (<anonymous>) Mar 27 19:27:24 xo-ce xo-server[55210]: at Xo.getBackupNgLogsSorted (file:///opt/xen-orchestra/packages/xo-server/src/xo-mixins/backups-ng-lo> Mar 27 19:27:24 xo-ce xo-server[55210]: at VmService.#getBackupsInfo (file:///opt/xen-orchestra/@xen-orchestra/rest-api/dist/vms/vm.service.m> Mar 27 19:27:24 xo-ce xo-server[55210]: at promiseWriteInStream (file:///opt/xen-orchestra/@xen-orchestra/rest-api/dist/helpers/utils.helper.> Mar 27 19:27:24 xo-ce xo-server[55210]: } Mar 27 19:27:24 xo-ce xo-server[55210]: 2026-03-27T19:27:24.057Z xo:rest-api:error-handler INFO [GET] /vms/138538a8-ef52-4d0a-4433-5ebb31d7e152/das> Mar 27 19:27:41 xo-ce xo-server[55210]: 2026-03-27T19:27:41.663Z xo:rest-api:error-handler ERROR Cannot read properties of undefined (reading 'vms'> Mar 27 19:27:41 xo-ce xo-server[55210]: error: TypeError: Cannot read properties of undefined (reading 'vms') Mar 27 19:27:41 xo-ce xo-server[55210]: at BackupLogService.isVmInBackupLog (file:///opt/xen-orchestra/@xen-orchestra/rest-api/dist/backup-lo> Mar 27 19:27:41 xo-ce xo-server[55210]: at filter (file:///opt/xen-orchestra/@xen-orchestra/rest-api/dist/vms/vm.service.mjs:228:40) Mar 27 19:27:41 xo-ce xo-server[55210]: at Array.filter (<anonymous>) Mar 27 19:27:41 xo-ce xo-server[55210]: at Xo.getBackupNgLogsSorted (file:///opt/xen-orchestra/packages/xo-server/src/xo-mixins/backups-ng-lo> Mar 27 19:27:41 xo-ce xo-server[55210]: at VmService.#getBackupsInfo (file:///opt/xen-orchestra/@xen-orchestra/rest-api/dist/vms/vm.service.m> Mar 27 19:27:41 xo-ce xo-server[55210]: at promiseWriteInStream (file:///opt/xen-orchestra/@xen-orchestra/rest-api/dist/helpers/utils.helper.> Mar 27 19:27:41 xo-ce xo-server[55210]: } Mar 27 19:27:41 xo-ce xo-server[55210]: 2026-03-27T19:27:41.663Z xo:rest-api:error-handler INFO [GET] /vms/138538a8-ef52-4d0a-4433-5ebb31d7e152/das> Mar 27 19:27:55 xo-ce xo-server[55210]: 2026-03-27T19:27:55.046Z xo:rest-api:error-handler ERROR Cannot read properties of undefined (reading 'vms'> Mar 27 19:27:55 xo-ce xo-server[55210]: error: TypeError: Cannot read properties of undefined (reading 'vms') Mar 27 19:27:55 xo-ce xo-server[55210]: at BackupLogService.isVmInBackupLog (file:///opt/xen-orchestra/@xen-orchestra/rest-api/dist/backup-lo> Mar 27 19:27:55 xo-ce xo-server[55210]: at filter (file:///opt/xen-orchestra/@xen-orchestra/rest-api/dist/vms/vm.service.mjs:228:40) Mar 27 19:27:55 xo-ce xo-server[55210]: at Array.filter (<anonymous>) Mar 27 19:27:55 xo-ce xo-server[55210]: at Xo.getBackupNgLogsSorted (file:///opt/xen-orchestra/packages/xo-server/src/xo-mixins/backups-ng-lo> Mar 27 19:27:55 xo-ce xo-server[55210]: at VmService.#getBackupsInfo (file:///opt/xen-orchestra/@xen-orchestra/rest-api/dist/vms/vm.service.m> Mar 27 19:27:55 xo-ce xo-server[55210]: at promiseWriteInStream (file:///opt/xen-orchestra/@xen-orchestra/rest-api/dist/helpers/utils.helper.> Mar 27 19:27:55 xo-ce xo-server[55210]: } Mar 27 19:27:55 xo-ce xo-server[55210]: 2026-03-27T19:27:55.046Z xo:rest-api:error-handler INFO [GET] /vms/138538a8-ef52-4d0a-4433-5ebb31d7e152/das> Mar 27 19:28:12 xo-ce xo-server[55210]: 2026-03-27T19:28:12.633Z xo:rest-api:error-handler ERROR Cannot read properties of undefined (reading 'vms'> Mar 27 19:28:12 xo-ce xo-server[55210]: error: TypeError: Cannot read properties of undefined (reading 'vms') Mar 27 19:28:12 xo-ce xo-server[55210]: at BackupLogService.isVmInBackupLog (file:///opt/xen-orchestra/@xen-orchestra/rest-api/dist/backup-lo> Mar 27 19:28:12 xo-ce xo-server[55210]: at filter (file:///opt/xen-orchestra/@xen-orchestra/rest-api/dist/vms/vm.service.mjs:228:40) Mar 27 19:28:12 xo-ce xo-server[55210]: at Array.filter (<anonymous>) Mar 27 19:28:12 xo-ce xo-server[55210]: at Xo.getBackupNgLogsSorted (file:///opt/xen-orchestra/packages/xo-server/src/xo-mixins/backups-ng-lo> Mar 27 19:28:12 xo-ce xo-server[55210]: at VmService.#getBackupsInfo (file:///opt/xen-orchestra/@xen-orchestra/rest-api/dist/vms/vm.service.m> Mar 27 19:28:12 xo-ce xo-server[55210]: at promiseWriteInStream (file:///opt/xen-orchestra/@xen-orchestra/rest-api/dist/helpers/utils.helper.> Mar 27 19:28:12 xo-ce xo-server[55210]: } Mar 27 19:28:12 xo-ce xo-server[55210]: 2026-03-27T19:28:12.633Z xo:rest-api:error-handler INFO [GET] /vms/138538a8-ef52-4d0a-4433-5ebb31d7e152/das> lines 1-50/50 (END)

@MajorP93 This was also my thought, the disconnection method you mentioned, I was just wanting some feedback about that. I do have to be a bit careful because the migration must happen and then the VM on VMware must go back online while I work with the vendor to migrate all the rest of the data. As for the bigger than 2TB issue, that won't be an issue for me. This VM is HUGE but it's because it's thick provisioned and no longer needs to be, the new VM will have like 8 disks but none of them will be over 2TB (most will be less than 100GB). So I am thinking using V2V and just powering off the VM on VMware, disconnect the unneeded VDIs, then migrate, then reconnect those VDIs and power the VM back on.

I can confirm that when using Citrix/Xenserver guest utilities version 8.4 (https://github.com/xenserver/xe-guest-utilities/releases/tag/v8.4.0) memory ballooning / DMC is working fine. After live migration the RAM of the linux guest is expanded to dynamic_max again. So this issue was in fact caused by Rust based xen-guest-agent. For now I'll keep using Citrix/Xenserver guest utilities on my Linux guests until the feature is implemented in Vates rust-based guest utilities. Best regards

@JSylvia007 Sorry, I'm really late to this thread, but note that backups can become problematic if the SR is something like 90% or more full. There needs to be some buffer for storage as part of the process. The fact you could copy/clone VMs means your SR is working OK, but backups are a different situation. If need be, you can always migrate VMs to other storage which is evidently what you ended up doing, which frees up extra disk space. Also backups are pretty intensive so make sure you have both enough CPU capacity and memory to handle the load. Finally. a defective SR will definitely cause issues if there are I/O errors, so watch your /var/log/SMlog for any such entries.

@florent Since both jobs were test jobs that i have been running manually, i do have an unnamed and disabled schedule on both that does look identical, so i unintentionally did have multiple jobs on the same schedule. I have since named the schedule within my test job so to each is unique. Updating to "f445b" shows improvement: I was able to replicate from pool A to Pool B, then run a backup job which was incremental. I then ran the replication job again which was incremental and did not create a new VM! Unfortunately though after this i ran the backup job again which resulted in a full backup from the replica rather than a delta, not sure why. The snapshot from the first backup job run was also not removed, leaving 2 snapshots behind, one from each backup run. [image: 1774618641909-e38c23b0-4259-4d16-9ed3-fa44d8490541-image-resized.jpeg] I then tried the process again. Ran the CR job, which was a delta (this part seemed fixed!) then ran the backup job after, same behavior, a full ran instead of a delta and the previous backup snapshot was left behind leaving the VM looking like: [image: 1774618909029-7edf1dba-e729-4b52-abcc-ffde76d8a0bb-image-resized.jpeg] So it seems one problem solved but another remains.

@TeddyAstie I hadn't seen anything special was needed in a VM other that a kernel new enough for support which 6.17 has, is there more to the story with adding things to Ubuntu?

I have two PE R630 and one PE R730xd. The two R630s show the IPMI data in XO but the R730xd does not. If I run ipmitool sensor from an ssh session, I get very similar data back on the 730 and 630. This isn't critical to me, just letting you know that there are cases that functioning ipmitool on a Dell does not seem to be enough to show it. There are some differences in the labels. The R730 has "Fan1 RPM", "Fan2 RPM" while the R630 has "Fan1A", "Fan2A", "Fan1B". Most of the other interesting fields seem to have the same names but the order is a bit different and I didn't do an exhaustive comparison. It's very cool that you are surfacing this data now.

Ping @Team-XO-Backend