QEMU-KVM SPICE Libvirt OpenStack Linux

Table of Contents

1. 第一章 绪论
   1. 1.1 前言
   2. 1.2 国内外研究现状
      1. 1.2.1 国外研究现状
      2. 1.2.2 国内研究现状
   3. 1.3 立题意义
   4. 1.4 主要研究内容
2. 第二章 相关理论与技术
   1. 2.1 资源池的概念
      1. 2.1.1 计算资源
      2. 2.1.2 网络资源
      3. 2.1.3 存储资源
   2. 2.2 桌面虚拟化技术
      1. 2.2.1 基本概念
      2. 2.2.2 技术架构
         1. 2.2.2.1 VDI架构
         2. 2.2.2.2 VOI架构
         3. 2.2.2.3 IDV架构
   3. 2.3 虚拟机迁移技术
      1. 2.3.1 P2V迁移
      2. 2.3.2 V2V迁移
      3. 2.3.3 V2P迁移
   4. 2.4 Libvirt库
   5. 2.5 本章小结
3. 第三章 混合型桌面云服务端架构设计
   1. 3.1 总体设计
      1. 3.1.1 整体架构设计
      2. 3.1.2 架构核心特点
   2. 3.2 逻辑架构设计
   3. 3.3 架构引申的问题与解决方案
      1. 3.3.1 两层管理问题
      2. 3.3.2 资源配置冲突问题
      3. 3.3.3 同一虚拟网段IP分配受限和IP冲突问题
      4. 3.3.4 节点加入和退出检测问题
      5. 3.3.5 资源释放与回收问题
      6. 3.3.6 USB设备重定向问题
   4. 3.4 功能结构与模块设计
   5. 3.5 系统类图设计
   6. 3.6 本章小结
4. 第四章 详细设计与实现
   1. 4.1 节点的动态加入和退出
   2. 4.2 数据中心容量计算

第一章 绪论

1.1 前言

• 桌面云解决方案（Desktop as a Service）
• 可以使用户通过瘦客户端或者其他任何与网络相连的设备来访问跨平台的应用程序，以及整个用户桌面
• 采用 集中式 的管理方式，通过将计算机的计算资源和存储资源集中部署在数据中心，通过虚拟化技术将这些物理资源转化为虚拟资源，并根据用户的不同需求将虚拟资源整合为各种规格的虚拟机，以虚拟桌面（Virtual Desktop）的方式交付给用户使用

1.2 国内外研究现状

1.2.1 国外研究现状

国外市场，x86平台上桌面云解决方案的主要提供商有以下三家

• VMware —— VMware View
• 微软 —— Microsoft虚拟桌面基础结构（VDI）
• Citrix —— Citrix XenDesktop

1.2.2 国内研究现状

近几年来，国内有许多企业都投入到了桌面云的研究领域，比较典型的有以下三家

• 华为 —— Fusion Cloud
• 红山 —— IDV（Intelligent Desktop Virtualization）架构
• 深信服 —— aDesk桌面云解决方案（自主研发的sRAP传输协议）

1.3 立题意义

• QEMU-KVM虚拟技术
• Libvirt虚拟化库
• VMware View 5.5
• Citrix XenDesktop 5.6
• OpenStack
• abiCloud
• 提出了混合型桌面云架构，并设计与实现了混合型桌面云服务端（HDCS: Hybrid Desktop Cloud Server）

1.4 主要研究内容

• 采用分层的方式设计混合型桌面云架构
• 通过数据中心的资源池统一管理资源
• 设计和实现VMM-Node程序完成服务器节点动态加入与退出资源池，并完成服务器节点Capacity值的计算
• 设计与实现HDCS虚拟化层，完成对物理层资源的池化功能
• 设计并实现虚拟机的调度机制
• 设计并实现虚拟机的管理层，包括虚拟机的运行状态管理、虚拟机调度、虚拟机的迁移、虚拟机的克隆、虚拟机的并发启动等功能
• 设计并实现虚拟机占用资源的释放与回收机制
• 针对派生镜像的特点，设计并实现对系统资源的高效备份机制，基于快照技术实现对派生镜像的增量备份，提高备份效率
• 设计并实现服务接口层，提供统一的API接口供上层应用的业务系统进行调用，方便上层应用基于HDCS进行二次开发
• 设计并实现系统的监控模块，对桌面云平台的运行环境进行监控
• 对HDCS进行性能测试，并针对测试结果进行详尽的性能分析

第二章 相关理论与技术

2.1 资源池的概念

资源池是云计算的五个基本属性之一，它将传统的IT的思维过程转变为基于服务的云计算方式。资源池是构建云计算数据中心的核心组成部分。

数据中心的资源从逻辑上可分为三类——计算、网络和存储。

2.1.1 计算资源

计算是所有CPU能力的集合，也称为计算池，代表了执行代码和运行实例的总能力，实质上数据中心的所有服务器，无论是起支持作用还是实质运行工作负载，都是这个集合的一部分。

2.1.2 网络资源

网络是将数据中心网络层及其以下的所有连接资源、网段、以及独立资源通过物理或人工的方式连接在一起，组合成网络池，包括物理设备、逻辑开关、地址空间和站点配置。

2.1.3 存储资源

存储是指数据中心中所有服务器主机的硬盘以及所连接的共享存储等各种存储共同组成的存储资源集合，这些存储资源按照一定的方式通过虚拟化技术形成存储池。

2.2 桌面虚拟化技术

2.2.1 基本概念

桌面虚拟化将桌面环境、相关的应用软件和用来访问它的客户端物理设备分离开来，实现桌面环境与终端设备的解耦，从而提高访问桌面环境的灵活性和安全性。

• 集中计算，分布显示
• 桌面虚拟化依赖于服务器虚拟化、 存储虚拟化等技术
• 在数据中心分别构造出计算池、网络池和存储池，并将这三者进行整合
• 桌面虚拟化还依赖于高效的远程访问协议，如微软桌面虚拟化产品使用的RDP协议、Citrix独立研发使用的ICA协议、VMware所采用的PcoIP协议，以及开源的SPICE协议等
• 桌面虚拟化可以与IaaS相结合，像云计算一样提供服务，形成桌面即服务（Desktop as a Service），即桌面云

2.2.2 技术架构

桌面虚拟化的技术架构实现需要考虑以下三个因素

• 虚拟桌面在本地还是远程运行
• 虚拟桌面的访问要求保持连续性还是设计成间歇式访问
• 虚拟桌面在不同会话之间是否持久化

通常情况下，可以将虚拟桌面运行于本地和远程的实现在同一个桌面虚拟化产品中提供，而其他两个因素需要根据用户的特定需求进行设计。

在服务器主机中会添加一层虚拟化管理程序用于实现虚拟化，称之为 Hypervisor，该层可以用硬件或软件的方式实现。

目前比较流行的桌面虚拟化技术架构主要有以下三种

• 虚拟桌面基础架构（VDI：Virtual Desktop Infrastructure）
• 虚拟操作系统基础架构（VOI：Virtual OS Infrastructure）
• 智能桌面虚拟化架构（IDV：Intelligent Desktop Virtualization）

2.2.2.1 VDI架构

虚拟桌面基础架构（VDI）是在远程服务器或者刀片服务器中托管用户的桌面环境，将用户操作系统、应用程序、数据等统一存放到数据中心得服务器和存储设备中，后台通过服务器虚拟化技术建立虚拟机池，提供给不同的用户，然后客户端通过远程显示协议访问专属于个人的桌面。

但是VDI架构在带来上述优点的同时，也存在着固有的不足之处。

• 采用硬件仿真技术，对视频、VoIP以及其他计算或图形密集型应用的支持性较差
• 桌面会话必须保持长时间的连接状态，不能很好的支持离线移动性场景
• VDI架构是基于服务器的模式，这也要求数据中心服务器需要有较高的配置
• 在服务端采用服务器虚拟化技术创建虚拟机池，将消耗大量的内存

2.2.2.2 VOI架构

VOI架构与VDI架构 所交付的对象 有所不同。VDI架构交付的是系统桌面和应用，而VOI则把操作系统作为交付对象。

VOI架构的 核心思想 是在终端本地缓存桌面OS。该架构模式通过虚拟容器技术将终端设备进行虚拟化，形成虚拟容器池，然后在此基础上再部署操作系统，让客户端从这个虚拟容器池中启动。

VOI模式采用即时分发的原则，通过在I/O层实现对底层存储介质的数据重定向，直接使用内部地址而不再将操作系统的端口与远程端口进行映射，并且将操作系统内核与终端设备的硬件驱动解耦，实现系统应用的跨平台交付，使客户端能够不再依赖于GPU/CPU虚拟化技术来利用系统资源，同时也降低了对服务器性能和网络带宽的要求，并且避免了软件和硬件之间的兼容性问题。

VOI模式并不像VDI模式那样对网络的连续性要求很严格，可以通过离线的方式在客户端完成大部分的运算，当网络连通时再传输数据同步更新，从而能够提供离线办公能力，并降低了对网络的依赖。因此，VOI模式很好地弥补了VDI模式上的不足，能够满足高清图像、VoIP、视频会议等办公需求。

2.2.2.3 IDV架构

IDV架构，又称为智能桌面虚拟化架构，此架构采取分布式方式来满足运营技术需求，同时集中和简化管理、部署功能。

IDV在架构设计上依据的是“集中管理，分散计算”的原则，这种分散计算的设计原则使其能够充分利用终端资源，对服务端的依赖与VDI模式相比大大降低。

与VDI架构不同，IDV架构的Hypervisor是建立在终端设备上，而非服务器的操作系统上。VOI架构和IDV架构之间的细微差别在于，VOI架构采用的是在终端本地通过虚拟化容器缓存桌面操作系统的技术，而IDV架构采用的是通过服务端将桌面数据发送到终端本地的Hypervisor，由本地的Hypervisor启动虚拟机进行计算。

IDV架构还包含两个组件，分别是：缓存服务器和镜像服务器组件，它们能够应对网速低的应用场景，降低对网络带宽的要求。IDV架构对镜像进行分层，使用户能够更灵活的对镜像进行管理。

IDV架构显著的缺点在于没有解决对终端设备的依赖性。

由于采用将虚拟桌面分散到各个终端设备进行计算来提高用户的体验性，虽然能够使用户获得接近PC的体验性能，但是这种体验性能同时依赖于终端设备的性能，需要采用配置较高的智能终端而不能采用瘦客户机或者接近淘汰的PC机，否则体验效果很不理想。因此，IDV架构并不能延长终端设备的使用年限以及对终端设备的维修费用。

2.3 虚拟机迁移技术

简单来说，虚拟机的迁移指的是 将虚拟机从源主机迁移到目的主机，迁移的内容一般包括 虚拟机的操作系统、应用程序、用户数据、以及虚拟机配置文件等，对于虚拟机的在线迁移还需要包括 虚拟机操作系统的内存数据。

衡量虚拟机的迁移技术的 性能指标 主要包括 迁移的整体时间 和 虚拟机的停机时间，以及 迁移对源主机和目标主机服务性能的影响。

高效的迁移技术力求将这三个因素都做到最优，但通常情况下，这三者彼此间互相制约，很难将它们同时做到最优化。因此，在选取迁移技术的时候需要根据具体的应用场景来权衡。

虚拟机的迁移方式主要包括三种

• 物理机到虚拟机的迁移（P2V：Pysical to Virtual）
• 虚拟机到物理机的迁移（V2P：Virtual to Pysical）
• 虚拟机到虚拟机的迁移（V2V：Virtual to Virtual）

2.3.1 P2V迁移

如图 2-1 所示，P2V迁移方式是将物理机上的OS、应用、用户数据等迁移到虚拟机中，通常在这种迁移方式中虚拟机都托管到虚拟机监视器（Hypervisor）中。

启动镜像前，首先需要完成两个步骤

• 在VM中安装好与物理机硬件设备所对应的驱动程序
• 将虚拟机的IP地址、Mac地址都设置成物理机对应的地址

当成功执行完这一迁移过程后，将VM重启后便能接替原来的物理机进行工作。

P2V方式按照迁移过程中系统服务的可用性可分为 冷迁移 和 热迁移 等。

冷迁移与热迁移：P2V的冷迁移在迁移过程中系统服务将在一段时间内中断，这种迁移方法无法满足一些特定的应用场合，此时需要选用P2V热迁移方法。目前，VMware和微软等公司已经推出了支持P2V热迁移的迁移工具。

2.3.2 V2V迁移

如图 2-2 所示，V2V迁移是指将VM从一个物理机上的Hypervisor迁移到另一台物理机的Hypervisor上。源主机上的Hypervisor与目的主机的Hypervisor类型可以有所不同。

与P2V迁移相似，V2V迁移可以按照VM的系统服务是否中断分为 离线迁移 和 在线迁移。

离线迁移（Offline Migration）：又称为常规迁移、静态迁移，在迁移过程中需要先将源主机上待迁移的VM暂停，等迁移完成后再从目的主机恢复运行。

在线迁移（Online Migration）：又称为实时迁移、热迁移，在迁移过程中维持VM上的系统服务正常运行。V2V的在线迁移与离线迁移在迁移内容和迁移步骤上基本相同，但由于要维持迁移过程中VM系统服务的可用性，因此在迁移的内容上需要比离线迁移多一项，即VM内存状态。

2.3.3 V2P迁移

如图 2-3 所示，V2P迁移实质上是P2V迁移的相反过程，将Hypervisor托管的VM上的OS、应用以及用户数据等迁移到物理机上，一个VM可以迁移到一台或多台物理机上。

但是与P2V迁移相比，V2P迁移过程要复杂得多。V2P迁移需要考虑 待迁移VM的配置是否适合目的物理机的硬件配置，包括系统架构和设备的驱动等。与其他迁移方式类似，V2P迁移也可以采用手动迁移或者借助迁移工具实现自动化迁移。如果VM和物理机的硬件设备不一致，则需要V2P转换工具进行转换，如PlateSpin Migrate。

2.4 Libvirt库

Libvirt是一套开源的C函数库，提供了跟最新版本的Linux或其它类型操作系统的虚拟化功能交互的API，用于对虚拟化平台管理。

Libvirt除了提供 开发库，还提供了一个 后台守护程序 以及一套 虚拟化管理工具。

目前，Libvirt所支持的虚拟化技术多达十几种，包括主流的Linux QEMU/KVM、Xen、VMware ESX、Microsoft Hyper-V等等。开发者可以根据Libvirt库开发出基于各种Hypervisor的监控管理程序，实现对虚拟机的监控管理。

如图 2-4 所示，Libvirt总体上可以分为三个层次，从上往下分别是 公共接口层（Public API Layer）、驱动接口层（Driver API Layer）、驱动实现层（Driver Implementation Layer）。

公共接口层 包含了virsh虚拟化管理工具和libvirt的API；而 驱动接口层 包含了网络、存储、监控等各种类型的驱动，每种类型的驱动都封装了该类型的功能模块；驱动实现层 则对应各种libvirt支持的虚拟化技术，不同的虚拟化技术以驱动的形式实现。

整个Libvirt库主要围绕着五个指针对象展开，分别是：virConnectPtr、virDomainPtr、virStoragePoolPtr、virNetworkPtr、virStorageVolPtr。每个指针对象都分别对应着一个模块的虚拟化管理功能，这五个指针对象通过virConnectPtr对象相互关联起来。具体如图 2-5 所示。

2.5 本章小结

本章围绕桌面云的构建过程中所涉及的相关概念和技术进行介绍，包括 资源池 的概念、桌面虚拟化技术 的概念和 主流的技术架构、虚拟机的 各种迁移技术 等，其中重点介绍了桌面虚拟化技术的技术架构，并对虚拟机迁移技术进行了深入分析，最后对 Libvirt库 进行了介绍。

第三章 混合型桌面云服务端架构设计

3.1 总体设计

3.1.1 整体架构设计

混合型桌面云服务端架构以 “集中式管理，分布式部署” 为架构的设计原则进行构建，作为通用性的基础平台向上层提供桌面云服务。

如图 3-1 所示，该架构通过 资源中心 对所有资源实行统一管理，数据中心由多个资源池组成，每个资源池都对应一个 域结点。域结点通过其对应的资源池来集中管理域结点的资源，域结点彼此之间采用分布式方式进行部署。所有域结点在局域网环境下整合在一起，交由系统管理端对资源统一进行调度管理，整个桌面云服务端主要包含以下四个核心组成部分：

• 数据中心：所有资源集中存放在数据中心，集中管理资源，是虚拟桌面 实际的运行环境
• 服务端管理节点：负责 处理和相应各种用户请求，通过通信协议与数据中心进行交互，对数据中心的资源进行管理
• 调度模块：负责完成 虚拟机和虚拟资源的调度与分配职能
• 监控模块：负责完成 虚拟机运行状态和系统集群运行状态的监控

系统的 物理 组成包括 数据中心的物理层设备、后台管理系统的代理服务器，以及 上层业务系统的服务器和客户端设备。

构建混合型桌面云架构首先需要构建数据中心，数据中心的架构示意图如图 3-2 所示。

每台服务器主机称为 服务器节点（Server Node），一个到多个服务器节点通过交换机设备连接到同一台共享存储设备构成一个 域节点（Domain Node）。从域节点中选出一个IP地址最小的服务器节点作为 NFS(网络文件系统) 的主节点，其他几个服务器节点通过NFS统一访问共享存储设备。

NFS主节点创建一个目录并挂载到共享存储设备中，该目录作为域结点的根目录，其它几个服务器节点通过NFS方式挂在到该根目录。所有的用户数据、虚拟机的镜像文件、配置文件、日志文件等数据都集中存放在共享存储设备中，客户端的终端设备不保存任何数据，通过对用户数据进行集中管理，统一实施加密认证以及冗余备份的措施，从而保证用户数据的安全性，并能使用户使用任意客户终端设备随时随地通过网络进行访问。

每个域结点的物理资源（包括域结点内所有的服务器节点、所连接的共享存储设备和网络等）通过HDCS的虚拟化层进行池化，构成一个资源池（Resource Pool）。多个域结点之间通过局域网连接形成一个集群节点（Cluster Node），集群节点内所有的资源池共同组成一个资源池组（RPG：Resource Pool Group），又叫做HDCS的数据中心。

服务端管理节点基于数据中心之上进行构建，通过网络连接到数据中心每台服务器节点上的守护进程，彼此间通过libvirt的通信机制进行数据交换，管理节点采用多进程机制集中管理数据中心的资源。管理节点首先与域结点层面进行交互，然后再与该域结点下的具体服务器节点交互，实现两层式的管理。

监控节点采用 代理机制 实行监控，数据中心的每台服务器节点都部署一个用于监控的Agent，该Agent会通过libvirt机制收集所需的监控信息，然后传给监控节点进行处理。

调度模块完成虚拟机和虚拟资源的调度与分配，该模块也涉及到域结点和服务器节点两个不同的层面的调度。

3.1.2 架构核心特点

从混合型桌面云架构的设计来看，“集中式管理、分布式部署” 是整个架构的核心特点。如图 3-3 所示，整个混合型桌面云服务端架构类似于一颗高度为3的树状结构，管理节点、调度模块和监控模块 三者作为 树的根节点，而 域结点 则作为根节点的子节点，服务器节点 是域结点的子节点，也是整棵树的叶子节点，作为 系统的计算节点。

整个系统对资源采用了 两层的管理方式，第一层是 对域结点的管理，第二层是 对服务器节点的管理。同一个域结点的服务器节点集中部署，并将所有数据都存放在共享存储设备中，然后通过资源池对这些数据和资源集中管理，在域内进行资源共享，使得域节点内的服务器在访问数据时更加方便快捷，对域节点的多台服务器实行负载均衡的代价很低，虚拟机能够在多台服务器节点间灵活迁移。

3.2 逻辑架构设计

混合型桌面云服务端（HDCS：Hybrid Desktop Cloud Server）的逻辑架构如图 3-4 所示。HDCS 从逻辑上根据职责的不同将系统划分为四个不同的层次，自底向上分别为 物理层、虚拟化层、管理层 和 服务接口层。这四层层层相扣，搭建了HDCS的主体部分。此外，HDCS还包括系统监控和运营计费等功能模块，这两个功能模块构建在管理层之上。

混合型资源池是数据中心的核心组成部分，资源池采用的是 “集中管理，统一分配” 的资源管理原则，所有的用户数据统一存放在资源池中，对应了HDCS的物理层和虚拟化层，是构建HDCS的基础。

物理层 包括 服务器主机、交换机设备、共享存储路由设备、路由器设备 等所有构成资源池的硬件设备，这些硬件设备共同向上层提供基础资源。

虚拟化层 的作用在于 使用不同的虚拟化技术对物理层提供的资源进行池化，分别创建计算池、存储池和网络池，这三种池整合在一起共同组成资源池，统一向上层提供虚拟资源。

管理层 用于 对整个虚拟机的运行环境进行管理，主要包括对虚拟机的管理以及资源的管理。这部分是系统的核心，负责响应服务接口层的调用，完成对用户请求的处理和响应，在系统中起到承上启下的作用。

服务接口层 用于 为上层应用的业务系统提供服务接口，采用统一的API供上层应用的业务系统进行调用，方便上层应用基于HDCS进行二次开发。此外，服务接口层还用于统一接受用户请求，对请求进行封装，然后根据请求的类型传给相应的管理层模块进行处理。

监控模块 用于 对云服务端的运行环境进行监控，收集系统运行状态的数据，当系统负载达到警戒值时自动发出警报，提高系统运行的健壮性。

3.3 架构引申的问题与解决方案

3.3.1 两层管理问题

1. 问题：需要对虚拟机和虚拟资源区分域节点层面和服务器节点层面进行两层管理。
2. 解决方案：采用 两层调度模式 和 两层迁移模式 对虚拟机和虚拟资源进行管理。
3. 设计优点：两层调度模式 使虚拟机调度变得可控，并大幅提高了虚拟机调度的 高效性、灵活性以及可扩展性。

3.3.2 资源配置冲突问题

1. 问题：由于采用多个子服务进程并发处理请求，会导致虚拟机的端口和MAC地址等资源在分配时发生冲突，因此需要采用适当的机制进行处理。
2. 解决方案：（1）端口冲突解决：对虚拟机的端口采用全局配置，然后按照域节点划分端口区间，系统采用 “同步申请，异步回收” 的策略来申请和回收端口。（2）MAC冲突解决：虚拟机的MAC地址是子进程在创建虚拟机时通过随机函数动态生成的，但由于多个子进程并发执行，有可能导致所生成的MAC地址一样。为避免多个子进程使用相同的随机种子，子进程将使用当前的时间戳加上该进程的进程号作为随机种子，这样哪怕不同的子进程并发创建虚拟机，所分配的MAC地址也将不相同。
3. 设计优点：解决了分配虚拟机的端口和MAC地址等资源的冲突问题，促使多个子服务进程能够并发处理用户请求，提高处理效率。

3.3.3 同一虚拟网段IP分配受限和IP冲突问题

1. 问题：多台服务器节点并发采用同一虚拟网段为虚拟机动态分配IP地址，有可能会造成IP冲突问题，并且分配的虚拟机数目将受限于一个虚拟网段所能提供的内网IP数，默认情况下是253台。
2. 解决方案：为每台服务器节点 分配一个独立的虚拟网段，当新增一台服务器节点时，从空闲的虚拟网段中为其分配一个IP地址，这样能够避免多台服务器节点的IP冲突问题。另外，为了支持超级服务器，在创建虚拟网段时修改其掩码，使每台服务器节点能够支持多达上千台虚拟机的IP分配。
3. 设计优点：通过对虚拟网段进行范围扩展，使每个虚拟网段能够支持上千台虚拟机。通过为每天服务器节点分配不同的虚拟网段，避免了IP冲突问题。

3.3.4 节点加入和退出检测问题

1. 问题：由前面设计可知，可以通过为域节点添加服务器节点，或者通过添加域节点这两种方式来扩展系统规模，但系统需要能够实时检测到节点的加入和退出，并同时需要更新资源池的容量大小。
2. 解决方案：为服务器设计一个守护进程，在部署服务器节点的时候运行，该守护进程收集域节点信息并计算其能力值，然后将这些数据发送给管理节点注册加入，管理节点认证通过后在数据库中更新该域节点对应的资源池的相关信息，并返回确认消息。通过TCP套接字的Keep-Alive机制与关节节点维持心跳检测，当服务器节点退出时断开连接，从而管理节点能够实时获知服务器节点的退出。
3. 设计优点：以守护进程的方式实现节点的动态加入和退出检测，并实时更新资源池的容量信息，实现服务器节点的 “即插即用” 功能。

3.3.5 资源释放与回收问题

1. 问题：由于将桌面的展示和运行环境解耦，虚拟桌面真正运行于服务器节点中，用户在使用完虚拟桌面以后有可能直接关闭终端上的客户端界面，而没有关闭虚拟机，这将导致虚拟资源没有被及时释放，降低资源的利用率。
2. 解决方案：提供虚拟资源的自动回收机制，针对用户使用虚拟机的状态进行监控，如果用户没有对虚拟机执行任何操作或者虚拟机没有执行任何用户进程，当达到一定的时间，则自动对虚拟机所占用的资源进行释放，并回收到资源池中。
3. 设计优点：当虚拟机没有被用户使用时，能够及时释放虚拟机所占用的资源，从而提高资源的利用率。

3.3.6 USB设备重定向问题

1. 问题：基于VDI技术架构实现的桌面云架构，如果没有提供对USB设备重定向的支持，则运行在数据中心的服务器上的虚拟机无法读取和写入插在客户端终端设备中的USB设备。
2. 解决方案：采用SPICE框架实现混合型桌面云服务端架构USB设备重定向，通过SPICE传输协议传输USB设备信息。在服务器节点创建虚拟USB设备，对该虚拟设备的操作被虚拟驱动通过传输协议传输到客户端设备，客户端设备收到请求后，发送相应的操作指令给USB设备，最后通过传输协议把操作结果返回给服务端，服务端再通过虚拟驱动将结果传达给虚拟USB设备。
3. 设计优点：可根据用户业务场景的需要决定是否为虚拟机添加对USB重定向的支持，这种设计方式能满足不同业务场景的需求，提高灵活性。对于某些具有政策和规定限制的场景，可以禁用该功能，使用户无法通过USB设备从虚拟桌面中拷贝数据，而对于学生上机实验等场景，则可以为他们添加这一功能，使得学生可以拷贝实验资料。

3.4 功能结构与模块设计

从功能的角度可将系统从整体上分为 虚拟机管理、虚拟资源管理、系统监控 三大模块，每个模块可进一步细分为多个子模块。

虚拟机的管理模块 包括 虚拟机运行状态的管理、虚拟机调度、虚拟机的克隆、虚拟机/镜像迁移、虚拟机对USB重定向的支持，以及虚拟机的并发启动 六个子模块。

资源的管理模块 包括 资源的调度与分配、资源的释放与回收、资源的备份与恢复 等子模块。

监控模块 是独立于管理层的模块，包括 对虚拟机运行状态的监控和集群运行环境的监控 等功能。

系统的功能结构如图 3-5 所示。

3.5 系统类图设计

系统在软件实现上主要包含六大部分的类，分别是 -

• 虚拟机 相关的类
• 存储池 相关的类
• 网络 相关的类
• 资源管理 相关的类
• 监控 相关的类
• 迁移调度 相关的类

这些类的设计采用了面向对象的设计思想，在基于 Libvirt 库的基础上，将所依赖的 Libvirt 库对象作为自定义类的成员，并对使用到的 Libvirt 库函数进行二次封装，提供完整的逻辑处理。

3.6 本章小结

本章首先对 混合型桌面云架构 进行总体架构设计并归纳了该架构的主要特点，包括 系统整体架构设计、逻辑架构设计、功能结构与模块设计、系统核心类设计 等，为后面的具体实现打下了基础。然后针对该架构设计中引申出的一系列问题进行详细分析，并给出了相应的解决方案。

第四章 详细设计与实现

4.1 节点的动态加入和退出

混合型桌面云架构要实现动态的伸缩性，需要能够识别出服务器节点的动态加入与退出，系统通过设计和实现Vmm-Node守护进程来提供这一功能。

在部署服务器节点时，每台服务器节点都需要通过交换机的方式或直连的方式连接到共享存储设备，属于同一个域结点的服务器节点连接到同一台共享存储设备。在共享存储设备中除了存放域结点的配置文件和其他用户相关的数据以外，还存放了 Vmm-Node 可执行文件。当部署好服务器节点后，需要在新部署节点中运行存放在共享存储设备中的 Vmm-Node 可执行文件，Vmm-Node 守护进程将运行于每台服务器节点，在 Vmm-Node 初始阶段将通过 TCP 套接字向代理服务器的后台管理程序（ Vmm-Server ）发起注册申请。

如图 4-1 所示，数据中心中有两个域结点 A 和 B，此时域结点需要添加一台服务器节点 C 对资源池进行扩容，此时服务器节点 C 首先需要连接到域结点 A 的共享存储设备上，然后读取并运行 Vmm-Node 程序。Vmm-Node 程序首先对系统初始化，然后计算服务器节点 C 的 Capacity（能力值，用于衡量服务器节点或域结点能够同时运行虚拟机数目的最大值），并通过 TCP 套接字将服务器节点的配置信息以及 Capacity 值等数据共同发送给 Vmm-Server 进行注册。注册成功后 Vmm-Server 将更新域结点的 Capacity 值以及资源池信息，并发送一个确认包给 Vmm-Node 进行确认，然后 Vmm-Node 和 Vmm-Server 之间将通过 TCP 的 KeepAlive机制维持心跳检测，一旦因为断网原因或者服务器节点主动退出，Vmm-Server都能动态检测到并更新域结点的 Capacity 值和资源池信息。

4.2 数据中心容量计算

计算服务器节点的 Capacity 值，需要考虑服务器的多个 性能指标，主要包括 CPU性能、内存性能和虚拟机的性能配置。其中 CPU性能 涵盖了 CPU的主频、处理器个数、每个处理器的核数、所支持的最大虚拟CPU个数、每个处理器所支持的最大线程数 等因素。