@ph7 @mathieura Whats even more strange... I just updated back to master branch and now all v6 dashboards are working sorta.... Initially all spinning circles from pool to every vm. But If i double click on the vm the dashboard loads. Same for Pool. This was not the case previously. Before i could double click or click refresh all day long never load.

Yes. In case you missed it, this is from https://docs.xcp-ng.org/installation/upgrade/ : [image: 1774993344472-ab571ebd-d6a7-4235-b29d-9a173e2a7f73-image.jpeg]

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

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 A2 (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! edit: Correction B1 A2

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.