[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: KARTHIK BALAJI G <findkb@xxxxxxxxx>
  • 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
  • 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=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.