7

We are moving our virtualization platform from Citrix's XenServer to Hyper-V on Windows Server 2008 R2. As part of this project I need to migrate, in one form or another, some Debian Linux servers over to Hyper-V. I have successfully built a Debian-based server on our new Hyper-V platform and I'm beginning to test it.

Debian 6 (Squeeze) uses the 2.6.32 kernel which includes the Hyper-V synthetic drivers, but it is not considered a supported operating guest operating system by Microsoft. I'm a little hesitant in trying to use them unless there's a compelling reason to, as other folks have had trouble (here, and here).

  • What advantages do the Hyper-V synthetic drivers offer over the emulated drivers?
  • For those of you who have experience with the Xen hypervisor, is using the synthetic drivers analgous to para-virtualizing a guest operating system?
  • Are then any noteworthy dangers or drawbacks of NOT using the synthetic drivers?

Why should I bother to either a) deal with the reported instability of the Hyper-V drivers currently in the kernel, b) try to build a newer kernel, or c) try to make the Virtual Machine Additions work with a distribution they weren't designed for when everything seems to "just work"?

EDIT: To add a little to the answers... Clock drift seems to be significant issue (as in so bad that NTP can't keep the clock in time) unless you are using Linux Integration Services. See KB918461. Apparently using the vmbus components included in the Linux Integration Services resolves this. My testing bares this out as a problem.

Community
  • 1

3 Answers3

7

The synthetic drivers 'talk' more directly to the actual hardware, bypassing most of the hypervisor (for common data operations). This dramatically cuts down on the hypervisor overhead related to most network activity.

If your server doesn't communicate much on the network, or if your hardware is well undercommitted, you should be fine with the emulated drivers. There's definitely a performance penalty for doing this however.

Chris S
  • 78,455
2

When your hypervisor is emulating hardware, there are lots of registers and timing issues and other things that the client's driver is going to expect to do when it is doing things like putting packets into the NIC's buffer or putting data into a block on a disk drive.

When you use the synthetic driver, you skip all the "fiddle with this register (that's emulated by the hypervisor anyhow)" and skip straight to the "here's the data -- do the right thing with it" stage.

So the whole process is far more efficient.

chris
  • 12,104
0

I don't have a full answer for you but some experience that might help round out the discussion. We initially used the emulated drivers on our Red Hat machines but the linux admin complained that network performance was abysmal. Eventually we got the synthetic drivers working via the Virtual Machine Additions and that made a big difference (I don't have proof or details, so take that with a grain of salt).

Separately, we sometimes image VMs over the network and when we do that we must use the emulated NIC on a Windows box because the synthetic NIC doesn't support PXE booting. Once the imaging is complete, we replace the emulated NIC with a synthetic one. Again, I'm talking about Windows here (not linux) but it's another difference.

In general, my understanding is that the emulated devices emulate older, more established or more generic devices that pretty much every OS or distribution will have built-in support for. In this regard they are more universal. The synthetic devices don't emulate any other devices that your OS or distribution would recognize and thus, you need Microsoft-provided drivers for them the likes of which you get by installing the VM Additions.

icky3000
  • 4,948