[转]漫谈虚拟化-计算虚拟化中的 I/O 虚拟化

如果你认为本系列文章对你有所帮助,请大家有钱的捧个钱场,点击此处赞助,赞助额0.1元起步,多少随意

声明:本文只用于个人学习交流,若不慎造成侵权,请及时联系我,立即予以改正

锋影

email:174176320@qq.com

 

今天,咱们继续计算虚拟化这个话题,主要来聊一下 I/O 虚拟化。

1 I/O 虚拟化

1.1 I/O 虚拟化简介

现实中的外设资源是有限的,例如服务器单个千兆以太网端口肯定能够支持单个应用,但是当被分割为 10 个、15 个或者更多的服务器负载时(这其中包括网络、存储以及服务器之间的流量)可能就不够用了,这就是所谓的 I/O 瓶颈。

当遇到 I/O 瓶颈时,CPU 就会空闲下来等待数据,计算效率则会大大降低。也就是说,I/O 瓶颈最终会拖累其他资源虚拟化所带来的资源使用效率的提升。所以虚拟化也必须扩展至 I/O 系统,在工作负载、存储以及服务器之间动态共享带宽,能够最大化地利用网络接口。通过缓解服务器 I/O 潜在的性能瓶颈,服务器能够承载更多的工作负载并提升其性能。

I/O 虚拟化的目的可以归纳为两个:

其一,是设备发现,即需要控制各 VM 能够访问的设备

其二,是访问截获,即可以通过 I/O 端口截获 VM 对设备的访问指令

1.2 I/O 虚拟化的分类

1.2.1 I/O 全虚拟化

即通过 VMM 模拟 I/O 设备(磁盘和网卡等)实现虚拟化。这种模式下,Guest OS 所能看到的就是一组统一的 I/O 设备。VMM 截获 Guest OS 对 I/O 设备的访问请求,然后通过软件模拟真实的硬件。这种方式对 Guest OS 而言非常透明,无需考虑底层硬件的情况。如下图所示,这是一个 Xen 的 I/O 全虚拟化模型:

 

[转]漫谈虚拟化-计算虚拟化中的 I/O 虚拟化

当虚拟机访问虚拟设备时,访问请求被虚拟机监视器截获,然后监视器程序将 I/O 请求交由 domain0 来模拟完成,最后将结果返回给虚拟机

其最大的优点在于不需要对操作系统内核做修改,也不需要为其改写驱动程序,因此,这是可移植性与兼容性最佳的一种 I/O 设备虚拟模型,这也是它被如此广泛使用的主要原因。但是 I/O 全虚拟化有一个很大的不足之处,就是性能较差,主要原因有两方面:

(1)第一、模拟方式是用软件行为进行模拟,这种方式本身就无法得到很高的性能;

(2)第二、这种模型下 I/O 请求的完成需要虚拟机与监视器程序多次的交互,产生大量的上下文切换,造成巨大开销。

1.2.2 I/O 半虚拟化技术

即前端(Front-End)和后端(Back-End)模型,模拟实现虚拟化。如下图所示:

 

[转]漫谈虚拟化-计算虚拟化中的 I/O 虚拟化

其中,Guest OS 中的驱动程序为前端,VMM 提供的与 Guest 通信的驱动程序为后端

前端驱动将 Guest OS 的请求通过与 VMM 间的特殊通信机制和接口发送给 VMM 的后端驱动,后端驱动对 VM 的数据进行分时分通道处理,处理完请求后再发送给物理驱动。

该模型采用了 I/O 环机制,减少了虚拟机与虚拟机监视器之间的切换;同时该模型摒弃了传统的中断机制,而采用事件或回调机制来实现设备与客户机间的通信。进行中断处理时,传统的中断服务程序需要进行中断确认和上下文切换,而采用事件或回调机制,无需进行上下文切换。

I/O 半虚拟化模型虽然在性能上比 I/O 全虚拟化模型要好,但是这种 I/O 模型有一个很大的缺点,就是要修改操作系统内核以及驱动程序,因此会存在移植性和适用性方面的问题,导致其使用受限。

1.2.3 I/O 硬件辅助虚拟化技术

这种技术直接给虚拟机分配物理设备,例如直接分配一个硬盘或网卡给虚拟机。在 Xen 下由 Dom0 分配,但是访问使用直接使用,不经过 Dom0。需要硬件支持。

这种模式,主要有三种网卡硬件作为辅助:普通网卡、VMDq 直通 和 SR-IOV,相关技术说明如下:

(1)普通网卡(IO-through,即 I/O 透传)

Dom0 网桥队列,就是把某一个设备直接分配给一个虚拟机,让虚拟机可以直接访问该物理设备而不需要通过虚拟机监视器或被虚拟机监视器截获。如下图所示

 

[转]漫谈虚拟化-计算虚拟化中的 I/O 虚拟化

在设备直接分配模型中,虚拟机操作系统可直接拥有某一物理设备的访问控制权限,虚拟机监视器不再干涉其访问操作。因此,该模型可以较大地改善虚拟化设备的性能,降低监视器程序的复杂性,易于实现,并且不需要修改操作系统,保证了高可用性。

虽然设备直接分配模型在性能上相比前面的两种 I/O 设备虚拟化模型有着很大的提升,但是因为该模型将一件物理设备直接分配给了一个虚拟机,其它虚拟机是无法使用该设备的,所产生的一个问题就是如果其它虚拟机需要访问该设备则无法满足需求,解决的办法就是服务器上还有一个同样的设备以供其它虚拟机使用。因此,设备直接分配模型的使用必须满足物理资源较为充足的前提条件,对于那些紧缺的物理资源,该模型是不适用的。

所以,业界又推出了如下两种办法来解决这个问题。

(2)VMDq虚拟机设备队列

VMM 在服务器的物理网卡中为每个虚拟机分配一个独立的队列,虚拟机出来的流量可直接经过软件交换机发送到指定队列上,软件交换机无需进行排序和路由操作。VMM 和虚拟交换机仍然需要将网络流量在 VMDq 和虚拟机之间进行复制。

(3)SR-IOV(原生共享):也叫单根 I/O 虚拟化

为降低虚拟机 I/O 的性能开销,学术界和工业界从软硬件方面对虚拟机 I/O 模型做了大量的改进。Intel VT-d 技术和 Passthrough 技术通过降低 I/O 操作中 VMM 的参与提升了虚拟机的 I/O 性能。

SR-IOV 这种技术更为彻底,它通过创建不同虚拟功能(VF)的方式,一个物理网卡可以虚拟出多个网卡,分配给虚拟机的就是独立网卡,实现虚拟机直接跟硬件网卡通信,不再经过软件交换机,减少了 Hypervisor 层的地址转换。

SR-IOV 标准定义了设备原生共享所需的软硬件支持。硬件支持包括芯片组对 SR-IOV 设备的识别,BIOS 为 SR-IOV 分配足够的资源,此外为保证对设备的安全、隔离访问还需要北桥芯片的 VT-d 支持。软件方面,VMM 将驱动管理权限交给 Domain 0,Domain 0 操作系统必须支持 SR-IOV 功能。Domain 0 通过物理功能(physical function,PF)驱动发现设备的 SR-IOV 功能后将包括发送、接收队列在内的物理资源依据 VF 数目划分成多个子集,然后PF驱动将这些资源子集抽象成设备即系统中所见的虚拟功能(virtual function,VF)设备,创建 VF 设备后,Domain 0 可将 VF 设备以 Passthrough(PCI\PCIe) 方式分配给虚拟机。如下图所示:

 

[转]漫谈虚拟化-计算虚拟化中的 I/O 虚拟化

SR-IOV 的软件架构分成四个部分:PF、VF、控制面板以及 PF 和 VF 间的通信机制。其中:

1)PF(物理功能),是 Domain 0 中负责管理 SR-IOV 设备的特殊驱动,其主要功能是为特权 Domain 0 提供设备访问功能和全局贡献资源配置的功能,虚拟机所有影响设备状态的操作均需通过通信机制向 PF 发出请求完成。

2)VF(虚拟功能),是轻量级的 PCIe 功能,其功能包含三个方面:

— 向虚拟机操作系统提供的接口;

— 数据的发送、接收功能;

— 与 PF 进行通信,完成全局相关操作。

由于 VF 的资源仅是设备资源的子集,因此 VF 驱动能够访问的资源有限,对其它资源的访问要求通过 PF 完成。

3)控制面板,同 PF 一样位于特权 Domain 0 中,其主要功能是负责生成 PCIe 配置空间并将 VF 抽象成 PCIe 设备,并向用户提供 VF 分配、回收等接口。

4)通信机制,一旦在 PF 中启用了 SR-IOV,就可以通过 PF 的总线、设备和功能编号(路由 ID)访问各个 VF 的 PCI 配置空间。每个 VF 都具有一个 PCI 内存空间,用于映射其寄存器集。VF 设备驱动程序对寄存器集进行操作以启用其功能,并且显示为实际存在的 PCI 设备。创建 VF 后,可以直接将其指定给 I/O 来宾域或各个应用程序。此功能使得虚拟功能可以共享物理设备,并在没有 CPU 和虚拟机管理程序软件开销的情况下执行 I/O。

上一篇:D - 水之矢 (URAL - 1353 )


下一篇:[WC2006]水管局长