I'll be the first to admit I'm out of my depth as to the challenges this way present. The install.sh in unable to determine how to install against Buildroot LTS.

OS Info:

The install.sh script from Citrix Hypervisor's guest tools ISO does not seem to be available on github. I'd like to contribute a fix that was contributed to me by a user of XCP-ng, but I don't know how.

Here is what we see when removing the IP recorded as "first one" by the tool:

initially:

6: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 3e:ed:36:5a:63:63 brd ff:ff:ff:ff:ff:ff
    inet 172.16.210.109/23 brd 172.16.211.255 scope global dynamic noprefixroute eth0
       valid_lft 77100sec preferred_lft 77100sec
    inet 1.2.3.5/32 scope global eth0
       valid_lft forever preferred_lft forever
...
root@debian11-test:~# xenstore ls attr/vif
 0 = ""
  ipv4 = ""
   0 = "172.16.210.109"
   1 = "1.2.3.5"

after removal of the IP with ip addr add 172.16.210.109 dev eth0, after a delay due to periodic polling we get:

vif = ""
 0 = ""
  ipv4 = ""
   0 = "1.2.3.5"
   1 = "1.2.3.5"

and after some more time finally:

vif = ""
 0 = ""
  ipv4 = ""
   0 = "1.2.3.5"

Besides the obvious problem of seeing the same IP address twice, the problem is there is no stability in the xenstore path for a given IP address: a client using xs_watch() here on vif/0/ipv4/1 would get a spurious wake when it disappears, and would have to spend CPU cycles with more code just to find out if the iface has been brought down, and to locate the new path if not.

Trying to build with go version 1.18.

I'm getting the following error:

# golang.org/x/sys/unix
vendor/golang.org/x/sys/unix/syscall.go:83:16: unsafe.Slice requires go1.17 or later (-lang was set to go1.16; check go.mod)
vendor/golang.org/x/sys/unix/syscall_linux.go:2255:9: unsafe.Slice requires go1.17 or later (-lang was set to go1.16; check go.mod)
vendor/golang.org/x/sys/unix/syscall_unix.go:118:7: unsafe.Slice requires go1.17 or later (-lang was set to go1.16; check go.mod)
vendor/golang.org/x/sys/unix/sysvshm_unix.go:33:7: unsafe.Slice requires go1.17 or later (-lang was set to go1.16; check go.mod)
make: *** [Makefile:90: /home/kevdog/src/xe-guest-utilities/build/obj/xenstore] Error 2

My go.mod file is as follows:

module github.com/xenserver/xe-guest-utilities

go 1.16

require golang.org/x/sys v0.1.0 

Hi

We run Talos linux with Xen Orchestra. Talos is a very minimal OS and does not have a shell and command line tools are not available. This breaks the guest utilities in multiple ways since shell commands (and the corresponding commandline tools) are used in several places. I fixed this issue for getting the IP address, and you can find the solution here. However, I know multiple people are facing this issue, so I would love to bring this solution back to the main repository.

I think it is generally better to avoid using command-line tools for such a low-level tool. But fixing the issue of fetching IP addresses for now is good enough for us.

To use the net library, we do need static linking. I am not sure about the implications for other operating systems.

The citrix.repo file, that is still distributed in the current RPMs built by Citrix, seems to me to be unused nowadays. The repository URL it points at is wrong and probably a thing of the past.

I suggest removing it from this repo and to remove references to it in spec files and such.

Since commit b9eebe3, the makefile looks for a vendor directory that is dynamically named after the current directory.

For example, if you're in directory xe-guest-utilities-7.30, it will look for xe-guest-utilities-7.30/vendor/xe-guest-utilities-7.30. This breaks the build because such directories don't exist. The only directory that exists is ./vendor/xe-guest-utilities, but for this to work the directory that contains the sources must be named exactly xe-guest-utilities, so that VENDOR_DIR is computed as xe-guest-utilities/vendor/xe-guest-utilities.

I don't think the build process should depend this way on the name of the current directory.

The daemon only looks at VIF interfaces. If an IP address is not assigned directly to the VIF but to an ethernet bridge with the VIF as slave (and there may be more cases) it does not get reported in Xenstore, even though it is the IP that should be used to communicate with that VIF.

Can those tools be used in a generic fashion without being in need on mounting the xen tools iso on the hypervisor or are those tools version specific as the xen-tools from the iso?

Thanks!

Xen Orchestra not showing the IP addresses of the VM when the OS is Ubuntu 24.04. The VM is running xe-guest-utilities version 7.20.2-0ubuntu1, which is the one automatically installed when I used the command "sudo apt install xe-guest-utilities".

I have another VM on the same server running Ubuntu 22.04 but in that case it shows the IP addresses

Service had a panic

May 03 14:42:48 host systemd[1]: Started Linux Guest Agent.
May 03 14:42:48 host xe-daemon[5682]: panic: runtime error: slice bounds out of range [:-1]
May 03 14:42:48 host xe-daemon[5682]: goroutine 1 [running]:
May 03 14:42:48 host xe-daemon[5682]: xe-guest-utilities/guestmetric.(*Collector).CollectDisk(0xc000122018)
May 03 14:42:48 host xe-daemon[5682]: /builddir/build/BUILD/xe-guest-utilities-7.30.0/vendor/xe-guest-utilities/guestmetric/guestmetric_linux.go:290 +0xdb0
May 03 14:42:48 hostxe-daemon[5682]: main.main()
May 03 14:42:48 host xe-daemon[5682]: /builddir/build/BUILD/xe-guest-utilities-7.30.0/build/gobuild/xe-daemon/xe-daemon.go:114 +0xdab
May 03 14:42:48 host systemd[1]: xe-linux-distribution.service: Main process exited, code=exited, status=2/INVALIDARGUMENT
May 03 14:42:48 host systemd[1]: xe-linux-distribution.service: Failed with result 'exit-code'.

I found this bug

I had /dev/xvdc1 which I created a PV with. However I had not created a VG with it. The process kept having the panic.

Once I created VG data with /dev/xvdc1. Then the service started accordingly.

The analyse.py script is written with python2.
Python2 is EOL since 01 Jan 2020, 1.5 Years ago.

Many Distributions no longer ship python2

/etc/os-release is a de-facto standard that describes a linux distribution, and has been around for years. See its announcement in 2012: http://0pointer.de/blog/projects/os-release and its manpage: https://www.freedesktop.org/software/systemd/man/os-release.html

See also some examples at https://gist.github.com/natefoo/814c5bf936922dad97ff

Using it, we could avoid parsing distro-specific release files, at least for distributions that are not extremely old.

It also comes with an interesting feature: the ID_LIKE key. Let's take Rocky Linux as an example, as we recently added support for it. If we had been using /etc/os-release:

1. Rocky Linux would automatically have been detected without any code addition.
2. In install.sh, we could have automatically inferred from ID_LIKE="rhel fedora" that we should install the xe-guest-utilities and xe-guest-utilities-xenstore RPMs.

The release with prebuilt binaries for RedHat does not contain a GPG signature.

Would it be possible for you to add one?

A Debian 11.2 is reported as 11.11:

$ cat /etc/debian_version 
11.2

$ cat /etc/os-release 
PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
NAME="Debian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

$ ./xe-linux-distribution 
os_distro="debian"
os_majorver="11"
os_minorver="11"
os_uname="5.10.0-11-amd64"
os_name="Debian GNU/Linux 11 (bullseye)"

The awk expression in identify_lsb assumes there is a dot in the lsb_release --short --release output, which is not the case here. It should likely conclude that minor="" instead, in this case.

Hi

Is it possible to have this daemon running in a container but so that it reports correctly the information on the host OS?

I am suspecting with enough time, tinkering and code analysis it's possible to bind mount whatever is needed or smth like that.

@stormi I know they did something for former rancher OS, but all those containers report wrong info to Xen Orchestra plus they report no version.

I tried writing my own to no avail. Maybe I need to bind mount some specific Linux Sockets or smth?

I need this for Fedora CoreOS. So is it just more let me use the word "linuxonix" (from "pythonic") to just layer this package on top of the rpm-ostree?

Thank you for reading this. I know Olivier Lambert proposed a new project for this thing but unfortunately I see people are stuck in the past. I mean the Citrix legacy code just had to go.

Xen Orchestra Web UI (from source commit d4637) with XCP-NG 8.2.1 (all the patches installed at Julu 26th 2024) is reporting that the agent is 6.6.80-0, but in the CLI of the VM the version is 7.20.2

Currently there is support for detecting SLES, but not the openSUSE variants.

There have been useful changes since last tag that happened more than one year ago, so I suggest to tag v7.31.0.

This would make it easier for packagers and downstreams to get a version with recent distros (ArchLinux, RHEL 9, that can have an enX prefix for network interfaces), and a smarter xe-linux-distributions based on /etc/os-release, among other changes.

build of xe-guest-utilities 7.18.0 fails on FreeBSD 12

build/gobuild/system/system.go:24:31: undefined: syscall.SYS_TIMERFD_CREATE
build/gobuild/system/system.go:36:31: undefined: syscall.SYS_TIMERFD_SETTIME

Please consider using a POSIX API instead.

AlmaLinux 8 is not correctly detected by and instead returns:

# ./xe-linux-distribution.orig
sed: -e expression #1, char 103: invalid reference \2 on 's' command's RHS

Hello,

if you can't provide newer debian package, can you at least provide instructions how to do it?

I realize this may be basic debian knowledge not specific to this package, but I'm unable to find anything on google: debian utilities like dch or dpkg-buildpackage are complaining that version number @Version@-@Release@ doesn't start with number. Obviously, this is supposed to be resolved to real number using some other command, possibly make, but I have no idea what command should that be and I don't want to risk filling it manually because I have no idea what else is that command supposed to do.

The tool does active polling every minute, instead of getting notified when a change occurs. This wastes CPU in the guest, and causes the toolstack to have information with delays, which slows down investigations and impairs the ability to understand the system.

E.g. on Linux systems, netlink should be used to get notified of changes in interfaces and IP addresses.

The latest release with prebuilt binaries for RedHat/Debian based linux distros is from Jul 27, 2015.

This is pretty old, would it be possible to release newer binaries?

Title.

The current implementation of xe-linux-distribution, based on sed, is rather fragile and often ends in that kind of error when the distro is unsupported:

[root@localhost Linux]# ./xe-linux-distribution 
sed: -e expression #1, char 103: invalid reference \2 on `s' command's RHS

We should implement the pattern matching in a more robust way while still portable of course.

I may give it a try sometime in the future...

Hello there!

We are organizing with the Xen project to rewrite guest agent from scratch, under the Xen Project umbrella directly (and not only XCP or XenServer).

Goals are:

• providing a unified upstream source repo for distro maintainers
• writing it from scratch to make it simple as possible (no daemon if possible)
• building it with an incremental approach (Linux support first)
• being community driven
• splitting clearly the agent from libs (xenstore-read/write…)
• reducing the burden to package it for distro's

https://gitlab.com/xen-project/xen-guest-agent

We might put someone dedicated to that, but before doing actual coding, we should probably set up a workgroup between Xen actors interested, to be able to agree on a minimal set of features.

The vendor dir https://github.com/xenserver/xe-guest-utilities/tree/master/vendor only has modules.txt files, without the vendor sources.

This makes plain go command fail to operate.

$ go build -o build/xenstore ./xenstore
go: finding module for package golang.org/x/sys/unix
xenstore/xenstore.go:11:2: cannot query module due to -mod=vendor
        (Go version in go.mod is at least 1.14 and vendor directory exists.)

Either removing the vendor/modules.txt file or keeping all vendor files will make go command happy.

$ rm -r vendor/
$ go build -o build/xenstore ./xenstore

$ go mod vendor
$ ls vendor/golang.org/x/sys/
AUTHORS  CONTRIBUTORS  internal  LICENSE  PATENTS  unix
$ go build -o build/xenstore ./xenstore