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研讨会上跟大家多多交流！