Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be unavailable on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 1347979 - CPU QoS does not work
Summary: CPU QoS does not work
Keywords:
Status: CLOSED DUPLICATE of bug 1346252
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: Backend.Core
Version: 4.0.0
Hardware: x86_64
OS: Linux
unspecified
urgent
Target Milestone: ---
: ---
Assignee: Nobody
QA Contact: Aharon Canan
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-06-19 13:55 UTC by Artyom
Modified: 2019-04-28 08:36 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-06-20 08:26:01 UTC
oVirt Team: SLA
gklein: ovirt-4.0.0?
gklein: blocker?
rule-engine: planning_ack?
rule-engine: devel_ack?
rule-engine: testing_ack?


Attachments (Terms of Use)
host vdsm and libvirtd log (618.62 KB, application/zip)
2016-06-19 13:55 UTC, Artyom
no flags Details
new vdsm and mom logs (243.77 KB, application/zip)
2016-06-20 08:55 UTC, Artyom
no flags Details

Description Artyom 2016-06-19 13:55:50 UTC
Created attachment 1169530 [details]
host vdsm and libvirtd log

Description of problem:
CPU QoS does not work

Version-Release number of selected component (if applicable):
rhevm-4.0.0.4-0.1.el7ev.noarch
vdsm-4.18.3-0.el7ev.x86_64
libvirt-1.2.17-13.el7_2.5.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Create CPU QoS on datacenter with the limit 10
2. Create   profile with above QoS
3. Create VM with number of CPU equal to number of CPU's on the host_1 and with above CPU profile
4. Start VM on the host_1
5. Load VM CPU to 100%

Actual results:
Host CPU also has load 100%

Expected results:
Host CPU has load 10%

Additional info:
I can see via virsh that we send correct quota
<name>golden_env_mixed_virtio_0</name>
  <uuid>cbe701c0-f395-4b90-a67f-a461057f4638</uuid>
  <metadata xmlns:ovirt="http://ovirt.org/vm/tune/1.0">
    <ovirt:qos xmlns:ovirt="http://ovirt.org/vm/tune/1.0">
        <ovirt:vcpuLimit>10</ovirt:vcpuLimit>
</ovirt:qos>
  </metadata>
but from some reason values under cgroups are not updated:
# cat /sys/fs/cgroup/cpu\,cpuacct/machine.slice/machine-qemu\\x2d128\\x2dgoldenenvmixedvirtio0.scope/vcpu0/cpu.cfs_period_us 
100000
# cat /sys/fs/cgroup/cpu\,cpuacct/machine.slice/machine-qemu\\x2d128\\x2dgoldenenvmixedvirtio0.scope/vcpu0/cpu.cfs_quota_us 
-1

Comment 1 Artyom 2016-06-19 14:18:09 UTC
I can say I have some similar problem connect to CPU shares.
I choose CPU shares equal to 512 and under cgroups I have:
[root@master-vds10 machine-qemu\x2d179\x2dgoldenenvmixedvirtio0.scope]# cat cpu.shares
512
[root@master-vds10 machine-qemu\x2d179\x2dgoldenenvmixedvirtio0.scope]# cd vcpu0/
[root@master-vds10 vcpu0]# cat cpu.shares
1024

Looks like CPU shares value applied only on VM but does not apply on VCPU

Comment 2 Artyom 2016-06-20 07:43:12 UTC
I believe it can be connected to the bug https://bugzilla.redhat.com/show_bug.cgi?id=1346252

Comment 3 Martin Sivák 2016-06-20 08:02:00 UTC
Artyom, can you please attach mom.log (with DEBUG evel enabled)? I believe you will see something like Guest xyz starting and Guest xyz is missing data.

MOM version would be nice too.

Comment 4 Doron Fediuck 2016-06-20 08:26:01 UTC
Bug 1346252 had the same root cause of applying the policy.
Let's focus on a single BZ for the same issue.

*** This bug has been marked as a duplicate of bug 1346252 ***

Comment 5 Artyom 2016-06-20 08:55:04 UTC
Created attachment 1169793 [details]
new vdsm and mom logs

Comment 6 Artyom 2016-06-20 08:56:20 UTC
Mom version: mom-0.5.4-1.el7ev.noarch


Note You need to log in before you can comment on or make changes to this bug.