Windows Server 2019 Hyper-V auf KVM

  • Hallo zusammen!


    Bevor ich meinen RS 4000 gebucht habe, habe ich mich umfangreich darüber informiert, ob dass, was ich vorhabe funktionieren könnte: Einen Hyper-V Server auf Basis von Windows Server 2019 zu installieren. In den Dokumentationen, die ich gefunden habe, hatten das zwar alle nur mit Windows Server 2016 Hyper-V zum laufen bekommen, aber ich dachte mir: Ok, es wird wohl nicht "schlechter" geworden sein. Allen, die das gemacht haben, war jedoch gemeinsam, dass sie selbst auch Zugriff auf den L0-Hypervisor - also den Bare-Metal Host hatten und somit direkt auf den KVM Zugriff hatten.

    Eins noch vorab: Ich habe wenig bis keine Erfahrung mit Linux, bin aber schon sehr viele Jahre auf der "dunklen Seite der Macht". also im Windows - Umfeld unterwegs in der IT.


    Aaaalso: Was habe ich gemacht?


    Ich habe mir für die sechs Kerne meines RS 4000 VMX freischalten lassen. Danach habe ich einen Windows 2019 Server aufgesetzt. (Alles zwei Mal inzwischen). Bis dahin war alles gut. Ich habe mir auch vorher angeschaut, mit welchen virtuellen Netzwerkkarten (virtio, e1000) und Platten (IDE, SCSI. virtio) die besten Erfahrungen gemacht wurden. Der Server lief bis dahin sauber, das Event-Log war blütenrein, alle Updates eingespielt, RDP-Zugriff freigeschaltet, alles prima bis dahin. Dann habe die Hyper-V-Rolle installiert (mit Nutzung der virtuellen Netzwerkkarte (virtio) und neu gestartet. Von da an ging nichts mehr.

    Beim ersten Mal antwortete der Server auf PING nach dem Neustart, danach habe ich versucht, per RDP zuzugreifen, danach kam kein Echo mehr. Auch in der VNC-Konsole reagierte der Server nicht mehr. Ok, dachte ich, dann war das wohl keine gute Idee, die virtuelle Netzwerkkarte für den RDP-Zugriff und Hyper-V zu nutzen...

    Gesagt, getan, Server neu aufgesetzt, dieses Mal mit der "e1000" virtuellen Netzwerkkarte. Dieses Mal habe ich auch beim Installieren des Hyper-V-Servers die Karte nicht ausgewählt und hatte vor, nach der Installation erst einmal mit einem "rein internen" virtuellen Netzwerk-Switch anzufangen. Leider kam es nicht dazu. Nach dem Neustart lief der Server zwar und ich konnte mich auch sowohl mittels VNC-Konsole als auch RDP verbinden, jedoch nur sehr kurz, nach dem Start des Server-Managers nach der Anmeldung reagierte der Server nicht mehr, auch PING bekam kein Echo. Ich hab dann verschiedenes versucht über das SCP: Virtuelle Platte von "virtio" auf SCSI umgestellt, virtuelle Netzwerkkarte auf "virtio" umgestellt - immer das gleich Bild: Kurz nach der Anmeldung (ich vermute, wenn der Hyper-V-Service startet) reagiert das System plötzlich nicht mehr....alle Kerne laufen auf 100% CPU-Last.


    Leider habe ich keinen Zugriff auf den darunter liegenden KVM (von dem ich ohnehin nicht viel verstehe) und daher kann ich auch nicht sehen, was konfiguriert wurde, also "VMX freigeschaltet" wurde. Ich vermute jedoch, dass zum einen der Windows Server 2019 Hyper-V sich eben doch anders verhält als der vom Windows Server 2016 (s.o.), zum anderen habe ich das ein oder andere darüber gelesen, was andere dort konfiguriert haben, die das auch versucht haben (z.B. "Host-pass-through" setzen).


    Hat irgendjemand hier das schon einmal erfolgreich umsetzen können? Hat jemand vom Support evtl. eine Idee, was man beim KVM noch ändern könnte, um das zum laufen zu bekommen? Ich kann mir vorstellen, dass der/die ein oder andere diese Möglichkeit auch nutzen würde - und sei es mit Windows 10 -, um wie ich seine Testumgebung zu virtualisieren.


    Vielen Dank im Voraus für Eure Antworten und Unterstützung. :thumbup:


    Schönes Wochenende und bleibt gesund...! :)

  • Mit Hyper-V 2019 Server (Core) bin ich erst seit kurzer Zeit in Kontakt, aber ich bin mir nicht sicher, ob die öffentliche IP Dir da nicht in Verbindung mit einer Gruppenrichtlinie oder mit einem via Powershell zu änderndem Defaultwert in die Suppe spuckt?


    CPU-Flags kannst Du über das Rettungssystem, das man via „CD/DVD-Image“ im Servercontrolpanel starten kann, mittels cat /proc/cpuinfo auslesen.

    Unter Windows müssten msinfo32 und Sysinternals Coreinfo¹ Dir Auskunft geben können.

    1: https://docs.microsoft.com/en-…ernals/downloads/coreinfo

  • Hi!


    Danke für die Antwort. Die Info mit dem Rettungssystem hatte ich noch nicht, "Coreinfo" kenne ich natürlich. Coreinfo und auch der Output aus dem Rettungssystem zeigt mir natürlich nur die Parameter aus dem Gastsystem an, dass dann mal der L1-Hypervisor werden soll, nicht die des Hosts, der von Netcup auf "Blech" als "L0" Hypervisor aufgesetzt wurde.

    Hat denn jemand mal einen "ESXi" oder "einen "Qemu/KVM" als Gastsystem zum laufen bekommen - und kann mir auch nicht sagen, wie?

  • Ok, das klingt schonmal, als wäre es ein guter "Plan B". Bis dato bin ich aber (noch) nicht bereit, mich geschlagen zu geben. Wenn also jemand Erfahrungen mit einem "Nested Hyper-V" hat, der auf KVM läuft, wäre ich sehr dankbar, wenn er/sie diese teilen könnte.

  • Hi


    kurze Frage: wozu hast Du das Hyper-V addon installiert? Unser 2013-Server läuft über nested Virtualisation auf einem RS8000 nach einem Host-Wechsel wieder problemlos... hast Du die Probleme nur bei einem oder bei allen (bzw. mehreren) Hosts?

  • Hi!


    Nun, das "Hyper-V add-on" ist das Windows Gegenstück zum KVM auf Windows. Was meinst Du mit "2013" - Server?

    Meinst Du Windows Server 2012, 2012 R2, 2016 oder 2019? Wenn Ihr das nicht nutzt, womit virtualisiert Ihr denn "nested"? KVM? ESXi? XEN?


    Ich habe das Problem bei nur einem Host (ich hab nur einen), allerdings ein RS4000.


    Für mich stellt sich das Bild wie unten stehend dar - mit ein paar Änderungen (von unten nach oben):

    - Der "Azure Hardware - Layer" ist das Blech bei Netcup.

    - Die dunkelblaue Schicht ist der KVM, das OS des Linux - Wirts wird bei KVM nicht virtualisiert, also gibt es den Block "Azure Root OS Server 2016" nicht.

    - Das Mittelblaue ist dann mein geplanter Hyper-V Host und

    - das hellblaue sind dann die Maschinen meiner geplanten Testumgebung (Windows, Linux, whatever).


    pasted-from-clipboard.png

  • Hey


    wir verwenden nun wieder erfolgreich ESXi. Das läuft, Du musst aber als Festplatten-Treiber "IDE" auswählen, sonst erkennt ESXi keine HD. Zudem musst Du mit pfSense (oder jedem anderen Router) arbeiten um mehrere Hosts mit mehreren IP-Adressen versorgen zu können, da jedes Produkt (RS was-weiss-ich-wieviel) nur eine "echte" IP-Adresse erhält... genaueres gerne bei Bedarf, aber das sprengt gerade mein jetziges Zeitbudget ;) Mit Hyper-V kenne ich mich nicht aus, deswegen meine doofe Frage (ich dachte, Du hättest schon ESXi in Betrieb und möchtet nun zusätzlich noch Hyper-V verwenden).

  • Hurra!!! Es hat funktioniert. Was habe ich dieses Mal anders gemacht?


    1) Ich vor der Installation die "virtio" - Karte auf auf DHCP belassen, also nicht die IP nicht vorab fest konfiguriert. Ggf. hat das neu erstellte virtuelle Interface, dass Hyper-V installiert dann die IP-Adresse dann zugewiesen bekommen, die ich vorab der Karte immer fest zugewiesen hatte. Das eigentliche Interface wird ja vom Hyper-V "totgelegt".


    2) NACHDEM der Server nach der Installation der Hyper-V-Rolle erneut nicht ansprechbar war, habe ich einfach mal die Netzwerkkarte von "virtio" auf "rtl8139" geändert und neu gestartet. Keine Ahnung, was bei dieser Karte nun anders ist. Nach der Installation habe ich Adresse auf dem neuen Interface nun fest zugewiesen und der Server läuft (noch). Mal sehen, ob es so bleibt...


    3) Nach den Installation habe ich im Hyper-V - Manager das neue virtuelle Interface (eigentlich ein virtual Switch) als "extern" (allow Management Operating System to share this adapter) geflaggt und einen neuen "internen Switch" konfiguriert, auf dem dann meine Gast-Systeme laufen.


    pasted-from-clipboard.png

  • Noch ein Tip zum Selbermachen: Hyper-V Server 2019 (der Gratis erhältliche Kern) auf altem Blech mit Ubuntu und libvirtd sollte Dein Szenario zu den bloßen Hardwarekosten nachbauen können. Zur komfortablen Bedienung gibt es ein GUI namens „Virt-Manager“, das im Grunde dasselbe tut, wie die Hyper-V-MMC, nur eben mit libvirt/qemu/kvm.