Xen devel - May 2010 - [Xen-API] XCP: handling "guest tools" versions (v2)

Hi,

I''d like to propose a small tweak to the way xapi expects guests to
signal the version of their "guest tools".

I''ve put the full text on the wiki:
  http://wiki.xensource.com/xenwiki/Handling_guest_tools_in_appliances
I''ve also made a simple index of XCP proposals/RFCs, of which this is
the first (of many I hope) :)
  http://wiki.xensource.com/xenwiki/XCP_proposals

Since v1 (posted to xen-api on Monday) I''ve received and incorporated
feedback from Andrew and Anil (cc:d). I''ve changed the name of the new
flag, clarified the behaviour a bit and also explicitly limited the scope so
that it doesn''t include full VM appliance check-for-updates
functionality :)

Here''s the text inline, feedback appreciated!

== Problem statement =
After installing a guest on XCP the "guest tools" should be installed
otherwise operations like suspend/resume/migrate are blocked. The windows guest
tools include:
    * the PV drivers;
    * a user-space agent responsible for handling clean shutdown/reboot requests
and reporting stats.
The linux guest tools include
    * possibly a kernel update;
    * a user-space agent responsible for reporting 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
include an arbitrary version of the guest tools and it might not be possible to
actually upgrade them, as the appliance may be (should be?) locked down.

== Proposal =
=== XenStore ==
I propose that we add a flag

/local/domain/<domid>/attr/PVAddons/NotUpgradable

Which if present in xenstore and has value "1" will hard-wire
PV-drivers-up-to-date to "true", thus users will not be prompted to
upgrade the tools.

The existing version number keys may or may not be present. If they are present
then the numbers will be visible in the XenAPI via the VM_guest_metrics
PV_drivers_version map as usual.

For reference the existing keys are:

/local/domain/<domid>/attr/PVAddons/MajorVersion
/local/domain/<domid>/attr/PVAddons/MinorVersion
/local/domain/<domid>/attr/PVAddons/MicroVersion
/local/domain/<domid>/attr/PVAddons/BuildVersion
/local/domain/<domid>/attr/PVAddons/Installed

Note these keys are inspected only when the key

/local/domain/<domid>/data/updated

is modified.

=== Linux guest agent ==
For convenience the linux guest agent will be modified so that: if a file
/etc/pv-drivers-not-upgradable is present in the filesystem, the NotUpgradable
key will be automatically added to xenstore. The linux guest agent will still
continue to write the existing version number keys.

== Out of scope =
We''ll not try to address the more general problem of detecting when an
appliance itself needs upgrading, or when some other software component within a
VM needs upgrading.

Cheers,
Dave

_______________________________________________
xen-api mailing list
xen-api@lists.xensource.com
http://lists.xensource.com/mailman/listinfo/xen-api

On Fri, 2010-05-28 at 14:47 +0100, Dave Scott wrote:
> 
> 
> For convenience the linux guest agent will be modified so that: if a
> file /etc/pv-drivers-not-upgradable is present in the filesystem, the
> NotUpgradable key will be automatically added to xenstore. The linux
> guest agent will still continue to write the existing version number
> keys.
Lets plan to add a proper config file rather than a stamp file. it can
be a shell fragment suitable for sourcing (/etc/sysconfig/ style). e.g. 
        $ cat /etc/xe-guest-utilities.conf
        #Uncomment in appliance VM
        #UPGRADEABLE=false
or something like that.

Ian.


_______________________________________________
xen-api mailing list
xen-api@lists.xensource.com
http://lists.xensource.com/mailman/listinfo/xen-api

Hi,
> On Fri, 2010-05-28 at 14:47 +0100, Dave Scott wrote:
> > For convenience the linux guest agent will be modified so that: if a
> > file /etc/pv-drivers-not-upgradable is present in the filesystem, the
> > NotUpgradable key will be automatically added to xenstore. The linux
> > guest agent will still continue to write the existing version number
> > keys.
Ian Campbell wrote:
> Lets plan to add a proper config file rather than a stamp file. it can
> be a shell fragment suitable for sourcing (/etc/sysconfig/ style). e.g.
>         $ cat /etc/xe-guest-utilities.conf
>         #Uncomment in appliance VM
>         #UPGRADEABLE=false
> or something like that.
Good idea. I've added this, with a slight tweak (I used NOTUPGRADABLE=true
for consistency with the negative-sense of the NotUpgradable xenstore key, and
dropped the "e" for uniformity). The relevant text now reads:
>>>>
For convenience the linux guest agent will be modified so that sources a
configuration file

/etc/xe-guest-utilities.conf

which has default contents:

        #Uncomment in appliance VM

        #NOTUPGRADABLE=true

If the file is modified so that NOTUPGRADABLE is defined as "true"
then the NotUpgradable key will be automatically added to xenstore. The linux
guest agent will still continue to write the existing version number keys.
<<<<

Cheers,
Dave

_______________________________________________
xen-api mailing list
xen-api@lists.xensource.com
http://lists.xensource.com/mailman/listinfo/xen-api