@Andrew that's planned

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.

People with FreeBSD 13.2 or later as a guest are also now able to use Netlink to get their IP address changes reported instantly (rather than having to wait for as much as 1 minute).

This is however not yet part of our CI jobs, as we rely on cross-rs, which for now only provides FreeBSD 12 cross-build support. Your choices to try it:

• build it yourself
• manually-prebuilt binary

Don't forget to kldload netlink first, the Netlink support is not active by default!

@sb2014 this address reporting looks buggy, can you please share some guest information (OS type and version, guest agent version reported by XO)?

@Dataslak can you please request a commandline from GRUB (hit c on the boot menu), and issue the following commands:

echo $root
search --label --set root root-eqjpzg
echo $root

Raised this on IRC, resulting in:

I'll see what I can do, we may still have some time to include this before the release

I guess that's pretty much all we can do on our side (and that's nice from them ).

Catching up with the subject...

The good news first: the patch is already in the 6.8 stable branch (as c8b7b2f158d9d4fb89cd2f68244af154f7549bb4), and part of v6.8.5.

The Ubuntu situation is:

• master kernel branch OTOH has been at v6.8.4 for 12 days, with only minor packaging adjustments since then
• latest tag on master is 6.8.0-25 (only used for lowlatency kernel as of today), based on v6.8.1
• they also have a 6.8.0-26 and changelog entries for -27 on master-next (all about s390)
• standard kernel at 6.8.0-22, based on v6.8.1 too

I'm not familiar with their internal processes, but I suspect they're probably in a validation cycle for upcoming upcoming version right now, and any such fix would have to wait for next one.

The tracker ticket for 6.8.0-27 seems to imply -27 packaging is "in progress". Still digging...

Adding this to our topics to discuss

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

@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

@Tristis-Oris and with a 3-host pool I can reproduce you issue on 2nd attempt: new master loses its xapi process

When the master is changed, the xapi service is stopped and then restarted but something seems to get wrong this time.

Among issues I realize that my former-master shows this at the time of the failing switch:

Oct 14 15:20:50 xcpng83-bzkcpvhy xsh: [ warn||0 ||xsh] TLS verification is disabled on this host: /var/xapi/verify-certificates is absent

(while both other hosts do have that file)

daemon.log on new-master shows systemd desperately trying to restart xapi:

Oct 14 15:20:59 xcp-ng-hqerhcgv xapi-init[1244028]: Stopping xapi: [  OK  ]
Oct 14 15:20:59 xcp-ng-hqerhcgv systemd[1]: Unit xapi.service entered failed state.
Oct 14 15:20:59 xcp-ng-hqerhcgv systemd[1]: xapi.service failed.
Oct 14 15:20:59 xcp-ng-hqerhcgv systemd[1]: xapi.service holdoff time over, scheduling restart.
Oct 14 15:20:59 xcp-ng-hqerhcgv systemd[1]: Cannot add dependency job for unit lvm2-activation.service, ignoring: Unit is masked.
Oct 14 15:20:59 xcp-ng-hqerhcgv systemd[1]: Cannot add dependency job for unit lvm2-activation-early.service, ignoring: Unit is masked.
Oct 14 15:20:59 xcp-ng-hqerhcgv systemd[1]: Starting XenAPI server (XAPI)...
Oct 14 15:20:59 xcp-ng-hqerhcgv systemd[1]: Started XenAPI server (XAPI).
Oct 14 15:20:59 xcp-ng-hqerhcgv xapi-init[1244047]: Starting xapi:
Oct 14 15:21:00 xcp-ng-hqerhcgv systemd[1]: xapi.service: main process exited, code=exited, status=2/INVALIDARGUMENT
Oct 14 15:21:00 xcp-ng-hqerhcgv xapi-init[1244078]: Stopping xapi: [  OK  ]

and xensource.log is very similar to yours. Congrats, that's a nice bug

@Tristis-Oris Oh OK. Had a try to run it several times myself (though on a 2-host pool), and I was able to see the operation performed twice, though apparently the second op did finish.
Running from the shell, if launch a second xe pool-designate-new-master while the first has not returned yet, it gets a DESIGNATE_NEW_MASTER_IN_PROGRESS error, but once it has returned there seem to be a window to do strange things.

@puneet336 you need to make your connection to your pool master (not your XOA guest), that's where the XAPI endpoint is.

If you did not deploy TLS certificates on your pool, XenAPI.Session(URL) will complain that the SSL certificate is self-signed (which you can workaround by adding ignore_ssl=True as you did above, but don't keep this in production).

You will also find a few guidelines to write a robust XenAPI client at https://xapi-project.github.io/xen-api/usage.html

@puneet336 @olivierlambert the lib is still working, but I'm usually use it with a local connection, running scripts inside dom0, with this code:

def get_xapi_session():
    session = XenAPI.xapi_local()
    try:
        session.xenapi.login_with_password('root', '', '', 'xcp-ng-tests session')
    except Exception as e:
        raise Exception('Cannot get XAPI session: {{}}'.format(e))
    return session

Will check what happens with a remote session.

@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?

@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.

@dClauzel since Debian has switched away from sysvinit we did not take the time to provide an init.d script, but if there is a need, we can include one. Feel free to open an issue (or, even better, a merge request ) on the project in Gitlab!

Thanks for your feedback!

If I understand he question correctly, the requirement is that the snapshot naming convention by ZFS-vol and by syncoid don't collide.
What convention is syncoid using? The current ZFS-vol driver just assigns a unique integer name to each volume/snapshot, and there would be an error when it attempts to create a snapshot with a new integer name that another tool would have created on its own.

@kevdog do you have any specific issue not addressed by the build instructions in the README?