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

[Dave Scott <Dave.Scott@xxxxxxxxxxxxx>]

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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/mailman/listinfo/xen-api