* [PATCH] add domain creation/shutdown script execution support.
@ 2007-03-06 13:56 Steve Kemp
2007-03-06 14:37 ` Mark Williamson
0 siblings, 1 reply; 8+ messages in thread
From: Steve Kemp @ 2007-03-06 13:56 UTC (permalink / raw)
To: xen-devel
[-- Attachment #1.1.1: Type: text/plain, Size: 414 bytes --]
This patch allows shell scripts / commands to be executed upon
either of the following events:
* Domain creation.
* Domain shutdown.
Scripts are executed in sorted order from two directories, which
if not present will disable the behavior:
* /etc/xen/domU-up.d/
* /etc/xen/domU-down.d/
Signed-off-by: Steve Kemp <steve@steve.org.UK>
Steve
--
http://www.steve.org.uk/
[-- Attachment #1.1.2: 01-add-script-support.diff --]
[-- Type: text/x-diff, Size: 1148 bytes --]
--- vif-common.sh-orig 2007-03-05 21:51:53.000000000 +0000
+++ vif-common.sh 2007-03-06 13:51:27.000000000 +0000
@@ -35,6 +35,19 @@
add | remove)
exit 0
;;
+ online)
+ if [ -d /etc/xen/domU-up.d/ ]; then
+ name=`xenstore-read ${XENBUS_PATH}/domain`
+ runDirectory /etc/xen/domU-up.d/ "${name}"
+ fi
+ ;;
+ offline)
+ if [ -d /etc/xen/domU-down.d/ ]; then
+ name=`xenstore-read ${XENBUS_PATH}/domain`
+ runDirectory /etc/xen/domU-down.d/ "${name}"
+
+ fi
+ ;;
esac
--- xen-script-common.sh-orig 2007-03-06 13:46:42.000000000 +0000
+++ xen-script-common.sh 2007-03-06 13:51:44.000000000 +0000
@@ -42,3 +42,25 @@
fi
done
}
+
+
+#
+# Run each executable script in the named directory,
+# passing them any arguments specified.
+#
+runDirectory()
+{
+ dir=$1
+ shift
+ args="$*"
+
+ if [ -d $dir ]; then
+ for i in $dir/* ; do
+ # regular files only which are executable
+ if ( test -f $i -a -x $i ); then
+ $i ${args}
+ fi
+ done
+ fi
+}
+
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] add domain creation/shutdown script execution support.
2007-03-06 13:56 [PATCH] add domain creation/shutdown script execution support Steve Kemp
@ 2007-03-06 14:37 ` Mark Williamson
2007-03-06 14:57 ` Steve Kemp
0 siblings, 1 reply; 8+ messages in thread
From: Mark Williamson @ 2007-03-06 14:37 UTC (permalink / raw)
To: xen-devel; +Cc: Steve Kemp
> This patch allows shell scripts / commands to be executed upon
> either of the following events:
>
> * Domain creation.
> * Domain shutdown.
Sounds like a very good thing to have. Other interesting events might include
domain crash, reboots (as distinct from domain crash / shutdown), etc, etc.
+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).
> Scripts are executed in sorted order from two directories, which
> if not present will disable the behavior:
>
> * /etc/xen/domU-up.d/
> * /etc/xen/domU-down.d/
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.
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'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"
Combined with a domain config file field like:
hooks = [ 'destroy=mylogdestroy.sh', 'customevent.wibble=mycustomscript.sh' ]
The syntax isn't particularly important; I based this on the hooks syntax used
by hg. The key is the functionality this would enable.
The ability to specify custom "events" that may be raised by Xend or that a
guest can raise explicitly using XenStore would enable easy plug-in extension
of dom0 functionality.
For instance, one might allow certain domains to trigger their own
checkpointing for backup purposes, or allow certain domains to request they
be suspended and restarted at a given time, etc (like "at daemon" for
domains).
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.
Thoughts, anyone?
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!
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] add domain creation/shutdown script execution support.
2007-03-06 14:37 ` Mark Williamson
@ 2007-03-06 14:57 ` Steve Kemp
2007-03-06 15:39 ` Mark Williamson
0 siblings, 1 reply; 8+ messages in thread
From: Steve Kemp @ 2007-03-06 14:57 UTC (permalink / raw)
To: Mark Williamson; +Cc: xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 2853 bytes --]
On Tue, Mar 06, 2007 at 02:37:50PM +0000, Mark Williamson wrote:
> 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.
> +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.
> 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.
> 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.
If it is a simple thing to implement than that would be a nice
bonus too.
> 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.
> 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.
Steve
--
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] add domain creation/shutdown script execution support.
2007-03-06 14:57 ` Steve Kemp
@ 2007-03-06 15:39 ` Mark Williamson
2007-03-06 15:49 ` Steve Kemp
0 siblings, 1 reply; 8+ messages in thread
From: Mark Williamson @ 2007-03-06 15:39 UTC (permalink / raw)
To: xen-devel; +Cc: Steve Kemp
> > 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!
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] add domain creation/shutdown script execution support.
2007-03-06 15:39 ` Mark Williamson
@ 2007-03-06 15:49 ` Steve Kemp
2007-03-07 0:50 ` Mark Williamson
0 siblings, 1 reply; 8+ messages in thread
From: Steve Kemp @ 2007-03-06 15:49 UTC (permalink / raw)
To: Mark Williamson; +Cc: xen-devel
On Tue, Mar 06, 2007 at 03:39:38PM +0000, Mark Williamson wrote:
> 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.
Yes that would be ideal.
> 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've currently only thought about this at a high level - am not so familiar
> with the post-Xenstore tools.
I'm not familiar with xenstore at all yet.
> 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".
That seems reasonable. The only downside is that I think I'd
be unable to implement it. I will try to find some time over the
next day or two to see how this stuff works and how easy it is
to "watch" with a daemon.
> 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.
Sure.
> 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.
Right. I guess that could be added later, once the xenstore watching
side was working for the events which were available immediately.
> 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 ;-)
That would. I didn't realise that the xenstore would be accessible
from within the domU - but I guess that just emphasizes the fact that
I'm hazy on how that stuff works.
Steve
--
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] add domain creation/shutdown script execution support.
2007-03-06 15:49 ` Steve Kemp
@ 2007-03-07 0:50 ` Mark Williamson
2007-03-07 9:37 ` Steve Kemp
0 siblings, 1 reply; 8+ messages in thread
From: Mark Williamson @ 2007-03-07 0:50 UTC (permalink / raw)
To: Steve Kemp; +Cc: xen-devel
> > 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.
> >
> :)
In fact, what I really meant was that the only reason I'm not recommending
they go in straight away (subject to a bit of clean up) is that it would be
nice to avoid changing the basic infrastructure in this area of the tools
later on if we want a more general mechanism.
I'm really glad you've taken the initiative on this, it has the potential to
give us some very powerful functionality quite cheaply.
> > I've currently only thought about this at a high level - am not so
> > familiar with the post-Xenstore tools.
>
> I'm not familiar with xenstore at all yet.
There's some information on it in the Wiki. Essentially it gives you a
hierarchical namespace describing the state of the management tools and the
domains running. This namespace is populated by (largely) human-readable
name=value pairs.
The nice thing is that it's basically a central point of contact for
configuration events *and* data. So if you stuff an entry in there saying
that blkback should create a virtual block device, it'll see that and create
one with the configuration it finds in Xenstore. Rendezvous between the
blkfront and blkback drivers *also* happens by each of them putting
information in Xenstore and performing actions when the other end does so.
Xenstore can apply updates transactionally.
> That seems reasonable. The only downside is that I think I'd
> be unable to implement it. I will try to find some time over the
> next day or two to see how this stuff works and how easy it is
> to "watch" with a daemon.
It shouldn't be *that* difficult for someone who groks Xenstore and can hook
into the right bits of Xend. But that would possibly require a bit of an
investment in time to figure out fully.
I'll continue thinking about how best to accomplish it in the meantime...
> > 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.
>
> Right. I guess that could be added later, once the xenstore watching
> side was working for the events which were available immediately.
Yep. It's not a big thing to add.
> > 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 ;-)
>
> That would. I didn't realise that the xenstore would be accessible
> from within the domU - but I guess that just emphasizes the fact that
> I'm hazy on how that stuff works.
It's certainly accessible from domU kernel space since it's used for various
signalling and setup operations. I recall there being long arguments on
exactly how / if Xenstore should be accessible from domU userspace but I'm
not sure how they panned out.
Anyhow, I really like this idea because it makes it straightforward for
administrators to delegate extra privileges to a domU without having to mess
about giving authentication for certain xm / XenAPI operations to the owners
of the domain. They wouldn't need access to dom0's network, and they can
only pass data through a narrow interface.
It'll be interesting to see where we can go with this...
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!
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] add domain creation/shutdown script execution support.
2007-03-07 0:50 ` Mark Williamson
@ 2007-03-07 9:37 ` Steve Kemp
2007-03-14 23:26 ` Mark Williamson
0 siblings, 1 reply; 8+ messages in thread
From: Steve Kemp @ 2007-03-07 9:37 UTC (permalink / raw)
To: xen-devel; +Cc: Mark Williamson
On Wed, Mar 07, 2007 at 12:50:39AM +0000, Mark Williamson wrote:
> In fact, what I really meant was that the only reason I'm not recommending
> they go in straight away (subject to a bit of clean up) is that it would be
> nice to avoid changing the basic infrastructure in this area of the tools
> later on if we want a more general mechanism.
Understandable.
> I'm really glad you've taken the initiative on this, it has the potential to
> give us some very powerful functionality quite cheaply.
I will endeavor to find some free time over the weekend to have a
play with the xenstored code, and see if I can watch events from it.
No promises at all, but if I get anywhere I'll post an update.
Right now I can use "xenstore-ls" to get a snapshot, and I guess
I could do that every five seconds or so to be able to detect newly
created domains, and existing ones which have been shutdown.
That's not ideal, but for a first pass should let me get something working.
Downside is I'd probably have to write the daemon in python to
get it into the core, right?
> There's some information on it in the Wiki. Essentially it gives you a
> hierarchical namespace describing the state of the management tools and the
> domains running. This namespace is populated by (largely) human-readable
> name=value pairs.
Great.
> I'll continue thinking about how best to accomplish it in the meantime...
:)
> It'll be interesting to see where we can go with this...
Agreed.
Steve
--
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] add domain creation/shutdown script execution support.
2007-03-07 9:37 ` Steve Kemp
@ 2007-03-14 23:26 ` Mark Williamson
0 siblings, 0 replies; 8+ messages in thread
From: Mark Williamson @ 2007-03-14 23:26 UTC (permalink / raw)
To: Steve Kemp; +Cc: xen-devel
> > I'm really glad you've taken the initiative on this, it has the potential
> > to give us some very powerful functionality quite cheaply.
>
> I will endeavor to find some free time over the weekend to have a
> play with the xenstored code, and see if I can watch events from it.
> No promises at all, but if I get anywhere I'll post an update.
>
> Right now I can use "xenstore-ls" to get a snapshot, and I guess
> I could do that every five seconds or so to be able to detect newly
> created domains, and existing ones which have been shutdown.
> That's not ideal, but for a first pass should let me get something
> working.
Should be interesting for prototyping, yes!
> Downside is I'd probably have to write the daemon in python to
> get it into the core, right?
Not necessarily; there is a C interface to Xenstore and some of the other code
(e.g. I think the console daemon) is written in C. Xend is mostly Python but
if you can cleanly code as a separate daemon then Python isn't strictly
necessary.
Cheers,
Mark
> > There's some information on it in the Wiki. Essentially it gives you a
> > hierarchical namespace describing the state of the management tools and
> > the domains running. This namespace is populated by (largely)
> > human-readable name=value pairs.
>
> Great.
>
> > I'll continue thinking about how best to accomplish it in the meantime...
> >
> :)
> >
> > It'll be interesting to see where we can go with this...
>
> Agreed.
>
> Steve
--
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!
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2007-03-14 23:26 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-03-06 13:56 [PATCH] add domain creation/shutdown script execution support Steve Kemp
2007-03-06 14:37 ` Mark Williamson
2007-03-06 14:57 ` Steve Kemp
2007-03-06 15:39 ` Mark Williamson
2007-03-06 15:49 ` Steve Kemp
2007-03-07 0:50 ` Mark Williamson
2007-03-07 9:37 ` Steve Kemp
2007-03-14 23:26 ` Mark Williamson
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.