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/
Home Products Support Community News


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 15:49:39 +0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 06 Mar 2007 07:48:42 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <200703061539.38596.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> <20070306145738.GA18390@xxxxxxxxxxxx> <200703061539.38596.mark.williamson@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.13 (2006-08-11)
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.


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


Xen-devel mailing list