Hi John,
> Yes, you're right, and I didn't explain my idea clearly.
>
> When I wrote 'smarter', I really meant something like the following: an
> administrator knows that the directory server must be booted first and
> others later. In a config file somewhere referenced by the xendomains
> init script, probably the same one below that configures per-domU
> settings for shutdown, he inserts the option to, for example, boot the
> dir. server immediately, and then wait 30 seconds to boot the remaining
> servers. This is a simple example, and there are probably use cases
> where more expression of more complex dependencies would be desirable.
I rather like your idea, actually. It seems like something that could
usefully be done. A couple of points that may be relevant to some, however:
* This is more complex than probably needed for an initially useful
proof-of-concept but ideally you'd like a domU to notify dom0 when
it's "ready" so that you can start other domains... Consider the case where
a server domU usually boots in 30secs but occasionally says "You've mounted
this ext3 filesystem 50 times without fsck, checking all filesystems now,
please wait three days" ;-) If you can set up your systems to be more
deterministic then this is less of an issue!
* For larger, multi-machine Xen deployments you'd need more complexity (e.g.
manage the dependencies on a cluster manager somewhere) because domUs on one
machine may depend on those on the other.
> >> It would also be nice, for example, to have per-domU settings for
> >> shutdown (hibernate or init 0?).
> >>
> >> This idea is still in a seed stage, so I'm not expressing it very
> >> clearly. Any pointers to similar-sounding information, though, are
> >> well appreciated. Thanks-
> >
> > Well, there you'd have to get into the "xendomain" init script that
> > RedHat uses. It's an interesting idea: the information could
> > theoretically be contained in a standard Xen init script, and even
> > reported to the Xen configurations for migration. But in the short
> > term, a sinple text-file with domain names and shutdown states could
> > be stuffed in /etc/sysconfig/ or /etx/xen/ for exactly this sort of use.
>
> So yes, the xendomains init script is where this work would have to be
> done. The RH xendomains script, and the one shipped with the
> xensource-provided RPMs, are the same IIRC, and both simply fire up all
> configs that exist in /etc/xen/auto (smart enough, at least, to wait a
> few seconds between successive fire-upings).
>
> For now, I am also tempted to stick things into an /etc/sysconfig file
> or perhaps to set variables in the /etc/xen/config scripts. This is
> just a hack for now, though, and there is probably a smarter way to
> integrate this information into the Xen system somewhere.
In theory, the New Way of handling configurable options like this is to add it
to the XenAPI and the managed domains facility in Xend. In practice these
aren't used that widely yet and it may be easier for you to hack it up using
scripting than to delve into Xend's codebase.
(a comparison point: Managed Domains can be created with an option to make
Xend auto start them itself, rather than relying on an init script to run
through /etc/xen/auto run xm create)
Cheers,
Mark
--
Push Me Pull You - Distributed SCM tool (http://www.cl.cam.ac.uk/~maw48/pmpu/)
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home