我正在阅读一些technet文章，以及关于VMware和hyper v做CPU调度方式的区别。
我想知道如果我能得到这方面的一些客观的信息。 看起来，VMware使用的团队调度是一个巨大的缺点，但我不想只喝coolaid。 它是否会严重影响性能，或者VMware最新版本的最新版本能够解决这个问题？
编辑：当我说劣势我的意思是相对于Hyper V的“免费处理器调度”或KVM做到这一点。 我正在阅读的资料并没有说“免费的处理器调度”有什么问题可以通过帮派调度来避免。
像吟诵血腥玛丽成为一个黑暗的浴室镜子，让我们看看我们是否可以让杰克Oshins出现…
团队调度也被称为协同调度。 我认为VMware更喜欢将协同调度这个术语用于帮派调度。
在版本3.x之前的ESX版本中，VMware使用“严格的”共同调度，这具有同步的缺点。 在ESX 3.x及更高版本中，VMware切换到“放松”的共同调度。
宽松的共同调度取代了ESX 3.x中严格的共同调度，并在后续版本中进行了改进，以实现更高的CPU利用率并支持广泛的多处理器虚拟机。 与严格的共同调度algorithm相比，宽松的共同调度有一些独特的性质。 最重要的是，在严格的协同调度algorithm中，存在滞后的vCPU会导致整个虚拟机器被共同停止。 在宽松的协同调度algorithm中，一个领先的vCPU根据对最慢的同级vCPU的偏差来决定是否应该自己共同停止。 如果偏差大于阈值，则主要的vCPU将自行停止。 请注意，滞后的vCPU比最快的同级vCPUless得多，而领先的vCPU比最慢的同级vCPU明显多。 通过跟踪最慢的兄弟vCPU，每个vCPU现在可以独立地做出自己的共同调度决策。 像一站式，共同启动的决定也是单独做出的。 一旦最慢的同级vCPU开始进行，共同停止的vCPU就有资格共同启动，并可以根据pCPU可用性进行调度。 这就解决了严格的共同调度algorithm中的CPU碎片问题，不需要一组vCPU一起调度。 在前面的4- vCPU虚拟机示例中，即使只有一个空闲的pCPU可用，虚拟机也可以继续前进。 这显着提高了CPU利用率。
上面的代码片段来自VMware自己的文档 。
所以VMware不再使用严格的安排。 我会直接从供应商处理文档作为更权威的。
唯一会给你带来难题的是一个基准testing，它将完全依赖于CPU正在运行的代码种类。 但是我可以告诉你，如果VMware处于劣势，那么他们在虚拟化市场上的份额依然不会太大。
好的，瑞安，你做了我的一天。 我不像以前那样阅读这个论坛，但是我恰好在办理登机手续。
Red888，你应该知道我是一名软件架构师，在微软的Hyper-V上工作。 我想大多数人阅读这个是完全有能力点击我的名字下面这个链接，并发现，甚至谷歌search，但对于这个答案是有用的，可以肯定的是，读这个人是毫无疑问的我的观点。
一般来说，如果pipe理程序没有任何方法来影响在VM内运行的操作系统的行为，那么排定日程安排很有用。 这当然是VMware为什么要这样开始的。 他们不拥有任何操作系统，所以他们的目标是使现有的操作系统运行良好。 如果我是他们，这是我会开始的地方。
Gang调度和VMware可能会说我是对的，在如何使用机器内的物理处理器方面有很多限制。 pipe理程序通常无法find适合当前的资源。 所以他们多年来一直在修改他们的algorithm，寻找更好地工作的调度方法。
微软（可能还有其他几家公司）以不同的观点出发。 我们拥有Windows。 虚拟化后，我们将使Windowsperformance良好。 因此，帮派安排将不是必要的。 我们甚至不打算build立一个帮派调度员。
有趣的是，我们微软更关心的是Windows相对于其他操作系统运行得更好，而不是我们关心的Hyper-V比VMware，KVM，Xen，Oracle，Unisys等更好。因此，我们发布了Windows用于与pipe理程序合作。 如果你好奇，这里有一个链接，虽然我不推荐它作为睡前阅读：
因此，任何虚拟机pipe理程序供应商都可以暴露将触发Windows合作行为的内容。 其中有几个。 我真的不知道VMware是否已经或将会公开这一点。 你不得不问他们，或者是一个很重视他们的人。 如果他们这样做，如果他们没有改变他们的调度员放松更多，我会非常惊讶。 最后一个陈述当然是纯粹的猜测。
所以我的底线答案是，我怀疑你应该根据pipe理程序调度程序的工作原理在2014年做出购买决定。 我怀疑他们现在都很好。 几年前，这可能不是真的。
你应该在各种系统上尝试你的工作负载，看看它们是如何工作的。 我敢打赌，你的最终性能取决于你的存储和networking是否满足你的需求。