持续创作，加速成长！这是我参与「掘金日新计划 · 10 月更文挑战」的第4天，点击查看活动详情

底层虚拟化架构

主流的开源虚拟化：

• Xen
• KVM

FusionCompute6.3之前使用的XEN，6.3以后（包括6.3）使用的KVM

FusionCompute 6.1版本是个分水岭，

FusionCompute 6.1之前用的是SUSE（苏谁） Enterprise Linux 11 64bit

FusionCompute 6.1之后（包括6.1）用的是华为自主研发的操作系统：EulerOS （欧拉OS）

在2019年，EulerOS开源了，称为OpenEuler

1、那到底XEN和KVM的区别在哪呢？

XEN被Citrix（思杰）收购，KVM被红帽收购

Citrix（思杰）全球第二大虚拟化厂商，仅次于VMware，它的桌面云是龙头老大。

区别：（1）如果想要使用XEN，就必须有一套独立运行XEN的内核，也就是说系统自带的Kernel不行，一个系统需要有Kernel-xen的内核才行。也就是说xen不是基于内核的虚拟化。

一个系统需要有两个内核：

就是这样的，只有选择第一个特定的xen内核，我们才可以使用虚拟化。那我们知道维护一个内核也是相当麻烦的，因此xen的缺点显而易见。

（2）而我们知道KVM是基于内核的，什么意思呢？就是我们不需要有特定的KVM-Kernel据可以使用KVM虚拟化。一个Kernel里面只要有KVM模块就能创建虚拟机了，并且虚拟机是以单独的进程来体现的，一个VM就是一个进程。非常轻量。

但这并不是KVM彻底打败XEN的原因，而是：虚拟化出来不久，迎接而来的就是云计算，当时Citrix用XEN支持了CloudStack，而红帽一看，它使用KVM支持了OpenStack，因此OpenStack的默认底层虚拟化技术就是KVM，后来OpenStack打败了CloudStack，最终KVM完胜XEN。

2、XEN和KVM区别2： XEN中有个特殊的虚拟机：domian0（特权虚拟机），这个虚拟机打不开。

他有一个非常重要的作用：起到消息队列的作用：

我们先来看看XEN的架构：

我们来分析图，当外部的客户访问XEN里面的VM1虚拟机时，流量通过宿主机的网卡进来，这个流量进来之后不会直接发送给VM1，而是先发送给domian0虚拟机，它相当于一个queue，然后在由它将流量发送给VM1，回来也一样。

domian0可以理解为宿主机的一部分，只有宿主机宕机了，domian才会宕机

所以可以总结为：xen中所有的数据包都需要先经过domian0，然后再下发至后面的VM。

所以在使用XEN虚拟化技术时，需要先给domian0预留资源（mem，cpu），这个操作需要修改内核文件参数。

如果没有预留资源，那么宿主机的全部资源都会给domian0，然后创建VM后，VM所需要的资源从domian0那里分配。

可见XEN这个地方有弊端，一方面domian0占用资源，而且当访问量大时，queue反应不及时，影响效率。

而反观KVM，KVM是在内核中的，是直接调度Kernel实现流量的转发，因此KVM更加轻量。

半虚拟化、全虚拟化、硬件辅助虚拟化

关于以上概念的解释有个文章非常好： blog.csdn.net/gui951753/a…

1、有个命令：lscpu

Virtualization: VT-x                     #有这个指令集，说明此虚拟机支持硬件辅助虚拟化
Virtualization type: full                #支持全虚拟化

如果CPU没有VT-x指令集就只能半虚拟化。

那半虚拟化有什么问题吗？

半虚拟化只能安装Linux，不能安装Windows。

为啥？

因为用半虚拟化需要修改内核，让内核支持半虚拟化，而微软是不开源的，没有内核的源码，因此修改不了内核，所以不行。

因此基于以上现象，我们需要知道半虚拟化，全虚拟化，硬件辅助虚拟化的概念。

2、半虚拟化

通过修改内核的代码，使VM知道自己本身时VM，然后VM Kernel发出的指令，直接就运行宿主机上的CPU上了（直接由宿主机的COU来处理指令了）。

3、完全虚拟化

上面那篇文章讲的很详细，其中完全虚拟化又叫做软件虚拟化，因为完全都是VMware、VirtalBox等软件在中间帮着VM的Kernel来向物理Kernel申请资源。

完全虚拟化的缺点就是：开销大，速度慢

所以现在完全虚拟化很少再用了，都在使用硬件辅助虚拟化。

4、硬件辅助虚拟化

在宿主机中的CPU上添加指令集，这个指令集就是：Intel的VT-X和AMD的AMD-V。

这样一来VM的Kernel在申请资源时：

VM的Kernel：我需要一些CPU资源跑个指令

这时就不经过VMware软件了

直接就是： 宿主机的CPU VT-X：他需要申请资源，我有这个指令集，那我给他处理，哥们，处理好了，结果给你

VM的Kernel：好嘞，哥。

也就是说在宿主机的硬件---CPU上添个指令集Intel-VT-X，然后再此宿主机上创建的机器就是虚拟机了，虚拟机也意识到自己就是虚拟机，因此虚拟机的Kernel在申请CPU,MEM资源时，就不经过虚拟化软件了（比如：VMware，KVM）而是直接向宿主机的CPU提交申请，直接让宿主机的CPU来完成我的事情。

因此这也就是为什么不能使用华为云里面的云服务器，来创建KVM，安装CNA，搭建OpenStack了，因为华为云里面的云服务器本身就是VM，华为云里面的服务器没有开启VT-X,AMD-V或者不支持VT-X，AMD-V。

现在已经没有全虚拟化了，现在能选的全虚拟化就是硬件虚拟化。支持硬件虚拟化肯定支持全虚拟化。

而之所以还有半虚拟化，就是当时CPU不支持VT-X，AMD-V的解决方案。

5、如何判断服务器是否支持硬件辅助虚拟化（VT-X）：

lscpu                     #这个方法可以
Virtualization: VT-x   
​
#下面的方法更加准确
[root@node1 ~]# cat /proc/cpuinfo |grep vmx       结果出来"vmx"接口，这是Intel
[root@node1 ~]# cat /proc/cpuinfo |grep svm       这是AMD-V

重点说半虚拟化

在全虚拟化中安装半虚拟化驱动：

另外就是访问网络或者硬盘的时候，为了取得更高的性能，也需要让虚拟机内核加载特殊的驱动，也是让虚拟机内核从代码层面就重新定位自己的身份，不能像访问物理机一样访问网络或者硬盘，而是用一种特殊的方式：我知道我不是物理机内核，我知道我是虚拟机，我没那么高的权限，我很可能和很多虚拟机共享物理资源，所以我要学会排队，我写硬盘其实写的是一个物理机上的文件，那我的写文件的缓存方式是不是可以变一下，我发送网络包，根本就不是发给真正的网络设备，而是给虚拟的设备，我可不可以直接在内存里面拷贝给他，等等等等。

它上面说的结论要清楚理解。我们先来看一个场景：

现在VM1想访问VM2，访问的路径：VM1发送数据包给OVS（OVS在宿主机上的mem中运行），OVS给物理交换机，物理交换机发给OVS，OVS给VM2。但是这个过程是不是看着别扭？

也许你有疑问，问什么VM1不能通过OVS直接和VM2通信，还需要在经过一层物理交换机？

因为VM1，VM2认为自己是物理服务器，他们不知道自己是虚拟机，但是如果这时我们使用了PV Driver（半虚拟化驱动），也就是VirtIO就是半虚拟化驱动，可以有网络VirtIO驱动，也可以有磁盘VirtIO驱动，那么这时虚拟机就认为自己就是虚拟机了，因为半虚拟化就是修改内核代码，使其重新定位自己的身份，这样既然VM1，VM2是虚拟机了，那它们也就理所当然的直接通过OVS进行通信了，不用再经过物理交换机了，可以大大提高性能。

Win使用VirtIO的说明

因为Windows默认OS光盘中没有PV Driver（半虚拟化驱动）因此如果Windows的系统盘选择VirtIO Disk，会无法识别，因为没有PV Driver驱动，但是建议DATA盘使用VirtIO Disk，因为我们可以在系统安装之后，先安装PV Driver，这样一来Windows有个识别VirtIO Disk的PV Driver驱动了，自然而然的就能安装了。

但是我真想将系统盘安装为 VirtIO Disk，也有办法，可以下载VirtIO软件，将此软件以虚拟光盘的形式外挂在光驱里面，在装系统时可以识别这个光驱，从而达到安装PV Dirver的目的，然后再装系统盘（VirtIO Disk类型的）。