Hyper-V Integretionsdienste für Linux

Ich musste mich aufgrund der Gegebenheiten schon ab Ubuntu 8.04 auf einem der ersten 2008 Hyper-V herumschlagen, ich habe etliche Probleme und ärgerliche Bugs mit den beschleunigten SCSI-Controllern,
und Netwerkadapter oder Zeitverschiebungen usw. erlebt.

Wers etwas pessimistisch aber kurz (IMHO) wissen will: Linux unter Hyper-V entweder mit einer älteren Enterprise-Distribution (RHEL5 / SLES10 und Klone) mit LIC 2.1 verwenden, oder alles Legacy-Komponenten mit allen anderen Distros.
Das hat sich als bisher stabil erwiesen. Es ist zwar in letzter Zeit deutlich besser geworden, aber für diese Konstellationen würde ich meinen, dass es klappt

Weiter:
- LIC 2.1 voni MS gehen z.Z nur mit den Enterprise-Distros RHEL5 (CentOS und Scientific gehen auch, jedoch nicht 6.x !) sowie SLES 10, das sind Kernel die auf 2.6.18 (RHEL) und 2.6.16 (SLES) aufbauen, nur mit denen gehen die LIC.
Damit funktionierts meiner Erfahrung nach (RHEL5 und Scientific 5) stabil und etwa gleichwertig wie eine Windows VM, damit hatte ich noch keine Probleme -
- Verwendet DKMS mit den LICs (MS hat sogar einen Artikel) und ihr könnt problemlos Kernel-Updates fahren ohne die LICs zu verschiessen.
- Die LIC 2.1 von MS sind bis auf wenige Codezeilen die gleichen Module wie sie ab 2.6.35 im staging-Bereich sind drinn sind (SMP in den Linux-VMs etwa gibts im 2.6.32er nicht)
- andere Distro: SLES 11 soll die Module integriert haben, Bei RHEL 6 wurden die Module deaktiviert, obwohl RHEL6 auf 2.6.32 basieret, dito bei Debian (man könnte auch diesen Kernel mit aktivierten hv-Modulen übersetzen, aber die in.32 sind schlecht)
- Ubuntu ist eine der wenigen mit bekannten Distributionen, die die hv-Module seit 10.04 LTS vorkompiliert und aktiviertbar haben - aber bitte mit Vorsicht zu geniessen.

Eine VM ohne paravirtualisierte Storage-Kontroller und Netzwerk sind unter Hyper-V dummerweise langsahm, für kleine Aufgaben OK, aber für mehr aber auch nicht.

Ich beobachte die Stabilität mit selbst gebauten Kernen unter Debian und Ubuntu seit 2.6.33 - und von gelegentlichen Komplettabstürzen der VM über Verlust von Netzwerk oder Blockdevices - ja gar bschädigte Filesysteme - leider alles gesehen.
Aber gerade letzteres war nur kurzzeitig ein Problem. Die Treiber sind seit dem Open-Sourcing durch MS immer noch im Staging-Bereich (aka für alle unfertigen Treiber: drivers/staging/hv), haben aber in den letzten Monaten an Stabilität gewonnen. - Manche scheinen Glück zu haben, je nach Hardware scheint es die Leute nicht zu treffen.

Auf Test-VMs (Ubuntu lucid) habe ich mit der 2.6.39er-Reihe keine solchen dramatischen Abstürze mehr unter etwas Last gesehen, zudem habe ich einen .39er mit den Patches aus 3.0 und neuer übersetzt, da da gerade gut 400 Patchsets reigekommen sind. Daher darf man optimistischer sein. - Wer interesse an diese gepatchten Kernelsourcen hat, ich kann sonst noch den Link dazu posten.

Zu den Modulen:

• hv_vmbus: Das Grundmodul, ohne dieses hat die VM keinen Zugriff auf den paravirtualisierten 'VMBus' wie das bei MS heist
• hv_netvsc: Steuert die paravirtualisierte Netzwerkkarte, die über den VMBus läuft - erst diese erreicht native LAN-Geschwindigkeit, sonst gibts nur die lahme legacy 100Mbit DEC-Emulation
• hv_blkvsc: Blockdevices generell, aber kann auch die IDE-Laufwerke paravirtualisieren (dieser dürfte wohl mit Kernel >=3.1 fliegen, es gibt Patches die die IDE-Devices auf storvsc ändern werden)
• hv_storvsc: Paravirtualisierter (nicht-bootfähiger!) SCSI-Kontroller - bietet annähernd Disk-IO der nativen Platten (nachgemessen, endlich auch unter Linux)
• hv_timesource - kann bei entsprechend (default) konfigurierter VM die Zeit in dieser über den Hypervisor setzen, dann brauchts kein NTP - funktioniert aber auf RHEL5 x86_64 etwa nicht (dort muss man timer ändern, sonst läuft die Zeit krumm)
• hv_tools: Wenn ihr die habt (>= 2.6.35) dann kann man die VM über die Windows-Tools (Hyper-V Konsole, Powershell) herunterfahren lassen, geht sonst nicht