add domain creation/shutdown script execution support.
PATCH 1/1 add domain creation/shutdown script execution support.
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/
Steve
Signature · 1 line
http://www.steve.org.uk/
vif-common.sh renamed from vif-common.sh-orig +13 -0
@@ -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 renamed from xen-script-common.sh-orig +22 -0
@@ -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 +} +
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel
Quoted 5 lines
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).
Quoted 5 lines
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
Signature · 4 lines
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!
Quoted 2 lines · Mark Williamson
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.
Quoted 3 lines
+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.
Quoted 4 lines
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.
Quoted 4 lines
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.
Quoted 8 lines
I've been thinking a bit about what a generalised "event hooks" infrastructure might look like:
e.g. a global
/etc/xen/events.configvaguely 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.
Quoted 4 lines
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
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel
Quoted 11 lines
Quoted 3 lines
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.
Quoted 6 lines
Quoted 3 lines
+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.
Quoted 8 lines
Quoted 4 lines
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.
Quoted 9 lines
Quoted 4 lines
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).
Quoted 2 lines
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".
Quoted 12 lines
Quoted 8 lines
I've been thinking a bit about what a generalised "event hooks" infrastructure might look like:
e.g. a global
/etc/xen/events.configvaguely 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:
Quoted 6 lines
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.
Quoted 7 lines
Quoted 5 lines
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
Signature · 4 lines
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!
Quoted 4 lines · Mark Williamson
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.
Quoted 3 lines
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.
:)
Quoted 2 lines
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.
Quoted 4 lines
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.
Quoted 4 lines
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.
Quoted 5 lines
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.
Quoted 6 lines
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
Quoted 5 lines
Quoted 4 lines
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.
Quoted 4 lines
Quoted 2 lines
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.
Quoted 4 lines
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...
Quoted 8 lines
Quoted 5 lines
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.
Quoted 10 lines
Quoted 6 lines
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
Signature · 4 lines
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!
Quoted 4 lines · Mark Williamson
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.
Quoted 2 lines
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?
Quoted 4 lines
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.
Quoted 1 line
I'll continue thinking about how best to accomplish it in the meantime...
:)
Quoted 1 line
It'll be interesting to see where we can go with this...
Agreed.
Steve
Quoted 7 lines
Quoted 2 lines
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.
Quoted 5 lines
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!
Quoted 2 lines
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
Quoted 16 lines
Quoted 4 lines
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.
Quoted 2 lines
I'll continue thinking about how best to accomplish it in the meantime...
:)
Quoted 2 lines
It'll be interesting to see where we can go with this...
Agreed.
Steve
Signature · 4 lines
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!