Xen devel - Mar 2007 - [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.

  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/



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

>   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@lists.xensource.com
http://lists.xensource.com/xen-devel

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
-- 


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

> > 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@lists.xensource.com
http://lists.xensource.com/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
-- 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/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!

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

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
-- 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/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!

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