@sb2014 this address reporting looks buggy, can you please share some guest information (OS type and version, guest agent version reported by XO)?

@pdonias said in Xen Orchestra netbox sync error:

So if XAPI isn't supposed to return space-delimited IPs in x/ipv4/x fields, better make sure it's fixed upstream, but from XO's point of view, we're supporting it anyway, now

Yes I'd think XAPI should not blindly forwarding information from guest without a minimum of sanitation.

@pdonias looks like the problem occurs because there are 2 kinds of data in the guest metrics: the "old style" which was never meant for multiple IPs but can be (and apparently has been) used for that, and OTOH the "new style" which XAPI created without checking it puts a valid value there.

Would it be that XO was parsing both, splitting 0/ip?
It would look like in the presence of both styles, given the existence of this issue, it would be sufficient to just ignore the "new style" one?

@sb2014 OK no fundamental change here.

Looking at this old agent code, though, I note that the IPs are all written space-separated in a single write to attr/eth0/ip, which is a place I've never heard about (the standard xenstore structure is documented here.

Still, this xenstore key is documented as "old style" in the XAPI code. We can easily check that writing just 2 IP space-separated addresses to this xenstore key had this exact behaviour:

host# xenstore ls /local/domain/443/attr
eth0 = ""
 ip = "1.2.3.1 1.2.3.2"
PVAddons = ""
 MajorVersion = "6"
 MinorVersion = "2"
 MicroVersion = "0"
 BuildVersion = "76888"
 Installed = "1"

XO then displays 3 entries, the first 2 ones being the individual IPs from the string, and the last one being the full unparsed string. This looks like a bug in XAPI, where the old way of publishing IPs is likely not that well tested.

EDIT Reported upstream - it looks like this old protocol simply did not support multiple IPs, and the old guest-agent is just buggy, it should have protected against multiple IPs and only reported one.

@sb2014 The status of the guest tools on FreeBSD is really bad at the moment, and they finally marked this port as unmaintained 2 weeks ago.
Looks like such a result could only result in ifconfig output changing; it would be useful to get a look at what your ifconfig output looks like, and likely update /usr/local/sbin/xe-update-guest-attrs and propose a patch to the BSD ports maintainers.

For a better solution, I'll try to allocate more time to xen-guest-agent to get it fully working in FreeBSD soon.

@sb2014 this address reporting looks buggy, can you please share some guest information (OS type and version, guest agent version reported by XO)?

@TheiLLeniumStudios from what I understood it could be run by generating a custom Talos image. I don't have any detailed knowledge of Talos, so I can't say if there is any easier way.
Everything named "xe-guest-utilities" refers to the current guest tools or an older version thereof, all of which require many external utilities not present in Talos.

@TheiLLeniumStudios you can get a prebuild Linux binary as linked from the blog post, so not from the latest code, but should be good for a first test. Please let us know how it fares!