I had a look at getting the xe-guest-utilities working on Ipfire v2 now (core 173, the latest version).

Using a new /usr/sbin/xe-linux-distribution script, like suggested here, allows it to detect the ipfire.
I then manually copied the binaries and scripts from the linux tar file, into the folders in Ipfire, since the install script did not seem to handle Ipfire properly.

When starting the daemon using /etc/init.d/xe-linux-distribution, the next problem was that the "action" function does not exist in the /etc/init.d/functions file in Ipfire.
So I just edited the script, replacing the "else" with an "fi" in the if testing where the functions file is sources, so that the locally defined action method is used.
Then the agent started fine.

Then I also saw the issue of the IP address not being reported.
In my setup, there are two reasons for this. One is that Ipfire uses "red0", "green0", "blue0" etc as interface names, which the xe-guest-utilities will not consider.
The other reason is that I do PCI passthrough of 3 network cards to the Ipfire, and hence does not use the "vif" interface/network that XCP-ng makes available to the Ipfire. Althought the "green0" is really on the same network as the "vif" in my setup.

This was using the 7.30 tar file from the XCP ISO, I think.
I then cloned the 7.33 / master version of xe-guest-utilities from github, and used that thereafter.

I manually changed and built the xe-guest-utilities, adding "red", "green", "blue" to the list of interface prefixes that got considered, but it did not help.
I suspect the reason is that these interfaces does not have a /sys/class/net/eth0/device/nodename entry, which contains a reference to the "vif" that XCP-ng knows about, as I understand it.
So
/sys/class/net/eth0/device/nodename exists, but the eth0 is not assigned any IP address, since it is not used by IPfire.
While there is no /sys/class/net/green0/device/nodename entry.

I am not sure who is "creating" this "nodename" entry, but I suspect is it Xen.
And I suspect it is missing, since the green0 interface has no relationsship with the dom0 really.

But then I also got more questions around what is actually meant to be displayed of "network" info in the XOA web UI. Is it only the network between dom0 and domU ? Or ideally all networks defined on domU ? (i.e. red0 and blue0 and orange0 ) ?

And I also think I spotted a bug on the "Stats" page of XOA, since under "Disk throughput", it seems like always "xvda" and "xvdd" is displayed, even if the host only has one disk, "xvda". But that I should report as a bug, if I do not find it as already reported / known.

While playing with this, I also noticed that the management agent version was not properly displayed, i.e. not at all. And this seems to be caused by the the version constants not being replaced while building the daemon.
I am not a go build expert, so I'll investigate it a bit more. But it seems like I'm not the only one with that issue, because the same problem seems to exist with the xe-guest-utilities that are part of Alpine Linux 3.17 distribution.

I do not think that there are that many running Ipfire on XCP-ng/Xen. I've been briefly involved in some pull requests against Ipfire, so I might look at making one for getting the xe-guest-utilities into Ipfire itself, but since the use is not high, I have a doubt it makes much sense.

Thanks for a great tool in XCP-ng, I enjoy using it in my home setup.
Regards
Alf Høgemark

So the tools you install on the VMs are merely an agent to make the VM more cooperative with the hypervisor, but they don't affect performance.

The situation is different on Windows systems where you need to install PV drivers to achieve better performance.

yes, they are renaming the network interfaces (like red0, green0, blue0) and perhaps it's the problem.
So the agent should work as expected in PVHVM ? My previous VM it was only in PV.
thanks for your answer

So i've made a mistake? the VM has an IPv4 address in local network but no gateway yet

[root@ipfire-test ~]# cat /var/cache/xe-linux-distribution
os_distro="ipfire"
os_majorver="2"
os_minorver="unknown"
os_uname="5.10.55-ipfire"
os_name="IPFire 2.27 (x86_64) - core160"
[root@ipfire-test ~]#

I still don't know why xcp-center doesn't detect the agent management and if it would work as expected

I also change the xe-linux-distribution in /etc/init.d because the function action is not available in ipfire. I don't know what is the best way.
Is there anything to change?

thanks
Pierre

I've tried to modify the xe-linux-distribution file but i definitly don't have the skills to modify it. I don't understand the sed commands to identify
Can someone help me with that?

thanks in advance
Pierre

Hi @Pierre-Briec,

If Ipfire is based on LFS, I suppose there's no RPM nor DEB package management. In this case you can use the .tgz tarball and install it manually, and make sure to install enable the xe-linux-distribution service (using the provided initscript or the systemd unit). But maybe there's a way to install a RPM or a DEB package through some compatibility tool, in which case you may try them.

That's true. There is only a package management pakfire for the addons. I will look at the tgz if i can install it.
Ipfire is using SysVinit script. I'm not very familiar with that and if someone can help me with that.

You may also have to tweak the xe-linux-distribution file to make it recognize your distro. If it has a /etc/os-release file, then future versions of xe-linux-distribution, not released yet, will recognize it automatically.

I can provide this file /etc/os-release

NAME="IPFire"
VERSION="2.27"
ID=ipfire
VERSION_ID=2
PRETTY_NAME="IPFire 2.27 (x86_64) - core160"
ANSI_COLOR="0:31"

hope it helps

Ideally, it would be nice to work towards pushing the tools directly in the distro, so that you could install them from their repositories when needed. We can provide some help if a packager gets it touch with us or if you want to try to contribute them yourself.

The IPFire is a german project so it's not easy for me to communicate with the team. I can make tests and even provide a remote access to a VM test through XO if need.

thanks
Pierre

If Ipfire is based on LFS, I suppose there's no RPM nor DEB package management. In this case you can use the .tgz tarball and install it manually, and make sure to install enable the xe-linux-distribution service (using the provided initscript or the systemd unit). But maybe there's a way to install a RPM or a DEB package through some compatibility tool, in which case you may try them.

You may also have to tweak the xe-linux-distribution file to make it recognize your distro. If it has a /etc/os-release file, then future versions of xe-linux-distribution, not released yet, will recognize it automatically.

Ideally, it would be nice to work towards pushing the tools directly in the distro, so that you could install them from their repositories when needed. We can provide some help if a packager gets it touch with us or if you want to try to contribute them yourself.

I have an Ipfire fresh VM which is not detected by the installer. How can I add support for this distro which seems to be LFS (linux from scratch) based.
I would like to have the guest-tools installed on it.
Can you help me please or tell me how can i add it manually?
I can provide all information you want.

thanks in advance
Pierre

See https://xcp-ng.org/blog/2021/06/28/summer-security-and-bugfix-updates/

You can still provide feedback, of course, but you don't need to try to pull packages from the testing repository for now.

What is strange is that I had RC version of Rocky Linux 8.3 laying around from testing in the past, so I tried to install guest tools from my platform (Citrix 7.0), it is able to report IP address correctly.

That leads to me to think, that somehow Rocky Linux 8.4 isnt fully supported yet ?
If you need more info(logs/screens), please let my know, thx

The biggest issue with the systemd file as it stands is that it has directories pointing to the ones used on FCOS rather than /usr/sbin. Split that off in the other PR.

I'm all for adding the ability to extract distro data from /etc/os-release (see my issue there: https://github.com/xenserver/xe-guest-utilities/issues/108) so I'll likely backport the commit that was contributed upstream. This won't change install.sh (you'd still need to use the -m and -d) but it should make the service able to start and report OS and version in many additional distros.

For systemd vs sysvinit we need either to create twice more DEBs and RPMs and make install.sh able to decide on which to use depending on the distro, or include both kinds of service files in the packages and use post-install scripts to decide which to enable.

stormi created this issue in xenserver/xe-guest-utilities

closed Use `/etc/os-release` for recent distros #108

EDIT: did some pull reqs-should fix MicroOS identification at the least. Could probably handle Tumbleweed the same way. Tried my hand at some systemd rpms too, but god knows if they work.

On a single host pool, the same commands will attempt a clean shutdown on each VM.