From owner-freebsd-arch@FreeBSD.ORG  Wed Oct 17 21:39:20 2007
Return-Path: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 8352C16A418
	for <freebsd-arch@freebsd.org>; Wed, 17 Oct 2007 21:39:20 +0000 (UTC)
	(envelope-from freebsd-arch@m.gmane.org)
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2])
	by mx1.freebsd.org (Postfix) with ESMTP id 1A63D13C468
	for <freebsd-arch@freebsd.org>; Wed, 17 Oct 2007 21:39:19 +0000 (UTC)
	(envelope-from freebsd-arch@m.gmane.org)
Received: from list by ciao.gmane.org with local (Exim 4.43)
	id 1IiGbX-0006S4-Tw
	for freebsd-arch@freebsd.org; Wed, 17 Oct 2007 21:39:03 +0000
Received: from r5j156.net.upc.cz ([86.49.9.156])
	by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
	id 1AlnuQ-0007hv-00
	for <freebsd-arch@freebsd.org>; Wed, 17 Oct 2007 21:39:03 +0000
Received: from gamato by r5j156.net.upc.cz with local (Gmexim 0.1 (Debian))
	id 1AlnuQ-0007hv-00
	for <freebsd-arch@freebsd.org>; Wed, 17 Oct 2007 21:39:03 +0000
X-Injected-Via-Gmane: http://gmane.org/
To: freebsd-arch@freebsd.org
From: martinko <gamato@users.sf.net>
Date: Wed, 17 Oct 2007 23:38:56 +0200
Lines: 41
Message-ID: <ff5vdh$jol$1@ger.gmane.org>
References: <470E5BFB.4050903@elischer.org>
	<470FD0DC.5080503@gritton.org>	<20071013004539.R1002@10.0.0.1>
	<47107996.5090607@elischer.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet@ger.gmane.org
X-Gmane-NNTP-Posting-Host: r5j156.net.upc.cz
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US;
	rv:1.8.1.6) Gecko/20070821 SeaMonkey/1.1.4
In-Reply-To: <47107996.5090607@elischer.org>
Sender: news <news@ger.gmane.org>
Subject: Re: kernel level virtualisation requirements.
X-BeenThere: freebsd-arch@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Discussion related to FreeBSD architecture <freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Oct 2007 21:39:20 -0000

Julian Elischer wrote:
> Jeff Roberson wrote:
>> On Fri, 12 Oct 2007, James Gritton wrote:
>>
>>> Julian Elischer wrote:
>>>
>>>> What I'd like to see is a bit of a 'a-la-carte' virtualisation
>>>> ability.
>>> ...
>>>> My question to you, the reader, is:
>>>> what aspects of virtualisation (the appearance of multiple instances
>>>> of some resource) would you like to see in the system?
>>>
>>> Of course everything jail has now, and all the network bits that 
>>> vimage offers.
>>>
>>> CPU scheduling, in particular schedule the CPU first by jail, and then
>>> by processes within jail.
>>
>> So the question I have is; why do all of these things instead of 
>> vmware/xen/other full virtualization?  We can implement these 
>> technologies.  Specifically, I could do the CPU scheduling.  However, 
>> why not just fix Xen?  There may be a very good answer to this, I just 
>> don't know it.
> 
> Generally, you can run several hundred (or more) virtual jail/vimage 
> style machines. xen/vmware uses so much more resources that you are 
> usually limited to
> so number like 20. it is possible in a virtual networking setup to have 
> a single process
> spanning several virtual environments (for example one process with a 
> socket in each of the child universes).
> It is a valid question, but there is I think a place for both types of
> partitioning.
> 

On the other hand fixing Xen or implementing something like LKVM seems 
to be much easier than changing all those subsystems people would like 
to resource partition.  Well, it's just my guess.

Martin