Reworking the 'xe-guest-utilities' Repo
-
Hi All,
After adding support for Alpine Linux, I found the state of the xe-guest-utilities repo to be in pretty bad condition. This is mostly Citrix fault but at this point, I think XCP-ng has grown large enough that full rework is justified. The Go itself looks reasonable but has somethings worth changing. There also seems to be a large number of 'dead' files and a LOT of very poorly formatted and documented shellcode.
If anyone as an interest in me reworking this repo I can take a look at cleaning this up into something far more 'professional' and better suited for XCP-ng. I currently have a pull request submitted if you would like to look at the work I have done so far.
https://github.com/xcp-ng/xe-guest-utilities/pull/2
Best,
Justinclosed Major Update To Guest Utilities #2
-
Thanks a lot for your contribution
Now the question is to test it enough on various distros.
Also, we need to see if that can become the new upstream for XenServer, that would be better than just growing the gap between 2 distros
If we can tell them it works well and the code is in better shape, we might become the upstream or they might get the changes at least.If they refuse, well, it's not up to us
-
Yeah, I agree on not growing the gap but from what I have seen looking at the issues and pull requests on the origin repo, they aren't very responsive. I think also a lot of the changes I would like to make wouldn't be very well received. They support so many dead and depreciated distros its kind of insane. Right of the bat, I would want to remove support for CoreOS(EOL), Scientific Linux(Dead), Asianux(Dead), Boot2Docker(Dead), TurboLinux(Dead), etc. (They seem to really want to support Asian distros)
Also, I have every major distro working in my cluster so testing won't be much of an issue for me. We can setup unit tests pretty easy to depending on how much testing is actually needed.
-
Having tests will be a great argument to become the new upstream
-
Do you keep a list of all the distro's you support? I am looking at converting the shell into go, but I want to make sure I am accounting for the edge cases.
Currently, I am looking to officially support:
RHL:
- CentOS
- Fedora
- REHL (I don't have a copy to test on)
Deb:
- Debian
- Ubuntu
- Kali
- Mint
- MX
- Tails
- Kylin
Arch:
- Arch Linux
- Manjaro
BSD:
- FreeBSD
- OpenBSD
OpenSuse:
- Leap
- TumbleWeed
Random:
- Alpine Linux
- Gentoo
-
@olivierlambert Who on your team maintains/packages the iso? The versioning seems to be way off and I'm not sure what to make of it.
In the 8.1 iso, the iso reports
xe-guest-utilities_7.16.0-2_all.tgzbut if I build from source I getxe-guest-utilities_6.6.80-121_x86_64.tgz. Even weirder, XO reports management versions that don't even exist.My Ubuntu 20.04 VM reports
xe-guest-utilities/now 7.11.0-1 amd64 [installed,local]but the package you have in the iso isxe-guest-utilities_7.16.0-2_amd64.debbut XO is reportingManagement agent 8.0 detected
The only XO VM's that actually report the correct version are the ones provided in official repo's like FreeBSD, Alpine, and Gentoo.
Furthermore, for the life of me, I can't figure out who the hell is responsible for the source code. Like Ubuntu says that the package provides "xe-daemon for monitoring Virtual Machines on a Xen Hypervisor." but Gentoo says that the package is "XenServer Virtual Machine Tools". Is it part of the Xen Project or is it owned by "Citrix XenServer"? All the
xe-guest-utilitiespackages are supported by the official teams (Canonical, Gentoo, RHL) but they don't link to where the code is actually being versioned? Does each team pull from the source then version themselves?Not sure we could make a case for being upstream because IDK where that even is?
Sorry if this is ranty/sounds like an insane person wrote it, but I am so lost right now. I feel like I'm in versioning hell.
-
@stormi is our package manager so he might be able to answer you.
-
So, the situation with the linux guest tools is a bit complicated.
- Citrix distributes an ISO with pre-built and tested tools, but they don't share the build process nor the exact sources that was built from. And the
install.shscript doesn't exist in any repository except ours where I added it. - XCP-ng currently still uses the ISO from Citrix, altered to update
xe-linux-distributionandinstall.shwith a few fixes and improvements. We currently don't built the tools ourselves from sources but we plan to so your help is welcome. There are a few constraints such as "built binaries must work on any distro, even somewhat older distros", but nowadays that is not too hard to achieve. - The upstream repository, from Citrix, is https://github.com/xcp-ng/xe-guest-utilities and the maintainers are indeed not very responsive to pull requests. However, I want structural changes to be proposed there first before integrating them into our fork and diverging too much. We may decide to become our own upstream for those tools at some point, and your help would help move towards this, but we haven't given up yet on collaboration with Citrix. We managed to collaborate on other components such as the XAPI and this is still the preferred way to us.
Regarding Asian distros, I think that is indeed a commercial target for Citrix.
In your distro list, a quick look shows at least SLES missing.
About the removal of dead distros, let's remember that users may still be using them and not be able to migrate in the short term so I wouldn't drop their support too fast as long as it does not cause much extra maintenance.
And I currently am as lost as you are regarding the versioning
- Citrix distributes an ISO with pre-built and tested tools, but they don't share the build process nor the exact sources that was built from. And the
-
Hey @stormi
Okay, that clarifies some things. There is a metric ton of stuff to discuss here but rather than try and hit it all I'll try and focus on the really important stuff first.
- So when you say you don't have the build tools yourself, what does that mean exactly? If you have a working go dev environment, there is a makefile that will generate source. It won't make the individual packages (.deb, .rpm, .pkg) but that is pretty trivial in the scope of this. Does this mean you are not building these tools from source for each release?
- Can you clarify the versioning for me? (Let's use ubuntu as a test case to reduce complexity) The official Ubuntu Repos contain version
xe-guest-utilities_7.10.0-0_amd64.debas the most recent version. The XCP-ng tools iso on the other hand contains versionxe-guest-utilities_7.16.0-2_amd64.deb. Is this because Ubuntu has yet to accept new versions built by Citrix and provided through their iso? - What is the meaning of the management agent version in XO? This has been adding to my confusion about what is actually getting versioned here.
-
About Q3: XO is reporting what's XAPI is seeing. You can do a
xe vm-param-listand check the output regarding tool records. -
@JustinTimperio said in Reworking the 'xe-guest-utilities' Repo:
- So when you say you don't have the build tools yourself, what does that mean exactly? If you have a working go dev environment, there is a makefile that will generate source. It won't make the individual packages (.deb, .rpm, .pkg) but that is pretty trivial in the scope of this. Does this mean you are not building these tools from source for each release?
Yes, we have an open issue for that because I want that everything we provide be built by us, but currently the packages we have in our guest tools ISO are extracted from XenServer's RPM (that contains the ISO).
Our situation is different from that of any linux distribution that wants to provide the tools (which we encourage any distro to do), since what we provide is a RPM that contains an ISO that itself contains DEBs, RPMs, and others. It's not something we can easily build in our build system, koji (though there may be a way to manage it). So we've get to automate that build process.
In addition to that, I know the packages produced by Citrix are made so that they still work on older distributions, and I haven't had the time to define which distro we should build the binaries on for maximum compatibility. Building them in the same build root as we build XCP-ng may not be appropriate.
- Can you clarify the versioning for me? (Let's use ubuntu as a test case to reduce complexity) The official Ubuntu Repos contain version
xe-guest-utilities_7.10.0-0_amd64.debas the most recent version. The XCP-ng tools iso on the other hand contains versionxe-guest-utilities_7.16.0-2_amd64.deb. Is this because Ubuntu has yet to accept new versions built by Citrix and provided through their iso?
It's most likely because they haven't synced the sources recently. I doubt they provide binaries built by Citrix. Official versioning is, as far as I can tell, that of the tags in https://github.com/xenserver/xe-guest-utilities/tags
- What is the meaning of the management agent version in XO? This has been adding to my confusion about what is actually getting versioned here.
As Olivier said, this is the version that the tools themselves report to the XAPI. It does not seem to be related to the tags discussed above, and I don't know the logic behind those numbers.
-
I think there's absolutely no logic, sadly…
-
Okay, I think I am starting to get the picture here.
XO is reporting what's XAPI is seeing.
@olivierlambert Not sure it's pulling from that command. The only thing that the XAPI returns that is relevant is
PV-drivers-detected ( RO): true. If I runxe-param-list someuuid | grep 8.0I get nothing. (Could totally be wrong here)Official versioning is, as far as I can tell, that of the tags in
@stormi Okay weird, so they don't use releases but they will bump versions using tags if they edit a file....
It's most likely because they haven't synced the sources recently. I doubt they provide binaries built by Citrix.
@stormi That's disconcerting...
I think there's absolutely no logic, sadly…
Yeah, that's why I wanted to fork this into something that actually follows open-source standards lol. Most of my desire to move this into a separate repo is to avoid all these issues, which IMO, makes the Xen project look kind of poorly. When I was a noob, I spent so many hours trying to understand what guest tools were and why none of the versions were the same. Its been over a year now and sadly it has nothing to do with skill level. The tools are poorly maintained and versioned. Since Citrix is doing such a poor job, I think becoming the new upstream developer and supplier of these tools is a far more achievable option than trying to get Citrix to pull it together. XCP-ng as an open-source project can work directly with distro developers to unify and standardize these tools and make sure all distros are up to date.
Furthermore, by actually developing these tools and adding new features that Citrix is neglecting, XCP can 'corner' the market so to speak. I would way rather see you all grow and succeed over Citrix or VMware.
-
@stormi said in Reworking the 'xe-guest-utilities' Repo:
Our situation is different from that of any linux distribution that wants to provide the tools (which we encourage any distro to do), since what we provide is a RPM that contains an ISO that itself contains DEBs, RPMs, and others. It's not something we can easily build in our build system, koji (though there may be a way to manage it). So we've get to automate that build process.
Yeah, that is the bain of every multi-distro project. I am actually tooling something right now that can hopefully do that. It won't be the most advanced thing on the face of the earth but it will at least allow for testing on multiple distro's at once. Will prob take me a few days to finish.
-
Be sure to use:
xe vm-param-get param-name=PV-drivers-version uuid=<VM UUID>Output example:
# xe vm-param-get param-name=PV-drivers-version uuid=1c970fff-a74c-2f9d-21fe-9a9259e333e1 major: 8; minor: 0; micro: 50; build: 1 -
Okay yeah, that works. Wow, what the hell then... So basically the management engine is a totally pointless output as far as determining the xe-guest-utilities version. I would have thought that the management engine was == to utilities version.
- FreeBSD 12.1 is
xe-guest-utilities-6.2.0_3.txzandManagement agent 6.2 detected - Alpine Linux 3.11 is
xe-guest-utilities-7.17.0-r1.apkandManagement agent 6.6 detected - Ubuntu 20.04 is
xe-guest-utilities_7.16.0-2_amd64.debandManagement agent 8.0 detected
- FreeBSD 12.1 is
-
-
Having tests will be a great argument to become the new upstream
Our situation is different from that of any linux distribution that wants to provide the tools (which we encourage any distro to do), since what we provide is a RPM that contains an ISO that itself contains DEBs, RPMs, and others. It's not something we can easily build in our build system, koji (though there may be a way to manage it). So we've get to automate that build process.
This weekend I was able to finish the first tool I needed to help streamline the process of testing and building these tools. Its something I'm just calling PRT(Parallel Remote Terminal) for now. I currently have a number of testbeds in my cluster but testing manually on each is a huge pain. PRT is a tool that allows a user to define a group of remote hosts using a yaml file, then send the same command in parallel to each host. PRT returns the connection status, output, and errors on each host directly back to your machine. I hope you won't judge too hard on the quality of my code and docs because this was built in space of 48 hours lol.
You can check it out here:
https://github.com/JustinTimperio/prtI'll clean this up and improve it over the coming weeks but obviously, this is just tooling to help facilitate the actual work of improving these tools.
-
Hey @stormi could you send me an original Citrix iso with its tagged version? I'm trying to figure out if they are making changes before shipping by comparing checksums.
-
You can download the latest built tools from https://www.citrix.com/downloads/citrix-hypervisor/, select CH 8.2 express edition and then the Citrix VM Tools for linux.
