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

Re: [Xen-devel] New Project Proposal - Please provide comments

To: KARTHIK BALAJI G <findkb@xxxxxxxxx>
Subject: Re: [Xen-devel] New Project Proposal - Please provide comments
From: George Dunlap <George.Dunlap@xxxxxxxxxxxxx>
Date: Wed, 18 Feb 2009 11:30:46 +0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 18 Feb 2009 03:31:13 -0800
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=osvhZAsqumlFj1ANNdnYPw9Vy0VZsLkjLkxKgfmvGRI=; b=B5yCIGe8V2/ZqhTfBKY0K6LXzJEhHcUSo/tt9qi1lC5xvfakDlVFGpFMTKOl9iYH10 oAuysgseMHnZKGLU98i+m6B/aDrdFKNDFPo4bIh7Cx17YwXIYvB/oR5EotaI3VDkWfOy m04rxpEEEL2hfNJ5ZBCPZzVahlB8+3pdxA5nI=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=CfwcFphNojxYNeelNYje8MyqRFQdw/gfNMkJiq8xXJKwf3nD1wplYsP2ocqKqZkXTY H1Rjguneh0PSQyD59ZfACIcS3BnWSLk+69QMHPB2twldeyPecdYC7eMKs5MTs28G3GxH hrubc2dytOaD5IvaL8+mgjH0hN7vF44I7SogU=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <e39b62c10902171709w7134895cub7cf863d355e16fc@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <e39b62c10902171709w7134895cub7cf863d355e16fc@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Sounds ambitious. Regarding physical resources, specifically cpu,
don't forget to include a couple of things:
* CPU cache sharing.  Sharing a cpu with a VM that is a cache hog may
increase cache misses, and increase the amount of cpu time required to
do the same work.
* Wake-to-run latency.  TCP in particular is very sensitive to
latency; so even reserving CPU time for a VM may not result in
sufficient performance if it has to wait in long runqueues.

Are you planning on making this an open-source project? Is this a
commercial / academic research venture?

 -George Dunlap

On Wed, Feb 18, 2009 at 1:09 AM, KARTHIK BALAJI G <findkb@xxxxxxxxx> wrote:
> Hello all,
>
> We are working on a new project idea for xen platform. I have summarized as
> well as given detailed description of what we are trying to achieve. I
> request your comments on the feasibility of this project. Also I have
> pointed some relevant works which I feel is primitive considering the goal
> we are trying to achieve. I request to point me to relevant links if there
> are any other works going on in this area. I am not familiar with xen. So it
> would be great if someone can guide me on this project.
>
> SUMMARY:
>
> we have a proposal to develop virtual machine migration algorithms that can
>
> (1) minimize the total number of physical machines used,
> (2) balance the loads across physical machines, and
> (3) meet the same performance requirement of individual applications.
>
> The most challenging issue of this project is to correlate an application's
> performance with the amount of physical resources (CPU, memory capacity and
> disk bandwidth) allocated to it for ARBITRARY applications. If such
> correlation can be derived, we can use it to determine the resource
> requirement for each virtual machine (assuming each virtual machine runs a
> single application), and the issues of (1) and (2) above can be trivially
> solved.
>
> More Details :
>
>
> PROBLEM:
>
>
> Enterprise applications have resource demands varying over time due to
> user demands. The current virtualization technologies are inadequate
> in dynamically achieving such demands (Service level objectives) for
> enterprise applications. Resources are over provisioned based on
> pre-production environment results. Because of this some data centres
> are under utilized and some are over utilized resulting in poor
> performance of the hosted applications. This essentially includes the
> following challenges.
>
>     a. Estimating resource requirements of an application running on
> native hardware needs to be transferred a virtualized environment.
> Additional resource requirements incurred by virtualization overhead
> needs to be taken into account. Our goal should be to minimize the
> number of physical machines used by consolidating the workload.
>
>     b. Once successfully transferred to a shared virtualized
> environment we need a automated resource control system that
> dynamically adapts to varying application needs. By this we mean,
>                    1. Finding the relationship between application
> performance and resource allocated.
>                    2. Migrating virutal machines to balance load
> across physical servers without comprising on availability and
> performance.
>                    3. Enterprise applications have complex mutl-tier
> architecture where distinct components of same application resides in
> different servers. So the resource requirements should not only be
> calculated locally but also across nodes where other components of
> application is hosted.
>
> EXISTING SOLUTIONS:
>
> 1. VMWARE DRS
>
> 2. TRACE BASED APPROACH - The application resource usage traces are
> routinely collected over a period to get a representative application
> profile. These traces can be used to consolidate the workload. But
> these pre-production environment results does not scale well in real
> world situations.
>
> 3. AUTOCONTROL(Hp Labs) - This consists of two parts a. Model
> Estimator that derives the relation between application and its
> resource allocation, b. MIMO (multi input,multi output) resource
> controller that allocates the required resource amounts. The advantage
> of this tool is, it takes care of application load as well as the load
> on each virtualized node. For this tool we need to specify application
> priority, performance metric and performance target. The application
> controller issues requests to node controllers. The node controller
> determines whether it has enough resources to satisfy all demands and
> computes resource reallocation. The computed value is fed into MIMO
> resource scheduler which allocates resources to VM in real time. If
> the performance target of the applications cannot be met Autocontrol
> should provide service level differentiation based on application
> priorities.
>
> Thank you,
>
> -KARTHIK
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
>
>

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>