Hi,
Am Samstag, 3. Mai 2008 16:55 schrieb Maximilian Wilhelm:
> Nobody interested in this?
i'm very interested in this. But my approach for now is, that i check on all
other xen hosts if the domU to be created is already running elsewhere.
My assumption is, that no two domU configration use the same block devices.
I've written a little wrapper for xm (xm-wrapper.sh.tgz) and include this with
alias xm='/usr/local/sbin/xm-wrapper.sh'
in the ~/.bashrc on my dom0s. It's ugly, because it uses ssh to connect to the
other dom0s and has its own configuration (/etc/xen/hosts) but works for me.
Perhaps something like this could natively implemented in xm? Hm, or
clusterfied xm (configuration of other dom0s in /etc/xen/xend-config.sxp)
which can check for a running domU cluster wide?
Mainly, the check should use the xen api to get informations (and not xm).
You also could walk though the domUs block device list and look which block
devices are in use, and check against the block devices to be used for the
starting domU? The same xm does for local running domUs.
What do other people to prevent two domUs from using the same block devices in
a xen cluster setup?
> > These days I had the idea, that it should not be that hard to pimp
> > 'xm' to check if a domain already is running somewhere in the cluster
> > if there is a shared storage available.
> >
> > The basic idea is the following:
> >
> > Consider a cluster of n (>= 2) Xen nodes which share some storage
> > (e.g. a SAN or NAS or whatever) where the storage for the DomUs is
> > located and where some piece of shared (cluster) filesystem is located,
> > too.
> >
> > Let's asume further the shared file system is mountet to /xen_cluster
> > on all nodes.
> >
> > Now it would come in handy if xm (or maybe some other part of the
> > Xen univserse) could create some kind of lockfile on this FS to
> > indicate that a given domain is already running somewhere in this cluster
> > (maybe the Dom0 could be written into this file).
> >
> > This way it would be quite easy to prevent trouble from people
> > running Xen in this kind of environment, as on domain could only be
> > started once on the cluster.
> >
> >
> > So I've made up there patches
> > * [0] Example options for /etc/xen/xend-config.sxp
> > * [1] for options parsing for /etc/xen/xend-config.sxp
> > * [2] Basic implementation of lockfile checking/creation during 'xm
> > create' phase. The interesting part (shutdown, destroy, reboot(?),
> > migrate, ...) is missig.
> >
> > So what do you think about all this?
> >
> > I guess there is no big resistance against the idea as such.
> > What about the implementation approach?
> > Is this somethings you could imagine as a direction to go to?
> > Or maybe handle all of this internally to drop the dependancy of the
> > shared file system?
> >
> > [0] http://files.rfc2324.org/patches/xen/xend-config.sxp.diff
> > [1] http://files.rfc2324.org/patches/xen/XendOptions.py.diff
> > [2] http://files.rfc2324.org/patches/xen/create.py.diff
>
> Ciao
> Max
--
greetings
eMHa
xm-wrapper.sh.tgz
Description: application/tgz
pgpeg3qaJIHeK.pgp
Description: PGP signature
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home