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

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

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

@Tristis-Oris very strange, your log seems to show that 2 designate_new_master requests were handled one after the other (at 12:11:33 and 12:12:45), both to switch to the same host - and we see in the logs that while the 1st one got all phases executed (1, 2.1, 2.2), the second one starts to have issues during "Phase 2.1: telling everyone but me to commit". Sending a second request should indeed not trigger the whole thing again, so something apparently went quite wrong, but what is indeed not obvious.