本文描述了三种虚拟化平台软件Fusion Compute、virt-manager、VMware vSphere的CPU绑定功能的功能介绍、实现原理、实现方法等。

功能介绍

设置虚拟机与主机的物理CPU内核绑定，用以限定虚拟机使用主机CPU资源的范围。默认情况下虚拟机随机在物理机的CPU上运行（实际上是由线程调度器计划分配），而进行绑定后则是在指定的CPU内核上运行。

实现原理

从上层虚拟化软件角度来考虑是利用“virsh vcpupin vm-id n m”将虚拟机的CPU直接与物理机的CPU绑定，vm-id为虚拟机id号，n为虚拟机的vcpu序号，m为物理机的cpu序号。从下层进程角度来考虑，利用“taskset -cp n  pid”将虚拟机的进程与物理机CPU绑定，n为物理主机CPU序号，pid为虚拟机运行时在物理机上开启的进程。

实现方法与验证

1. Fusion Compute

实现方法：

将虚拟机与所在主机绑定。
选择“虚拟机”-“硬件”-“CPU”，内核数为2个，CPU高级设置中，绑定cpu设置为“2-3”，即虚拟机的cpu与物理机的cpu序号2和3绑定。设置后立即生效。

验证：

登录物理主机，virsh vcpuinfo i-00000047，见图1

可以看出虚拟机的序号为0的cpu与物理机序号为3的cpu绑定，虚拟机序号为1的cpu与物理机序号为2的cpu绑定。这仅是通过virsh命令得到了验证。下面通过其他方法进一步验证。

通过：ps -ef |grep i-00000047，得到虚拟机的进程为2933，使用ps -eLo pid,ppid,lwp,psr |grep 2933，见图2最后一列为进程2933对应的物理cpu序号，序号0/1/3与绑定的2/3不符合。而且查询的序号会发生变化。

2. virt-manager 

实现方法：

打开“虚拟机详情”，选择“processor”-“CPU”-“Pining”，将“Default pining”修改为“2-3”。应用后重新启动虚拟机。

验证：

登录物理主机终端，virsh vcpuinfo 2。（2为虚拟机的id号）

可以看出，虚拟机的序号为0的CPU跟物理机序号为2的CPU绑定了，虚拟机序号为1的CPU跟物理机序号为3的主机绑定了。

通过：ps -ef |grep qemu，得到虚拟机的进程为12871，使用ps -eLo pid,ppid,lwp,psr |grep 12871，见图2最后一列为进程2933对应的物理cpu序号，序号2/3与绑定的2/3符合。

3.  VMware vSphere 

实现方法：

打开“虚拟机”-“管理”-“虚拟机硬件”-“CPU”-“调度关联性”，在框里填入“2-3”，点击“确定”即将物理主机序号为2、3的CPU分配给虚拟机使用。

验证：
登录物理主机终端，使用命令esxtop查看CPU使用情况。

红色框里的四个数值为四个物理CPU使用率，可以看出都比较低。
在虚拟机里使用脚本或者stress工具消耗CPU资源，本文使用sh脚本来消耗CPU资源，使用方法为sh killcpu.sh 2，其中数字2为虚拟机CPU个数。
再次切换到物理主机终端，使用命令esxtop查看CPU使用情况。

可以看出序号为2和3的CPU使用率接近100%，序号为0和1的CPU使用率也增加的原因是原来在CPU 2和3进程在线程调度器的作用下跑到CPU 0和1上了，但可以确定的是肯定不存在虚拟机的进程。

总结：

通过验证可以看出Fusion Compute两种验证方法结果不一致，说明此功能有问题，需要进一步调查研究。使用同样方法对virt-manager进行验证，发现完全符合，cpu绑定功能正常使用。在VMWare中由于virsh命令无法使用，ps又无法查看单个cpu的进程使用，只有对虚拟机加负载，使用“esxtop”命令查看了，结果与预期符合。

附录：killcpu.sh

#! /bin/sh
# filename killcpu.sh
if [ $# != 1 ] ; then
echo “USAGE: $0 <CPUs>”
exit 1;
fi
for i in `seq $1`
do
echo -ne ”
i=0;
while true
do
i=i+1;
done” | /bin/sh &
pid_array[$i]=$! ;
done

for i in “${pid_array[@]}”; do
echo ‘kill ‘ $i ‘;’;
done