最近工作要搞下 kvm ，但是对于 QEMU 和 KVM 的关系有点搞不清；但是看了下面这篇文章后就明白了。转载自：http://blog.chinaunix.net/uid-23769728-id-3256677.html 版权归原作者所有。
QEMU是个完全独立的虚拟环境，因为KVM的出现，使得某些同学（包括我自己）对QEMU和KVM之间的关系不是很清楚。QEMU本身可以不依赖于KVM，但是如果有 KVM的存在并且硬件(处理器)支持比如Intel VT功能，那么QEMU在对处理器虚拟化这一块可以利用KVM提供的功能来提升性能。这篇博文侧重点在QEMU这块，前期主要是考察一下其使用，以及和KVM之关系，后续的博文会涉及到两者间的一些实现机制。
QEMU目前最新的版本是1.1.0 ( http://www.qemu.org), download到本地后，比如放到/home/dennis/workspace/Linux下是qemu-1.1.0-1.tar.bz2, 解压之后得到一个qemu-1.1.0的目录，为了实验的目的，我不想让它替换掉我系统中已经安装的qemu工具集合（bin tools set)，所以我在/home/dennis /workspace/Linux下面重新建立了一个目录，比如qemu-bin-dbg. 先进入到/home/dennis/workspace/Linux/qemu-1.10目录下，然后依次执行：
1)./configure --prefix=/home/dennis/workspace/Linux/qemu-bin-dbg --enable-debug
这一步需要说明的是，我实验用的环境是ubuntu 12.04, 内核版本是我自己更新的3.4.3, intel i3处理器，在我实际操作过程中出现了以下的错误：
Error: zlib check failed
Make sure to have the zlib libs and headers installed.
----------------------------------------------------------
google了一下，这个错误很容易解决：
apt-get install zlib1g-dev
apt-get install libglib2.0-dev
2) make
3) make install
然后我们到/home/dennis/workspace/Linux/qemu-bin-dbg目录下，会发现QEMU的工具集都放在了其中的bin目 录下，其中会有qemu-i386和qemu-system-i386，前者只是对处理器的模拟(指令)，后者则模拟一个基于i386的PC. 如果没有KVM的支持，比如rmmod kvm_intel，然后再运行qemu-system-i386，那么就会出现这样的提示信息：
Could not access KVM kernel module: No such file or directory
failed to initialize KVM: No such file or directory
Back to tcg accelerator.
因为前面我大体浏览过KVM的某些代码，KVM内核模块会生成一个"/dev /kvm"设备文件供用户空间程序使用，上面的提示信息就是因为QEMU在初始化阶段因为无法找到该"/dev/kvm"文件，因此认为当前系统没有提供 对KVM的支持，因而QEMU回退到所谓的tcg accelerator模式，这从另一个角度说明，独立的QEMU虚拟化方案并不一定需要KVM提供支持。
我的理解是KVM模块的存在可 以视为QEMU对i386处理器模拟的一种accelerator，如同GPU对3D的hardware acceleration一样(在没有GPU存在的情况下，软件也可以实现某些3D的功能，不过性能显然要慢多了，比如mesa).所以即便在 kvm_intel.ko不存在的情况下，QEMU也可以完成对一个pc的虚拟化。
KVM是Kernel-based Virtual Machine,从存在形式看，是两个内核模块kvm.ko和kvm_intel.ko(对AMD处理器来说，就是kvm_amd.ko)，这两个模块用 来实现CPU的虚拟化，如果要让用户在KVM上完成一个虚拟机相关的操作，显然需要用户空间的东西，同时还包括IO虚拟化，所以KVM的解决方案借鉴了 QEMU的东西并做了一定的修改，形成了自己的KVM虚拟机工具集和IO虚拟化的支持，也就是所谓的qumu-kvm.
所以总结下来 是：QEMU是个独立的虚拟化解决方案，从这个角度它并不依赖KVM。 而KVM是另一套虚拟化解决方案，不过因为这个方案实际上只实现了内核中对处理器(Intel VT, AMD SVM)虚拟化特性的支持，换言之，它缺乏设备虚拟化以及相应的用户空间管理虚拟机的工具，所以它借用了QEMU的代码并加以精简，连同KVM一起构成了 另一个独立的虚拟化解决方案，不妨称之为：KVM+QEMU. 在我看来，KVM在用户空间的工具实际上是QEMU虚拟机管理工具的一个子集(KVM使用的QEMU代码可以在http://www.linux-kvm.org/page/Code上 下载）：KVM用户空间虚拟机管理工具有kvm， kvm-img， kvm-nbd ，kvm-ok 和kvm_stat，实际上kvm就是一个指向qemu-system-x86_64的符号链接，kvm-img则是指向qemu-img的符号链接，至 少我的系统中就是如此。从适用的范围来讲， QEMU虚拟化方案除了支持x86架构外，还支持其他很多架构，这从上文中/home/dennis/workspace/Linux/qemu- bin-dbg/bin目录下的文件名就可以看出来，比如qemu-system-m68k，qemu-system-mips64， qemu-system-ppc64， qemu-system-arm等等。但是目前提到KVM，一般指x86上基于Intel VT和AMD SVM的解决方案，虽然目前将KVM移植到ARM, PPC的工作正在进行中。
当然由于redhat已经开始支持KVM，它认为KVM+QEMU'的方案中用户空间虚拟机管理工具不太好使，或者通用性不强（可以参考2011年10月份在南京大学举办的中国内核开发者大会上，来自redhat从事libvirt工作的资深专家 Daniel Veillard当天演讲的ppt文档：http://v.csdn.hudong.com/linuxkernal2011/page2.html），所以redhat想下一盘很大很大的棋，于是它搞了一个libvirt出来，一个用来管理虚拟机的API库，不只针对KVM,也可以管理Xen等方案下的虚拟机。关于libvirt，这是后话了，我会在后续的博文中予以讨论。
综上：QEMU虚拟化(模拟器)解决方案并不依赖KVM，而KVM虚拟化方案则一定要依赖QEMU(至少目前是），即便redhat开发了libvirt，但后者可以简单认为是一个虚拟机管理工具，libvirt依然需要用户空间的QEMU来和KVM交互。
