Balbir Singh wrote:
That's the limit part. I'd like to be able to specify limits and
guarantees on the same host and for the same groups; I don't think that
works when you advance the bandwidth period.
Yes, this feature needs to be configurable. But your use case for both
limits and guarantees is interesting. We spoke to Peter and he was
convinced only of the guarantee use case. Could you please help
elaborate your use case, so that we can incorporate it into RFC v2 we
send out. Peter is opposed to having hard limits and is convinced that
they are not generally useful, so far I seen you and Paul say it is
useful, any arguments you have or any +1 from you will help us. Peter
I am not back stabbing you :)
I am selling virtual private servers. A 10% cpu share costs $x/month,
and I guarantee you'll get that 10%, or your money back. On the other
hand, I want to limit cpu usage to that 10% (maybe a little more) so
people don't buy 10% shares and use 100% on my underutilized servers.
If they want 100%, let them pay for 100%.
I think we need to treat guarantees as first-class goals, not something
derived from limits (in fact I think guarantees are more useful as they
can be used to provide SLAs).
Even limits are useful for SLA's since your b/w available changes
quite drastically as we add or remove groups. There are other use
cases for limits as well
SLAs are specified in terms of guarantees on a service, not on limits on
others. If we could use limits to provide guarantees, that would be
fine, but it doesn't quite work out.
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
