当虚拟化刚出现时，我们尝试将一切虚拟化，但随后我们注意到，在某些情况下，我们的虚拟机比裸机慢得多。
对于我们来说，在决定不进行虚拟化时，我们会使用以下规则：
- 网络 IO 密集型应用程序（即具有许多中断/数据包）
- 磁盘 IO 密集型应用程序（如果不在 SAN 存储上）
- 占用大量内存（这是最宝贵的资源）
我们在使用 Xen 和 DRDB 以及 Hyper-V 与 DAS 的无共享功能时有过这样的经历。所有虚拟机管理程序都是这种情况吗？
当决定是否虚拟化应用程序/服务器时，我应该寻找哪些（其他）指标？
答案1
您已经触及问题中的主要指标：
网络输入输出
您需要确保所提出的虚拟化工作负载不会使主机系统的网络连接饱和。在 10Gbit NIC 盛行的今天，对于大型企业来说，这不再是一个问题，而小型企业通常可以从千兆（或组合/聚合千兆）NIC 获得所需的性能。磁盘输入输出
您需要确保您的磁盘子系统（本地磁盘、SAN、NAS）能够处理您提议的磁盘 I/O。
在确定大小时，请记住您的 SAN 结构（交换机等）也需要能够处理负载 - 您可能拥有一个超级 SAN 存储系统，可以向其磁盘推送每秒兆兆位的数据，但如果这个庞然大物连接到一个糟糕的 100Mbit iSCSI 结构，您的网络就会在存储设备出汗之前饱和。内存
更具体地说是“活动”RAM（因为非活动内存可能会被虚拟机管理程序交换出去，但没有人会注意到）。理想情况下，您拥有足够的物理 RAM，虚拟机管理程序无需交换。实际上，您可能会找到一种过度使用的最佳方法。
其他需要考虑的事项：
CPU（和工作负载模式）
如果您有一堆执行 CPU 密集型任务的系统，如果它们同时争抢主机系统的处理器，您可能会遇到麻烦。（例如，如果您有 1 个主机 CPU 和 3 个虚拟机，它们都想在午夜进行数字运算，则每个虚拟机只能看到主机 CPU 性能的约 1/3，因为虚拟机管理程序会尝试在它们之间分割争夺的资源）。
另一方面，如果您有一堆在不同时间执行 CPU 密集型任务的系统（例如午夜、凌晨 3 点和早上 6 点，并且总是在下一个人开始之前完成），您可以虚拟化它们，它们永远不会知道其中的区别。定制硬件
某些虚拟机管理程序（如 VMWare）允许 PCI 和存储直通。其他虚拟机管理程序可能不允许。
如果您需要访问主机上的硬件（如显卡或直接磁盘访问），则需要在规划虚拟化时考虑到这一点。计时
虚拟机管理程序在这方面已经做得更好了，但精确计时任务仍然更适合专用物理服务器。例如，您组织的主要 NTP 服务器应该是物理主机（或路由器，如果您的路由器能够充当 NTP 服务器）。通常无法很好地虚拟化的东西
关于这一点有很多传闻数据，所以在虚拟化之前要做一些研究。
举几个例子，我上面提到的计时问题、VOIP 系统（如 Asterisk PBX）和使用频繁的数据库通常不适合虚拟化（前两个是因为计时精度问题，数据库通常是因为比其他工作负载更容易引起资源争用）。
每家公司都会收集一份他们知道无法虚拟化的事物的本地列表——当你找到你的项目时，一定要把它们记录下来（包括原因，以防有一天你得到一个可以解决问题的虚拟机管理程序）。
答案2
正如评论中指出的那样，并非所有虚拟化软件都是相同的。
http://wiki.openvz.org/FAQ#What_is_the_performance_overhead.3F
性能开销是多少？几乎为零。没有模拟层，只有安全隔离，所有检查都在内核级别完成，无需上下文切换。
绩效期望是什么？当只有一个容器有活动任务时，性能会达到最佳。在这种情况下，它可以使用 100% 的可用资源：所有 CPU、所有物理内存、所有磁盘和网络带宽。OpenVZ 不会将您限制在单 CPU 虚拟机上。
虽然这可能感觉像是一个非答案：没有一概而论的情况不允许使用虚拟化。我现在习惯于只使用 1 个 OpenVZ 容器部署硬件：由于虚拟化本身提供的硬件抽象，使用提供的工具迁移它们非常容易。作为一个小小的副作用，软件许可证成本通常也更便宜。