Bug 860234

Summary: engine [Quota]: allow vcpu limit on consumption for single vm
Product: Red Hat Enterprise Virtualization Manager Reporter: Dafna Ron <dron>
Component: RFEsAssignee: Miki Kenneth <mkenneth>
Status: CLOSED NOTABUG QA Contact: Yaniv Kaul <ykaul>
Severity: medium Docs Contact:
Priority: medium    
Version: 3.1.0CC: dfediuck, dyasny, iheim, jkt, lpeer, sgrinber
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard: sla
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-02-13 16:59:59 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: SLA RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Dafna Ron 2012-09-25 11:09:54 UTC
Description of problem:

in current quota, there's no limit to the maximum vCPUs a single VM can try and consume, we can either run 10 VMs with 1vCPU, or 1 VM with 10vCPUs

Version-Release number of selected component (if applicable):

si18.1

How reproducible:

100%

Steps to Reproduce:
1. create a vCPU limit of 4
2. run a single vm with 4 vcpu
3. run 4 vms with 1 cpu each
  
Actual results:

we cannot limit vcpu consumption for a single vm 

Expected results:

it would be nice to be able to limit a single vm consumption


Additional info:

Comment 4 Yaniv Kaul 2012-09-28 08:25:58 UTC
We block it on the host level.  But it still means that two customers without limit per VM will 'compete'. It would be much more manageable to limit than cause issues later.

Comment 5 Doron Fediuck 2013-01-01 12:41:43 UTC
Yaniv, how and where do you see such limitation?

Is it another special quota? addition to current cpu quota?
Cluster policy?

There's a difference between trying to run a single VM with 8 vCPUS
on a host with 4 cores, to running 2 VMs each with 4 vCPUs on the same
host.

In the first case the backend will block you. The latter, is an SLA
issue and can be resolved using cpu shares and VM SLA.

Also, this may also be influenced in the future by NUMA topology,
or even if the admin turns on or off hyperthreading.

Comment 6 Yaniv Kaul 2013-01-01 13:21:48 UTC
(In reply to comment #5)
> Yaniv, how and where do you see such limitation?

I thought backend when tries to execute will fail that (and looking at your response, it does).

> 
> Is it another special quota? addition to current cpu quota?
> Cluster policy?
> 
> There's a difference between trying to run a single VM with 8 vCPUS
> on a host with 4 cores, to running 2 VMs each with 4 vCPUs on the same
> host.

I'm concerned with running 2 VMs with 8vCPUs on a host with 8 pCPUs.

> 
> In the first case the backend will block you. The latter, is an SLA
> issue and can be resolved using cpu shares and VM SLA.
> 
> Also, this may also be influenced in the future by NUMA topology,
> or even if the admin turns on or off hyperthreading.

Comment 7 Doron Fediuck 2013-01-01 14:35:07 UTC
(In reply to comment #6)
> (In reply to comment #5)
> > Yaniv, how and where do you see such limitation?
> 
> I thought backend when tries to execute will fail that (and looking at your
> response, it does).
> 

It's a mis-understanding. I was trying to see at which level would you
like to set such a quota limitation. Indeed today we ignore hosts with less cores than needed vCPUs. 

> > 
> > Is it another special quota? addition to current cpu quota?
> > Cluster policy?
> > 
> > There's a difference between trying to run a single VM with 8 vCPUS
> > on a host with 4 cores, to running 2 VMs each with 4 vCPUs on the same
> > host.
> 
> I'm concerned with running 2 VMs with 8vCPUs on a host with 8 pCPUs.
> 

So this would probably be an SLA issue, just like running 2 VMs with 6vCPUs on a host with 8 pCPUs. This can be settled by VM priority and cpu shares.