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

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?

@Tristis-Oris said in New Rust Xen guest tools:

@Theo main point to avoid such issues without tuning the OS.
easy way - disable selinux.

I'd like to point out, while this is useful to test the tools, it is not recommended to do that on a production VM - sorry if that sound obvious, but better safe than sorry

We just released version 0.4.0. Biggest highlight is that it is not necessary any more to have libxenstore separately installed in guests, so the new RPM is now compatible with RHEL/CentOS and similar distros.

Details to be found at https://gitlab.com/xen-project/xen-guest-agent/-/releases/0.4.0

@forbiddenera FreeBSD support is already there, and binaries are available since v0.3.0 release. However, full support making use of Netlink (supported since FreeBSD 13.2) is not to be considered as mature yet, only due to the need to use still-unofficial patches on some dependencies -- full status here.

Windows support is also coming, but requires more work than FreeBSD did, you can follow the status of the first meaningful step (communicating collected info back to host) here. Right now a few other tasks take precedence, expect things to move forward again within a few weeks.

@ajpri1998 We have a tracking issue set up for progress on that front.

@lawrencesystems thanks for those details, I could identify 2 specific issues from this, will fix that for 0.3.0:

• https://gitlab.com/xen-project/xen-guest-agent/-/issues/12
• https://gitlab.com/xen-project/xen-guest-agent/-/issues/13

@dhiraj26683 if it was used by a process it would be counted in used not in buff/cache. Those are used by the kernel's Virtual Filesystem subsystem.

Now if your problem is that a given process fails to allocate memory while there is so much of the memory in buff/cache, then there may be something to dig in that direction, but we'll need specific symptoms to be able to help.