[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: Next steps for Rust guest agent
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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |