Xen桥接网络

一个 Xen 虚拟化环境包括一组项目，它们一起工作来提供虚拟化环境：
Xen hypervisor；
dom0；
domain management and control，域的管理和控制；
domU PV 客户机；
domU HVM 客户机。

它们之间的关系参见：
http://www.chenyajun.com/2009/03/01/xen-virtualization-model-explored/

hypervisor 是操作系统以下硬件以上的一个软件抽象。负责 CPU 调度，虚拟机内存分配。hypervisor 不仅为虚拟机抽象硬件，也要控制虚拟机的执行。它对于网络、存储设备和其它 IO 功能等一无所知。

dom0
是一个修改的 linux 内核，是一个运行在 xen hypervisor 之上的独特虚拟机，对访问物理 IO 和其它 domu 虚拟机具有特殊的权利。 xen 虚拟环境需要 dom0 在其它任何虚拟机之前先启动。
在 dom0 中包括的驱动用来支持 domu 的网络和本地磁盘请求，包括Network Backend Driver 和 the Block Backend Driver。

domU
所有运行在 Xen hypervisor 上的半虚拟化客户机被称为 domain U PV 客户机，可以运行修改过的Linux，Solaris，FreeBSD 和其它操作系统。所有运行在 Xen hypervisor 之上的完全虚拟化的客户机被称为 Domain U HVM 客户机，运行标准的 windows 或者其它未修改的操作系统。
DomU PV 客户机意识到它不直接访问到硬件，认识到其它的虚拟机运行在同样的机器上。DomU HVM Guest 不会意识到它在和其它虚拟机共享硬件资源。
一个 domU PV 客户机包含用于网络和磁盘访问的 2 种驱动，PV Network Driver 和 PV Block Driver。

一个 domU HVM 客户机没有那种 PV 驱动；取而代之的是在 dom0 下对每个 HVM 有一个特别的守护进程：qemu-dm。它支持 domU HVM 客户机来进行网络和磁盘访问请求。
domU HVM 客户机必须进行一些初始化，加载一些软件模块（固件）来模拟 BIOS 。

dom 的管理和控制
一系列的 Linux 进程被归类为 dom 管理和控制工具，它们被用来进行 dom 0 内虚拟机的管理和控制。

xend
Xend 是一个 python 应用，它是 Xen 环境的系统管理器。它调节 libxenctrl 来向 hypervisor 请求，所有经由 Xend 的请求通过 xm 工具用 xml-rpc 接口发起。

xm
命令行工具，接收用户输入通过 xml rpc 传递到 Xend。

Xenstored
这个维护在 dom0 和 domU 之间的内存和事件通道等的信息。

libxenctrl
一个 C 库提供 Xend 和 Xen hypervisor 通过 dom0 对话的能力。在 dom0 中，privcmd 分发请求到 hypervisor。

Qemu-dm
每个 HVM 客户机要求有自己的 Qemu 守护进程。这个工具处理所有来自 domU HVM 完全虚拟化的客户机的网络和磁盘请求。Qemu 必须存在于 Xen hypervisor 之外，因为它必须能访问 dom0 中的网络和IO。

Xen 虚拟固件
一个虚拟的 BIOS 插入到每个 domU HVM 客户机中，保证操作系统接收到在正常启动过程中各种标准的启动指令。

dom0 和 domU 之间的通讯
Xen hypervisor 不用来支持网络或者磁盘请求，因此一个 domU 通过 hypervisor 向 dom0 通信来进行磁盘或者网络请求。
domU PV 客户机块设备驱动接收到磁盘写请求时，它将通过 Xen hypervisor 写数据到和 dom0 共享的一块本地内存。在 dom0 和 domU PV 客户机之间存在一个事件通道允许它们使用 Xen hypervisor 的异步域间中断来通信。dom0 将接收到一个来自 hypervisor 的中断引起 PV Block Backend Driver 来访问本地系统内存读取 domU PV 客户机共享内存中的块。共享内存中的数据然后被写到本地磁盘。

 

 

 

如前所描述，后端驱动（backend driver）运行在特权域，前端驱动（frontend driver）运行在非特权域。非特权的客户端发出设备请求到前端驱动。前端驱动然后和运行在特权域中的后端驱动通信。特权域将请求排队向实际物理硬件请求。

前端和后端驱动的通信通过使用 XenBus 的系统内存来完成，这是一个用来共享事件通道和生产者/消费者的环缓冲。为了避免昂贵的数据拷贝，XenBus 通过简单映射来完成。比如当要写数据到磁盘或者通过网络发送数据，一个属于非特权域的缓存可能被映射到特权域。同样，要从磁盘读数据或者接收来自网络的数据，一个由特权域控制的缓存可以被映射到非特权域。

这种通信通过 XenStore 来建立。当前端驱动启动时，它使用 XenStore 来建立一个共享内存池和与后端驱动通信的事件通道。在连接建立以后，前端和后端将请求或者响应放置到共享内存中通过事件通道向彼此发送通知。XenStore 向后端和前端驱动提供了对这种连接的可见性。

桥接、路由和 NAT 
Xen 提供了 3 种虚拟网络模型来供客户机访问物理设备——桥接、路由和 NAT。在桥接模式中，虚拟网络接口（vif）在外部局域网是可见的，在路由模型中，vif 在外部局域网是不可见的，但是 IP 是可见的。在 NAT 模型中，vif 在外部局域网不可见，它也没有一个外部可见的 IP 地址。

在桥接模式下， brctl 工具被用来创建软件方式的桥接接口，一个物理网络接口然后附加到桥上。Xen 客户机域的后端 vif 能被附加到这个桥上。当桥接口接收到来自物理接口的包时，物理网络接口将依据各域的虚拟网卡的 MAC 地址转发它们到不同的域上。

在路由模型下将使用 iptables 机制来进行路由。由物理接口所收到的所有的包将被驱动域的网络 IP 层所处理。驱动域（dom0）查找路由表条目并将包转发到不同的客户机 IP 地址。在路由模式下，驱动域连接 2 个不同的网段：内部由客户机使用的网段和连接外部网络的网段。

在驱动域作为一个 NAT 网关时，驱动域仍然作为一个路由器，但是更进一步映射一个它自己的 IP 地址和端口到一个客户机的 IP 地址和端口。客户机的 IP 地址隐藏在驱动域后面对外部网络不可见。

Linux 防火墙提供了 iptables ，而 bridge-utils 则提供了 etables 来进行基本的 MAC 地址过滤。也可以指定一个物理网卡给一个域使用。

下图是个桥接的例子。

veth0、vif0.0 是 dom0 的网络接口。veth0 被重命名为 eth0。xenbr0 接口是软桥接接口。vif1.0 是运行的客户机的后端网络接口。
peth0、xenbr0、vif0.0、vif1.0 都共享同样的 MAC 地址 FE:FF:FF:FF:FF:FF，它是以太网的广播地址。这意味着实际的网络接口、dom0 的回环接口、客户机的后端接口都向 xenbr0 广播。当物理网卡接收到包时，它直接发送到桥接接口 xenbr0，这个桥接接口通过包的 MAC 地址决定将包转发到哪个域的后端接口。因此 peth0 不需要 IP，只需要 MAC 地址。物理接口的原先 IP 已经被告知给 eth0——驱动域的虚拟前端接口。xenbr0 通过 MAC 地址是 00:11:25:F6:15:22 或者是 00:16:3e:45:e7:12 来决定包转发到 eth0 或者 vif1.0。客户域相应的前端接口被命名为 eth0。从 dom0 的角度看，客户机中 eth0 实际是 vif1.0。
brctl 命令的显示：

[user@Dom0]# brctl show bridge name bridge id STP enabled interfaces xenbr0 8000.feffffffffff no vif1.0 peth0 vif0.0