Conrey：你提到的定位是很重要的一点。是的，红帽在OpenStack和oVirt这两个项目上都进行了非常多的投入。不过，不仅仅是红帽在这样做：思科，IBM，Intel，NetApp和其他一些企业都在同时对两个软件项目进行投入——我们对两个项目的价值都非常看重。
一眼看上去，这两个项目的确有重合之处，这使得我们很容易认为部署了其中一个软件的用户就不需要另外一套软件了。而事实并非如此。
如果你正在为大型企业或多数据中心级别的用户进行部署，这两个软件栈可以很好的进行互补。当然，并非所有的oVirt部署都需要OpenStack，也不是所有的OpenStack部署都能够从oVirt部署中获益，不过在很多情况下，这两个软件的互补是很有用的，这正是红帽和其他支持oVirt的公司同时关注两个项目的重要原因。
纯oVirt部署在很多情况下是用于以前VMware vSphere类型的应用场景。也有的用户看中了oVirt中vSphere没有的一些特性，如自助式的门户管理网站。对于红帽而言，一方面oVirt集成了KVM中最细节的特性，另一方面oVirt是RHEV的上游项目，所以让oVirt更加容易部署、更加安全、更加可维护、可获取支持，是红帽非常看重的。

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

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

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

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项目的发展。

Conrey：在很多场合下，现在的oVirt已经足够稳定了。我希望这位用户和其他对oVirt项目感兴趣的用户能够更多的参与到社区当中来，一起决定项目前进的方向。
希望能够在5月8号到9号的oVirt研讨会上跟大家多多交流！
原文：http://www.infoq.com/cn/news/2013/05/conrey-on-ovirt
参考：
http://www.ovirt.org/
http://www.ocselected.org/