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交互。
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交互。