> I would certainly appreciated this. Then I can keep my automation roughly
> in line with what's going to happen anyway, so I can move from my system to
> the official one without too much pain. I'm certain the official one will
> be much better anyhow :o)
OK, here's some thoughts that clarify the existing control structure and what
a cluster controller ought to do. I attach an old design doc from before the
current set of control tools, which I've updated to correspond better to
reality.
The crux of the cluster controller is that it really consists of two parts:
* Stuff to manage the cluster resources in a uniform way (e.g. migration,
start / stop domains anywhere in the cluster, monitor domains... + the
console concentrator)
* Stuff to manage VMs (image templates, etc) more effectively.
These are pretty independent. We imagine all state being stored in an SQL
server. Hopefully, the SQL server can provide us replication of this data,
etc.
On top of this, command line (and at some stage) web-based interfaces would be
required to run the show.
A lot of the code shouldn't be too technically difficult, just time-consuming.
The SQL database will need to be carefully designed. We would probably tend
to implement daemon code in Python, like all the rest of the tools.
We would love to see contributions in this area.
HTH,
Mark
> Another little query about the LVM stuff: I'm using kernel 2.6 so does this
> rule out the LVM option? The package note for Sarge's LVM2 says that it
> works with 2.4 only.
>
> Thanks Mark.
>
> Regards,
> Paul
>
> On Tuesday 28 September 2004 09:46 am, Mark A. Williamson wrote:
> > > I wonder if anyone on the list has written any scripts to automate the
> > > management of VMs with loopback images. Here's what I want to be able
> > > to do:
> >
> > Managing loopback block devices (and other non-physical block devices)
> > will get friendlier than it currently is. They'll get automatically
> > allocated, deallocated etc by Xend.
> >
> > However, the functionality you want is much like we'd envisaged for the
> > "cluster controller" some time in the future. The idea behind it is to
> > simplify the management of multiple Xen machines as a single pool of
> > resources.
> >
> > We have some preliminary design documents on this but no implementation
> > as yet. There are other people working on their own cluster management
> > schemes (hi Brian, hi Steve ;-) but there's not a general-purpose Xen
> > package for doing this.
> >
> > If you're interested, we can post some of our design docs on this
> > subject.
> >
> > Cheers,
> > Mark
xen-ctl-plane.txt
Description: Text document
|
Home