WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: "Brian Wolfe" <brianw@xxxxxxxxxxxx>
Subject: [Xen-devel] Re: new IO layer, dev expoting and my plans for using xen. (WAS: Tiny Patch)
From: Ian Pratt <Ian.Pratt@xxxxxxxxxxxx>
Date: Fri, 09 Apr 2004 10:09:04 +0100
Cc: "Ian Pratt" <Ian.Pratt@xxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxxx, Ian.Pratt@xxxxxxxxxxxx
Delivery-date: Fri, 09 Apr 2004 10:11:49 +0100
Envelope-to: steven.hand@xxxxxxxxxxxx
In-reply-to: Your message of "Fri, 09 Apr 2004 03:49:58 CDT." <42990.216.166.50.35.1081500598.squirrel@xxxxxxxxxxxxx>
List-archive: <http://sourceforge.net/mailarchive/forum.php?forum=xen-devel>
List-help: <mailto:xen-devel-request@lists.sourceforge.net?subject=help>
List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
List-post: <mailto:xen-devel@lists.sourceforge.net>
List-subscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=subscribe>
List-unsubscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=unsubscribe>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
> *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?

Yep, that's how it will work. 

In high availability situations you might want to have a seperate
xenolinux instance to drive each device or class of device. The
plan is to be able to 'live restart' such driver domains if they
fault or otherwise fail.
 
> 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.;)
> ). 

Yep, Xen should be great for this kind of application. I should
have checked my live migration stuff in to xeno-unstable in a few
days, which will allow you to load balance by migrating domains
across a cluster without stopping them.

> 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. 

Cool!  I'm really must bite the bullet and make the switch to debian...

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