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: Steve Kemp <steve@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] add domain creation/shutdown script execution support.
From: Mark Williamson <mark.williamson@xxxxxxxxxxxx>
Date: Wed, 7 Mar 2007 00:50:39 +0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 06 Mar 2007 16:49:28 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20070306154939.GA21594@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> <200703061539.38596.mark.williamson@xxxxxxxxxxxx> <20070306154939.GA21594@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.9.5
> > 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...


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