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.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home