Next steps for Rust guest agent

Next steps for Rust guest agent

[Yann Dirson]

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

Some points raised during the community call:
- we likely want first to agree on a core set of collected information
- 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
- what should be the criteria to advertise it as official Xenproject 
guest agent ?


Yann Dirson | Vates Platform Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech

Re: Next steps for Rust guest agent

[Yann Dirson]

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

Re: Next steps for Rust guest agent

[George Dunlap]

On Thu, Jan 11, 2024 at 12:27 PM Yann Dirson <yann.dirson@vates.tech> wrote:
> > - what should be the criteria to advertise it as official Xenproject
> > guest agent ?
>
> What do people think here?

As we discussed at the community call, I think that we should
basically set a date at which we consider this the official Xen
Project guest agent.  Anyone who wants to have input can give it
before then.  Then once you guys think it's ready, we can start to
"market" it to the distros.

Shall we say 29 February, 8 weeks from now?

 -George

Re: Next steps for Rust guest agent

[Julien Grall]

Hi George,

On 01/02/2024 16:55, George Dunlap wrote:
> On Thu, Jan 11, 2024 at 12:27 PM Yann Dirson <yann.dirson@vates.tech> wrote:
>>> - what should be the criteria to advertise it as official Xenproject
>>> guest agent ?
>>
>> What do people think here?
> 
> As we discussed at the community call, I think that we should
> basically set a date at which we consider this the official Xen
> Project guest agent.  Anyone who wants to have input can give it
> before then.  Then once you guys think it's ready, we can start to
> "market" it to the distros.

+1

> 
> Shall we say 29 February, 8 weeks from now?

This is 4 weeks away. I am fine with that, but checking this is the date 
you intended to set.

Cheers,

-- 
Julien Grall

Re: Next steps for Rust guest agent

[George Dunlap]

On Thu, Feb 1, 2024 at 4:57 PM Julien Grall <julien@xen.org> wrote:
>
> Hi George,
>
> On 01/02/2024 16:55, George Dunlap wrote:
> > On Thu, Jan 11, 2024 at 12:27 PM Yann Dirson <yann.dirson@vates.tech> wrote:
> >>> - what should be the criteria to advertise it as official Xenproject
> >>> guest agent ?
> >>
> >> What do people think here?
> >
> > As we discussed at the community call, I think that we should
> > basically set a date at which we consider this the official Xen
> > Project guest agent.  Anyone who wants to have input can give it
> > before then.  Then once you guys think it's ready, we can start to
> > "market" it to the distros.
>
> +1
>
> >
> > Shall we say 29 February, 8 weeks from now?
>
> This is 4 weeks away. I am fine with that, but checking this is the date
> you intended to set.

...

I have no idea how that 8 got there... yes, 4 weeks is what I meant to write.

 -George