Hello to all,
In light of many people screaming for ways to easily install and
configure guests I'm going to go ahead and GNU some of the scripts I've
written to accomplish it. I've been barking about how easy it is and
have no problem putting my money where my mouth is.
The problem is, as-is they make sense only to me. Right now they read
data from a csv file, handle making the LV backed devices , formatting
them, copying over OS template and kernel modules, setting up everything
on the guest including root password so its ready to go at boot, and
create the xen configuration files. After that they do a dozen other
tasks that are unique really only to my setup.
This is a problem because its written for the most common use on my
scenarios, where each guest gets only 1 root fs, a swap fs and only one
vif. I just setup others manually as needed.
If it will be worth packaging and prettying up, one should be able to
easily make lots of vbd's and utilize all 3 vifs if they wanted.
so I thought I'd do it comma, and pipe and colon delimited. Something
like this:
domname=abc.com,kernel=/boot/vmlinuz,ram=1024,vif=mac:auto|bridge:br0|
ip:1.2.3.4|netmask:255.255.255.0|
gateway:1.2.3.1,hostname=s1.abc.com,vbd=lvm|vg:/dev/vg|size:10G|
type:jfs|inguest:sda1,rootfs=sda1, etc, etc, etc
I can then easily go through a recursive nested switch and have a pretty
easy time of commenting the flow of it.
This way the order of the csv data is not important, sanity checking
becomes easier and recursion in bash is very very easy to grasp. To add
more vifs or vbds you'd just , well add another stanza to the csv.
This also makes it even easier if using a more advanced language,
especially one that supported nested arrays.
This will be done in bash because I want it to be useful to as many
people as possible. Admins are inclined to know at least the basics of
editing a bash script but may not be well versed with perl, python or
even php. Since most customizing will usually lead to editing something
at this point, this is important.
I will make every effort to make this 'dash' friendly, but that's going
to need more forks to use externals to parse strings. Worth it? Or maybe
think about teaching dash more regex? That takes a bit of time.
The result is a handy building block that uses a format that lends well
to easily concantenating together a bunch of variables in php to store
this centrally, so its easy to write your own little console to go with
it. I'll include a very basic one written in php5, with srce as promised
to do remote calls. Its as easy as using the wrappers I left similar
to , srce_query("server1","setupguest abc.com"); since the csv data is
stored centrally (mysql or sqlite, haven't decided yet).
I've also xml-ified the output of xentop in a single iteration which is
easy to gather and parse via SRCE with whatever php => xml parser you
like.
Since the xml feed also realys bandwidth accounting per vif, some
'hooks' will be left for storing it and graphing via rrdtool. This is
why I'm thinking sqlite (for some tables) since bash so easily interacts
with it.
I would rather get input now, and do it once rather than later and do it
twice. The better I get to 'good' the first time, the less effort needed
by the xen and programming newbie. I have seen so many people shoot
themselves in the foot by simply not coming up with a well planned
naming convention. This will use one that fits pretty much any scenario.
Please reply to list with any feedback. This is not a control panel for
xen, its the bones of one so you can build your own.
While I fully intend to take advantage of the xen API via xmlrpc
(later), not everyone wanting to build something is comfortable with
that. They would need to learn a bit before they can dive in.
My goal is something simple, reliable, predictable and easy to hack. It
will be as elegant as possible given those goals. Elegance is nice,
helping people setup sane networks correctly is nicer.
This will be developed in place on a 40 server farm, each supporting a
minimum of 2 guests, some supporting as many as 40. I should be able to
squash every bug before it gets off the 'bench'.
Remember, next month is "php bugs" month :( (sigh) , I may be pretty
busy, this could take a few weeks to get out the door.
Best,
--Tim
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home