I just tried to install Ubuntu 24.04 to test it out, and I experienced the same problem with it not recognizing the IP address. I was first using the Ubuntu-provided package (xe-guest-utilities=7.20.2-0ubuntu1), which was failing. I then tried the package I had been using with my Ubuntu 22.04 servers that used to be part of the XCP-ng guest-tools.iso (xe-guest-utilities_7.20.0-9_amd64.deb) and had the same results. I mounted my current guest-tools.iso, which now has xe-guest-utilities_7.30.0-11_amd64.deb, and installed it. Now it was retrieving the IP address correctly. I'm not sure why the OP was still having trouble with that version (I'm using UEFI instead of BIOS, but I wouldn't think that would matter).

I went ahead and tried out the Rust-based tools mentioned (xen-guest-agent_0.4.0_amd64.deb), and it was properly getting the IP address as well. I'm guessing there's some incompatibility (probably with the 6.x kernel) that was fixed between 7.20 and 7.30 (intentionally or accidentally).

Given how much the Linux tools have changed over the years and the fact that they're not used for PV drivers anymore, is there a particular reason to use one over the other (legacy vs Rust)? What features do they really provide now? Is it just CPU/memory/disk/network status?

@forbiddenera said in xe-guest-utilities on ubuntu 22.04:

I was just able to install them fine on 22.04.3 LTS; perhaps they've been added back?

FYI, the original Ubuntu 22.04 (Jammy) release dropped xe-guest-utilities, while 20.04 (Focal) had it. It was later added through the jammy-updates repo.

A little info is here: https://bugs.launchpad.net/ubuntu/+source/xe-guest-utilities/+bug/2006459

I just tried to install Ubuntu 24.04 to test it out, and I experienced the same problem with it not recognizing the IP address. I was first using the Ubuntu-provided package (xe-guest-utilities=7.20.2-0ubuntu1), which was failing. I then tried the package I had been using with my Ubuntu 22.04 servers that used to be part of the XCP-ng guest-tools.iso (xe-guest-utilities_7.20.0-9_amd64.deb) and had the same results. I mounted my current guest-tools.iso, which now has xe-guest-utilities_7.30.0-11_amd64.deb, and installed it. Now it was retrieving the IP address correctly. I'm not sure why the OP was still having trouble with that version (I'm using UEFI instead of BIOS, but I wouldn't think that would matter).

I went ahead and tried out the Rust-based tools mentioned (xen-guest-agent_0.4.0_amd64.deb), and it was properly getting the IP address as well. I'm guessing there's some incompatibility (probably with the 6.x kernel) that was fixed between 7.20 and 7.30 (intentionally or accidentally).

Given how much the Linux tools have changed over the years and the fact that they're not used for PV drivers anymore, is there a particular reason to use one over the other (legacy vs Rust)? What features do they really provide now? Is it just CPU/memory/disk/network status?

@pdonias That would make sense for most use cases. If no tools are detected (whether running or not), don't do anything with IPs.

However, that leads to a different corner case. What if you shut down a machine that you don't intend to bring back up (except if there's an emergency), and you do want the IPs to get removed. Maybe at that point, the responsibility falls on the admin to manually update Netbox.

@pdonias Sorry for the delay.

Yes, allowing someone to define the tags in the plugin that are used for the different features would avoid locking in the names, so I'm not opposed to that.

For the IPs, I had thought about looking at whether the xentools were installed, but I couldn't find a guaranteed way to determine that (mainly for machines that have the tools but are currently shut down). I see the PV-drivers-detected parameter under xe vm-param-list, but it shows false when the VM is shut down, even if it has the tools installed. It might be a little bit of a corner case, but I wouldn't want the sync to delete IP addresses I've manually assigned just because it's shut down.

A follow-up to the "keep interfaces" option. It doesn't look like that would really be needed, as the NB interface stores the UUID from XCP. It should just be a matter of checking for a blank UUID in order to assume it was manually created in NB.

@pdonias One more doc note. With the recent changes to store the VM platform, you also need to grant full permission on DCIM > Platform

Related to this: Netbox Plugin Enhancements

I recently started using Netbox and set up the sync plugin through XO from sources to give it a try. In general, it's pretty nice (much better than manually keeping up with things). However, one issue I ran into that was similar to the one reported in the referenced post was things getting deleted in Netbox that I had manually added.

In my case, I have two VMs that are full HVM appliances with no xentools integration, so XCP cannot see their IP addresses. If I manually add the IP address in Netbox to the interfaces, they will get deleted on the next sync (the code deletes any existing IP addresses on a NB interface that don't exist on the XCP interface). In my particular case, XCP will never see any IP addresses, so I need to track them manually.

There was a similarly related request for more control of the sync with Github issue #5965.

The overall idea is to introduce a tag system to control the Netbox sync on a per-VM level. I think this may be the most versatile way of handling tweaks like this. A standard namespace could be introduced (e.g. nbsync_*) that holds the different config options for a VM. Maybe it could start with something like this:

nbsync_keep_ips - Keep existing IP addresses assigned to an interface in Netbox even when the IP address no longer exists in XCP

nbsync_keep_interfaces - Keep existing interfaces in Netbox even when the interface no longer exists in XCP

nbsync_exclude - Exclude this VM from the Netbox sync

I've looked at the Netbox code a little to understand the sync process, and these options don't seem too complicated to add. I'd love to help out, but I've done zero node.js programming, so it would/will take me a while to get acquainted with the nuances of the language (probably a lot of copy-and-paste-and-tweak from existing code).