@Andrew that's planned

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

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