[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] 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. 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! _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |