When I saw the No data to calculate in the Last 3 backup archives, I was thinking if all this has to do with my disabled schedule but enabled Sequence job.

This issue appears to have been resolved by a recent change.

I observed similar behaviour. Two pools. Pool A composed of two hosts. Pool B is single-host. B runs a VM with XO from source. Two VMs on host A1 (on local SR), one VM on host B1 (on local SR). Host A2 has a second local SR (separate physical disc) used as the target for a CR job. CR job would back up all four VMs to the second local SR on host A2. The behaviour observed was that, although the VM on B would be backed up (as expected) as a single VM with multiple snapshots (up to the 'replication retention'), the three other VMs on the same pool as the target SR would see a new full VM created for each run of the CR job. That rather quickly filled up the target SR. I noticed the situation was corrected by a commit on or about the same date reported by @ph7. Incidentally, whatever broke this, and subsequently corrected it, appears to have corrected another issue I reported here. I never got a satisfactory answer regarding that question. Questions were raised about the stability of my test environment, even though I could easily reproduce it with a completely fresh install. Thanks for the work!

Replicating the issue with another OIDC OP (simplesamlphp module-oidc), it appears to hinge on an expectation of a 'thick' JWT token being returned from the OP, whereas some OPs (simplesamlphp, but also SRAM which IIRC uses SATOSA) strictly interpret OpenID Connect Core section 5.4 so that in the Authorization Code flow the returned JWT token is 'thin' and the RP must collect the claims (based on the requested scopes) from the userinfo endpoint, rather than expecting them to be in the returned IDToken. And since the auth-oidc plugin uses the response_type=code ... (see https://github.com/vatesfr/xen-orchestra/pull/9648#issuecomment-4161156812 for more details). Modifying an OP to always add claims to the IDToken, i.e. disregarding section 5.4 of the OIDC core spec, makes the issue above go away ... olivierlambert opened this pull request in vatesfr/xen-orchestra draft fix(xo-server-auth-oidc): handle missing profile fields in username resolution #9648

While I was updating all the pools, a micro-update for 5 packages was released again. They come out every week now. Same issue with basic migration. Now it impossible.

@Pilow open a dedicated topic on this . I will ping the relevant team there is it iscsi + CBT ?

Come on everyone! Click Here to vote to support HP IPMI info in XO!

@User-cxs said: when I want to shut down a node with VMs on it, the HA will cause the following We are still waiting for your question. P.S. The solution is in the GH issue that I previously linked.

@User-cxs dans ce cas en l'occurence de coupures intempestives au niveau réseau (scrute de plus pret le routage entre ces 2 subnets (j'ai supposé que c'etait du /24)) tu peux avoir le comportement erratique ou tout disparait et fini par revenir monitore un ping du xoa vers les hosts, voir si tu as des pertes de paquet de temps en temps. au moment ou les hosts disparaissent, essaie de pinger les hosts depuis le XOA... a mon avis un probleme de réseau quelque part...

yes, the last changes are released in latest ( 6.3) tomorrow if everything proceed as intended mostly : https://github.com/vatesfr/xen-orchestra/pull/9622 https://github.com/vatesfr/xen-orchestra/pull/9557 and this one was in 6.2 : https://github.com/vatesfr/xen-orchestra/commit/e36e1012e20c9678efa15148179941cb284c39a6 that's nice to hear fbeauchamp opened this pull request in vatesfr/xen-orchestra closed feat(xo-server): use index for getAllUnhealthyVdiChainsLength #9622 fbeauchamp opened this pull request in vatesfr/xen-orchestra closed fix(backups): better handling of generator cleanup #9557 0 fbeauchamp committed to vatesfr/xen-orchestra fix(xo-web): reducing polling for patches and license

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.