WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH] add domain creation/shutdown script execution su

To: Mark Williamson <mark.williamson@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] add domain creation/shutdown script execution support.
From: Steve Kemp <steve@xxxxxxxxxxxx>
Date: Tue, 6 Mar 2007 14:57:38 +0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 06 Mar 2007 06:56:49 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <200703061437.50220.mark.williamson@xxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20070306135628.GA14559@xxxxxxxxxxxx> <200703061437.50220.mark.williamson@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.13 (2006-08-11)
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: signature.asc
Description: Digital signature

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel