18
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..
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 169094
Url: https://administrator.de/contentid/169094
Ausgedruckt am: 22.11.2024 um 10:11 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.
Jo den Link habe ich auch genommen.
Ich habe mit dem im Artikel angegebenen Kernel kompiliert und dennoch eine Meldung beim Booten wegen dem hv_vmbus\nhv_storvsc\nhv_blkvsc\nhv_netvsc.
Hattest du die auch?
Ich habe den Apache2 und den phpmyadmin (welchen du in LAMP hast) installiert.
Hast du eine 100Mbit/1Gbit Netzwerkkarte? Wie kann ich in Linux die Netzwerkgeschwindigkeit testen bzw. überprüfen ob die Integrationsdienste wirklich installiert sind?
Ich habe mit dem im Artikel angegebenen Kernel kompiliert und dennoch eine Meldung beim Booten wegen dem hv_vmbus\nhv_storvsc\nhv_blkvsc\nhv_netvsc.
Hattest du die auch?
Ich habe den Apache2 und den phpmyadmin (welchen du in LAMP hast) installiert.
Hast du eine 100Mbit/1Gbit Netzwerkkarte? Wie kann ich in Linux die Netzwerkgeschwindigkeit testen bzw. überprüfen ob die Integrationsdienste wirklich installiert sind?
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
ja aber beim booten kommt eine fehlermeldung speziell das die hv_vmbu, hv_utils,hv_blkvsc,hv_storvsc,hv_netvsc nicht richtig geladen werden konnte.
das beantwortet aber eigentlich nicht meine grundlegende frage...
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
debian 6 amd64 ist mein installationskandidat. der rechner hat eine gigabit-netzwerkkarte. deswegen muss und will ich den legacy-modus umgehen.
sind denn die integration treiber von microsoft performanter als die hyper-v treiber im linux-kernel?
sind denn die integration treiber von microsoft performanter als die hyper-v treiber im linux-kernel?
Sollten die gleichen sein. Aus dem Team Blog:
Microsoft just submitted source code for the Hyper-V Linux Integration Components to the Linux Kernel Community Under GPL v2.
ich habe ein besseres gefühl wenn ich einem neuen kernel kompiliere als den integration services (der ist uralt von 2009??) zu nutzen.
als den integration services (der ist uralt von 2009??) zu nutzen.
Wenn ich mir aber überlege, dass das Kompilieren und Installieren des neuen Kernels + Hyperv fast 2h gedauert hat überlege ich mir doch auf die Windows Variante umzusteigen
Zitat von @Beagle:
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
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
Meinst du bei der Windows Geschwindigkeit die Integrationstreiber oder im normalen Windowsbetrieb?
Natürlich die Integrationsdienste.
nur noch mal um misverständnisse zu vermeiden: die integrationsdienste sind 1/10 der windows-geschwindigkeit?
na ungefähr, aber wie gesagt nur beim HDD Zugriff. Netzwerk ist so schnell wie bei einer realen Maschine.
Aber das kannst du doch selber testen.
Aber das kannst du doch selber testen.
problem ist: die integrationsdienste sind nicht für debian. es gibt zwar diesen blog http://blog.manglar.com/how-to-install-linux-integration-services-versi ... aber dennoch kommt es zu problem beim befehl make oder make install!!
deswegen habe ich mich doch lieber für das neu kompilieren mit hyper-v treibern entschieden..
deswegen habe ich mich doch lieber für das neu kompilieren mit hyper-v treibern entschieden..
wenn ich lsmod | grep hv eingebe taucht folgendes auf:
hv_utils 2421 0
hv_netvsc 23266 0
hv_timesource 1055 0 [permanent]
hv_vmbus 35453 2 hv_utils,hv_netvsc
kann mir das mal einer erklären??
hv_utils 2421 0
hv_netvsc 23266 0
hv_timesource 1055 0 [permanent]
hv_vmbus 35453 2 hv_utils,hv_netvsc
kann mir das mal einer erklären??
problematisch ist auch sobald ich /sbin/lsmod | grep vsc aufrufe müssten doch all hyper-v (vsc) module angezeigt werden.
mir fehlen aber blkvsc und storvsc bzw. scsi_mod
ich sehe also quasi nur
hv_netvsc
hv_vmbus
können die anderen module vernachlässigt werden?
mir fehlen aber blkvsc und storvsc bzw. scsi_mod
ich sehe also quasi nur
hv_netvsc
hv_vmbus
können die anderen module vernachlässigt werden?
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
