New Rust Xen guest tools

yann

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?

john.c

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?

The Arch Linux distribution is a rolling release! The release packages appear to be for stable non-rolling release based software distributions.

So if kevdog were to create the PKGBUILD based on release packages, then how well will they handle the rolling release Arch Linux?

yann

@john-c a rolling-release distro does not have to follow every commit of each software component, that would be a bit extreme They are rather about providing users with latest component releases as they are published.

mhomoky

olivierlambert / Sam According to the Gitlab docs the project URI needs to be in URL encoded format, resulting in a working line as below in my own cloud-init:

      deb [trusted=yes] https://gitlab.com/api/v4/projects/xen-project\%252Fxen-guest-agent/packages/generic/deb-amd64/ release/

I found this through experimentation, but weirdly it seems to be a double-URL encoded string at that point in the URI for Gitlab… go figure.

I have another escape related question though. I'm not sure if it's your YAML parser or my editor but if I attempt to use the % as found in the beginning of the documentation example, neovim no longer recognises the file as YAML. So this:

#cloud-config
hostname: {name}
fqdn: {name}%.my-domain.com

from line 3 onwards doesn't work correctly, despite being valid YAML 1.2.2.

Again to get this working, I had to surround the value with single quotes:

#cloud-config
hostname: '{name}%'
fqdn: '{name}%.my-domain.com'

Which library / version of YAML are you targeting?

Also, is the UUID or mac address of a VM exposed to the cloud-init parser internally (or is there a list somewhere of other variables like {name} that are?).

Thanks for a great product and I hope this helps someone

olivierlambert

Hi mhomoky I think it's unrelated to the topic, that would be better to create a new thread I think.

Sam

mhomoky Thanks, worked perfectly fine.

deb [trusted=yes] https://gitlab.com/api/v4/projects/xen-project\%252Fxen-guest-agent/packages/generic/deb-amd64/ release/

No issues in Cloud-config

Also for hostname, I just used {name}without any %

The only thing missing is being able to reapply cloud-init configs or easy reconfigure from the Ui. But that's for another topic.

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.