> > Sounds like a very good thing to have. Other interesting events might
> > include domain crash, reboots (as distinct from domain crash / shutdown),
> > etc, etc.
>
> Indeed. One thing that I wanted to have was events firing upon pause
> and unpause. Right now that wouldn't be possible with my naive
> approach.
>
> I was pleasantly surprised that a shutdown managed to trigger as
> distinct shutdown + create events, but it would be nicer to have
> a distinct event-type of "reboot" to catch it.
Yes, the separate shutdown + create events might be useful for some
circumstances but it would also be good be good to distinguish the case of a
true reboot. Maybe it could be a flag to the shutdown / create events since
it seems possible that some of the work will be the same.
> > +1 for the functionality, although it would be nice for more general
> > consumption if you could arrange to not rely on the vif scripts
> > (particularly as people may have customised these already).
>
> Agreed. As I said in a private mail elsewhere it was just a convenient
> place to hang the hook.
Yes, that's completely understable! These scripts are an excellent place to
hang stuff off.
> > We ought to try and figure out exactly what the requirements for generic
> > support for scripts executed on dom0 events are. Sorry for taking this a
> > bit off course, but I think maybe this is a good point to think about
> > infrastructure for actions-on-dom0-events stuff.
>
> If it is going to get accepted then I'm happy for it to be haggled
> over first! I'd rather get it right first time if possible, even if
> that does take a couple of attempts.
Cool. None of this discussion precludes the usefulness of the patches you've
proposed, I'm just wondering if a slightly more generic version would be a
good idea.
> > I wonder if a better long term approach might be to have some daemon
> > (either Xend or a separate daemon) execute scripts based on some (global
> > or domain-specific) config options tying Xenstore watches directly to
> > commands to execute.
>
> I'm not too sure just yet how that would be implemented, but if it
> is integrated with xenstore I imagine it would allow a lot more
> hooking facilities such as as additional disks being brought up,
> memory sizing is changed, etc.
I've currently only thought about this at a high level - am not so familiar
with the post-Xenstore tools.
There could either be a separate daemon issuing its own Xenstore watches and
responding to events based on them, or Xend could start a thread (or just
wait for events in an existing thread) which watches those items that are
relevant to its config.
When then watch callback fires, it'd process the event according to the
config, initially by just issuing a shell command with some standard
arguments (e.g. domain, event type, etc).
> If it is a simple thing to implement than that would be a nice
> bonus too.
I'd say it'll be more complex in the implementation than your current patch,
but it might scale better with different kind of event configurations:
associating scripts directly with Xenstore changes gives us the ability to
monitor all kinds of stuff, almost "for free".
> > I've been thinking a bit about what a generalised "event hooks"
> > infrastructure might look like:
> >
> > e.g. a global /etc/xen/events.config vaguely like:
> >
> > domains.*.create = logCreate.sh # log the create of any domain
> > domains.webserver.crash = emailSysadmin.sh # log the creation of the
> > domain called "webserver"
>
> Interesting idea. I guess the key here is working out which events
> are useful to have. So far we've got:
>
> create
> shutdown
> crash
>
> "Nice to have", for me, would include: reboot, pause, unpause,
> console attach, and console detach.
Yep.
Possibly we'd need a bit of "syntactic sugar" to make specifying the Xenstore
watches more palatable for people who don't like to know about the internals
of the management plane ;-) If necessary, some kind of "shorthand" for
specifying common events might work well.
As far as I know, stuff like paused / unpaused status is not available in
Xenstore. The obvious solution would be to create a Xenstore node allowing
Xend to announce when it has paused / unpaused domains to Xenstore watchers
who might be interested. This could easily generalise to other tools-level
events as well.
> > This would make it easier to customise Xend behaviour for site-specific
> > behaviour without needing to hack on the core code in the first instance.
> > These custom events could potentially be easily shared, too. This would
> > not replace generally useful functionality being rolled into Xend in some
> > way.
>
> Agreed.
Another feature which I had in mind when thinking about this was that of
domain users requesting they have a previous backup of the filesystem
restored. By simply writing to a Xenstore node from within their domain,
they could request that the management plane restore a backup of their
filesystem from a particular date and then reboot them with it. That would
be super cool ;-)
Cheers,
Mark
--
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!
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home