OpenSolaris xVM 简介

最新推荐文章于 2024-10-02 14:03:05 发布

apollowm

最新推荐文章于 2024-10-02 14:03:05 发布

阅读量791

点赞数

分类专栏： Sun 文章标签： solaris 虚拟化平台 xen linux freebsd

Sun 专栏收录该内容

28 篇文章 0 订阅

订阅专栏

OpenSolaris xVM 简介

1. 关于文档

本文并不打算详细介绍 OpenSolaris xVM 架构、xVM 配置和域管理。本文只对 xVM 的各组成部分进行基本介绍，目的是让开发人员理解引入 xVM 带来系统变化。

有关 xVM 和/或 xVM 架构的更多信息，请参阅：

OpenSolaris 社区：http://www.opensolaris.org/os/community/xen/

开源 Xen 项目主页：http://www.cl.cam.ac.uk/research/srg/netos/xen/ index.html

xVM 社区发行文档：http://www.opensolaris.org/os/community/xen/documentation/

2. 基本架构

xVM 是在 Xen 社区工作的基础上开发的。系统运行时，Xen 的作用是在硬件和操作系统之间进行协调。

xVM 同时支持多个操作系统实例。每个实例被称作一个“域（domain）”。有两种不同的域：控制域（通常称作 "dom0"）和用户域（称作 "domU"）。与 Solaris Zones 有所不同，xVM 的每个域都运行操作系统的一个完整实例。xVM 管理程序虚拟系统硬件。这显然意味着xVM 管理程序在用户域之间共享并分割系统资源 ( CPU、 memory、 NIC 等等)。

管理程序执行向操作系统提供虚拟平台的低级管道，对于其他方面却严重依赖于控制域。控制域决定创建哪些用户域，访问哪些资源，拥有多少内存等等。此外，xVM 不包含任何设备驱动程序，所以控制域执行所有的设备访问。

有两种基本的虚拟化技术：全虚拟化（full virtualization）和准虚拟化（paravirtualization）。在全虚拟化过程中，操作系统根本识别不到系统正在虚拟化环境中运行。在准虚拟化过程中，操纵系统识别虚拟层面，与管理程序协作获得较高性能。 xVM 支持两种模式。由于操作系统必须和管理程序层面密切协作，控制域始终被准虚拟化。用户域既可准虚拟化，又可全虚拟化，而且系统可以同时运行在两种模式下。

全虚拟化要求管理程序显式的截取操作系统直接在硬件上执行的许多特定操作。这种截取使管理程序保证一个域不能读取或修改另一个域的内存，不干扰设备访问，且不能关掉该域正在使用的 CPU。xVM 要求专用设备支持来实现全虚拟化。具体讲，必须使用 VT 支持的 Intel CPU （例如Intel 酷睿双核心处理器），或者带有 AMD-v 技术的 AMD CPU。全虚拟化允许包括 Solaris、 Linux 以及 Windows 操作系统在内的任何一个 x86 操作系统在访客域中运行。

准虚拟化建立在同步调用（hypercall）接口之上。hypercall 同步调用与系统调用相类似，但 hypercall 同步调用是操作系统对管理程序层面的调用。这些 hypercall 同步调用允许一个域创建另一个新域，请求创建地址映射，将缓冲器从一个域传递到另一个域，以及在 CPU 之间发送中断等等。虚拟机管理层允许操作系统明确地启动在全虚拟化环境中被显式截取的操作。由于没有截取请求，准虚拟化并不需要专用设备支持，而且可在任意 CPU 上运行。由于准虚拟化要求对操作系统进行改动，所以在准虚拟化用户域中只有特定操作系统才能被操控。目前这些操作系统仅限于 Solaris、Linux 和 FreeBSD。

3. 资源虚拟化

3.1. 中央处理器

xVM 分配给每个域一个或多个虚拟 CPU（vcpu）。每一个虚拟 CPU 包含与典型物理 CPU 相关的所有状态：缓存器、标志、时间戳记等等。xVM 中的虚拟 CPU 就像 Solaris中的一个线程，是可以预订的实体。当轮到一个域在 CPU 上运行时，xVM 把在 vcpu 中捕获的状态数据载入到物理 CPU 中并运行。

Solaris将每一个虚拟 CPU 视为一个物理 CPU。当 xVM 选择一个虚拟 CPU 运行时，xVM 将运行 Solaris 在虚拟 CPU 上加载的线程。

3.2. 内存

Solaris 以页的形式管理内存。当 Solaris 直接在硬件上运行时，使用系统 BIOS 或固件所提供的物理页桢号。当系统在 xVM 下运行时，管理程序提供可用的物理页面列表。为了将子操作程序（guest OS）从硬件中分离出来，为了启用像动态迁移这样的特性，由 xVM 提供的页桢号并不反应被硬件识别的物理页。而这些页面反映系统内存的优化视图。xVM 将访客操作系统的“物理”页号变换成硬件可识别的“机器桢号（MFN）”。

对于绝大多数的情况，Solaris 管理由 xVM 提供的 PFN 就像管理在实际硬件上所使用的 PFN 一样。Solaris需要识别的和PFN 被虚拟的部分是最低的 HAT 层。只有当我们修改进程页表时才会使用 MFN 而不是 PFN。

如果你发现自己需要在HAT 层面之外区分MFN 和 PFN ，那么一定表明你做错了什么。

3.3. 设备

Dom0 Solaris 驱动等同于在裸机（bare metal )上运行的 Solaris 驱动。只要这些驱动完全通过标准 DDI 接口编写，它们就能同时适用于控制域和主机 Solaris。

围绕着 DDI 接口工作的任何驱动在控制域上运行时都可能遇到问题，特别突出的漏洞区域是 DMA。如果驱动试图直接使用物理页桢码( PFN ) 而不是使用 ddi_dma_*_bind_handle() 接口，那么驱动将错过从 PFN 到 MFN 这一必要的翻译过程，驱动将指示设备到或从错误位置执行 I/O 操作。运行失败将最有可能导致控制域崩溃，但也可能导致系统无记载数据损坏（即：把错误数据直接交给上层应用）。

在用户域中设备驱动有两种不同的工作方式。

在全虚拟化用户域中，xVM 将捕获任何写到 I/O 空间或者任何 DMA 操作的内容，并将这些请求直接转发给控制域中合适的设备。这种捕获和转发操作开销很大，所以对这类设备的访问可能导致其性能下降，尤其是网络设备更是如此。

在准虚拟化用户域中，每个驱动都有一个在用户域内呈现的“前端”和在控制域内运行的“后端”，这里简称 PV 驱动。前端驱动从 Solaris 获取标准请求并将其转发给后端驱动。后端驱动在物理硬件上执行请求，并将结果返回前端驱动，然后前端驱动通知 Solaris 请求完成。由于驱动清楚地识别到管理程序，它能够和虚拟机以及后端驱动一起协作，使传输性能比全虚拟化环境下的驱动更好。

在ON上有两个主要的准虚拟化驱动器：虚拟块设备和虚拟网络设备。这两个设备提供给用户域标准的磁盘和网络设备。

有一种支持设备的混合方法:在全虚拟化的环境中应用 PV 驱动。因此，操作系统作为一个整体仍不能识别其虚拟的运行环境，但域中的 PV 驱动能够识别管理程序。这种方法使我们无需要求整个操作系统支持管理程序，而获得更好的I/O性能。

4. 资源结构与管理

4.1 管理程序

xVM 管理程序基于一个开放源码的项目，并且 xVM 社区广受 Linux 用户欢迎。仅需少量修改，管理程序就可以使 Solaris 以控制域的方式运行。虽然其中一些修改已经并入主 xVM 代码树，但其余的修改仍然需要我们自己完成。因此，你不能简单地从 xVM 开放源站点下载资源，并期望这些资源能和 Solaris 控制域协同工作。

完整的 OpenSolaris xVM Community Release 发布文章可在此获取： Installable DVD ISO.

4.2 Solaris 与 Intel 平台

根据对 xVM 的介绍，在 Intel 架构上有两种不同的平台：i86pc 和 i86xpv。i86pc 平台指运行在裸机（bare metal )上的 Solaris 系统。i86xpv 平台指运行在准虚拟化的 xVM 管理程序之上的 Solaris 系统。

i86pc 和 i86xpv 这两个平台的相似之处多于不同之处。i86xpv平台指定代码在 sr/src/uts/i86xpv 下都可找到。但是，应用于 i86xpv 平台的大量代码可以直接从 i86pc 子目录 usr/src/uts/i86pc 中找到。

构建 i86xpv 平台代码需要一些来自 xVM 源代码树的标题文件，这些标题文件在 common/xen/public 目录中可以找到。为了确保导入 ON 源代码树的标题文件路径与 xVM 源代码树标题文件路径一样，要进行人工处理。工程师在对一个代码树修改的同时，必须对其他的代码树做同样的修改。

仅用于 i86xpv 平台的代码应当用 #ifdef __xpv 进行保护。

绝大多数情况下，用户和用户端应用程序根本识别不到运行的平台。在用户级别上，在 i86pc 和 i86xpv 有完全一致的二进制兼容性。如果你认为有必要决定选用那个平台，用 uname -i。

5. 启动

系统启动时间决定是以虚拟控制域运行还是以独立操作系统运行 Soliras。

要以独立操作系统运行 Soliras，继续使用与当前相同的 GRUB 菜单条目。要用管理程序以控制域运行 Soliras，必需在 /boot/grub/menu.lst 文件中有指定管理程序的条目。描述如下： here.

6. 可观察性/调试功能

6.1 `xm`

虽然管理程序和控制域一起紧密协作，管理运行系统，但是在管理程序中，控制域操作系统有很差的直接可见性。控制域无法访问管理程序整个地址空间，因此惟一的信息源只有 xm，xm 是一个通过同步调用 hypercall 与管理程序通讯的用户地址空间工具。

部分有用的 xm 命令如下：

xm info - 报告机器静态信息，例如 CPU 数量，内存大小，xVM 版本信息。
xm list - 列出所有的域和一些高级信息
xm top - 类似于 Linux 的 “top” 命令，但是它报告域信息而不是进程信息。
xm log - 显示 xend 日志内容
xm help - 列出所有的可用命令
xentrace - 从 xVM 中获取路径缓存数据
xentop - 以连续更新的方式显示 xVM 系统和域方面的信息

6.2 故障转换

当系统运行时，完全禁止管理程序的内存进入控制域。但是当管理程序崩溃时，造成的应急转储将生成一个 xVM 和控制域统一视图的磁心存储文件。在磁心存储文件中，xVM 作为一个简单的 Solaris 内核模型出现，称作 xpv。

例如：

                > $c
                xpv`panic+0xbf()
                xpv`do_crashdump_trigger+0x19()
                xpv`keypress_softirq+0x35()
                xpv`do_softirq+0x54()
                xpv`idle_loop+0x55()

需要弄清楚的是：如果控制域崩溃带有标准的 Solaris 应急，这种转储仅包含控制域。只有当管理程序自己也发生应急的时候，所导致的转储才包括 xVM。

有关处理 xVM 应急的更多信息，以及调试 xVM 应急的示例，请参阅： http://blogs.sun.com/nilsn/resource/xen _solaris_panic.pdf.

如果域出现挂起，可以使用 xm dump-core 获取转储文件。可以通过 /bin/mdb 方式查看该文件。有关更多信息，请参阅 xm(1) 手册页和 Debugging a Hung domU.

6.3 Dtrace

由于管理程序与控制域的分离，目前还没有什么方法可以将 Dtrace 直接应用于管理程序。新的 xpv DTrace 提供程序允许跟踪控制域和管理程序之间的交互。提供程序由引入到 privcmd 设备驱动的多个 SDT 探测器构成。列出可用探测器的命令为：dtrace -l -i 'xpv:::'

要了解这些探测器的细节，需要对 OpenSolaris xVM 接口有相当深入的理解，简单地启用这些探测器，探测器所有信息集合（dtrace -n 'xpv::: {}'）能够提供一个涉及创建域、破坏域、转移域等步骤的高级介绍。