当虚拟化是新的，我们试图虚拟化一切，但是我们注意到我们的虚拟机比裸机慢得多的用例。
对于我们而言，在决定不虚拟化时，我们使用以下规则：
我们已经有了Xen和DRDB的经验，以及Hyper-V与DAS的共享。 所有pipe理程序都是这种情况吗？
当决定虚拟化应用程序/服务器时，我应该寻找哪些（其他）度量标准？
你已经达到了你的问题的主要指标：
networkingIO
您希望确定您提议的虚拟化工作负载不会使主机系统的networking连接饱和。 在10Gbit网卡的这些日子里，这对于大型企业来说不是什么问题，小企业通常可以从千兆位（或合并/聚合千兆位）NIC获得所需的性能。
磁盘IO
您需要确保您的磁盘子系统（本地磁盘，SAN，NAS）可以处理您提出的磁盘I / O。
当考虑到这一点时，您的SAN光纤（交换机等）也需要能够处理负载 – 您可能有一个可以将每秒兆兆比特推到其磁盘的超级SAN存储系统，但是如果那个怪物连接到一个糟糕的100Mbit iSCSI结构，在存储设备出汗之前就会使networking饱和。
内存
更具体地说，“主动”RAM（因为不活动的东西可能被pipe理程序换出，没有人会注意到）。 理想情况下，您有足够的物理内存，pipe理程序不需要交换。 事实上，你可能会find一个过度承诺的快乐媒介。
其他人要考虑：
CPU（和工作负载模式）
如果你有大量的CPU密集型任务的系统，如果他们都在同时争吵主机系统的处理器，可能会遇到麻烦。 （例如，如果您有一个主机CPU，并且有三个虚拟机都想在午夜时间处理数字，那么每个虚拟机只会看到主机CPU性能的1/3，因为pipe理程序试图拆分它们之间的争用资源）。
另一方面，如果你有一堆系统在不同的时间执行CPU密集型任务（比如午夜，上午3点和上午6点，并且总是在下一个开始之前完成），你可以虚拟化它们，知道区别。
自定义硬件
一些pipe理程序（如VMWare）允许PCI和存储传递。 其他人可能不会。
如果您需要访问主机上的硬件（如显卡或直接磁盘访问），则需要在规划虚拟化时考虑这些因素。
计时
虚拟机pipe理程序已经变得更好了，但是精确的计时任务仍然更适合于专用的物理服务器。 例如，您的组织的主要NTP服务器应该是物理主机（或路由器，如果您的路由器能够充当NTP服务器）。
通常不能很好地虚拟化的东西
有很多关于这方面的轶事数据，所以在虚拟化一些东西之前做一点研究。
举几个例子，上面提到的计时问题，VOIP系统（如Asterisk PBX）和高度使用的数据库通常是虚拟化的不好的候选者（前两个是由于计时精度问题，数据库一般是因为它们导致，与其他工作量相比资源争夺受到影响）。
每个公司都会搜集一个他们知道不能虚拟化的东西的本地列表 – 当你发现你的项目确保你logging了它们（包括原因，以防有一天你得到一个解决问题的pipe理程序）。
正如评论中指出的那样，并非所有的虚拟化软件都是平等的。
http://wiki.openvz.org/FAQ#What_is_the_performance_overhead.3F
性能开销是多less？ 接近零。 没有仿真层，只有安全隔离，所有检查都是在内核级完成的，没有上下文切换。
性能预期是什么？ 当只有一个容器具有活动任务时达到最高性能。 在这种情况下，它可以使用100％的可用资源：所有CPU，所有物理内存，所有磁盘和networking带宽。 OpenVZ不会将您限制为单CPU虚拟机。
虽然这可能感觉不到答案：不应该使用虚拟化。 我现在习惯于只用一个OpenVZ容器部署硬件：由于虚拟化本身提供的硬件抽象，使用提供的工具很容易迁移。 作为一个小副作用，软件许可成本通常也更便宜。