One possible use case - Tiering services based on # of cores. Let's say I have one RP/Cluster made of servers with mulitple cores (expensive than the server with less # of core) and I do not want a user utlizing more than certain # of cores in their VMs. If they want to then they have to pay more.
That is contrary to the model. You want to stay away from tying up resources dependent on anything physical.
You should, instead, create a provider with an allocation pool model. This way you can set a reservation for the pool up to what the customer says they need and charge them accordingly for usage of that pool. Anything above/beyond the reservation you can charge a premium.
I agree and understand in terms of allocation pool /reservation in the number of Ghz. However, do I charge a customer who has a 4Ghz VM (utilizing say 8 cores- I need to have an expensive server for that) and another customer 4Ghz VM (utlizing say only one core ) the same?
Depends. The scenario is not clear.
A VM that is using (consistently?) 4GHz is only using 4 GHz whether or not 1 core or 8 cores is supplying the cycles. What weighs more? A pound of feathers or a pound of lead?
The confusion for me is I don't measure VM configurations in GHz. I measure them on how many vCPUs with which they are configured. Those vCPUs will demand cycles from the physical CPUs but I can limit how many cycles they are allowed -- I just don't care which pCPUs provide the cycles.