George Dunlap wrote:
> 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
> cpus?
More or less.
But the processors of our servers are 6-core. A customer might want to pay
for only some cores of power.
>
> 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.
Correct.
>
> 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). :-)
In theory, yes.
But if a customer has a license for the power of 3 cores for BS2000, he
should be able to run for example 4 BS2000 domains which must not consume
more power in sum, but if 3 domains are more or less idle, the remaining
domain could take all 3 cores.
I don't think this is an easy job with caps.
>
> 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.
That is the direction I would go.
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
|
Home