Raised this on IRC, resulting in:
I'll see what I can do, we may still have some time to include this before the release
I guess that's pretty much all we can do on our side (and that's nice from them ).
Raised this on IRC, resulting in:
I'll see what I can do, we may still have some time to include this before the release
I guess that's pretty much all we can do on our side (and that's nice from them ).
Catching up with the subject...
The good news first: the patch is already in the 6.8 stable branch (as c8b7b2f158d9d4fb89cd2f68244af154f7549bb4), and part of v6.8.5.
The Ubuntu situation is:
I'm not familiar with their internal processes, but I suspect they're probably in a validation cycle for upcoming upcoming version right now, and any such fix would have to wait for next one.
The tracker ticket for 6.8.0-27 seems to imply -27 packaging is "in progress". Still digging...
@Houbsi not sure what indeed happened I had messed up and used links to the CI run on commit instead of that of the tag. I had to update the links to point to new job ids. Thanks for the notice!
@usuari While we're pretty happy with how they work with XCP-ng as @olivierlambert says, our goal is to have those tools more generally useful for the whole Xen ecosystem, and there will likely be changes related to this. For example, it might be that a configuration becomes necessary to get the more general version to behave like they do today - naturally we would provide such a file, but it could require the installation of an additional package when that is done. (disclaimer: this is the outcome I have in mind, which does not mean it is precisely what's going to happen )
@CJ it looks like people really want to get it auto-enabled (which makes sense) so if we don't discover major problems we'll just let it auto-enable on first install. But yes, if it turns out it is better to leave it disabled but default a notice makes sense.
@Tristis-Oris said in New Rust Xen guest tools:
@Theo main point to avoid such issues without tuning the OS.
easy way - disable selinux.
I'd like to point out, while this is useful to test the tools, it is not recommended to do that on a production VM - sorry if that sound obvious, but better safe than sorry
@Davidj-0 @Tristis-Oris I started a pull request for this. Seems to work for simple cases, but if you want to shake it in real life that can help!
[shortcut to test RPM]
@stormi that would need to be done only if not upgrading then, or it would interfere with local admin's choice.
@Davidj-0 unfortunately not enabling daemons at first install is the standard behavior in RPM world. I already had a look at changing this for one package, and it turns out to be messy with unforeseen impact, so I gave up with the excuse that admins of RPM-based distros already have to live with this idiosyncrasy anyway.
I added this in install instructions in the Gitlab release notes already.
@Tristis-Oris I must say the error message is rather obscure. Can you please open a ticket for this one too?
@Tristis-Oris yes I had looked into that last week, and I suspect it could to be related to cert verification in some way, but I'm really not sure what's happening yet.
@Tristis-Oris said in New Rust Xen guest tools:
Incompatible with CentOS 7, well that obvious.
Right, we should find a place to mention the compatibility range, and check for a way to produce binaries for older distros even from newer ones (like what's done in Python world, but I have not spotted that yet in Rust world).
@Tristis-Oris currently it replaces xe-guest-utilities
but apparently I had missed xe-guest-utilities-latest
, adding it!
See https://gitlab.com/xen-project/xen-guest-agent/-/merge_requests/74 - you should get fresh RPMs in the "artifacts" section of RPM job in a few minutes
@Tristis-Oris that would be an agent issue, likely due to os_info misidentifying Rocky as CentOS, you can report it in https://gitlab.com/xen-project/xen-guest-agent/-/issues, I'll double check and forward as needed.
Thanks for the feedback again!
@Tristis-Oris That's it - I thought it would not be necessary to dive into the details, as the RHEL/CentOS/etc policy is that newly installed services are not started by default (as a Debian guy I never understood why, but eh), and I assumed it would in every admin's cookbook already. Will add this together with the DEB instructions.
Thanks guys for the feedback!
We just released version 0.4.0. Biggest highlight is that it is not necessary any more to have libxenstore
separately installed in guests, so the new RPM is now compatible with RHEL/CentOS and similar distros.
Details to be found at https://gitlab.com/xen-project/xen-guest-agent/-/releases/0.4.0
Hello @ajpri1998! Can you confirm that running this in the guest does print Pop!_OS
?
xenstore read data/os_distro
@forbiddenera FreeBSD support is already there, and binaries are available since v0.3.0 release. However, full support making use of Netlink (supported since FreeBSD 13.2) is not to be considered as mature yet, only due to the need to use still-unofficial patches on some dependencies -- full status here.
Windows support is also coming, but requires more work than FreeBSD did, you can follow the status of the first meaningful step (communicating collected info back to host) here. Right now a few other tasks take precedence, expect things to move forward again within a few weeks.