Ok, let's involve Team-XAPI-Network

flakpyro No VM stats despite a reboot of the hosts?

New update candidates for you to test!

As we move closer to making XCP-ng 8.3 the new LTS release, taking over from XCP-ng 8.2.1, a new batch of update candidates is now available for user testing ahead of a future collective release. Details are provided below.

• biosdevname: Update as a dependency for another component.
• blktap: Fix: enable NBD client only after completing handshake
• cyrus-sasl: Fix for CVE-2022-24407 (not directly affecting XCP-ng in normal use).
• gpumon: Rebuild for XAPI update.
• intel-ice: Update ice driver to v1.15.5
• kernel: improve timer handling for better compatibility with hardware.
• plymouth: Packaging update. No visible changes.
• psmisc: Update to version 23.6.
• python-urllib3: Update to version 1.26.30.
• rsync:
  • Update to version 3.4.1
  • Fixes for CVE-2024-12084, CVE-2024-12085, CVE-2024-12086, CVE-2024-12087, CVE-2024-12088, CVE-2024-12747
  • The rsyncd configuration and systemd unit files now come in a separate package named rsyncd-daemon, not installed by default
• smartmontools: Update to version 7.4
• xapi:
  • Drop FCoE support when fcoe_driver does not exists
    • FCoE support will be removed from next versions
  • No more CPU checks for halted VMs in cross-pool migration
  • Move CPU check to the target host during cross-pool migration
  • Serialize all PCI and VUSB plugs to keep them ordered
  • Fixes multiple issues in periodic scheduler
  • Fixes multiple issues in the way XAPI handles RRD metrics
  • Improve SR.scan by reducing a racing window when updating the XAPI db
  • A lot or maintenance-related changes, XAPI being a very active project.
• xcp-featured: rebuilt for XAPI
• xcp-ng-release: update copyright years and EULA
• xen:
  • Improve support for Zen 5 and Diamond Rapids CPUs
  • IOMMU logic improvements and fixes
  • add PCI quirks for problematic hardware (e.g Cisco VIC UCSX-ML-V5D200GV2)
  • fix emulation of MOVBE
• xenserver-status-report: maintenance update.
• xha:
  • Support configurable syslog printing
  • Fixes issue where sub-threads can't be scheduled enough resources.

Test on XCP-ng 8.3

From an up-to-date host:

yum clean metadata --enablerepo=xcp-ng-testing
yum update --enablerepo=xcp-ng-testing
reboot

The usual update rules apply: pool coordinator first, etc.

Versions

• biosdevname: 0.3.10-5.xcpng8.3
• blktap: 3.55.5-2.1.xcpng8.3
• cyrus-sasl: 2.1.26-24.el7_9
• gpumon: 24.1.0-40.1.xcpng8.3
• intel-ice: 1.15.5-2.xcpng8.3
• kernel: 4.19.19-8.0.38.1.xcpng8.3
• plymouth: 0.8.9-0.31.20140113.3.xcpng8.3
• psmisc: 23.6-2.xcpng8.3
• python-urllib3: 1.26.20-3.1.xcpng8.3
• rsync: 3.4.1-1.1.xcpng8.3
• smartmontools: 7.4-2.xcpng8.3
• xapi: 25.6.0-1.4.xcpng8.3
• xcp-featured: 1.1.8-1.xcpng8.3
• xcp-ng-release: 8.3.0-31
• xen: 4.17.5-9.1.xcpng8.3
• xenserver-status-report: 2.0.11-1.xcpng8.3
• xha: 25.0.0-1.1.xcpng8.3

What to test

Normal use and anything else you want to test. The closer to your actual use of XCP-ng, the better.

Test window before official release of the updates

None defined, but early feedback is always better than late feedback, which is in turn better than no feedback

We will not be very available on this forum until Monday to help fixing issues if there are any, so don't update too fast if that's a possible problem for you.*

flakpyro Could you export the output of xen-bugtool -y and make it available somewhere privately? This will contain all logs and information about the hardware. Let us know also of times where you rebooting a VM and got this issue.

Greg_E We announce updates here. There's no frequency set in stone. We're working on the next wave of updates, that is ready except that we found a regression so we're working on fixing that first.

If you're adventurous, there's a way to install this next wave earlier, but until it passed internal checks, I don't guarantee that your pool doesn't explode with these.

Could someone summarize this thread for me (XCP-ng Product Owner) so that I see what could be worth tracking and/or doing on our side?

Indeed, we forgot to tell you about this temporary regression. They're coming back in the next batch of updates, as soon as CI is green!

Dual stack support for IPv4 + IPv6 on the management interface in XCP-ng 8.3:

• requires reinstalling to define both IPv4 and IPv6 for the management interface
• is still experimental, there are a few known issues

CC BenjiReis gthvn1 andriy.sultanov

CCing anthonyper who is tasked with following this regression closely and letting us know about any progress.

bberndt https://bugzilla.redhat.com/show_bug.cgi?id=2331326

There's also a KB now: https://access.redhat.com/solutions/7116307

I also passed the information to Almalinux maintainers, they're now aware of the situation.

2planks said in NIC not working on new HPE DL360 Gen11:

Has this issue happened before?

I don't remember such an issue on this hardware. Can you share the outputs of lspci -v, lsmod, dmesg, and dmidecode?

Greg_E It is a separate SR type that you can select when you create a SR in Xen Orchestra.

It's also just local SR. For NFS you still use the NFS storage driver.

peder No, but let me ping our XAPI developers gthvn1 and andriy.sultanov

I'd start with checking the usual logs (notably xensource.log) when the issue happens.

See https://docs.xcp-ng.org/troubleshooting/log-files/

Yes, I know, getting logs about an issue getting logs. Of course, I mean checking them via CLI on XCP-ng hosts :).

MJGZ51 said in XCP-ng 8.3 PCI Passthrough issue:

For anyone experiencing this issue, it happens when you enable Passthrough via CLI (hide devices from DOM).

After a clean install of xcp-ng 8.3, Passthrough would work via XOA GUI. However, as soon as I enabled PCI Passthrough for a device via CLI, the errors appeared.

I've moved to just passing the devices via GUI and not CLI. Everything is now working.

What's the involved CLI command?

archw It's written in the blog post

bvitnik It's better to consider it as working by chance in some scenarios, but I think Teddy can give you details

The default templates are all re-created from JSON files on the filesystem everytime the guest-templates-json* RPMs are updated in dom0.

psylo xensource.log and daemon.log will usually give more information about failed operations. It could also be an issue in XOA's warm migration code in specific cases.