oVirt虚拟化关键概念、组件与技术原理

云管理平台组-陈志安

1. 介绍

1.1. ovirt-engine

ovirt-engine为虚拟化环境提供了一个集中管理的平台，用户可以根据具体的需求选择使用不同的方式来访问ovirt-engine。

ovirt-engine架构图如下：

• 应用服务器（ovirt-Wildfly）

Wildfly是一个JavaEE应用服务器，但是需要注意的是部署ovirt-engine所需要的wildfly是特殊定制过的，因此您不能将其它应用部署在这个为ovirt-engine专门定制的wildfly上，为了便于与通用版本区分开来，本文档后续将定制版本统称为ovirt-wildfly。

• 用户门户（User Portal）

桌面系统虚拟化为用户提供了一个近似于物理PC的桌面系统。用户可以使用网络浏览器来访问用户门户，并通过用户门户来访问分配给他们的虚拟桌面资源（SPICE/VNC）。系统管理员需要为每个用户设定他们可能访问的资源及相关权限。User Portal的用户有两种类型：标准用户、高级用户。标准用户可以启动、停止和使用分配给他们的虚拟桌面（无法编辑虚拟机配置），而高级用户则还可以执行一些额外的管理任务（如创建、删除、编辑虚拟机，管理虚拟磁盘和网络接口等）。

• 管理门户（Admin Portal）

管理门户是ovirt-engine的一个图形管理界面。管理员可以通过该管理界面来监控、创建并维护整个ovirt虚拟环境中的所有资源（计算、网络、存储）。通过管理门户可执行如下操作：

• 创建和管理虚拟基础架构（网络、存储域）
• 创建和管理虚拟机
• 创建和管理逻辑项（数据中心、集群）
• 安装和管理计算节点（虚拟主机）
• 用户权限管理

详细的使用文档请查阅官方文档。

oVirt持续集成方案分析

云管理平台组-陈志安

1. STDCI

oVirt项目定义了一套标准规范，通过这套标准，一个源码工程就可以一种通用的方式定义其应该如何被构建、测试、部署与发行，而这个定义规则是独立于开发该源码工程所使用的编程语言及工具，本质上讲它是由oVirt制定的适用于CI/CD(持续集成/持续部署)的DSL(Domain Specific Language)，这套规范简称为STDCI。

CI团队可以基于这套标准创建像mock_runner这一类通用的构建、测试、部署与发行工具，这些工具以统一的方式来处理所有的ovirt工程。

oVirt项目的持续集成系统（CI系统）就是使用这套标准以自动化的方式执行该项目下各个工程的构建、测试、部署、发行进程。

该规范的实现请参考：https://github.com/oVirt/jenkins/tree/master/scripts

1.1. Stage

STDCI中的一个核心概念是“stage”，State是指作用在变更过的源码上的各种操作，它代表了源码从开发人员初始创建到成为正式发布产品整个生命周期的各个阶段。在每个特定的stage会执行一系列与该stage相关的各种操作（命令），这些操作命令是由每个具体工程定义。

当前STDCI定义了如下几个常用的stage：

• build-artifacts：该阶段定义了如何从源码构建出用户可使用的归档文件，比如RPM包或Docker镜像之类的文件。
• build-artifacts-manual：该阶段主要定义了如何从tar格式的源码包进行项目构建，一般在人工处理的方式进行正式版本发布时会涉及到该阶段，比较少用。
• check-patch：这个阶段定义了当代码发生变更时如何进行代码质量、功能或回归验证。一般是用户在Github等平台上发起PR请求会触发与该阶段关联的操作。
• check-merged：这个阶段定义了当代码发生变更时如何进行代码质量、功能或回归验证。一般是分支合并操作后会触发与该阶段关联的操作。
• poll-upstream-sources：有时项目会依赖的上游或外部项目或库，该阶段主要定义了上游或外部依赖项目的更新操作。

ovirt-engine开发环境搭建指南

云管理平台组-陈志安

中文

提示：为了能比较顺畅的阅读本文档，您需要具体基本的docker基础知识及常用命令的使用。如果您尚未听说过docker，则请先通过docker官方文档学习必要的知识。

重要说明：在windwos下存在以下需要注意的细节

• 在docker中创建的一些特殊文件，在外部主机上无法马上删除，需要重启外部主机，详见这里
• 如果将docker中的目录通过volumn参数映射至windows本地目录时，docker中的链接文件在windows的文件系统下是无法生效的，详见这里

1. 快速入门

制作本镜像的主要目的：快速创建并启动一个近似于本地的ovirt-engine容器，它可以为有需要的开发人员（特别是基于windows平台）提供近似于本地的开发、测试、调试环境。

1.1. 先决条件

• 安装Docker运行环境，docker分企业版与社区版，我们只需要社区版即可，具体可参考Docker官网文档。

由于Windwos系统的特殊性，建议在Windows-10专业版或企业版（64位）系统上安装Docker for windows（直接基于Windows Hyper-V）;
而之前的Windows版本则需要使用Docker Toolbox on Windows（需要借助Oracle Virtual Box）。

在Windwos上激活Hyper-V意味着无法同时运行Virtual Box与VMWare workstation等其他虚拟化平台

1.2. 构建ovirt-engine镜像

如果您想自己定制一个新镜像，您才需要使用本节介绍的内容。正常情况下，您可以忽略本节内容。

1
2
3

# 假设工作目录为：~/workspace/Dockerfiles，要创建的镜像名为：simiam/ovirt-engine-dev
cd ~/workspace/Dockerfiles/ovirt-engine
docker build -t simiam/ovirt-engine-dev ./latest

1. 基础概念

本文先简单介绍下与分布式系统相关的几个概念。

1.1. 分布式锁

所谓分布式锁是指在一个分布式集群中，同一个方法在同一时间只能被一台机器上的一个线程执行，也就是所谓的分布式互斥。就像单机系统上的多线程程序需要用操作系统锁或数据库锁来互斥对共享资源的访问一样，分布式程序也需要通过分布式锁来互斥对共享资源的访问。分布式锁是保障数据一致性的手段之一。
一般情况下，我们可以使用数据库、Redis或者ZooKeeper来做分布式锁服务。不管怎么样，分布式的锁服务需要有以下几个特点：
1）安全性：在任意时刻，只有一个客户端可以获得锁（排他性）
2）避免死锁：客户端最终一定可以获得锁，即使锁住某个资源的客户端在释放锁之前崩溃或网络不可达
3）容错性：只要锁服务集群中的大部分节点存活，客户端就可以进行加锁解锁的操作

即分布式锁服务在实现上一般关注如下三个问题：
1）锁获取机制：超时释放导致多方获取同一把锁问题（CAS机制）
2）锁释放机制：正常释放、超时释放
3）客户端如何知道锁被释放：客户端不断重试、服务端主动通知

1.2. 数据一致性

说起数据一致性，简单说有三种类型：
1）Weak（弱一致性）：当你写入一个新值后，读操作在数据副本上可能读出来，也可能读不出来。比如：某些cache系统，网络游戏其它玩家的数据和你没什么关系。
2）Eventually（最终一致性）：当你写入一个新值后，有可能读不出来，但在某个时间窗口之后保证最终能读出来。比如：DNS，电子邮件、Amazon S3，Google搜索引擎这样的系统。
3）Strong（强一致性）：新的数据一旦写入，在任意副本任意时刻都能读到新值。比如：文件系统，RDBMS，Azure Table都是强一致性的。

从这三种一致型的模型上来说，我们可以看到，Weak和Eventually一般来说是异步冗余的，而Strong一般来说是同步冗余的，异步的通常意味着更好的性能，但也意味着更复杂的状态控制。同步意味着简单，但也意味着性能下降。

1. What?

正如Jack Reecves所发表的《源码就是设计》：源码就是最好软件设计文档，而其他非代码性的文档只是源码的辅助。本文并非为了讨论编程与软件设计的关系，只想借以说明源码的重要性。

简单讲，整洁代码行云流水如同阅读精美好文，代码能够尽可能的自解释；具体讲，整洁代码具备如下特性：

• 变量、函数、类、包、模块命名合理有意义
• 代码结构（格式）清晰
• 必要的合理的注释信息：代码能自解释只是理想，该注释的地方还是免不了
• 合理的异常处理机制
• 有效的日志信息
• 遵循面向对象设计原则