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

Re: [Xen-devel] XEN Proposal

  • To: "Juergen Gross" <juergen.gross@xxxxxxxxxxxxxxxxxxx>
  • From: "George Dunlap" <dunlapg@xxxxxxxxx>
  • Date: Thu, 11 Dec 2008 15:13:49 +0000
  • Cc: Chris <hap10@xxxxxxxxxxxxxx>, "Tian, Kevin" <kevin.tian@xxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
  • Delivery-date: Thu, 11 Dec 2008 07:14:15 -0800
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=eF/6/yweE0U472Wf804qAJ88ySyZZkLOF99hxmGhy8F167vj7gZQIWZ4sR2dsk0lb9 nwMgKO9o9CcQeqVqgA4ljggHW/tFtdnG3L8qjJq3aSb+TryEorKvFov2ehz5WbB4kV80 28ySfbEBcMQbEy0ELOB0Nof9oq7bH3ZlH0v8k=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

On Thu, Dec 11, 2008 at 6:23 AM, Juergen Gross
<juergen.gross@xxxxxxxxxxxxxxxxxxx> wrote:
>> The software prices for BS2000 will be still related to the machine power.
> But often customers need only a small portion of the complete x86 machine
> power for BS2000, so we added a license scheme to limit the power available
> to BS2000 by pinning the domains with BS2000 to a subset of cpus.

OK, so... you sell software, and the cost of it depends on how
powerful a machine you run it on.  But most people don't need even one
full core's worth of power.  You want to be able to charge people who
need a full core of processing power one price, and charge people who
need only say, 20%, less?  So to artificially limit the power
available to a given instance, you pin all instances to some subset of

I presume then, that there are multiple instances, and people pay for
how many cores they can use total...?  And that your customers
generally have other things running on the server as well.

It seems like what you really want is to cap the number of credits the
VMs can get, and then take them offline when their credits go negative
(instead of competing for resources in a "best-effort" fashion).  :-)

However, it does seem like being able to partition up a Xen server
into "pools" of cpu resources, each with its own scheduler, that don't
compete with each other, might be generally useful.  It should be
relatively straightforward to slide in under the current scheduler
architecture, without having to change much in the schedulers
themselves.  That's how I'd prefer it done, if possible: a clean layer
underneath a scheduler.


> BTW: on /390 and SPARC we already support VM-pools, so adding pools to XEN
> would make this feature available to our customers who are still using it
> today on other platforms.
> Juergen
> --
> Juergen Gross                             Principal Developer
> IP SW OS6                      Telephone: +49 (0) 89 636 47950
> Fujitsu Siemens Computers         e-mail: juergen.gross@xxxxxxxxxxxxxxxxxxx
> Otto-Hahn-Ring 6                Internet: www.fujitsu-siemens.com
> D-81739 Muenchen         Company details: www.fujitsu-siemens.com/imprint.html
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel

Xen-devel mailing list



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