XCP-ng 8.3 updates announcements and testing

acebmxer

Installed updates on home lab. No issues to report initially other then nslookup still an issue.

[10:54 xcp-ng-haznrrtw ~]# nslookup vates.com 8.8.8.8
Server:         8.8.8.8
Address:        8.8.8.8#53

Non-authoritative answer:
Name:   vates.com
Address: 104.21.52.238
Name:   vates.com
Address: 172.67.205.118

openssl_link.c:132: INSIST(dst__memory_pool != ((void *)0)) failed, back trace
#0 0x7f163cd960e7 in ??
#1 0x7f163cd9603a in ??
#2 0x7f163d9a3780 in ??
#3 0x7f163c1aedf6 in ??
#4 0x7f163c1f5464 in ??
#5 0x7f163c1f5732 in ??
#6 0x7f163c1f4b8d in ??
#7 0x7f163a95fbd9 in ??
#8 0x7f163a95fc27 in ??
#9 0x7f163a94844c in ??
#10 0x405818 in ??
Aborted (core dumped)
[12:50 xcp-ng-haznrrtw ~]#

flakpyro

Installed on my usual hosts, one of which has an E810 and used the ICE driver, no issues so far however i am not using LACP bonding on that host.

rzr

@acebmxer said:

@rzr
No issues to report initially other then nslookup still an issue.

openssl_link.c:132: INSIST(dst__memory_pool != ((void *)0)) failed, back trace

Yes I looked at it, it looks like it's a design isssue that was fixed in later version of bind.

In details If I understand correctly this patched version of nslookup is facing a SIGARBT caused by an assert on previously cleanup resources (dst__memory_pool) which is unexpected in finishing part of the openssl thread (dst__openssl_destroy).

This bind patched version (where ssl support is in progress) is also known to have memory leaks, but those are resolved in later version, so until we catch up you'll probably have to live with this little annoyance on process exit unless we find (and validate) a better fix.

Andrew

@rzr Installed and running. Not expecting any issues because I'm not using SMB/CIFS, ice card, or CPU with affected microcode.

Rolling pool reboot failed me again... This time it got stuck evacuating a host with no VMs.

bufanda

@rzr Installed on my usual lab pool. No immediate issues seen.

ph7

@rzr

manilx

@Andrew I have the RPU failing most of the time now also. I have reported and opened a ticket. No solution so far. It's a hit and miss and beginning to be a PITA.

Pilow

@manilx yup, same here
we evacuate & roll patch manually because RPU is inconsistent in achieving a full pool update nowadays

maximum hosts in pools are 3, so it is still easy to process manually
thoses with 5-6+ hosts must be more painful

olivierlambert

That would be interesting to group your findings/issues on RPU in a dedicated topic, because I don't think the logic changed recently So it's an interesting investigation to make.

JeffBerntsen

@rzr
Seems to be working well on my test systems as well.

marcoi

update to latest test patches on 2nd pool. no issue. LACP worked, started UB26 VM on host 4 and live migrated to host 3.