New Rust Xen guest tools

dClauzel

@olivierlambert I tried it in Debian 12.8/stable with sysvinit as init (and not systemd).

The package was installed without problem, but the agent is not started.

When run manually via sudo /usr/sbin/xen-guest-agent, the agent is then correctly detected by the dom0.

So it means no dependencies on systemd (which is good :), and only an init script in /etc/init.d/ is required for having full support.

yann

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

dClauzel

@yann Thanks for the fast reply

Ok, I am opening a ticket, and providing a simple support script.

David_5.1

Hello,

I have a setup with routers (running Debian Bookworm) that need more interfaces than the maximum allowed number of vifs so the VM has one vif and VLAN untagging is done inside it.
As no IPs were detected by the traditional xen tools, I switched to the new, Rust ones, but they fail to detect IPs too

I think it is caused by the lack of /sys/class/net/enX0.*/device/devtype files, despite a few enX0.* interfaces (and folders) and /sys/class/net/enX0/device/devtype (containing vif, as expected) exist.

Should I create an issue directly in the Gitlab project, or comment the partially-related one for SR-IOV support?

yann

@David_5.1 a new issue would be better. Thanks fo your feedback!

David_5.1

@yann here you are : https://gitlab.com/xen-project/xen-guest-agent/-/issues/22

Dillweed

@kevdog @yann said in New Rust Xen guest tools:

@kevdog great news, looking forward for this PKGBUILD!
Wouldn't it make sense to build from release packages rather than from Git?

The CI scripts should give you some guidance. For dependencies you should have a list at https://gitlab.com/xen-project/xen-guest-agent#build-requirements. Not sure why you would want python-setuptools?

Hey all, I put together PKGBUILD for Arch which pulls the latest git. It seems to be working fine for me. You'll need to install xen package on AUR.
https://aur.archlinux.org/packages/xen-guest-agent-git

It's my first attempt at submitting something on AUR. I look forward to any feedback.

Andrew

@olivierlambert No IP record... Using Debian 11 with Management agent 1.0.0-proto-0.4.0. It's a non-standard interface setup with the IPv4/IPv6 assigned to the bridge interface. The agent does not report any addresses up to XO.

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br0 state UP group default qlen 1000
    link/ether 32:a9:24:28:18:56 brd ff:ff:ff:ff:ff:ff
3: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 52:31:46:59:66:a1 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.33/24 brd 192.168.1.255 scope global br0
       valid_lft forever preferred_lft forever
    inet6 2000::5031:46ff:fe59:66a1/64 scope global dynamic mngtmpaddr
       valid_lft 2591833sec preferred_lft 604633sec
    inet6 fe80::5031:46ff:fe59:66a1/64 scope link
       valid_lft forever preferred_lft forever

olivierlambert

Likely because br0 isn't parsed. Pinging @yann and @TeddyAstie

yann

@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