@olivierlambert I think so. ceph.ko anyway isn't a core module for XCP-ng, so I don't think there's a high risk in patching it, especially with patches coming from upstream kernel.org. Regarding the initial question, XCP-ng 8.3 will also have a newer kernel-alt. However, I don't recommend it for production, because it is a lot less tested in the context of XCP-ng.

Hello, just a follow-up I figured out probable fix for performance issues (the locking issue seems to have disappeared on its own I suspect it happened only due to upgrade process as pool contained mix of 8.0 and 8.2 hosts) It was caused by very slow (several second) executions of basic LVM commands - pvs / lvs etc took many seconds. When started with debug options it seems it took excessive amount of time scanning iSCSI volumes in /dev/mapper as well as the individual LVs that were also presented in /dev/mapper as if they were PVs - it actually subsequently ignored them but still those were (in my case) hundreds of LVs and each had to be open to check metadata and size. After modifying /etc/lvm/master/lvm.conf by adding this: # /dev/sd.* is there to avoid scanning RAW disks that are used via UDEV for storage backend filter = [ "r|/dev/sd.*|", "r|/dev/mapper/.*|" ] Performance of LVM commands improved from ~5 seconds to less than 0.1 second and issue with slow startup / shutdown / snapshot of VMs (sometimes they took almost 10 minutes) was resolved. Of course this filter needs to be adjusted based on specific needs of the given situation. In my case both /dev/sd* as well as /dev/mapper devices are NEVER used by LVM backed SRs, so it was safe to ignore them for me. (all my LVM SRs are from /dev/rbd/)

Ah nice! Ideally, we'd like to avoid to use the complicated XAPI RRD + XML system. See https://xcp-ng.org/blog/2022/05/25/fetching-metrics-in-xen-why-the-method-matters/ Thanks a lot to bring this, I'll promote it!

Hi @mauricio_hps This is a XCP-ng forum, please try with XCP-ng https://xcp-ng.org