mwiederkehr 373 Geschrieben 17. Dezember 2018 Melden Teilen Geschrieben 17. Dezember 2018 Hallo zusammen Einem Cluster bestehend aus Servern mit Windows Server 2016 und nicht mehr so jungen Xeon E5645 wurde ein neuer Host mit Server 2019 und Xeon Gold 6130 hinzugefügt. Das Problem ist nun, dass sich die VMs zwar mittels Live Migration von den alten auf den neuen Host verschieben lassen, aber nicht mehr zurück. Die Fehlermeldung ist sehr sparsam: Event ID 21111, " Live migration of 'Virtual Machine <VM NAME>' failed". Der Fehler tritt auch mit aktivierter CPU-Kompatiblität auf. Wenn ich richtig informiert bin, sollten die unterschiedlichen Windows-Versionen kein Problem sein. Bei den CPUs bin ich mir nicht sicher und habe leider keine exakte Dokumentation gefunden: maskiert die CPU-Kompatibilität genug Features, damit Sprünge über mehrere CPU-Generationen möglich sind? Komischerweise funktioniert Quick Migration in beide Richtungen. Dabei wird die VM ja auch nicht neu gestartet und eine zu unterschiedliche CPU sollte ein Problem darstellen? Vielen Dank für eure Tipps! Zitieren Link zu diesem Kommentar
NilsK 2.934 Geschrieben 17. Dezember 2018 Melden Teilen Geschrieben 17. Dezember 2018 Moin, geben die Eventlogs mehr her? Insbesondere die unter Dienst- und Anwendungsprotokolle. Sonst kann auch eine Suche nach der ID und Quelle Anstöße geben: https://www.google.de/search?q=event+id+21111+hyper-v-high-availability Die CPU-Kompatibilitätsmaske ist "fest", d.h. sie blendet alles aus, was "zu neu" ist. [Was die Prozessorkompatibilität in Hyper-V wirklich tut | faq-o-matic.net]https://www.faq-o-matic.net/2013/09/23/was-die-prozessorkompatibilitt-in-hyper-v-wirklich-tut/ Gruß, Nils Zitieren Link zu diesem Kommentar
zahni 554 Geschrieben 17. Dezember 2018 Melden Teilen Geschrieben 17. Dezember 2018 Der E5645 ist sehr alt. Ich würde es mir gut überlegen hier mit CPU-Kompatibilität zu arbeiten. Da liegt auf dem neuen XEON zu viel ungenutzt herum, z.B. die AVX Extension. Wenn die CPU-Kompatibilität korrekt aktiviert wurde: Hast Du die VMs 1x komplett ausgeschaltet und wieder eingeschaltet? Neu starten reicht u.U. nicht (zumindest nicht bei VMWare, sorry Hyper-V nutzen wir nicht). Bei Hardware-Maschinen kannst Du im Betrieb auch nicht einfach die CPU austauschen. Zitieren Link zu diesem Kommentar
NilsK 2.934 Geschrieben 18. Dezember 2018 Melden Teilen Geschrieben 18. Dezember 2018 Moin, vor 12 Stunden schrieb zahni: Der E5645 ist sehr alt. Ich würde es mir gut überlegen hier mit CPU-Kompatibilität zu arbeiten. mit dem Alter der beteiligten CPUs hat die Option nichts zu tun. Zitat Da liegt auf dem neuen XEON zu viel ungenutzt herum, z.B. die AVX Extension. Das ist korrekt, aber wie immer eine Frage der Anforderungen. Wenn man die erweiterten Kommandos nicht oder nur selten braucht, kommt es auf die Option nicht an. Wenn doch, muss man eben abwägen, was wichtiger ist. Zitat Wenn die CPU-Kompatibilität korrekt aktiviert wurde: Hast Du die VMs 1x komplett ausgeschaltet und wieder eingeschaltet? Neu starten reicht u.U. nicht (zumindest nicht bei VMWare, sorry Hyper-V nutzen wir nicht). Hyper-V lässt das Setzen der Option nur zu, wenn die VM abgeschaltet ist. Gruß, Nils Zitieren Link zu diesem Kommentar
mwiederkehr 373 Geschrieben 18. Dezember 2018 Autor Melden Teilen Geschrieben 18. Dezember 2018 Vielen Dank für eure Antworten! Habe nur folgende Events, leider alle ohne weiteren Text: ID 21111: "Live migration of 'XY' failed." ID 21502: "Live migration of 'XY' failed." ID 1155: "The pending move for the role 'XY' did not complete." Den verlinkten Artikel von Nils kannte ich schon. Ich meinte eben, irgendwo gelesen zu haben, dass die CPU-Kompatiblität nur +/- zwei oder drei Generationen unterstützt. Leider finde ich diese Aussage nicht mehr. (Wäre für mich nachvollziehbar, sonst müsste man ja quasi alles bis runter zu MMX maskieren.) (Bei VMware stellt man ja fix die CPU-Generation ein, dort kann man sehr weit zurück.) Sobald wir den zweiten neuen Host geliefert bekommen, werde ich testen, ob zwischen den neuen Hosts die Live Migration funktioniert. Vielleicht lässt sich das Problem dadurch etwas eingrenzen. Zitieren Link zu diesem Kommentar
NilsK 2.934 Geschrieben 18. Dezember 2018 Melden Teilen Geschrieben 18. Dezember 2018 Moin, wenn Quick Migration funktioniert, Live Migration aber nicht, ist es unwahrscheinlich, dass die VM-Konfiguration das Problem darstellt. Möglicherweise ist was zwischen den Hosts nicht okay: Netzwerktreiber, Netzwerkkonfig, Jumbo Frames ... Gruß, Nils Zitieren Link zu diesem Kommentar
mwiederkehr 373 Geschrieben 15. Januar 2019 Autor Melden Teilen Geschrieben 15. Januar 2019 Am 18.12.2018 um 11:25 schrieb NilsK: Jumbo Frames Bingo! Die Netzwerkkarten in den neuen Hosts unterstützen maximal 9600 Bytes statt wie bisher 9014 Bytes. Bei der Konfiguration wurde irrtümlich einfach er unterste Wert im Dropdown-Menü gewählt... Die Live Migration von den neuen Hosts mit Server 2019 zu den älteren mit Server 2016 funktioniert aber immer noch nicht, immer noch ohne vernünftige Fehlermeldung. Da inzwischen ein weiterer neuer Host installiert wurde, konnten wir die Migration zwischen den neuen Hosts testen: diese funktioniert ohne Probleme. Könnte noch ein Bug vom Server 2019 sein. Zitieren Link zu diesem Kommentar
nemonix 2 Geschrieben 17. Januar 2019 Melden Teilen Geschrieben 17. Januar 2019 (bearbeitet) Hallo, Gibt es für die älteren Server "Spectre vulnerabilities" bios updates? Sind diese installiert? Schau dir mal folgendes an, vielleicht hilft es dir weiter: https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/CVE-2017-5715-and-hyper-v-vms Du solltest eventuell auch folgendes Verhalten sehen können: Cold boot der VM auf einem alten Host --> Live Migration müsste funktionieren Cold boot der VM auf einem neuen Host --> Live Migration funktioniert nicht Lg bearbeitet 17. Januar 2019 von nemonix Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.