我正在阅读一些技术文章以及这个关于 VMware 和 Hyper V 进行 CPU 调度方式的差异。
我想知道我是否可以得到一些关于此问题的客观信息。看来 VMware 使用的群组调度是一个巨大的缺点，但我不想就此罢休。它是否严重影响性能，或者 VMware 的最新版本的虚拟机管理程序是否解决了这个问题？
编辑：当我说缺点时，我指的是相对于 Hyper V 的“空闲处理器调度”或 KVM 的实现方式。我读到的材料并没有说“空闲处理器调度”存在任何问题，而组调度可以避免这些问题。
答案1
就像吟诵血腥玛丽面对光线昏暗的浴室镜子，让我们看看是否能让杰克·奥辛斯出现……
群组调度也称为协同调度。我认为 VMware 更喜欢协同调度这个术语，而不是群组调度。
在 ESX 3.x 之前的版本中，VMware 使用“严格”协同调度，这存在同步缺陷。在 ESX 3.x 及更高版本中，VMware 改用“宽松”协同调度。
宽松协同调度取代了 ESX 3.x 中的严格协同调度，并在后续版本中进行了改进，以实现更好的 CPU 利用率并支持广泛的多处理器虚拟机。与严格协同调度算法相比，宽松协同调度具有一些独特的属性。最重要的是，在严格协同调度算法中，滞后 vCPU 的存在会导致整个虚拟机被共同停止。在宽松协同调度算法中，领先的 vCPU 根据与最慢的兄弟 vCPU 之间的偏差来决定是否应该共同停止自身。如果偏差大于阈值，领先的 vCPU 将共同停止自身。请注意，滞后 vCPU 的进度明显低于最快的兄弟 vCPU，而领先的 vCPU 的进度明显高于最慢的兄弟 vCPU。通过跟踪最慢的兄弟 vCPU，现在每个 vCPU 都可以独立做出自己的协同调度决策。与共同停止一样，共同启动决策也是单独做出的。一旦最慢的兄弟 vCPU 开始运行，共同停止的 vCPU 就有资格共同启动，并可以根据 pCPU 的可用性进行调度。这解决了严格共同调度算法中的 CPU 碎片问题，因为不需要将一组 vCPU 一起调度。在前面的 4 vCPU 虚拟机示例中，即使只有一个空闲的 pCPU 可用，虚拟机也可以向前推进。这显著提高了 CPU 利用率。
上面的代码片段来自 VMware 自己的文档。
因此 VMware 不再使用严格的群组调度。我认为直接从供应商处获取的文档更具权威性。
唯一能给你提供确切数字的就是基准测试，而基准测试完全取决于 CPU 运行的代码类型。但我可以告诉你，如果 VMware 处于如此劣势，那么他们就不会仍然占据虚拟化市场的最大份额。
答案2
好吧，Ryan，你让我很开心。我现在不像以前那么常看这个论坛了，但我还是来看看了。
Red888，你应该提前知道我是一名软件架构师，在微软从事 Hyper-V 工作。我认为阅读本文的大多数人完全有能力点击下面的我的名字链接并发现这一点，甚至在谷歌上搜索我，但对于这个答案，完全确定阅读本文的人对我的观点没有任何怀疑是有用的。
一般来说，如果虚拟机管理程序无法影响虚拟机中运行的操作系统的行为，那么成组调度就很有用。当然，这就是 VMware 以这种方式开始的原因。他们不拥有任何操作系统，因此他们的目标是让现有的操作系统运行良好。如果我是他们，我就会从这里开始。
群组调度（VMware 可能会说我对此是正确的）对如何使用机器中的物理处理器有很多限制。虚拟机管理程序通常无法找到适合当前情况的正确资源。因此，他们多年来一直在修改算法，寻找更好的调度方法。
微软（可能还有其他几家公司）一开始就持有不同的看法。我们拥有 Windows。我们将使 Windows 在虚拟化时表现良好。这样就不需要群组调度了。我们甚至懒得构建群组调度程序。
有趣的是，在微软，我们更关心 Windows 与其他操作系统相比运行得如何，而不是 Hyper-V 是否比 VMware、KVM、Xen、Oracle 或 Unisys 等更好。因此，我们发布了 Windows 用于与虚拟机管理程序协作的接口。如果您感兴趣，这里有一个链接，但我不建议将其作为睡前读物：
因此，任何虚拟机管理程序供应商都可以公开触发 Windows 协作行为的内容。他们中的一些人已经这样做了。老实说，我不知道 VMware 是否已经、正在或将要公开这一点。你必须问他们，或者问那些非常关注他们的人。如果他们这样做了，我会非常惊讶他们没有修改他们的调度程序以使其更加放松。当然，最后这句话纯粹是猜测。
因此，我的底线答案是，我怀疑您是否应该根据虚拟机管理程序调度程序的工作方式在 2014 年做出购买决定。我认为它们现在都相当不错。几年前，情况可能并非如此。
您应该在各种系统上尝试您的工作负载，看看它们如何工作。我敢打赌，您的最终性能取决于您的存储和网络是否满足您的需求。