Vorsicht ist geboten, wenn versucht wird die Boot-Partition eines »Windows Server 2008« größer zu ziehen. Als ich heute auf einer frisch eingerichteten VM die Festplatte von 30 auf 80GB vergrößert hatte und die Partition mit dem »Acronis Disk Director 10« angepasst hatte, meldet sich der »Windows-Start-Manager« mit der Fehlermeldung:

Datei: \Windows\system32\winload.exe
Status: 0xc000025
Info: Der ausgewählte Eintrag konnte nicht geladen werden, da die Anwendung fehlt oder beschädigt ist.

Problem ist hierbei möglicherweise eine Signatur, die durch den Fremdeingriff zerstört wird. Ganz klar ist mir der technische Hintergrund hierbei aber noch nicht – weitere Informationen sind an dieser Stelle erwünscht, sollte sie jemand liefern können. Über die Windows-CD lässt sich dieses Problem glücklicherweise aber über die »Eingabeaufforderung« der »Computerreparaturoption« folgendemaßen beheben:

Nachzulesen ist das Problem ebenfalls in Matthew Cosier’s Blog. Weitere Details hierzu sind in den folgenden Screenshots zu erkennen:

[Show as slideshow]

Update 2010-01-14: Der gleiche Fehler unter Windows 7

Heute ist mir meine Windows 7 Sandbox zu klein geworden. Eine Vergrößerung der Boot-Partition, ebenfalls mit »Acronis Disk Director 10«, brachte unter »Windows Seven« das gleiche Problem. Auch hier aber hilft ein kurzes Booten der Installations-CD und die »Computerreparaturoption«, um das Problem in den Griff zu bekommen. Anders als bei dem »Windows Server 2008« aber erkennt die Reparatur direkt, dass ein Problem besteht und fragt, ob es behoben werden soll. Man spart sich also die Tipparbeit Ein Tipp von j-zero war die Nutzung von »GParted« für die Partitionsänderungen. Der nächste Versuch wird also mit Hilfer einer »Ubuntu Desktop CD« durchgeführt (hier ist »GParted« direkt aufrufbar). Sollte die kostenlose Software hier tatsächlich wieder einmal die Nase vorn haben?

Wer den ESX-Server noch aus alten Zeiten kennt, erinnert sich auch noch an die Icons vor der virtuellen Maschine, welche Hinweise auf das eingesetzte System gegeben haben. Im Virtual Center hatte ich diese zu Anfang tatsächlich vermisst, mich aber später nicht mehr daran gestört. Auf der Website von »H9Labs« habe ich heute Morgen ein VI3-Plugins namens »GuessMyOS« gefunden, dass genau diese Funktion ins Virtual Center zurückbringt. Auf der Suche war ich ursprünglich nach der aktuellen Version von dem Storage VMotion Plugin »SVMotion«, hier hatte sich seit dem 15.6.2008 allerdings nichts mehr geändert an der Version. Wer SVMotion noch nicht einsetzt sollte sich dieses Plugin natürlich ebenfalls angucken.

Da soll also ein kritischer Server, der unter VMWare in der DMZ läuft, per VMotion verschoben werden. Nur wie wird das Ganze überwacht? Im Normalfall lasse ich hier einen Ping laufen, einfach um zu sehen, dass das Zielnetz auf dem neuen Host auch vernünftig durchgereicht wird und der Server durchgehend erreichbar bleibt. Per ICMP-Echo ist die gute Maschine in der DMZ aber nicht erreichbar, also per WHILE-Schleife ein »Ping« auf Port 80. So die einfache Idee, leicht erweitert sollte das folgende Script in keiner Tools-Sammlung fehlen:

tcpping.sh:

j-zero, der bei der Umsetzung geholfen hat, wird das Script sicherlich noch um das eine oder andere Feature erweitern.

Wer Ubuntu Hardy (8.04) nativ auf einem IBM Blade vom Typ HS21 XM (7995) einsetzt, sollte einmal überpüfen, ob das System bei Volllast nicht unerwartet in einen Freeze läuft. Bei uns ist dies nun zum 2. Mal aufgetreten (siehe Bild), beim ersten Mal hatte der Blank-Screen den Absturzgrund erfolgreich verstecken können, Logeinträge bleiben hier natürlich ebenfalls aus. Da es sich um keinen Hardwarefehler handelt, hüllt sich ebenfalls auch das Eventlog vom Bladecenter in Schweigen.

Der »Konsolen-Bildschirmschoner« lässt sich über folgenden Eintrag in der »/etc/rc.local« abschalten (hinterher muss natürlich entweder neu gestartet oder »/etc/rc.local« einmalig manuell über tty1 ausgeführt werden):

Kurze Zeit später ist der Fehler erneut aufgetreten, das hängende »htop« hat noch 3 CPU-Kerne auf 100% angezeigt, in der Console war folgender Fehler zu erkennen (siehe auch Bild):

Um den Fehler nun zu umgehen, wird der Kernelaufruf um die Parameter »nmi_watchdog=0 nohpet« ergänzt. Die Kernelparameter werden dafür in der Datei »/boot/grub/menu.lst« folgendermassen editiert:

Im Anschluss wird die menu.lst über »update-grub« aktualisiert, das System kann neu gestartet werden und sollte nun auch unter Volllast stabil laufen. Bei mir tut es dies nun seit 3 Tagen.

Tja es hätte so einfach werden können. Da heute Abend noch etwas Zeit war, dachte ich, jetzt wo die Besucherzahl gering ist, schnell die Zeit nutzen und den in den letzten Wochen langsam an der Last zu erdrücken drohenden Intranet-Webserver, welcher natürlich unter VMWare ESX läuft, vergrössern. Konkret wollte ich den RAM von 2GB auf 4GB und die CPU Anzahl von 2 auf 4 erhöhen. Um die Downtime zu überbrücken habe ich also am vorgelagerten »Apache« auf den Backupserver umgeschaltet und meinen unter »Ubuntu Hardy« laufenden Apache- und MySQL-Server neu gestartet. Doch was ist jetzt? »fsck« hängt bei 14% fest und die VM ist nicht mehr bedienbar, weder ein Reset noch ein PowerOff möchte gelingen. Ein kurzes Warten, ob sich die Situation von alleine auflöst, bliebt leider ohne Erfolg. Wie bekomm ich den Prozess jetzt beendet, es laufen ja noch einige weitere VMs auf dem ESX-Host. Kein Problem, einfach per SSH auf die ESX-Konsole und die »PID« des hängenden Prozesses heraussuchen:

»-ww« steht für »wide output« und bewirkt hier doppelt angewandt, dass die Prozess-Zeile komplett angezeigt wird. Nötig wird das, da der Name der VM erst am ganz am Ende der Ausgabe erscheint. Wenn die VM also tatsächlich läuft, was bei mir zum Glück der Fall war, dann sollte die Ausgabe wie folgt aussehen:

Die in der Ausgabe angezeigte PID, in diesem Beispiel »3860« wird einfach über ein:

terminiert. Bei mir war die Option »-9« aber noch nicht einmal nötig.

Gut nun folgte noch ein weiterer Versuch, allerdings hing »fsck« hier erneut, so dass ich versucht hatte die VM über das Virtual Center zu clonen. Der Clone zog sich hin (~1Std), wurde aber erfolgreich erstellt – beim Starten allerdings das Gleiche: »fsck« hängt, die CPU-Auslastung der VM liegt dabei bei 100%. 10 Minuten warten, aber nichts passiert.

Die nächste Idee also, eine neue HDD an die VM hängen und mittels Knoppix die Daten übertragen und das scheinbar defekte »VMDK« entsorgen. Ein Fehler im VMFS bzw. auf dem gesamten Datastore schloss ich aus, da der Clone bereits auf einem anderen Bereich erstellt wurde. Unter Knoppix lief das »fsck« übrigens durch, auch die VM lief hinterher wieder hoch und schien in Ordnung. Da die VM aber nach einem Stromausfall schon einmal Probleme gemacht hatte (der Snapshot vom vRanger-Backup konnte nicht wieder entfernt werden) habe ich die Platte unter Linux mit Hilfe von »rsync« geclont und das alte VMDK prophylaktisch doch komplett entsorgt.