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

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

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.

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

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

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