|
|
|
|
|
|
|
|
|
|
xen-api
Re: [Xen-API] handling "guest tools" versions
On 24 May 2010, at 14:23, Dave Scott wrote:
> Hi,
>
> After installing a guest on XCP we usually recommend installing the "guest
> tools". For windows this includes the PV drivers + a user-space agent (the
> agent handles things like clean shutdown requests); for linux this includes
> possibly a kernel update + a user space agent (actually a simple bash script
> which runs from cron and reports stats).
>
> Currently the user space agents write version numbers to xenstore which xapi
> compares with its internal version number and sets a per-VM flag
> PV-drivers-up-to-date. If this flag is false we're basically saying, "please
> upgrade the guest tools just in case something has changed"
>
> Unfortunately when someone makes a VM "appliance", they have to choose an
> arbitrary version number and stick it in there.
It is a little odd that there's no way to name the guest tools that are
installed, so someone with a custom or modified one can mark it as such from
the API. Right now the best you can do is pick a weird build number and set
the version to something arbitrary, as you note. If the user (as I do)
modifies the Linux PV tools to do custom stuff, then there's no way to separate
that from the base PV drivers version. It doesn't matter much for Linux, but
it does a lot more for Windows where the PV drivers actually do something.
One way to fix this might be to move the Major/Minor/Micro/Build information
into a PVAddons/<name>/ tree, and have a key in the root that lists the names
of the installed tools. Brownie points for moving the 'out of date' detection
logic to a dom0 host plugin instead of in xapi so that I can add custom tests
for detecting when to update my guest drivers :)
-anil
_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/mailman/listinfo/xen-api
|
|
|
|
|