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

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