On 12/8/23 10:38, Yann Dirson wrote:
> Current status:
> - primary goal: to have one guest agent all downstreams can use, in all
> guests (with Linux and FreeBSD already supported), as efficient as
> possible (with Netlink already supported on Linux)
> - developed at https://gitlab.com/xen-project/xen-guest-agent (till now
> using gitlab PRs)
> - works fine as a replacement for the Xenserver xe-guest-utilities
Let's try to reboot the discussion.
> Some points raised during the community call:
> - we likely want first to agree on a core set of collected information
Currently I see the set of information collected as divided in the
following categories:
- those that are genuinely useful
- OS identifier (data/os_distro), and more detailed descriptive
string (data/os_name)
- kernel version (data/os_uname)
- IP addresses assigned to VIFs attached to the guest
- those that could be more useful but XAPI wants them
- free memory (data/meminfo_free) and total memory
(data/meminfo_total) according to guest OS (not necessarily well defined)
- control/feature-balloon=1 (necessary for XAPI's ballooning control
to do anything today)
- the version of the running agent, split in components
(attr/PVAddons/{Major,Minor,Micro,Build}Version) (including constraints
like Major being at least 1)
- those we provide for XAPI to be but without which it seems to be not
too sad, and I'd happily drop
- OS major and minor version (data/os_majorver, data/os_minorver)
What set of information (not necessarily from this list) do you think
would qualify as "core set of information to collect" ?
> - could be made more configurable (eg. define a xenstore schema at
> runtime, we don't want specific schemas needs to cause forks)
> -> it could be the agent requesting a specific xenstore schema
I do find some appeal to the idea that a toolstack should decide what
info the guest should give it and where. That could take the form of a
TBD string written to xenstore before the domain starts, e.g. matching
well-known IDs for pieces of information to xenstore paths.
> - what should be the criteria to advertise it as official Xenproject
> guest agent ?
What do people think here?
There is at least one known issue I'd like to address rapidly, which is
that the FreeBSD ports ship a buggy bash script [1] derived from
obsolete version of a XenServer tool. Maybe at least it's not necessary
to wait before approaching them to replace that old script with the Rust
agent in its current state?
[1]
https://github.com/freebsd/freebsd-ports/tree/main/sysutils/xe-guest-utilities
Best regards,
--
Yann
Yann Dirson | Vates Platform Developer
XCP-ng & Xen Orchestra - Vates solutions
web: https://vates.tech
