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

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

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

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

@fred974 v6.80.6 is definitely very old, and did report MemFree, we ship v7.30 with XCP-ng 8.2. You will likely want to update it, from the "XCP-ng tools" SR.

@fred974 right, it is reporting MemFree here.

What does xenstore ls attr/PVAddons show for this VM? And which kernel version is it using?

Old xe-guest-utilities before v7.30 indeed reported MemFree, which XenServer then improved in v8.4 to still report something for kernels older than 3.14 which did not have MemAvailable yet, but Ubuntu 22.04 ships a decently-recent kernel, so I suspect it would be rather due to an old xe-guest-utilities.

@fred974 the tools should be reporting the value from MemAvailable, so buffer/cache should not be considered as in-use. What do you see (reported by the agent) in xenstore ?

From within the guest:

# xenstore ls data
meminfo_free = "324060"
meminfo_total = "973736"
os_distro = "Debian"
os_name = "Debian 11"
os_uname = "5.10.0-21-amd64"
updated = "1"

The meminfo_free should match what you see in /proc/meminfo.

@Maelstrom96 said in Icon appears in the XOA interface:

do you have pointers on how to build a slackware package for xe-guest-utilities?

If you still want to have a try at building (even though that will not let XO show an icon) the first question is, do you really want to build a slackware package (as in "contribute a package to Slackware so it is available to all Slackware users), or just get it built.
In the latter case, @TeddyAstie answered already, but if you really want to get into packaging, you should look on the Slackware side (e.g. here). I would have added "you may also want to have a look at any existing packaging of a Rust program", but given how "unstructured" the whole thing seems to be (I stand quite surprised of those 1995-looking all-manual instructions), you should be able to build a package once you've built the binary using rustup.

@Ajmind-0 this was an install not an upgrade of 8.2.1, right? Was your previous working install of 8.2.1 in UEFI mode?

@Ajmind-0 does it still freeze if you add atexit=shell on the linux commandline? In some error situations the installer attempts to reboot the system after a few seconds, this will make it drop into a shell instead.

@Ajmind-0 there may be more details in the log a bit before those last lines, and they would not be visible because of the screen size and volume of logs. You can switch to the console with a shell and have a look into /tmp/install-log, there may be some more useful info in there.

@Tristis-Oris I also reproduced the issue on 8.2.1, and record the issue. As for your pool left in a tricky state, would it be reasonable for you to reinstall the impacted hosts?