New Rust Xen guest tools

qnx

Is this version of the tools considered to be production ready? If so, when are we expecting that packages will start being signed?

Thanks

olivierlambert

I'm using it in my own production without any problem since the last months. We will discuss with @yann about the next steps to go further.

Sam

A few notes about the tools and install through Cloud-init.
In Xen Orchestra for cloud-init user data if you add the debian source:

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

There's an error parsing:

%252F

Would parse a:

% = 0

Would result in the following:

deb [trusted=yes] https://gitlab.com/api/v4/projects/xen-project0252Fxen-guest-agent/packages/generic/deb-amd64/ release/

The error would only apear on the parsed data in the VM. Doesn't matter single, double, without quotes, double % would be 00.

#cloud-config
apt:
  sources:
    xen-guest-agent:
      source: "deb [trusted=yes] https://gitlab.com/api/v4/projects/xen-project%252Fxen-guest-agent/packages/generic/deb-amd64/ release/"

packages:
  - xen-guest-agent

olivierlambert

Does it work if you replace %252F by a /?

Sam

@olivierlambert said in New Rust Xen guest tools:

Does it work if you replace %252F by a /?

I did that, and the / was parsed correctly, but apt didn't update with it.

EDIT:
I just try. Ubuntu 24.04 cloudimage, if you add manually with / instead of encoding it as %252F would give errors.
Like other people the 401 unathorized

Same cloud data file works without issues on other hypervisors.

olivierlambert

@julien-f could it be our lib parsing incorrectly the content of the cloudinit drive?

Sam

@olivierlambert also if you use hostname with

hostname: {name}%

The hostname of the vm would end in 0

kevdog

When using this toolset, what network interface names does this match against? For example it will match against interface names starting with eth and I think enpS. I looked in the source code within the main branch but couldn't find the file where this search occurs.

yann

@kevdog on Linux it really does not care about the interface name, it checks if it is a VIF (see src/vif_detect_linux.rs). On FreeBSD it does filter on the interface name (xn*).

kevdog

So I managed to build with Cargo on arch (which also required clang as a dependency). Moved xen-guest-agent/target/debug/xen-guest-agent to /usr/sbin and also copied the basic xen-guest-agent/startup/xen-guest-agent.service file to /etc/systemd/system and enable/started the service.

And ahh -- success --
Screenshot 2024-09-09 at 9.29.58 AM.png

I guess my project for week is to figure out how to write a PKGBUILD file for this particular project. We'll see how that goes

I'm assuming since building from git repository (https://gitlab.com/xen-project/xen-guest-agent) there aren't going to be any file signatures to check against. I'm looking at cargo, clang, python-setuptools and xen as dependencies?

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.