更有甚的直接机翻的东西都丢上来....我操什么玩意
首先，cgroup就是限制资源的，你可以认为和kvm没关系
cgroup是直接操作进程限制资源的
下面这个文章就是会让你产生一个误导，比如你看了以后会认为在设置/etc/cgconfig.conf就能控制虚拟机资源占用，但这是是错误的，但是这文章对了解cgroup配置有点帮助，还是值得看一下的
http://blog.csdn.net/t0nsha/article/details/8511433
上面文章的错误就在于，这个配置文件其实是没办法控制到虚拟机的。
你可以简单测试下，比如你的虚拟机叫panabit，你cgconfig.conf里有如下内容
点击(此处)折叠或打开
-
group libvirt {
-
cpuset {
-
cpuset.mems="0-1";
-
cpuset.cpus="0-15";
-
}
-
}
-
group libvirt/qemu {
-
cpuset {
-
cpuset.mems="0-1";
-
cpuset.cpus="0-15";
-
}
-
}
-
group libvirt/qemu/panabit {
-
cpuset {
-
cpuset.mems="0-1";
-
cpuset.cpus="0-15";
-
}
-
}
-
group libvirt/qemu/panabit/vcpu0 {
-
cpuset {
-
cpuset.mems="0-1";
-
cpuset.cpus="0";
-
}
- }
点击(此处)折叠或打开
-
<cputune>
-
<vcpupin vcpu="0" cpuset="1"/>
- <cputune>
cpu绑定在xml定义的1号cpu而不是cgroup定义的0号上
这并不是说cgroup不起作用，而是因为你的虚拟机配置文件里指定了1号，所以虚拟机程序会修改cgroup配置
相当于虚拟机启动以后执行了
cgset -r cpuset.cpus=1 libvirt/qemu/panabit/vcpu0
这样就直接覆盖了你cgroup的配置，所以，cgroup不是不能控制kvm占用，而是kvm会根据自己的配置文件来修改cgroup配置
所以没事不要去用cgruop的配置文件来控制虚拟机占用，而是用kvm自己的配置文件来控制
顺便解释下几个cpu资源限制的参数含义
这两个参数在cgroup的group是libvirt/qemu/panabit
下面两个参数也是一样，不过是针对虚拟机在真机里的进程的（emulator是模拟器的意思）
这两个参数在cgroup的group是libvirt/qemu/emulator
cfs_period_us/cfs_quota_us都是什么参数来的？简单来说就是几个进程调度参数，可以参考
http://124.16.139.131:24080/lxr/source/Documentation/scheduler/sched-bwc.txt?v=linux-3.5.4
cpu.cfs_quota_us: the total available run-time within a period (in microseconds)
cpu.cfs_period_us: the length of a period (in microseconds)
cpu.stat: exports throttling statistics [explained further below]
The default values are:
cpu.cfs_period_us=100ms（虚拟机xml里的单位是微妙，所以xml默认参数是1000000）
cpu.cfs_quota=-1
A value of -1 for cpu.cfs_quota_us indicates that the group does not have any bandwidth restriction in place, such a group is described as an unconstrained bandwidth group. This represents the traditional work-conserving behavior for CFS.
所以，最简单降低panabit这个虚拟机cpu占用的方法就是
在xml定义
如果你的虚拟机已经启动，直接执行指令修改cfs_quota_us
cgset -r cpu.cfs_quota_us=25000 libvirt/qemu/panabit/vcpu0
详细的调优化还可以修改rt_runtime_us/rt_period_us（默认real time是0，参数里的cfs其实是cfs调度，real time在fifo，和rr）
这些涉及到linux real time相关知识，其实也就是linux调度的相关知识（man chrt，man ionice，man nice有相关内容）
点击(此处)折叠或打开
- linux内核中提供了两种实时调度策略：SCHED_FIFO和SCHED_RR，其中RR是带有时间片的FIFO。这两种调度算法实现的都是静态优先级。内核不为实时进程计算动态优先级。这能保证给定优先级别的实时进程总能抢占优先级比他低得进程。linux的实时调度算法提供了一种软实时工作方式。实时优先级范围从0到MAX_RT_PRIO减一。默认情况下，MAX_RT_PRIO为100，所以默认的实时优先级范围是从0到99.SCHED_NORMAL级进程的nice值共享了这个取值空间；他的取值范围是从MAX_RT_PRIO到MAX_RT_PRIO+40.也就是说，在默认情况下，nice值从-20到19直接对应的是从100到139的实时优先级范围。
点击(此处)折叠或打开
- scheduling class of the process. (alias policy, cls). Field’s possible values are:
- - not reported
- TS SCHED_OTHER
- FF SCHED_FIFO
- RR SCHED_RR
- B SCHED_BATCH
- ISO SCHED_ISO
- IDL SCHED_IDLE
- ? unknown value
ps -eo pid,class,pri,nice,time,args | grep qe
可以看到
477 TS 19 0 00:17:52 /usr/libexec/qemu-kvm -name panabit
如果我们用chrt改变了进程，我们就会进入fifo或rr调度，这时候cfs相关的参数就不再起作用
原因可以参考下面论坛讨论
内核对于实时进程(就是Real time/top里标识RT的进程)有两种：
1）FIFO，对于这种实时进程，nice'值基本可认为无效，因为，在该种进程执行完代码前其余的进程是不会被调度的
2）RR，对于该组的进程，其内部之间会发生路转调度，而在该组进程全部执行完之前，其余的进程是不会调度的。
在 SCHED_FIFO/SCHED_RR的所有实时进程完成任务之前（CPU不会给CFS调度的进程，只有这两类实时进程执行完毕才会让出CPU），所设置的nice值并不会起作用，也就是说不会发生CFS调度。
一篇带代码的相关文章
http://www.cnblogs.com/openix/p/3254394.html