Hyper-V Integretionsdienste für Linux
Wir möchten Linux auf dem kostenlosen Hyper-V 2008R2 incl. Sp2 virtualisieren.
Welches von den beiden Varianten ist besser:
Die Linux Integrationsdienste von Microsoft (http://blogs.technet.com/b/germanvirtualizationblog/archive/2010/08/02/ ..) oder den hauseigenen Kernel mit neuen Hyper-V Treiber (http://www.hyper-v-server.de/hypervisior/kompilierung-eines-eigenen-deb ..) kompillieren?
Bei dem zweiten hatten wir nur Probleme. Dabei verwendeten wir noch nicht einmal den neusten Linux Kernel sondern den dort beschriebenen und trotzdem kommt beim Booten immer eine Fehlermeldung
Der von Microsoft soll doch aber nich so performant sein..
Welches von den beiden Varianten ist besser:
Die Linux Integrationsdienste von Microsoft (http://blogs.technet.com/b/germanvirtualizationblog/archive/2010/08/02/ ..) oder den hauseigenen Kernel mit neuen Hyper-V Treiber (http://www.hyper-v-server.de/hypervisior/kompilierung-eines-eigenen-deb ..) kompillieren?
Bei dem zweiten hatten wir nur Probleme. Dabei verwendeten wir noch nicht einmal den neusten Linux Kernel sondern den dort beschriebenen und trotzdem kommt beim Booten immer eine Fehlermeldung
Der von Microsoft soll doch aber nich so performant sein..
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 169094
Url: https://administrator.de/forum/hyper-v-integretionsdienste-fuer-linux-169094.html
Ausgedruckt am: 23.12.2024 um 01:12 Uhr
18 Kommentare
Neuester Kommentar
Hallo,
dein zweiter Link funktioniert bei mir nicht. Ich hab es nach dieser Anleitung probiert:
http://www.hyper-v-server.de/hypervisior/kompilierung-eines-eigenen-deb ...
Es gibt zwar Fehler beim Booten, aber ansonsten funtioniert es mit dem 2.6.38er Kernel in der x86 und x64 Variante.
Es läuft nicht viel nur (L)AMP mit Solr/Jetty (Java) und Subversion. Seit ca 3 Wochen stabil (mit gelegentlichen Reboots wegen Windows-Updates ;))
Shutdown und Netzwerk geht ...Livemigration IMO nicht.
Benchmarks hab ich noch nicht gemacht ...ich wüsste jetzt auch nicht genau, was ich testen sollte.
Beagle
Kleiner Nachtrag zur Anleitung ...
Ich setzte die MAC-Adresse der neuen syntetischen NIC auf die MAC der Lagecy NIC, welche ich dann lösche.
Ausserdem hab ich mir auch den den Teil: "Optimierung des Kernels an seine Umgebung" gespart.
dein zweiter Link funktioniert bei mir nicht. Ich hab es nach dieser Anleitung probiert:
http://www.hyper-v-server.de/hypervisior/kompilierung-eines-eigenen-deb ...
Es gibt zwar Fehler beim Booten, aber ansonsten funtioniert es mit dem 2.6.38er Kernel in der x86 und x64 Variante.
Es läuft nicht viel nur (L)AMP mit Solr/Jetty (Java) und Subversion. Seit ca 3 Wochen stabil (mit gelegentlichen Reboots wegen Windows-Updates ;))
Shutdown und Netzwerk geht ...Livemigration IMO nicht.
Benchmarks hab ich noch nicht gemacht ...ich wüsste jetzt auch nicht genau, was ich testen sollte.
Beagle
Kleiner Nachtrag zur Anleitung ...
Ich setzte die MAC-Adresse der neuen syntetischen NIC auf die MAC der Lagecy NIC, welche ich dann lösche.
Ausserdem hab ich mir auch den den Teil: "Optimierung des Kernels an seine Umgebung" gespart.
Soweit ich weiss, würde ohne die Dienste der Shutdown und die synthetische Netzwerkkarte nicht funktionieren.
Und wenn lsmod sowas liefert:
hv_vmbus 29649 4 hv_utils,hv_blkvsc,hv_storvsc,hv_netvsc
...ist es auch schonmal ein guter Hinweis darauf.
Ich hab jetzt mal ein bissle rumprobiert ...die SMB/CIFS Performance ist nicht so doll ungefähr 1/10 der Windows Geschwindgkeit.
90-115MB/s vs 6-9MB/s
Offenbar ist der hv_blkvsc nicht sehr performant ...falls dieser für den HDD Zugriff zuständig ist.
Da hätte ich gerne mal eine zweite Meinung.
Am LAN-Durchsatz liegt es jedenfalls nicht. Ich hab mal mit iperf den Durchsatz zu einem echten Linux gemessen und komme auf 800 bis 900 MBit/s.
Beagle
Und wenn lsmod sowas liefert:
hv_vmbus 29649 4 hv_utils,hv_blkvsc,hv_storvsc,hv_netvsc
...ist es auch schonmal ein guter Hinweis darauf.
Ich hab jetzt mal ein bissle rumprobiert ...die SMB/CIFS Performance ist nicht so doll ungefähr 1/10 der Windows Geschwindgkeit.
90-115MB/s vs 6-9MB/s
Offenbar ist der hv_blkvsc nicht sehr performant ...falls dieser für den HDD Zugriff zuständig ist.
Da hätte ich gerne mal eine zweite Meinung.
Am LAN-Durchsatz liegt es jedenfalls nicht. Ich hab mal mit iperf den Durchsatz zu einem echten Linux gemessen und komme auf 800 bis 900 MBit/s.
Beagle
Hi
Welche Linux Distribution / Version installierst du? Ohne Integrations Services kannst du nicht auf die Synthetic Devices (Network Adapter, SCSI Controller) zugreifen, sowie stehen die genannten Funktionen wie Shutdown etc nicht zur Verfügung. Dh. dass du nur den Legacy Network Adapter (100 MBit/s) und nur die beiden IDE Controller zur Verfügung hast.
Nun, ab Linux Kernel 2.6.32 sind die benötigten Komponenten für Hyper-V (die gleichen wie beim Download von Microsoft) integriert. Das steht unter anderem hier: http://blogs.technet.com/b/port25/archive/2009/07/20/more-on-the-hyper- ...
Wie du diese aktivieren kannst, findest du hier: http://www.server-talk.eu/2010/04/02/how-to-virtualisieren-von-linux-mi ...
Klappt dies?
Grüsse
Michel
Welche Linux Distribution / Version installierst du? Ohne Integrations Services kannst du nicht auf die Synthetic Devices (Network Adapter, SCSI Controller) zugreifen, sowie stehen die genannten Funktionen wie Shutdown etc nicht zur Verfügung. Dh. dass du nur den Legacy Network Adapter (100 MBit/s) und nur die beiden IDE Controller zur Verfügung hast.
Nun, ab Linux Kernel 2.6.32 sind die benötigten Komponenten für Hyper-V (die gleichen wie beim Download von Microsoft) integriert. Das steht unter anderem hier: http://blogs.technet.com/b/port25/archive/2009/07/20/more-on-the-hyper- ...
Wie du diese aktivieren kannst, findest du hier: http://www.server-talk.eu/2010/04/02/how-to-virtualisieren-von-linux-mi ...
Klappt dies?
Grüsse
Michel
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:
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