On Wed, 2005-08-24 at 09:15 +0100, Christian Limpach wrote:
> Hi Rusty!
> > I'm working on making the xenstore init/restart more robust. My idea
> > is to introduce a "--init" option which means "blow away any data in the
> > store, we're starting fresh" for use at boot time, and a "--restart"
> > which shuts down the old xenstored and gracefully takes over (upgrades).
> Sounds good, although wouldn't it be just as easy (and maybe a little
> more flexible) to implement the --init option in a seperate tool?
It's tempting, but that means exporting knowledge about the
representation the store uses, which I'd prefer not to do. And we
already have the code to destroy directories, so it's not at all
> > The daemon is going to have to remember outstanding transactions,
> > watches and watch events, and associate them when tools reconnect.
> > Where possible, these will be stored on disk, so even daemon crashes can
> > be recovered (as far as possible).
> Yes, this is currently one of the major draw backs from switching over
> to the store. If xenstored restarts, you lose all the watches and won't
> be able to start any more domains because the backends won't notice any
> changes anymore.
Yes, it's not possible at the moment, but it must be. I'm also thinking
hard about catastrophic failure modes: there are always "too hard" cases
but I'd like to be able to SIGKILL the store and (usually) have no
A bad analogy is like a leaky screwdriver -- Richard Braakman
Xen-tools mailing list