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/)

Hello, no, since I changed this, server is rock solid:

20:59:01 up 136 days, 22:40, 1 user, load average: 0.45, 0.31, 0.36

@fbifido yes, I have 3 CEPH nodes running in separate VM's that have direct passthrough to underlying physical disks. CEPH volume is connected as RBD that forms shared block device on XCP-ng servers. On that shared block device I use LVM.

It's all described here: https://github.com/xcp-ng/xcp/wiki/Ceph-on-XCP-ng-7.5-or-later#lvm-on-rbd

@AbyssMoon I run it on Windows 10, but I think it's weird it worker before and now it doesn't. Do you have any other newer Windows available to try it on?

@AbyssMoon

I just downloaded it myself from same link and tried, look on the screenshot, versions are matching, it works to me. I think you must have some different problem, maybe firewall?

@AbyssMoon yes I did, but you clearly use different version of XCP-ng admin, not my build. Compare build numbers.

@AbyssMoon it works just fine to me

can you provide some details?

@olivierlambert BTW due to inactivity of "new maintainer" I think I could probably volunteer to become another co-maintainer, but can't promise to be overly active either.

@O_V_K Does that version I posted not work?

@Seneken that build I shared here works with latest XCP-ng, current maintainer on github just didn't make a release for latest codebase, but master branch in github works with latest version just fine

@manilx yes because the fix was made 2 weeks ago https://github.com/xcp-ng/xenadmin/commit/cd4c62ee48a2288a01c8b902df4eba0293b27b8e but latest download is from January. Version I shared is from last HEAD of repository, it's newer than what you had.

0 michael-manley committed to xcp-ng/xenadmin

Added API 2.21 to allow connection to latest XCP-ng

@manilx here is compiled last development version that works to me with 8.3 - https://cloud.bena.rocks/s/kEWmsmg8ABtQJZe using VS 2022

I take it back

@manilx I just tried last version of XCP-ng (from development branch) and it works with XCP-ng 8.3 beta2 just fine. The fix is already implemented. What doesn't work to you? Are you just missing a built version?