红帽工程师 Theron Conrey 谈 oVirt，OpenStack 与 VMware

oVirt 是一个虚拟化管理软件的开源项目。该项目起源于 Qumranet，该公司在 2008 年被红帽收购之后，其原有的虚拟化管理软件被从 C#改写为 Java，并在 2011 年开源为 oVirt 项目。2011 年 11 月初，红帽在思科公司举办了第一次oVirt 研讨会（oVirt Workshop），与IBM、英特尔、思科、Canonical、NetApp 与SUSE 一同宣布oVirt 社区的成立。

利用oVirt 管理KVM 虚拟机和网络，企业可以快速的搭建起一个私有云环境。从这一点看来，oVirt 的定位和另一个知名云计算项目OpenStack 的定位是有些类似的。不过有意思的是，oVirt 实际上是红帽的企业级虚拟化解决方案RHEV 的上游项目，而这些支持oVirt 项目的厂商们，也同时是OpenStack 项目的参与者。为什么要同时支持两个目标有所重合的云计算项目？企业可以利用oVirt 实现什么？

今年的5 月8 日到9 日，下一场 oVirt 研讨会将在上海英特尔研发中心举办。InfoQ 编辑借此机会联系到了本次活动的联络人 Theron Conrey ，邀请他对 oVirt 项目进行一个简单的介绍。Theron Conrey 目前效力于红帽开源与开放标准团队（Open Source and Standards Team），关注云计算，虚拟化与存储相关领域。在加入红帽之前，Conrey 就职于 Nexanta，提供 vCloud、CloudStack、OpenStack 相关的解决方案，并实施过多个 VMware ESX 相关的项目。Conrey 的个人博客是 conrey.org。

InfoQ：红帽同时在 OpenStack 和 oVirt 上投入相当大的研发精力，而这两个项目在某些方面是极为类似的。目前我们知道，OpenStack 项目的定位是建立数据中心级别的 IaaS 公共云服务，然而对于 oVirt，可能很多人还不是很了解。能否介绍一下 oVirt 的应用场景是怎样的？

Conrey：你提到的定位是很重要的一点。是的，红帽在 OpenStack 和 oVirt 这两个项目上都进行了非常多的投入。不过，不仅仅是红帽在这样做：思科，IBM，Intel，NetApp 和其他一些企业都在同时对两个软件项目进行投入——我们对两个项目的价值都非常看重。

一眼看上去，这两个项目的确有重合之处，这使得我们很容易认为部署了其中一个软件的用户就不需要另外一套软件了。而事实并非如此。

如果你正在为大型企业或多数据中心级别的用户进行部署，这两个软件栈可以很好的进行互补。当然，并非所有的 oVirt 部署都需要 OpenStack，也不是所有的 OpenStack 部署都能够从 oVirt 部署中获益，不过在很多情况下，这两个软件的互补是很有用的，这正是红帽和其他支持 oVirt 的公司同时关注两个项目的重要原因。

纯 oVirt 部署在很多情况下是用于以前 VMware vSphere 类型的应用场景。也有的用户看中了 oVirt 中 vSphere 没有的一些特性，如自助式的门户管理网站。对于红帽而言，一方面 oVirt 集成了 KVM 中最细节的特性，另一方面 oVirt 是 RHEV 的上游项目，所以让 oVirt 更加容易部署、更加安全、更加可维护、可获取支持，是红帽非常看重的。

InfoQ：oVirt 在设计上可以支持多大的集群？

Conrey：oVirt 可以轻松地扩展到上百个节点的规模。可以支持的 VM 的数量取决于该集群运行怎样的任务。

InfoQ：oVirt 在资源消耗方面表现如何？

Conrey：用于管理的 oVirt engine 组件一直在致力于变得更加容易使用，比如网络配置选项中的拖拽功能：点击，拖拽，完成配置。跟其他数据中心级别的虚拟化管理解决方案一样，oVirt 在不同规模的部署下需要的资源也不尽相同。我们建议用户在规划之前查看相关文档。

InfoQ：在稳定性和安全性方面，oVirt 又表现如何？

Conrey：怎么说呢，最简单的答案当然是“看情况”，不过这并不是个好答案。对于任何一个用于管理基础架构的软件栈而言，无论是 vSphere 还是 oVirt，最基础的一个组件是应用层之下的服务器操作系统。操作系统本身的安全性和稳定性往往要高于应用软件本身的安全性和稳定性。这涉及到你如何配置你的操作系统和软件，是否遵循了最佳实践等等。目前在社区里成功部署 oVirt 的案例中，很多种操作系统都出现过，重要的是提供支持的公司是否值得信赖。在 oVirt 这个领域有很多优秀的工程师，对各方面的最佳实践都非常了解。

InfoQ：前一段时间我们看到了一位 oVirt 用户的吐槽，认为 oVirt 跟 VMware 的成熟方案相比，还有不少问题，包括：总是崩溃，很多 bug，web UI 不够友好，没有对 CPU 和内存很精细的调节限制功能，容错不够强大，性能查看及数据过于简单，且不支持分布式交换机等。你对于这位用户的吐槽有什么看法吗？

Conrey：首先我想说的是，我很希望帮助这位用户！在不知道具体配置——包括系统打了哪些补丁、使用了哪个 oVirt 版本等等——的情况下，崩溃和 bug 的问题我很难具体去帮他解决。我们的 bug 跟踪系统是开放的，如果用户碰到任何 bug，我们鼓励大家去这个系统上作报告！

作为社区驱动的上游项目，能够让用户将其与 VMware 的产品进行比较，其实是非常棒的事情。

在 OpenStack 的模式下，红帽最近公布了一个叫做 RDO 的上游社区项目。RDO 纯粹针对 OpenStack，其中绑定的 OpenStack 代码完全来自上游，不经过任何修改。红帽做的事情是，在这个源代码的基础上进行加固，为红帽的客户提供 RHOS。RHOS 是产品，而 RDO 项目也会一直公开。

项目与产品的区别可能不太容易识别，但这区别非常重要。oVirt 项目的开发工作和发布都是开放的。对于商业产品的用户而言，这可能会有些迷惑。对于部署 oVirt 的用户而言，他们可能期待这是一个稳定的发布，在一个稳定的操作系统上运行。稳定性对他们而言可能要比 oVirt 有哪些特性更加重要。我们的建议是，参加 IRC 频道的讨论，注册邮件群组，了解如何从社区获得帮助。如果你在 oVirt 方面的经验不足，但是又想要 VMware 级别产品的一些功能特性（如容错和分布式交换机），那么可以考虑一下 RHEV。

我觉得有关分布式虚拟交换机的吐槽是一个很有趣的特性请求。oVirt 项目本身的分布式虚拟交换机的特性基本上不会进行特别多的推进——事实上，我们在 ovirt.org 官网上介绍了一个用法，就是用 oVirt 配合 Quantum 网络组件来实现很多的网络功能。这样的集成不仅对 open vSwitch 项目有利，同时也促进了 Quantum 项目的发展。

InfoQ：您认为 oVirt 在未来一年的时间内会发展的足够稳定么？

Conrey：在很多场合下，现在的 oVirt 已经足够稳定了。我希望这位用户和其他对 oVirt 项目感兴趣的用户能够更多的参与到社区当中来，一起决定项目前进的方向。

希望能够在 5 月 8 号到 9 号的 oVirt 研讨会上跟大家多多交流！