Re: Next steps for Rust guest agent

[Yann Dirson <yann.dirson@xxxxxxxxxx>]

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