[Xen-devel] new IO layer, dev expoting and my plans for using xen. (WAS: Tiny Patch)

["Brian Wolfe" <brianw@xxxxxxxxxxxx>]

*nod* I'd gathered as much from the list archives.

Adam filled me in with his take of the plans for the new IO stuff. xen
itself won't handle the hardware except for the memory, cpu, and access
permissions. To use a device, you would launch a privileged xenolinux
kernel and share the devices it has found to the other xenolinux
instances. Does this sound about right?

My end goal is to run xen on all 6 DMZ servers as a cluster. Each server
will NFS mount from the backside a dom0 partition specific to that cluster
node, then launch domains based on what it is tasked to do. ex. one would
run a mail server on 256M, and mount NFS partitions for the
maildirs/files. Another would run a 256M apache server, another a mysql
server, etc, etc, etc (sql probably isn't too great without gig-e).

Anyways, as the load reaches the limits of that instance, the controling
server on the backside network would detect this and launch a new
xenolinux instance of that specific service type on another node(chosen
based on CPU, memory, and network load). Upon completing the bootup, it
would alter the NAT rules on the DMZ firewall to now pass incoming
connections for that service to both xenolinux instances.

The idea is to actually implement a system that scales the resources
across a cluster setup on an as needed basis. Sort of how apache launches
threads, and reaps threads based on load. My hope is this will lower the
need for large multicpu servers to simpler (cheaper) dual, or single cpu
servers and add in fault tolerance without a complex HA type setup that is
commonly used now with heartbeat cables and all the interlinking mess (IBM
HACMP background makes me think that there HAS to be a better way).

If I am correct in my thinking that xen would be an ideal platform due to
it's extremely low overhead and remote manageability (coupled with
xenoboot for loading xenolinux images), I'd effectively have "grid
computing"(or whatever each company wants to call this stuff.;) ). Cept it
would be based ona cluster of inexpencive comodity hardware relying on
cheap fast network for IO to a fault tolerant network based cluster
filesystem.

Anyways, even if I'm wrong, this is just WAY too cool geekwise to pass up
messing around with. *grin*

BTW, if anyone here uses Debian, I'm working on updating Adam's xen
packages of xen 1.2 to create nightly builds of xen-unstable. He has been
a GREAT help in my learning to package (or in this case, update) debian
packages. I will have them at the following URL. I just finished creating
debs from 2004/04/08 build (including my tiny patch). The xenolinux
kernels are built for PII , one for privileged with direct access, and
another for unpriviliged NO direct access (and associated modules).

If you use the debs, please send me feedback on the packages. :) Just
remember, i'm new to debian package creation.

http://www.terrabox.com/debian

Debian sources.list lines

deb http://www.terrabox.com/debian/ binary/
deb-src http://www.terrabox.com/debian/ source/

-- 
Brian Wolfe           | Phone 1-(214)-764-1204
President,            | Email  brianw@xxxxxxxxxxxx
TerraBox.com Inc.     |


pub  1024D/73C5A2DF 2003-03-18 Brian Wolfe <brianw@xxxxxxxxxxxx>
     Key fingerprint = 050E 5E3C CF65 4C1E A183  F48F E3E3 5B22 73C5 A2DF
sub  1024g/BB87A3DD 2003-03-18


Ian Pratt said:
>> Tiny patch. :)  Compile fails if you turn off priviliged access in the
>> xenolinux config.
>
> Cheers.
>
> There's an argument for doing away with the option
> altogether. Xen enforces the protection, so it doesn't matter
> whether untrusted domains are compiled with
> CONFIG_XEN_PRIVILEGED_GUEST or not. The amount of code that this
> option compiles out is likely less than 1KB, so it's probably
> not worth having.
>
> However, we should make sure that the domain hides the various
> proc files if it has insufficient privilege from Xen, so as to
> avoid confusing users.
>
> Ian
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxxxx
> https://lists.sourceforge.net/lists/listinfo/xen-devel
>



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel