That's indeed more on @Team-Hypervisor-Kernel side. Maybe a driver/firmware version mismatch?

@kawreh said:

So, it seems not an easy task downgrading due to dependencies. -Fixed some, but more coming up..
Anyway, thanks for replying @yann. I will put it to rest and just wait a bit...

Downgrading just ipmitool should not cause dependency issues. Maybe you tried to apply my original suggestion of downgrading xcp-ng-xapi-plugins?

HI @andrew,

Thanks for the report. Would you mind opening an issue in https://gitlab.com/xen-project/xen-guest-agent/-/work_items?

yann said:

@kawreh said:

After updating to XCP-ng 8.3 (March 2026), IPMI / iDRAC information fails in both XO5 stable and XO6 stable (built from sources).
It is thrown a XENAPI_PLUGIN_FAILURE log line for failure of the "ipmitool lan print" which works fine on the (DELL) node(s).

Thanks for this report!

Can you please check if just yum downgrade xcp-ng-xapi-plugins-0:1.12.0-1.xcpng8.3.noarch makes the plugin work again, and it does can you please provide the output of ipmitool lan print for both package versions?

Actually, don't bother with the plugins, the regression comes from the ipmitool package. You can downgrade that one to get the functionality back, we're on it.

@kawreh said:

After updating to XCP-ng 8.3 (March 2026), IPMI / iDRAC information fails in both XO5 stable and XO6 stable (built from sources).
It is thrown a XENAPI_PLUGIN_FAILURE log line for failure of the "ipmitool lan print" which works fine on the (DELL) node(s).

Thanks for this report!

Can you please check if just yum downgrade xcp-ng-xapi-plugins-0:1.12.0-1.xcpng8.3.noarch makes the plugin work again, and it does can you please provide the output of ipmitool lan print for both package versions?

@jsajous26 xolite n'est pas un service, c'est juste une appli web servie par XAPI, qui est owner du port 80 (le port 443 est lui servi par stunnel@xapi).
Si xapi n'a pas démarré, il doit y avoir un gros soucis. Je commencerais par un systemctl list-units --failed pour voir l'étendue des dégats. Si xapi a échoué à démarrer, xensource.log devrait avoir des détails.

@Tristis-Oris yes it is likely you're using a newer kernel, we likely need to rebuild the agent using a newer version of the netlink crate.

@wlp94114 for example, did you get any warnings in the kernel logs about the firmware version mismatch?

@wlp94114 said in Intel x710-t2l Problems:

The x710 series has a reputation for being picky about driver and nvram versions.

Out of curiosity, is there anything reported by the linux driver that would allow make the situation obvious?

@hoehnp we're aiming at sharing a very first public version before end of year, but don't hope for it to be anything complete or stable

Adding this to our topics to discuss

Since GPU passthrough is involved I'd ping @Team-Hypervisor-Kernel

@rhkean note we did not publish any build yet (there is code available, but I wouldn't advise anyone to jump on it yet )

Hi @rhkean,

You should first check that the hardware in question is supported by a driver in Linux 4.19, or possible to build out of tree for that kernel.
I'd think you will have more chances of success on a recent laptop with the upcoming XCP-ng 9

@john.c OK, that will be useful when the repo is signed, but for now I don't see what adverse effect it can have. Do I miss something?

Also we try to avoid breaking support for older OS versions, so we'll likely continue to advertise the old format for older versions of Debian.

@flakpyro the old format is still supported, and actually the [trusted=yes] in the old-style configuration shown in the release notes does work in my quick test with our own Debian 13 hub template.

@olivierlambert updating the README will be quick enough... but if the sig is indeed mandatory we need to setup something for this first... and autosigning from a CI rather requires doing that on a trusted runner rather than on gitlab-provided ones, so that requires some provisioning and IT work first.

@olivierlambert yes, and that's a known issue. The protocol used to communicate with XAPI only allows to report info for VIFs (and SR/IOV, with support coming with in a PR). We can likely implement something by querying the status of bridge devices and listening to their changes like we do for the VIFs, and report those for the VIFs that are part of bridges - but it's a bit more than just "parsing br0" .

Opened https://gitlab.com/xen-project/xen-guest-agent/-/issues/24

@David_5.1 a new issue would be better. Thanks fo your feedback!

@fred974 there is an undeclared conflict between the xe-guest-utilities in the ISO and xenstore-utils, you can install the former after removing the latter (but yes, it is a problem, the Go implementation of xenstore tools should not be in this package).