Schlagwort-Archive: Hyper-V

MySQL „Error 1067: The process terminated unexpectedly“

Nach einem strombedingten Totalausfall einer Hyper-V Maschine startete der MySQL Server einer VM nicht mehr.

MySQL „Error 1067: The process terminated unexpectedly“

Der check auf der Commandozeile mittels C:\Program Files\MySQL\MySQL Server 5.5\bin>mysqld.exe -console zeigte keinerlei Fehlermeldung.

Alle Verzeichnisse waren intakt bzw. wurden korrekt zurückgesichert.

Abhilfe brachte das MySQL Instance Config-Tool (zu finden unter \bin\MySQLInstanceConfig.exe).

Mittels der Einstellung „Reconfigure Instance“ wurde sämtliche Config erneut durchgeklickt – es wurden keine Änderungen vorgenommen und mittels „Execute“ die sämtliche Konfig, die zur Instanz gehört, neu geschrieben.

Danach startete der Service fehlerfrei und es standen sämtliche Daten wieder zur Verfügung.

Es handelte sich hierbei um eine bereits etwas in die Jahre gekommene Version 5.5.22-winx64 welche lediglich ein internes Programm befeuerte.

Windows Server 2012 R2 (Build 9600) auf HP Microserver N36L

In meinem Hardware-Park darf ich auch einen HP Microserver N36L mein eigen nennen. Im Jahr 2011 habe konnte ich bereits Testberichte über den N36L in Bezug auf Windows 7 bzw. Windows Server 2008 R2 liefern (hier, ich war der Projektkollege).

Nun folgt vor kurzem ein weiterer kleiner Machbarkeits-Test für die inzwischen etwas betagte Lady mit Windows Server 2012 R2 (Build 9600).

Leider verlief die Installation nicht ganz so reibungslos wie beim Windows Server 2008 R2.

Das initiale Betanken mit dem Image klappte, jedoch stockte es beim ersten in dem Punkt „Getting devices ready“ bei genau 84%. In meinem Microserver N36L war sowohl Remote Access Karte als auch eine Intel PRO/1000 PT Dual Port Netzwerkkarte verbaut. Da es sich offensichtlich um ein Hardwarethema begann ich Geräte zu deaktivieren. Erster Ansatz war der Onboard Netzwerkchipsatz (Sorry Broadcom), da dieser Port unter Windows Server 2008 R2 Hyper-V eh deaktiviert war kein starker Verlust und siehe da, die Maschine installierte nun sauber durch.

Die Installation von Windows Server 2012 R2 (Build 9600) klappte problemlos. Alle weiteren Geräte und Treiber wurden erkannt.

Die Intel PRO/1000 PT Dual Port Netzwerkkarte läuft im LACP Teaming. Eine weitere Intel Gigabit-CT-Desktop-Adapter dient als Management-Interface für den darauf laufenden Hyper-V Host.

Um der Parent-Partition etwas „boost“ zu geben hängt eine kleine SSD am SATA Port, der ursprünglich mal für ein 5,25″ Laufwerk gedacht war.

Noch ein Tipp:Der Original-Lüfter ist inzwischen gegen einen Sharkoon SILENT EAGLE 1000 (120mm) getauscht. So ist das Gerät nahezu geräuschlos.

Windows Server 2012 R2 „Recommended Hotfix List“

Gibt es jetzt auch als Neuauflage für Windows Server 2012 R2 Hyper-V:

http://social.technet.microsoft.com/wiki/contents/articles/20885.hyper-v-update-list-for-windows-server-2012-r2.aspx (wird ständig von Microsoft aktualisiert)

Das gleiche jetzt auch als KB Artikel direkt von Microsoft speziell für Failover Cluster:

http://support.microsoft.com/kb/2920151 (wird ständig von Microsoft aktualisiert)

 

Windows Server 2012 R2 (Build 9600) auf HP DL380 G5

Obwohl es seitens HP, meines Wissens, keinen offiziellen Support mehr für Windows Server 2012 R2 auf einem HP DL380 G5 gibt, war es mal einen Versuch wert. Erfolg!

Wie? Da in div. Foren ggf. Probleme mit dem Controller P400 dokumentiert sind, habe ich vor der Windows Server 2012 R2 Installation das Supportpack 2013.09.0 drüber laufen lassen (es war noch ein Windows Server 2008 R2 enthalten) um auch alle Firmware-Stände aktuell zu bekommen.

Die Installation des Windows Severs 2012 R2 lief problemlos durch. Einige Geräte wurden nicht sauber erkannt, jedoch konnte ich nach der Installation des Windows Servers 2012 R2 das Supportpack 2013.09.0 nochmal drüber laufen lassen. Beim ersten Durchlauf schlugen einige Installationen fehl, der zweite Rest lief dann sauber durch.

Alle Geräte im Device Manager laufen, IML als auch HP System Management Homepage sind sauber und Windows Eventlog auch. Danach der Hyper-V Test – auch hier alles ok.

Virtuelle Maschine sporadisch nicht erreichbar

Gestern erreichte mich ein Problem, dass nach dem Umbau div. Hyper-V Singlehosts zwei virtuelle Maschinen auf einem neuen Host sporadisch nicht mehr erreichbar waren. Die Umgebung bestand aus div. HP Procuve Switchen incl. einem L3 Switch sowie div. HP Proliant DL Servern. Die Hyper-V Hosts hatten Windows Server 2008 R2 Enterprise und die virtuellen Maschinen Windows Server 2008 R2 Standard.

Ein Dauerping auf eine der betroffenen virtuellen Maschinen zeigte sporadische Timeouts.

Das riecht nach Troubleshooting. Beginnen wir mit dem Layer 1 – nachdem die Verkabelung zum betroffenen Singlehost geprüft und die Zuordnung der virtuellen Netze im Hyper-V Manager geprüft war ging direkt auf die nächste Ebene. Da es nach einem Netzwerkproblem aussieht (sogar ICMPs gehen nicht durch) könnte der Fehler bereits im Layer 2 liegen.

Gesagt getan, erster Punkt, pingen vom Routerinterface des VLANs. Auch hier klappte es mal und mal nicht – gleiches Fehlerbild.

sw1# ping 10.10.1.10
10.10.1.10 is alive, time = 6 ms
Request timed out.
Request timed out.
Request timed out.
10.10.1.10 is alive, time = 1 ms
10.10.1.10 is alive, time = 1 ms
10.10.1.10 is alive, time = 1 ms

Als nächstes liegt es also nahe zu prüfen, ob die MAC Adresse hinter der virtuellen Maschine mit der IP 10.10.1.10 auch wirklich an dem Port des Public-Interfaces vom Hyper-V Host bekannt ist.

sw1# sh mac-address 00155d-32fb04
Status and Counters – Address Table – 00155d-32fb04
Port VLAN
Trk1 21

Der Ping lief zunächst, plötzlich brach der Ping weg und selbiger Befehl auf dem Switch sw1 zeigte nun folgendes:

sw1# sh mac-address 00155d-32fb04
Status and Counters – Address Table – 00155d-32fb04
Port VLAN
Trk2 21

Ok, die Ursache für die sporadische Nichterreichbarkeit scheint gefunden aber warum wechselt die ist die gleiche MAC plötzlich auf einem anderen Interface bekannt?

Es galt zu hinterfragen was genau beim Umbau passiert ist:

Es waren vor dem Umbau zwei Hyper-V Singlehost VH1 und VH2. Die IP des VH2 wurde geändert und es kam ein dritter Hyper-V Singlehost, VH3, hinzu und bekam die IP des VH2.

Ok der Fall wird klarer. Bei Hyper-V arbeitet Microsoft mit dynamischen MAC Adress Pools welche wie folgt zusammengesetzt sind:

Z. B. die MAC Adresse 00:15:5D:32:FB:01

  • 00:15:5D is the OEM identifier
  • 32:FB letzten zwei Oktetts des ersten Hyper-V Netzwerkadapters konvertiert in HEX
  • 01 aufsteigende Nummerierung

Nun war es relativ einfach, die dynamischen MAC Address Pools beider Hyper-V Singlehosts waren identisch. Warum? Als die Hyper-V Rolle auf dem VH2 zur Installation aktiviert wurde, wurde der MAC Adresspool generiert (wird abgelegt unter HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization bzw. ist im Hyper-V Netzwork Manager auch sichtbar) – der VH2 hatte zum Zeitpunkt der Aktivierung der Rolle „x.x.50.251“ gebunden insofern kam es zu „32:FB“. Während der Laufzeit des VH2 wurde die IP geändert aber der dynamische MAC Pool bleibt natürlich gleich.

Als der VH3 nun mit der alten IP des VH2 konfiguriert und dessen Hyper-V Rolle aktiviert wurde generierte er nach der gleichen Logik auch „32:FB“ und seine erste Maschine bekam die „01“ verpasst.

Btw: so ein Fehlerbild erhält man auch in größeren Umgebungen wenn jmd eine virtuelle Maschine von z.B. Singlehost A auf Singlehost B umzieht jedoch die alte VM auf Singlehost A heruntergefahren liegen lässt und dann später versehentlich hochfährt.

Hier ein weiterer interessanter Artikel zum Thema der MAC Address Kollision:

  • http://blogs.technet.com/b/jhoward/archive/2008/07/15/hyper-v-mac-address-allocation-and-apparent-network-issues-mac-collisions-can-cause.aspx

 

Hyper-V Requirements via Systeminfo

Bei der systeminfo in der CMD wurde bei Windows 8 und Windows Server 2012 ein ziemlich cooles Feature nachgeschoben. Die letzten vier Zeilen des systeminfo Outputs in der CMD geben bei noch nicht aktivierter Hyper-V Rolle an, wie der Support ist aktuell konfiguriert ist.

Vor der Aktivierung der Hyper-V Rolle:

C:\Users\stefan>systeminfo
[…]
Anforderungen für Hyper-V:
Erweiterungen für den VM-Überwachungsmodus: Ja
Virtualisierung in Firmware aktiviert: Ja
Adressübersetzung der zweiten Ebene: Ja
Datenausführungsverhinderung verfügbar: Ja

C:\Users\stefan>systeminfo
[…]
Hyper-V Requirements:
VM Monitor Mode Extensions: Yes
Virtualization Enabled In Firmware: Yes
Second Level Address Translation: Yes
Data Execution Prevention Available: Yes

Nach der Aktivierung der Hyper-V Rolle:

C:\Users\stefan>systeminfo
[…]
Hyper-V Requirements: A hypervisor has been detected. Features required for  Hyper-V will not be displayed.

C:\Users\stefan>systeminfo
[…]
Anforderungen für Hyper-V: Es wurde ein Hypervisor erkannt.
Features, die für Hyper-V erforderlich sind, werden nicht angezeigt.

2008R2 bootet nicht mehr nach Aktivierung der Hyper-V Rolle

Habe gerade einer abgeschalteten DL 380 G5 wieder etwas Leben eingehaucht um ein paar Hyper-V Themen zu testen. Die Betankung des Betriebssystems war problemlos. Nach Aktivierung der Hyper-V Rolle führ das System jedoch nicht mehr hoch.

Die Ursache lag am unterschiedlichen Stepping der CPUs. Der DL 380 war ein ausgemusterter Anwendungsserver, wo mal eine CPU nachgeschoben wurde – also kein ursprünglicher Hyper-V Host per sé.

Lösung war der Austausch einer CPU mit einer, die identisch in Revision und Stepping war.

Fündig geworden im Technet:

http://blogs.technet.com/b/asiasupp/archive/2011/05/03/the-server-that-has-multiple-cpus-with-different-cpu-revision-and-stepping-is-no-boot-after-hyper-v-role-is-enabled.aspx