面试指南—虚拟化部分_两个vm不通 vf

1.两个VM不能通信的原因

两台VM不能通信的故障如图：

故障排错：
1.如果是VM1无法访问VM2，首先从VM侧分析：是否VM是否安装Tools，以及Tools是否正常运行。VM是否开启了防火墙，防火墙会屏蔽ICMP协议的ping。VM是否安装了其他的第三方安全软件，有可能是安全软件的拦截。VM侧IP地址和掩码是否配置错误等。如果VM和VM2虚拟机侧都正常，因为两个VM在同一个CNA，所以要看两个VM是否关联了同一个DVS，是否在同一个DVS下的相同的端口组，如果不是相同的端口组，Vlan一致也能通信。这是VM1与VM2之间不通信的问题。
2.VM1与VM3能相互访问，首先还是VM侧，如果VM侧正常，也加入了相同的DVS和端口组，那么有可能是TOR交换机的配置有问题，有可能TOR没有放行相对应的Vlan，端口配置有问题。
3.VM1与VM4不通信的原因，因为他们在不同的物理网络下，所以不能通信，要想通信，则两端的TOR交换机需要打通，并且配置相应的命令。

故障快速定位：
如果是VM1与VM3不通的话，可以在VM1上ping自己的网关，（VM1的网关在哪？TOR？）如果能ping通，说明VM1到TOR是没有问题的，如果ping不通，则说明VM1到自身网关的通信有问题。如果VM1、VM3都能ping通自己的网关，但是还不能通信，则故障定位在TOR侧。

热迁移

热迁移分为了存储热迁移和VM热迁移。
存储热迁移：在虚拟机正常运行的情况下，管理员通过手动操作，将虚拟机的磁盘迁移至其他存储单元。存储热迁移使得客户在业务无损的情况下动态的调整VM存储资源。
存储热迁移的限制：与VM热迁移中的更改主机+数据存储中的存储限制一致。
存储热迁移的应用场景：在不中断业务的情况下进行内存维护和存储迁移。

VM机热迁移的定义：热迁移是指在业务不中断的情况下，将一台VM从一个物理服务器迁移到另外一个物理服务器。

VM热迁移的分类：热迁移分为了：1.更改主机，2.更改主机+数据存储。
针对于更改主机的实现原理：针对内存采用的是“内存分片”+“迭代迁移技术”。存储必须是共享的存储，来确保VM迁移后数据不变。
针对于更改主机+数据存储的实现原理是：针对内存采用“内存分片”+“迭代迁移技术”，针对于存储采用的是“MirrorIO+迭代迁移技术”来确保迁移后的数据不变。
VM热迁移的限制条件：
计算侧：VM安装了Tools，并且正常运行。VM处于开机状态。VM没有绑定外设（USB设备，图形处理器等）。如果源主机和目标主机的CPU类型不一致，需要开启集群的IMC模式。当跨集群迁移时，源主机所属的集群和目标主机所属的集群的内存复用开关设置需要相同。
存储侧：如果只是在集群内部迁移（更改主机），则需要使用相同的共享存储。如果是更改主机和数据存储，则只支持虚拟化数据存储之间的迁移。不支持已经挂载为“共享”类型的磁盘，和链接克隆VM的磁盘。不支持非持久化磁盘和开启了Icache功能VM磁盘的迁移。不支持目标存储或源存储为FS的迁移。
网络：因为虚拟机热迁移在未配置“虚拟机热迁移流量”业务接口的情况下默认走的是CNA管理网络平面，所以需要两个CNA管理网络平面三层互通，在FC场景中，为了保证VM迁移后仍能正常的对外提供服务，所以FC强制要求目标主机关联虚拟机所在的DVS，也就是DVS上行链路有目的主机的端口。

虚拟机热迁移应用场景：1.在服务器升级操作前，为了避免因升级导致的业务中断的风险。2.在服务器维护操作前，为了避免因为维护操作导致业务中断的风险。3.将空闲的服务器上的虚拟机迁移到其他服务器，将没有负载的服务器关闭，降低运行成本。

虚拟机热迁移失败的原因：1.源主机和目标主机网络中断或网络不通。2.目标主机无法访问虚拟机的磁盘。3.目标主机故障、重启或已经进入了维护模式。4.源主机和目标主机CPU类型不兼容。5.源主机和目标主机的BIOS配置不一致。

Tools的作用
1.为虚拟机提供高性能磁盘 IO ，网络 IO。
2.监控虚拟机硬件信息。
3.为虚拟机提供高级特性：迁移虚拟机；安全关闭，重启，休眠虚拟机；在线调整 CPU 规格；快照；虚拟机网卡高级功能，QOS ，流量整形；虚拟机蓝屏检测；虚拟机与 ntp 同步；自动升级虚拟机驱动程序。

服务器虚拟化与FusionCloud的区别

1.架构方面：

SV架构：

FC接入底层的计算、存储、网络资源，实现虚拟化，FM接入FC或者其他厂商的虚拟化层WMware，实现异构化的统一的管理与运维。SOI是提供性能监控和分析。ebackup虚拟化备份软件，与FC快照功能和CBT技术实现备份，BCManage实现容灾。eSDK实现的是北向的统一接口，其他的运营平台可以通过eSDK实现无缝对接。
FusionCloud架构：

FusionCloud架构，底层是基础设施层，有服务器、存储、网络、安全等等硬件，通过FusionSphereOM的extennol-OM平面接入底层资源，将计算资源接入Nova，存储接入Cinder，网络接入Neutron等。通过FusionSphereOpenstack提供的VM来将公共服务层部署，如LVS、NTP、DNS、Nginx、HAproxy、API-网关等，这些服务是通过DMK统一部署的。在公共服务层之上是云服务层，云服务层利用底层的资源，给用户提供计算、存储、网络、备份等云服务。计算服务有ECS，IMS，BMS。存储服务有EVS。网络服务有，VPC，EIP，VFW，ELB，VPN，SG等等。备份服务有，CSBS，VBS，CSDR，VHA等等。在云服务层之上是云管理层，ManageOne的SC，OC。esight，FusionCare，FusionNetworkDoctor。
SV使用的是FM来对资源池进行管理，而FusionCloud使用的是FusionSphereOpenstack来对底层资源的接入和管理，对底层资源有更好的兼容能力，而且对资源有更好的精细化管控。

除了架构不同之外，他们的关注点，应用场景和价值也不一样。

SV的关注的是基础设施层和虚拟化层，资源管理层，并没有考虑过多的云服务层，没有实现云的核心特点：服务。FusionCloud其关注点包含SV关注点外，还重点实现了云服务层，提供种类丰富、功能强大的云服务，例如：ECS，BMS，IMS，EVS等等。

应用场景和价值，SV更注重于底层的虚拟化层，利用虚拟化技术提高硬件的利用率，缩短业务的上线周期，实现业务的高可用。FusionCloud基于上面SV的场景和价值外，突出了业务驱动，云管协同等价值。

DPM

DPM是动态的电源管理，根据业务情况，智能的将部分物理机上下电。将负载较轻的物理机上的VM迁移到其他的物理服务器上，然后将此物理机进行下电，降低运营成本。（集群内，而且要配置IBMC口）

DRS

DRS动态资源调度。根据物理服务器的负载情况，智能的对资源进行调整，达到系统的负载均衡。（集群内）

分布式资源调度

是server—stagt平台实现方式，应用在FusionCloud上，在VDC内多个AZ间来进行资源的负载均衡。（在下发时选择性的在AZ间实现负载均衡）

内存虚拟化的原理与实现方式

内存虚拟化的实现原理是，VM的物理地址不是直接映射到主机的物理地址上，而是经过了VMM来统一的管理与分配。VM的VA映射到了VMM的PA，VMM将PA在映射到真实的主机物理地址MA上。VM保存了VA—PA的地址映射关系表，VMM保存了PA—MA的地址映射关系表。

内存虚拟化的实现的三种方式：1.内存共享+写时复制，2.内存置换，3.内存气泡。

内存共享+写时复制是指多台VM共享同一物理空间，此时VM对这块内存只有读的权限，如果想写入数据则需要单独开辟一块空间来给VM进行写入，并且建立映射关系。（共享的是内存为零页的空间）

内存置换指的是，VM将暂时不用的数据置换到磁盘上，并且建立映射关系，当VM需要这部分数据时在从磁盘上读到内存中。

内存气泡指的是，系统主动收回VM暂时不用的内存空间，分配给需要内存复用的VM使用，整个过程是系统自动执行的，VM是无感知的。

QOS

QOS是服务质量，是在资源紧张的情况下，保证关键业务的体验度。QOS分为了计算、存储、网络。
计算包含了CPU的QOS，内存的QOS。
CPU的QOS包含了CPU的上限、CPU的份额、CPU的预留。CPU的上限是指一台VM能使用的最大CPU资源。CPU的份额指的是在资源发生抢占时，根据CPU份额来分配CPU的资源。CPU预留指的是，给关键业务分配CPU预留，在资源抢占时可以保证关键业务的体验度。CPU的预留，在未发生抢占时，可以给其他VM来使用这部分预留资源，前提时没有达到VM的上限。
内存QOS分为了内存的上限，内存的份额，内存的预留。内存的上限指的是一开始创建VM时在Web上规划的内存大小，这是内存的上限。内存的份额指的是，当内存发生抢占时，根据内存份额来分配内存的资源。内存预留是指，给关键的业务分配预留资源，保证在资源抢占时能保证关键业务，内存预留一旦规划完毕，预留的资源即使VM没有使用到，别的VM也不能抢占。
存储的QOS是指针对于磁盘的IOPS，每秒IO的读写次数。
网络的QOS是指针对于端口组的流量整形和消峰填谷。

虚拟机HA

虚拟机的HA指的是，VM的高可用性。当VM开启了HA特性后，如果VM所在的物理服务器故障，或者是VM故障，则系统自动的在一台可用的物理节点上启动相同的VM，实现高可用。
虚拟机HA时，业务已经中断了。
特性实现：VM蓝屏或物理主机故障，VRM通过心跳检测到VM故障，判断VM是否有HA特性。如果开启了HA的话，VRM会根据之前VM的信息（磁盘信息，网卡信息等等），选择一台可用的CNA启动VM。CNA收到消息后，根据VM之前的信息，启动一台配置跟之前一样的VM，在启动过程中，会将之前的VM的卷重新挂载。
（HA需要共享存储）

KVM与XEN的区别

1.KVM架构是混合虚拟化类型，XEN是裸金属虚拟化类型。
XEN架构：在XEN架构中，有一台运行在特权级别下的虚拟机（不是一台真正的VM），它有两个模块，后端驱动模块用于和Domain U相连，设备驱动用于和硬件相连，用户VM通过前端驱动与Domain0的后端驱动将IO流发给Domain0。再由Domain0的设备驱动完成对硬件的访问。由Domain0实现虚拟化。
缺点：IO路径过长。

KVM架构：

在硬件层之上，装Linux操作系统，Linux操作系统有一个KVM.KO虚拟化模块。因为VM在Linux上只是一个文件的方式存在（进程），VM下发的指令没办法直接被Linux识别，所以需要用到QEMU（模拟仿真软件）用于和Linux进行通信。QEMU在VM和Linux中都装有。
缺点：不安全，没有VM控制台。

2.XEN与KVM的IO环：

XEN的IO环：

XEN架构下的IO环：首先如果VM1想要发送“hello”给VM2，那么首先，VM1会通过事件通道先去找到Domain0，对Domain0说“我要在内存共享区域的某一个地址写入‘hello’，是给VM2的”，在Domain0允许后，VM1才能写入，之后Domain0会通过IO环通知VM2，在内存共享区域的某个位置有你的数据，然后VM2在去取出数据。

KVM的IO环：

在KVM的IO环中，没有Domain0，此共享区域变成了真正的共享区域，由VM1直接写入“hello”，再由VM2直接读出即可。
KVM和XEN对于应用层来说都是“重”量级虚拟化。

3.KVM与XEN架构的对比：XEN架构有Domain0，更好的管控其他VM，但是会出现Domain0的瓶颈问题。而且由于增加了Domian0会使得XEN架构的核心代码增多，安全性降低。
KVM没有Domain0没有性能瓶颈问题，但是针对于VM不易管理。KVM只实现了计算虚拟化，IO虚拟化时QEMU来实现的。