Basic xenstore questions (building a watchdog)

Basic xenstore questions (building a watchdog)

[Charles Duffy]

I'm looking at building a xenstore-based watchdog, as described at 
http://lists.xensource.com/archives/html/xen-users/2005-07/msg00597.html

However, being somewhat new to xenstore, I'd appreciate some pointers.

- What portions of the xenstore namespace should I use? I'm looking for 
at least two settings writable by the DomUs: A flag to enable/disable 
the watchdog for a given domain (ideally, this would be specific to an 
individual run of the instance in question and not persisted across 
runs), and a counter via the modification of which the watchdog may be pet.

   http://wiki.xensource.com/xenwiki/XenStoreReference indicates that 
/tool is likely an appropriate region (perhaps I should create 
/tool/watchdog/<vmid>/{enabled,counter}?), but this doesn't provide 
guidance as to how I can avoid persistance (if this is possible). 
Alternately, are vm GUIDs unique on a per-invocation basis? If so, 
/tool/watchdog/vmid/enabled could enable the watchdog only when it 
contains the current vm's GUID (preventing it from working across 
restarts). (Given some basic playing around with xenstore-list, 
xenstore-read and friends from within a DomU, however, it looks like I 
can't read contents of /vm from the DomU -- so am I actually able to 
find my own GUID such as to be able to use it in this way? For that 
matter, how can a DomU find its own vmid?)

- Are the xend.xenstore classes intended exclusively for xend's use, or 
is it acceptable for them to be used by 3rd-party software as well?

- Any example code I'd be well-advised to look at?

Thanks!

Re: Basic xenstore questions (building a watchdog)

[Ewan Mellor]

On Thu, Jan 12, 2006 at 03:46:38PM -0600, Charles Duffy wrote:

> I'm looking at building a xenstore-based watchdog, as described at 
> http://lists.xensource.com/archives/html/xen-users/2005-07/msg00597.html
> 
> However, being somewhat new to xenstore, I'd appreciate some pointers.
> 
> - What portions of the xenstore namespace should I use? I'm looking for 
> at least two settings writable by the DomUs: A flag to enable/disable 
> the watchdog for a given domain (ideally, this would be specific to an 
> individual run of the instance in question and not persisted across 
> runs), and a counter via the modification of which the watchdog may be pet.
> 
>   http://wiki.xensource.com/xenwiki/XenStoreReference indicates that 
> /tool is likely an appropriate region (perhaps I should create 
> /tool/watchdog/<vmid>/{enabled,counter}?), but this doesn't provide 
> guidance as to how I can avoid persistance (if this is possible). 
> Alternately, are vm GUIDs unique on a per-invocation basis? If so, 
> /tool/watchdog/vmid/enabled could enable the watchdog only when it 
> contains the current vm's GUID (preventing it from working across 
> restarts).

A UUID belongs to a VM, which is the entity that is the same across reboots and
migrations.  A domain is a running instance of a VM on that machine, so the
domain ID changes when a VM is migrated or rebooted.

You might want to hook off the domain ID rather than the UUID.  Your namespace
ideas sound fine otherwise though.

When domains are created or destroyed there are special watches that fire
(@introduceDomain and @releaseDomain).  This might help you get the
non-persistence that you require (by removing the path again when the domain
is destroyed).

> (Given some basic playing around with xenstore-list, 
> xenstore-read and friends from within a DomU, however, it looks like I 
> can't read contents of /vm from the DomU -- so am I actually able to 
> find my own GUID such as to be able to use it in this way? For that 
> matter, how can a DomU find its own vmid?)

Xenstore paths are controlled by permissions.  Dom0 can see everything and do
everything, but an unprivileged guest is only allowed to read and write to its
own areas.  Permissions are all set up by dom0 tools, and you will have to do
this yourself for the areas of the store that you are interested in.  I wrote
a long email on this matter before Christmas, because it changed quite
recently and is quite complicated.  You should dig it out of the archive.

The connection from the domU has an implicit root at /local/domain/<domid>.
If you specify a path without a leading /, then the implicit root is used, so
you can see your own vm path simply by reading "vm", your own domain ID by
reading "domid", etc.  However, domU's cannot by default read what is stored
inside /vm, even their own, as a security precaution.

> - Are the xend.xenstore classes intended exclusively for xend's use, or 
> is it acceptable for them to be used by 3rd-party software as well?

You're welcome to use them, I guess, but there's no guarantee about the
stability of the API, etc.  I would say that it's not likely that those
interfaces will change often, but they aren't something that we guarantee to
freeze or maintain backwards compatbility with.

> - Any example code I'd be well-advised to look at?

Xend's device handling in DevController.py does watch handling, transactions,
and permission setting.  That would be a good place to start.  If your
watchdog in the domU will be a device in the kernel, then you could start with
xenbus_probe.c and netfront/xenbus.c to see how xenstore is used by a domU to
trigger state changes inside drivers (using a watch and then responding to the
watch firing by reading and changing state appropriately).

Cheers,

Ewan.

Re: Basic xenstore questions (building a watchdog)

[Charles Duffy]

Ewan Mellor wrote:
> When domains are created or destroyed there are special watches that fire
> (@introduceDomain and @releaseDomain).  This might help you get the
> non-persistence that you require (by removing the path again when the domain
> is destroyed).
>   
Do those work outside of xend? I'm trying the following, and it's having
no effect when my domains restart after the watches' initial fire:

#!/usr/bin/env python

from xen.xend.xenstore.xswatch import xswatch
from pprint import pprint
import time, logging
logging.basicConfig(level=logging.DEBUG)

class XenWatchdog:
        def __init__(self):
                xswatch('@releaseDomain', self.onReleaseDomain)
                xswatch('@introduceDomain', self.onIntroduceDomain)
        def onReleaseDomain(self, *args, **kwargs):
                pprint([ 'onReleaseDomain', args, kwargs ])
        def onIntroduceDomain(self, *args, **kwargs):
                pprint([ 'onIntroduceDomain', args, kwargs ])

XenWatchdog()
while True:
        time.sleep(1)

Re: Basic xenstore questions (building a watchdog)

[Mark Williamson]

> I'm looking at building a xenstore-based watchdog, as described at
> http://lists.xensource.com/archives/html/xen-users/2005-07/msg00597.html

Sounds cool!

I knocked up a little prototype of one some time last year.  The Xend code was 
surprisingly tricky (couldn't get rebooting the domain to behave right, 
although I didn't try very hard).  You'd be welcome to the kernel code if you 
want to take a look, although it's very simple - the hacks required to the 
softdog device in Linux were minimal.

I'd suggest as an alternative to using the store, you might like to think 
about adding watchdog functionality to Xen itself...  The advantage here is 
that it also allows you to watchdog dom0, without requiring watchdog 
hardware.  Timing out dom0 would reboot the system, a domU would just result 
in its destruction (and the tools recreating it).

Just a thought ;-)

Cheers,
Mark

> However, being somewhat new to xenstore, I'd appreciate some pointers.
>
> - What portions of the xenstore namespace should I use? I'm looking for
> at least two settings writable by the DomUs: A flag to enable/disable
> the watchdog for a given domain (ideally, this would be specific to an
> individual run of the instance in question and not persisted across
> runs), and a counter via the modification of which the watchdog may be pet.
>
>    http://wiki.xensource.com/xenwiki/XenStoreReference indicates that
> /tool is likely an appropriate region (perhaps I should create
> /tool/watchdog/<vmid>/{enabled,counter}?), but this doesn't provide
> guidance as to how I can avoid persistance (if this is possible).
> Alternately, are vm GUIDs unique on a per-invocation basis? If so,
> /tool/watchdog/vmid/enabled could enable the watchdog only when it
> contains the current vm's GUID (preventing it from working across
> restarts). (Given some basic playing around with xenstore-list,
> xenstore-read and friends from within a DomU, however, it looks like I
> can't read contents of /vm from the DomU -- so am I actually able to
> find my own GUID such as to be able to use it in this way? For that
> matter, how can a DomU find its own vmid?)
>
> - Are the xend.xenstore classes intended exclusively for xend's use, or
> is it acceptable for them to be used by 3rd-party software as well?
>
> - Any example code I'd be well-advised to look at?
>
> Thanks!
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

-- 
Dave: Just a question. What use is a unicyle with no seat?  And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!

Re: Basic xenstore questions (building a watchdog)

[Charles Duffy]

Mark Williamson wrote:
>> I'm looking at building a xenstore-based watchdog, as described at
>> http://lists.xensource.com/archives/html/xen-users/2005-07/msg00597.html
>>     
>
> Sounds cool!
>
> I knocked up a little prototype of one some time last year.  The Xend code was 
> surprisingly tricky (couldn't get rebooting the domain to behave right, 
> although I didn't try very hard).  You'd be welcome to the kernel code if you 
> want to take a look, although it's very simple - the hacks required to the 
> softdog device in Linux were minimal.
>   
I would be very much interested in looking at what you've got so far, as 
an example if not a base.
> I'd suggest as an alternative to using the store, you might like to think 
> about adding watchdog functionality to Xen itself...  The advantage here is 
> that it also allows you to watchdog dom0, without requiring watchdog 
> hardware.  Timing out dom0 would reboot the system, a domU would just result 
> in its destruction (and the tools recreating it).
>   
It's a thought, yes -- but I'm already outside the realm of 
stuff-I-know, and I'd like to get at least *something* in working 
condition before I stray much further. Also, I'm under the impression 
that running softdog in dom0 with nowayout set should provide similar 
functionality -- perhaps I saw someone mentioning on the ML that they 
were doing just that?