New Rust Xen guest tools
-
@yann Yes I tried compiling with cargo. Got along some of the way until I reached this:
Failed to locate xenstore library: pkg-config exited with status code 1 > PKG_CONFIG_ALLOW_SYSTEM_LIBS=1 PKG_CONFIG_ALLOW_SYSTEM_CFLAGS=1 pkg-config --libs --cflags xenstore The system library `xenstore` required by crate `xenstore-sys` was not found. The file `xenstore.pc` needs to be installed and the PKG_CONFIG_PATH environment variable must contain its parent directory. The PKG_CONFIG_PATH environment variable is not set. HINT: if you have installed the library, try setting PKG_CONFIG_PATH to the directory containing `xenstore.pc`.
Where do I get the xenstore library? I've searched the AUR and pacman official archives and I can't seem to find.
-
@kevdog you can get xenstore with the
xen
package on AUR (will be promoted to [extra] repo in the future)
https://aur.archlinux.org/packages/xenit shouldn't cause issues for boot (at worst, it will add a new non-default Xen boot entry, that shouldn't be used)
-
@yann said in New Rust Xen guest tools:
In Debian 10 and Ubuntu 20.04, what I see is on
apt-get update
on first run is:Certificate verification failed: The certificate is NOT trusted. The certificate issuer is unknown. Could not handshake: Error in the certificate verification. [IP: 172.65.251.78 443]
That would look like Gitlab current SSL certificates would be depending on a root CA that only appeared in newer distros?
And on subsequent runs, then I start getting 401 replies as others reported.
I'm getting this error with a clean install of Debian 12.4... was this something that was addressed and is appearing again, or is the solution at this stage to still install manually?
-
@sccf that looks really strange. Just made a fresh install with a Debian 12.5 netinstall ISO (disabling any desktop task, only installing the ssh-server one), and I get no such issue
-
I also encounter the "401 unauthorised [IP: 172.65.251.78 443]" issue on a fresh Debian 12.5.0 install.
I see that other people manually install the guest tool. But I just want to check if it expected that the "apt update" still doesn't work?
-
just checked installation on ubuntu 24, no problem.
-
@Tristis-Oris So sorry, I had a typo in the url. But I works now.
-
@olivierlambert said in New Rust Xen guest tools:
deb [trusted=yes] https://gitlab.com/api/v4/projects/xen-project%252Fxen-guest-agent/packages/generic/deb-amd64/ release/
JUST A NOTE: I followed the steps in the initial post by olivier - I DID NOT use a -f like many suggested, no errors, installed and then addition items displayed as per below.
I just installed using your steps above on the debian-12.5.0-amd64-netinst.iso.
Not sure what you want us to test, but if you can let me know.. I will do my best to help. -
@olivierlambert I was just curious. These agent lists installs - couldn't this be done in XO? Where after you create the VM and then under the ADVANCE Tab, have a section:
Install Guest Tools (slider) Yes /No
Drop down for the OS types that are supported INSTALLThat would be great - The more that can be automated over searching for command lines is great!
-
@wtdrisco
AFAIK, that's how Windows works. When you choose to install the guest utils it slightly changes how the hypervisor presents itself so guest utils can be installed automatically by Windows.Linux doesn't support that, unfortunately. Or would need changes at the distribution level. There are automation options such as cloud-init, although that's above my knowledge
-
@wtdrisco Chicken-egg thing: you need a program to listen in the VM to "get the order from XO" to install the tools. By default, there's no way to tell a VM doing something without any permission or specific program to listen to commands (which tools are doing partially, but since you haven't got them in the first placeβ¦).
For Linux, the best approach is indeed some automation in your templates (eg with Packer) or manual templates with tools already installed. Or Cloudinit to install them on first boot (but when you have a VM that's cloudinit ready, you also have the opportunity to install the tools soβ¦)
-
Is this version of the tools considered to be production ready? If so, when are we expecting that packages will start being signed?
Thanks
-
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.
-
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
-
Does it work if you replace
%252F
by a/
? -
@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 the401 unathorized
Same cloud data file works without issues on other hypervisors.
-
@julien-f could it be our lib parsing incorrectly the content of the cloudinit drive?
-
@olivierlambert also if you use hostname with
hostname: {name}%
The hostname of the vm would end in 0
-
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.
-
@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*
).