我们正在将虚拟化平台从 Citrix 的 XenServer 迁移到 Windows Server 2008 R2 上的 Hyper-V。作为此项目的一部分，我需要以某种形式将一些 Debian Linux 服务器迁移到 Hyper-V。我已经在我们的新 Hyper-V 平台上成功构建了一个基于 Debian 的服务器，并且正在开始测试它。
Debian 6 (Squeeze) 使用 2.6.32 内核，其中包含 Hyper-V 合成驱动程序，但 Microsoft 不将其视为受支持的客户操作系统。除非有令人信服的理由，否则我不太愿意尝试使用它们，因为其他人遇到了麻烦（这里， 和这里）。
- Hyper-V 合成驱动程序与模拟驱动程序相比有哪些优势？
- 对于那些有使用 Xen 虚拟机管理程序经验的人来说，使用合成驱动程序是否类似于对客户操作系统进行半虚拟化？
- 那么，不使用合成驱动程序是否存在任何值得注意的危险或缺点？
为什么我要费心 a) 处理内核中当前 Hyper-V 驱动程序报告的不稳定性，b) 尝试构建较新的内核，或 c) 尝试使虚拟机添加当一切似乎“正常工作”时，他们如何使用一个他们没有被设计的发行版来工作？
编辑：补充一点答案... 时钟漂移似乎是一个重大问题（严重到 NTP 无法保持时钟及时），除非您使用 Linux 集成服务。请参阅KB918461。显然，使用 Linux Integration Services 中包含的 vmbus 组件可以解决此问题。我的测试表明这是一个问题。
答案1
合成驱动程序更直接地与实际硬件“对话”，绕过大多数虚拟机管理程序（用于常见数据操作）。这大大减少了与大多数网络活动相关的虚拟机管理程序开销。
如果您的服务器在网络上的通信量不大，或者您的硬件配置不足，那么使用模拟驱动程序应该没问题。但是这样做肯定会影响性能。
答案2
当您的虚拟机管理程序正在模拟硬件时，会出现许多寄存器和时序问题，以及客户端驱动程序在执行诸如将数据包放入 NIC 的缓冲区或将数据放入磁盘驱动器上的块等操作时需要执行的其他操作。
当您使用合成驱动程序时，您会跳过所有“摆弄这个寄存器（无论如何都由虚拟机管理程序模拟）”并直接跳到“这是数据 - 用它做正确的事情”阶段。
因此整个过程更加高效。
答案3
我无法给你一个完整的答案，但一些经验可能会有助于完善讨论。我们最初在 Red Hat 机器上使用模拟驱动程序，但 Linux 管理员抱怨网络性能太差。最终，我们通过虚拟机附加组件让合成驱动程序正常工作，这产生了很大的不同（我没有证据或详细信息，所以对此持保留态度）。
另外，我们有时会通过网络对虚拟机进行映像处理，当我们这样做时，我们必须在 Windows 机器上使用模拟 NIC，因为合成 NIC 不支持 PXE 启动。映像处理完成后，我们会用合成 NIC 替换模拟 NIC。再次强调，我这里说的是 Windows（不是 Linux），但这是另一个区别。
总体而言，我的理解是，模拟设备模拟的是较旧、较成熟或较通用的设备，几乎每个操作系统或发行版都会内置支持这些设备。在这方面，它们更通用。合成设备不会模拟您的操作系统或发行版可以识别的任何其他设备，因此，您需要 Microsoft 为其提供的驱动程序，您可以通过安装 VM Additions 获得类似的驱动程序。