|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Notes about "A common codebase for guest utilities, defined and shared with Xen downstreams"
sa: Samuel ed: Edwin xi: Xihuan an: Anthony ya: Yann pa: Pau sa: agent running in a vm communication with the host via xenstore, there's no common code between vendors. linux vendors do not know what version to package. we tell customers to download the citrix tools. current implementation in go Freebsd didn't package them ed: what's the minimal features that are needed? And what are the added features that are needed? ya: suspend resume handled by the guest kernel qubes have their own infrastructure sa: there's an empty git repo listing features in https://gitlab.com/xen-project/xen-guest-agent There are differences between the metrics in qubes and xenserver ya: instead of pushing information, only publish the info to xenstore on demand. Different agents report the memory stats in different xenstore locations ed: after resuming, the guest agent refreshes xenstore keys, could be done by udev ya: go agent don't do it, maybe kernel drivers do ed: there's a commit from 2016 fixing it currently we have to support current protocol, and the current protocol. Signal through xenstore, use a new interface instead. The new interface was proposed years ago, to expose metrics from the guests, did it get implemented? ya: a more efficient xenstore? ed: is it even the correct interface? but there are too many guests using it to remove it. sa: maybe guests could rely on xenstore's package from the distribution? ed: the agent probably need root access, currently go agent reimplements xenstore, but it's incompatible with distro's package if there's already a xenstore library available, the agent should just use that sa: the initial coreos issues may not still hold, there's now fedora coreos PoC was tasked to Yann to gfetch the IP address and other easy metrics, we will share once we have a minimal set of feature to gather feedback. ed: are you using the distro packages for xenstore? sa: if it's available yes, and otherwise we make the package ourselfves. On gitlab we won't include this packages, only the agent code. ed: the one installed in dom0 has different parameters from the ones in the guests, it's probably not intentional sa: we'll make them compatible with the upstream provided why create a new project? do not depend on xenserver, but be in xen so distro packagers know to take that code to build packages. We must reach qubes to follow this, as well as Amazon, maybe other downstreams? reading /etc/release was major improvement that users contributed, based on a design we wrote distro detection tool can massively simplify ed: what about bsd? is there any interest? sa: we don't provide package that can be installed, instead it will fetch user-contributed repos that have an old version that works ed: avoiding linux-specific dependencies would be good. xi: the repo is empty sa: the repo will be empty until we have a proof of concept vates can share ed: does this need to be an rpm? A lot of complexity in Citrix is in the pipeline sa: it may be a noarch rpm, without building anything ed: if the rpms need to be build for guest is very complex sa: how to provide packages for distros that don't provide them. In our bbuild system there's black magic. In koji the go program is done, then build the rpm and tar.gz is built, because it's statically linked ed: without binaries would be even simpler ya: depending on distro the config files are on different places sa: location should be defined in the package metadata, not in the user repo build upstream distros should build most of the packages we build only for some distributions which don't release the up-to-date guest utils we offer users in our webpage the option to pick pa: what language is the PoC? ya: we haven't started! sa: we're trying to use without any languages, using udev. We haven't discussed what language would be appropriate For linux it should be very simple to build Static linking is very convenient for vates pa: there's an ocaml project using cosmopolitan libc allows to run static binaries on windows, linux and freebsd ya: seems very specific, runs risk of not being accepted, it should be simple to code an: compatibility in python is not good sa: not all distros will have python ed: maybe a kernel driver? pa: it's linux-specific, though ed: what do other hypervisor do? kvm agents? qemu agent? an: never seen a qemu agent ya: there's a helper for better mouse interaction through qemu ed: what language, how are they distributed? an: maybe the source is in qemu ya: there may be a driver iso, can't remember an: https://www.qemu.org/docs/master/interop/qemu-ga.html sa: copy and paste... surprising to see there was no easy way to share clipboard an: xenserver has sa: but only for windows, with a vnc console for linux, there's no such thing. Maybe it's easy to activate but we don't know the way ed: vnc should have that (nobody in the room knows) ya: in qubes has it's own rpc infrastructure to control access to clipboard access through vchan There are shortcuts to share guest clipboard to the global one and back ctrlc ctrlshiftc etc, it's a specific mechanism ed: we could reuse that, maybe ya: it's not very advanced, only text. Maybe patches needed! sa: let's wrap up thanks for joining everybody, we'll share the notes
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |