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.
Best Answer
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.