Re: [Xen-devel] [PATCH] add domain creation/shutdown script execution su
> > 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
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