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

[Mark Williamson <mark.williamson@xxxxxxxxxxxx>]

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