KVM他说的基于内核的虚拟机是什么意思

下面的概念定义很多来自我自己的定义，但和现有的概念基本上不会冲突，也应该更容易帮助读者理解虚拟化技术，所以我猜应该没有什么问题。

虚拟化技术，一般理解上，是在一个操作系统之上，模拟另一个操作系统的执行环境。我们看到的各种游戏机模拟器，还有为开发CPU做仿真而做的模拟程序，就是早期比较常见的虚拟化解决方案，它的工作原理很简单：把CPU的所有寄存器都写在一组变量中（这组变量我们称为CPUFile），然后用一片内存当作被模拟CPU的内存（这片内存这里称为vMEM），然后在用一些数据结构表示IO设备的状态（这里称为vIO），三者的数据结构综合在一起，就是代表一个虚拟化的环境了（这里称之为VM），之后按顺序读出一条条的指令，根据这个指令的语义，更改VM的数据结构的状态（如果模拟了硬件，还要模拟硬件的行为，比如发现显存被写了一个值，可以在虚拟屏幕上显示一个点等），这样，实施虚拟的那个程序就相当于给被虚拟的程序模拟了一台计算机，这种技术，我称它为“解释型虚拟化技术”。指令是被一条一条解释执行的。

在这个方案中，我们有三个对象：

Host：执行虚拟程序的系统

Emulator：实施虚拟的，运行在Host上的那个程序

Guest：被虚拟出来的系统，也就是运行了软件（例如操作系统）的VM

这些概念在技术演进的过程中会一定程度变化，读者要注意这一点，记住它的原始含义，否则很容易乱掉。

解释型虚拟化技术很简单，直接，概念也容易理解，但很明显，这个效率是很低的。优化得比较成功的是qemu，它使用一种所谓“编译型”的技术，把每条被虚拟的设备的指令都写成一段C代码，用这段C代码去修改CPUFile等VM数据，然后再用编译器去编译这些C代码，借用了编译器的优化能力，最后在解释Guest的指令的时候，用一个“翻译区“，把这些C代码的编译结果拼起来，然后直接执行。这种方法有效提高了”解释”的效率（所以qemu才称为Quick-emulator），但效率很明显还是非常低的。Android的SDK模拟基于ARM的手机，用的就是这种技术。

随着技术的发展，有人就开始取巧了：很多时候，我们仅仅是在x86上模拟x86，这些指令何必要一条条解释执行？我们可以用CPU直接执行这些指令啊，执行到特权指令的时候，我们直接异常，然后在异常中把当前CPU的状态保存到CPUFile中，然后再解释执行这个特权指令，这样不是省去了很多”解释“的时间了？用这种技术实现的虚拟机，就称为”调度型虚拟化技术“，这种情况下，Emulator的主要工作就不是解释了，它的主要工作是调度，调度Host和所有的Guest来分时（或者分核）使用CPU。

qemu也可以工作在这种模式。要工作在这种模式，它需要在内核中插入一个kqemu.ko，以便处理那些特殊的，由它的模拟程序产生的异常。

这种情况下，我们会发现，Emulator已经不是原来那个意思了，虽然我们仍需要使用这个程序，但仅仅靠这个程序，它作为Host上的一个程序，没有办法调度Host的资源。所以我们引入另一个实体，所谓Hypervisor，Hypervisor负责调度，Emulator只是给它提请求而已。

（这里，Emulator的语义也发生变更了，读者有必要注意这一点）

Hypervisor需要掌控整个系统的资源，这样它就需要有所有设备的驱动，这样会让Hypervisor变得非常复杂的。所以Host的概念仍然存在，一种简化的理解可以是，BIOS启动Hypervisor，Hypervisor首先启动第一个OS，那个就是Host，之后Host上的Emulator启动Guest，Emulator向Hypervisor请求资源，Hypervisor模拟一个环境给新的Guest，但如果Guest向Hypervisor请求IO或者其他特殊能力，这些请求就会被Hypervisor调度到Host上，让Host执行。

在Xen上，这个Host称为DOM0，说明Xen是认为Host和Guest在调度上没有本质区别的，都是一个调度的对象，但DOM0带有所有的驱动，管理程序也可以放在这里直接和Hypervisor通讯。

好了，现在你可以明白为什么KVM称为”内核（K）的VM"技术了，Xen的Hypervisor是一个独立的部件，由BIOS（其实是grub了）直接加载，然后和DOMx的各个操作系统通讯。而KVM的Hypervisor直接就是内核的一部分，这个Hypervisor的代码直接就在Linux的内核中，当Host启动的时候，它们一起加载，一同初始化，只是Hypervisor的代码工作在虚拟机调度器的状态，而其他代码工作在普通内核状态而已。

这个用ARM64平台特别好理解，ARM64平台（不考虑安全态）3个特权级，EL0用户态，EL1内核态，EL2?Hypervisor态。这样，内核启动先进入EL2，初始化Hypervisor部分的状态，然后切换入EL1，初始化内核的状态，然后才fork?init，进入EL0。这之后，你启动qemu-kvm，这个程序就可以通过系统调用（对/dev/kvm文件做ioctl）进入内核，调用KVM的请求，执行调度，从内核中直接做Hypervisor请求，进入Hypervisor要求调度Guest。

这样，很明显，KVM确实是”Linux内核提供的虚拟化技术“，这就是它和其他虚拟化技术不同的地方了。

vmware和virtualbox的技术和Xen类似，无论它们如何加载，是否独立，或者作为一个内核模块加载，毕竟它们不是内核原始设计的一部分。

至于是全虚拟化（Guest不知道你自己是被模拟的系统），还是Para虚拟化（Guest知道自己是模拟的系统，用直接和Hypervisor通讯的方法实现IO），这个问题和是否KVM没有关系（kvm两种模式都可以支持），和性能也没有关系。这仅仅是构架的不同。

讨论区有读者问，为什么没有看到VirtualBox从BIOS加载Hypervisor呢？这个涉及到两个要素：

第一，kqemu.ko也可以不从BIOS加载，这种模式我仍把kqemu称为Hypervisor，但这个Hypervisor并非工作在Hypervisor状态，它是和内核互相妥协从而工作在Hypervisor的角色上的，它的工作级别并不比Host高，但仍可以为Guest模拟出一个运行环境来。VirtualBox使用一样的技术。

第二，VirtualxBox还可以支持VT-x这样的硬件加速的虚拟工作状态。这个事情和VT-x的设计有关，VT-x的特权级继承自传统的x86特权级，就是0-3，0是最高优先级，3是最低优先级。像Linux就只用了0和3级表示内核和用户态。刚开始支持虚拟化的时候，Intel考虑0是Hypervisor级（VMM级），1是内核，3是用户。但这种设计造成不兼容和复杂度。所以到了64位后，新的模式是：系统刚启动的时候，是Host态0级，在这个级别你可以用VMXON进入VMM级，然后你可以在这个级别创建虚拟机，再用VMXON进入虚拟机，VMXOFF退出虚拟机。虚拟机中仍可以有0-3级。这样一来，在Host中，你只要能进入0级，就可以把自己提升到VMM级。VirtualBox只要能在内核中插入一个模块，就可以为自己获得VMM的权限。但这个方法在ARM64上是行不通的。

（读者应该已经注意到了，这里面的定义在整个发展过程中不断发生语义的变化，这造成很多人对技术误解，所以，我们理解计算的概念，更多看我们如何用和如何建模，如果你认为某个概念是持久不变的，基本上你很快就被计算机技术抛弃了。因为基于概念保持部分使用模式不变，然后进行技术演进，是计算机发展的常态）

目前为止，虚拟技术的老大仍然是VMware,虽然被EMC收购，名义上是EMC的老二，但事实上由于技术的牛X，老二不是很摆老大，当然这只是聊天的话,不做为事实依据。

一、KVM简介

KVM是一个全虚拟化的解决方案。可以在x86架构的计算机上实现虚拟化功能。但KVM需要CPU中虚拟化功能的支持，只可在具有虚拟化支持的CPU上运行，即具有VT功能的Intel CPU和具有AMD-V功能的AMD CPU。

Xen与KVM的比较

Xen是Linux下的一个虚拟化解决方案，但由于被Citrix收购后，变成了和红帽企业版一样了，卖服务收取费用，Redhat从rhel6.0开始已经从内核中把XEN踢出去了，全心投入开发免费的KVM，虽然市场上老用户还在用Xen,但相信kvm会逐步占领大面积的市场，必竟有redhat做为强大支持源。

Xen的实现方法是运行支持Xen功能的kernel，这个kernel是工作在Xen的控制之下，叫做Domain0，使用这个kernel启动机器后，你可以在这个机器上使用qemu软件，虚拟出多个系统。Xen的缺点是如果你需要更新Xen的版本，你需要重新编译整个内核，而且，稍有设置不慎，系统就无法启动。

相比较，KVM就简化的多了。它不需要重新编译内核，也不需要对当前kernel做任何修改，它只是几个可以动态加载的.ko模块。它结构更加精简、代码量更小。所以，出错的可能性更小。并且在某些方面，性能比Xen更胜一筹。

二、KVM的使用

现在以Turbolinux 11版本为基础，介绍KVM的使用方法。

在安装之前，你需要先确认，你的CPU是否支持虚拟化技术，执行：

# egrep '^flags.*(vmx|svm)' /proc/cpuinfo

如果有输出返回，则表示你的CPU支持虚拟化技术。

1.KVM的安装

从官方网站下载KVM源码包：http://kvm.qumranet.com

我们使用KVM-33版本

# tar zxf kvm-33.tar.gz

# cd kvm-33

# ./configure --prefix=/usr/local/kvm-33

# make

# make install

make install后，kvm的模块会安装到/lib/modules/$KernelVersion/extra/目录下。其他相关文件会安装到/usr/local/kvm-33/目录下。

将kvm相关目录连接到系统目录中

# ln -s /usr/local/kvm-33/bin/* /usr/bin/

# ln -s /usr/local/kvm-33/lib/* /usr/lib/

(若为x86_64系统,则执行: ln -s /usr/local/kvm-33/lib64/* /usr/lib64/)

# ln -s /usr/local/kvm-33/include/kvmctl.h /usr/include/

# ln -s /usr/local/kvm-33/include/linux/* /usr/include/linux/

# ln -s /usr/local/kvm-33/share/qemu /usr/share/

2.KVM的使用

a.你需要先建立一个映像文件作为虚拟系统的硬盘

# mkdir /images

# cd /images

# /usr/bin/qemu-img -f qcow gtes11.img 20G

b.创建网络配置脚本

# echo ’/sbin/ifconfig $1 10.0.1.1 netmask 255.255.255.0’ > /etc/qemu-ifup

c.加载KVM模块

Intel CPU使用:

# modprobe kvm-intel

AMD CPU使用:

# modprobe kvm-amd

d.安装虚拟系统

# /usr/bin/qemu-i386 -m 512 -k en-us -M pc -hda /images/gtes11.img -cdrom /iso/zuma-SP3-rc3-6-\

disc1-20061031.iso -net nic,vlan=1,model=rtl8139,macaddr=00:00:00:00:99:01 -net tap,vlan=1,ifname=tap0,\

script=/etc/qemu-ifup -vnc localhost:1 -boot d

在另一个终端执行：

# vncviewer localhost:1

参数分析：

我们为虚拟系统分配512MB内存。使用gtes11.img作为它的第一块硬盘，使用Turbolinux10.5的disc1作为它的光盘。

并从光盘引导。它有一块rtl8139的网卡，MAC地址为:00:00:00:00:99:01，并把这个网卡与主机的tap0接口连接。

tap0接口使用/etc/qemu-ifup脚本进行初始化。虚拟系统的输出作为一个vnc服务器，绑定在主机的localhost:1上。

注：

1.若为x86_64系统，则使用/usr/bin/qemu-system-x86_64代替qemu-i386

2.在64位系统上，可以安装32位和64位的虚拟系统。但在32位系统上，只能安装32位的虚拟系统。

qemu参数介绍：

-da 映像文件：使用映像文件作为虚拟系统的第一块硬盘。同样还可以使用hdb、hdc、hdd指定第2、3、4块硬盘。

-drom 光盘映像文件：使用光盘映像文件作为虚拟系统的光盘。

-oot [a|c|d|n]：设置虚拟系统的引导顺序。a为软驱、c为硬盘、d为光驱、n为网络。

- 内存大小：设置虚拟系统使用的内存大小，单位为MB。

- 语言：设置虚拟系统键盘类型。

-et nic[,vlan=n][,macaddr=addr][,model=type]

建立一个虚拟网卡，并把它连接到VLAN的n端口上。

-net tap[,vlan=n][,fd=h][,ifname=name][,script=file]

把主机的TAP网络接口连接到VLAN的n端口上，并使用script指定的脚本进行初始化。

鹏仔微信 15129739599 鹏仔QQ344225443 鹏仔前端 pjxi.com 共享博客 sharedbk.com