当虚拟化刚刚兴起时，我们试图将所有东西都虚拟化，但随后我们注意到在用例中我们的虚拟机比裸机慢得多。
对于我们来说，在决定不进行虚拟化时，我们使用以下规则：
- 网络 IO 密集型应用程序（即具有许多中断/数据包）
- 磁盘 IO 密集型应用程序（如果不在 SAN 存储上）
- RAM 密集型（这是最宝贵的资源）
我们在 Xen 和 DRDB 以及 Hyper-V 与 DAS 的无共享方面有过这些经验。所有管理程序都是这种情况吗？
在决定是否虚拟化应用程序/服务器时，我应该寻找哪些（其他）指标？
AskOverflow.Dev
您已经达到了问题中的主要指标：
网络 IO
您希望确保建议的虚拟化工作负载不会使主机系统的网络连接饱和。在 10Gbit NIC 时代，这对于大型企业来说不是什么大问题，小型企业通常可以从千兆（或成组/聚合千兆）NIC 获得所需的性能。
磁盘 IO
您希望确保您的磁盘子系统（本地磁盘、SAN、NAS）能够处理您提议的磁盘 I/O。
在确定大小时，请记住您的 SAN 结构（交换机等）也需要能够处理负载——您可能拥有一个 über-SAN 存储系统，可以每秒将太比特数推送到其磁盘，但如果那个怪物连接到一个糟糕的 100Mbit iSCSI 结构，你会在存储设备出汗之前使你的网络饱和。
RAM
更具体地说是“活动”RAM（因为不活动的东西可能会被管理程序换掉，没有人会注意到）。理想情况下，您有足够的物理 RAM，您的管理程序不需要交换。实际上，您可能会找到一种快乐的过度承诺方式。
其他一些需要考虑的：
CPU（和工作负载模式）
如果您有一堆执行 CPU 密集型任务的系统，如果它们都同时要求主机系统的处理器，您可能会遇到麻烦。（例如，如果您有 1 个主机 CPU 和 3 个虚拟机，它们都想在午夜处理数字，每个虚拟机将只能看到主机 CPU 性能的 ~1/3，因为管理程序试图在它们之间分配有争议的资源）。
另一方面，如果你有一堆系统在不同时间执行 CPU 密集型任务（比如午夜、凌晨 3 点和早上 6 点，并且总是在下一个人开始之前完成），你可以虚拟化它们，它们永远不会知道区别。
自定义硬件
一些管理程序（如 VMWare）允许 PCI 和存储直通。其他人可能不会。
如果您需要访问主机上的硬件（如显卡或直接磁盘访问），您需要在规划虚拟化时考虑到这一点。
计时
管理程序在这方面做得更好，但精确计时任务仍然更适合专用物理服务器。例如，您组织的主要 NTP 服务器应该是物理主机（或者路由器，如果您的路由器能够充当 NTP 服务器）。
通常不能很好地虚拟化
的东西 有很多关于这方面的轶事数据，所以在虚拟化某些东西之前做一些研究。
举几个例子，我上面提到的计时问题、VOIP 系统（如 Asterisk PBX）和大量使用的数据库通常不适合虚拟化（前两个是由于计时精度问题，数据库通常是因为它们导致，并且比其他工作负载更容易遭受资源争用）。
每家公司都会收集一份他们知道无法虚拟化的东西的本地列表——当你找到你的东西时，确保你记录了它们（包括原因，以防有一天你得到一个可以解决问题的管理程序）。
正如评论中所指出的，并非所有的虚拟化软件都是平等的。
http://wiki.openvz.org/FAQ#What_is_the_performance_overhead.3F
虽然这听起来像是一个无法回答的问题：没有任何情况是您不应该使用虚拟化的。我现在习惯于只使用 1 个 OpenVZ 容器部署硬件：由于虚拟化固有地提供了硬件抽象，因此使用提供的工具非常容易迁移它们。作为一个小的副作用，软件许可成本通常也更便宜。