2 paths we are doing in parallel: We are doing our best to make it upstream in Linux, it's a regression after all. We know how to fix it, so hopefully this will be fixed quickly. Then, we'll have to wait for a Linux kernel update in main distros. Invariant TSC in Xen is also a way to fix it, because we want to improve that anyway. But as Teddy said, it's more work and it will take more time.

@pierrebrunet Thanks.

Hi, everyone Thank you for your help. I had a flux that was blocked by our firewall. The button worked after that. But it doesn't explain why I lost this configuration and had to reinstall it. Thanks again.

@johnnezero To add one more info on top of Mathieu's post : ACL (XO5 only) and RBAC (in REST API + XO6 soon) are completely separate, so better use RBAC as it gives much more flexibility ! Interesting plugin by the way !!!

@Bryanvh No problem The issue you encountered wasn't very clear. Therefore, I've proposed a change to the XAPI to make the error more explicit (this will likely be implemented in future XAPI releases). So instead of SSL Certification failure the message will be: POOL_JOINING_MASTER_CERTIFICATE_NOT_IN_POOL_BUNDLE. Thank you very much for your patience and for bringing this issue to our attention. References: https://github.com/xapi-project/xen-api/pull/7112 LucienLassalle opened this pull request in xapi-project/xen-api closed xapi: Improve error reporting when pool join fails on TLS verification #7112

@itservices It may be a storage or a xo issue. You can try to restart xo-server and retry the backup. If it is solved, it was an issue with xo-server not freeing your vdi. If it still happens, it will be a storage issue

@dthenot Thanks a lot for the information. I did some more testing on my end and I've now noticed differences in handling VDI format across different SR types (local LVM and EXT). Should I expect even more differences across remote SR types like LVMoHBA or NFS or are these differences more like block based vs file system based SRs? Any way, it looks like I have to consult the following keys: image-format vdi_type type In my tests, local EXT SRs tend to have only one of them, while local LVM SRs tend to have first two or all three, depends which one was used when creating the VDI.

@Andrew I did suspect that would be sufficient, but we need to think at feature level, and as mentionned there is no such thing we could do "quickly" for linux and other OSes. I anyway did a brain dump of my investigation before posting my previous message and we do now have an entry in the roadmap for it, which was not the case previously.

Maybe you can check for a bigger timeout on your UDM?

@LucienLassalle — Thanks Lucien, appreciate the detailed reply. Glad we landed on the same result independently, and the CI/testing rationale makes complete sense — stability matters more than rushing a same-day patch. Good to see June Updates #1 out covering Fragnesia, ptrace_may_dream, and Pintheft, and good to know CIFSwitch will likely be treated the same way. I'll keep checking the blog and the VSA registry. And noted on security@ for future reports. Thanks for the great work as always.

@Andrew Hi, i'm the one that made the plugin, the documentation is in progress. Meanwhile, can you post the result of running ipmitool sdr list ? You might find some leads as to which regexes should work for your particular host. Also you can check ipmitool lan print (be carefull not to share ip's or sensitive info ).

@pszelestey Hi, yes, we've pushed an initial commit and a few more here https://github.com/vatesfr/cluster-api-provider-vates/ it is moging every day. Ping us in Matrix/Discord devops if you want to chat live while trying

@tsukraw multiple NBD connection will open multiple reading connection, but the writing one is always one stream per disk in incremental replication with full replication, it's one stream for read and one for write

@acebmxer Yeah, it does not show up as an available device in XOA or XCP-ng Center. Just listed when running lspci

@poddingue Not seeing it anymore

Yes, there's a weird issue when using both XOSTOR and HA, probably due to the HA mechanism itself. @Team-Storage is on it

Maybe, the view from hypervisor level would be interesting, too: # xenstore-ls -f | grep -i driver Will list the drivers for each domain. # list_domains Gives the VM UUID for each domain id.