Posts Tagged ‘VMWare’

Samstag, 27. August 2011

Debian unter VMware meldet „Waiting for root file system“

Gestern wurde der VMware-Server aktualisiert, unter welchem eine von mir betreute Debian GNU/Linux-Installation läuft. Wie ich erst jetzt realisiert habe, funktioniert der Server seit dem Update nicht mehr.

Nachdem ich mich per VPN über den Terminalserver und den VMware vSphere Client auf die Konsole der Kiste eingewählt und die Kiste neu gestartet hatte, lächelte mich folgende Fehlermeldung an:

Waiting for root file system

Nach einer Google-Suche und einiger Lektüre stiess ich auf einen erhellenden Artikel “Waiting for root file system” caused by out dated VMware Server, dessen Lösung für mich zwar nicht anwendbar war, mich aber immerhin darauf brachte, die in GRUB hinterlegten Referenzierungen auf die Partitionen zu überdenken.

Und siehe da: Zuerst betätigte ich beim GRUB-Screen zuerst einmal den Cursor, um den automatischen Start des Betriebssystems zu verhindern. Anschliessend bearbeitete ich den standardmässig aktivierten Eintrag mit Druck auf die Taste e. Hier wechselte ich folgende Angaben:

kernel          /boot/vmlinuz-2.6.26-2-686 root=/dev/sdb2 ro

auf

kernen          /boot/vmlinuz-2.6.26-2-686 root=/dev/sda2 ro

und einem anschliessenden Enter gefolgt von b liess die Kiste wieder booten.

Als nächstes musste ich die soeben gemachte Anpassung noch fix in /boot/grub/menu.lst vornehmen. Beim nächsten Neustart lief alles wieder wie gewohnt.

Tags:
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 18. Mai 2011

Ctrl-Alt Tastenkonflikt in vSphere Client, welcher in einer Parallels Virtual Machine läuft

Betätige ich in einer geöffneten vSphere Client-Konsole, welche in einem virtualisierten Windows unter Parallels läuft, die Tastenkombination Ctrl-Alt, verlasse ich nicht etwa das Konsolenfenster, sondern die Parallels-Applikation.

Damit man die vSphere-Konsole mit der gewohnten Tastenkombination schliessen kann, muss die Parallels-Konfiguration angepasst werden:

  1. Parallels Desktop
  2. Einstellungen
  3. Tastatur und Maus
  4. Bei Ctrl-Alt – Eingabegeräte freigeben muss die Tastenkombination mit Klick auf den Bleistift unterhalb der Liste angepasst werden. Ich habe mich für Ctrl-Alt-9 entschieden
  5. OK

Ab sofort kann man die vSphere Client-Konsole verlassen und in Windows zurückkehren, statt dass die Eingaben über Tastatur und Maus gleich auf Mac OS X einwirken.

Tags: , , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Freitag, 27. April 2007

Wenn VMWare das Wochenende herauszögert …

image-1130

VMWare streikt
Originally uploaded by emeidi.

Vor etwa einer Stunde erhielt ich einen Telefonanruf eines Kunden: „Wir können nicht mehr auf unser Wiki zugreifen. Was ist da wohl los? Wir präsentieren die Applikation doch morgen Samstag einem breiteren Publikum, ein Ausfall liegt da nicht drin!“.

Tatsächlich – der Server reagierte auf kein Ping mehr, logischwerise funktioniert auch der Zugriff auf Web-Seiten nicht mehr. Der Adrinalinaustoss verdoppelte sich innert eines Bruchteils einer Sekunde.

Murphy’s Law Extended

Sofort machte ich mich daran, das Problem zu lösen. Natürlich war Murphy nicht weit und sein Effekt trat kumulativ auf:

  • Der Virtual Infrastructure Client läuft nur unter Windows – Linux/Mac? Fehlanzeige
  • Mein MacBook mit Intel CPU und einer Windows XP-Installation unter Parallels ist momentan leihweise bei der Freundin in Basel, weil deren MacBook von WLAN-Empfangsprobleme geplagt wird und nun in der Reparatur weilt
  • Das Thinkpad, ein Arbeitsgerät, von dem aus ich die Instanz normalerweise betreue, liegt brav gesichert im Panzerschrank im Büro
  • Ein in eine Web-Site eingebettetes Applet zur Administrierung einer VMWare-Instanz (Alternative zum Infrastructure Client) lässt sich per VPN-Verbindung unter Mac OS X (Safari sowie Firefox) nicht laden.
  • Mangels funktionierender VPN-Verbindung von der Wintel-Maschine aus versuche ich, mittels WebVPN auf die entsprechende Seite zu kommen. Zumindest mit dem Internet Explorer müsste das Vorhaben doch gelingen? Leider nein – ob das Applet oder die Verschlüsselung und Zertifizierung spukt, WebVPN erlaubt mir nicht, auf die dringend benötigte Web-Seite zuzugreifen.
  • Immerhin gibt es hier zu Hause noch eine ältere Wintel-Kiste, die von meinem Vater benutzt wird – versuchen wir es damit!
  • Der Cisco VPN-Client funktioniert auf meinem PowerMac tadellos, auf der Windows-Maschine klappt die Einwahl hingegen nicht.
    • Vielleicht gibt es ein Update? Auf der Web-Site des Arbeitgebers findet sich tatsächlich die Version 5, installiert ist noch die Version 4.6. Glücklicherweise darf der Client mittlerweile auch aus dem Internet heruntergeladen werden, man muss sich also nicht mehr zwingend auf dem Campus aufhalten.
    • Bevor der neue Client installiert werden kann, muss der alte vom System geputzt werden. Selbstverständlich mit dem obligatorischen Windows-Neustart (wobei auch ein Mac für einmal neugestartet werden müsste, weil sich der Client relativ tief ins System einklinkt)
    • Nachdem der neue Client installiert wurde, ist ein weiterer Windows-Neustart nötig. Ohne Neustart läuft zwar ein Prozess vpngui.exe, doch das Fenster wird nicht angezeigt.
    • Nach dem Neustart startet auch die Applikation ordnungsgemäss und wählt sich – o Freude – tatsächlich in das Campus-Netzwerk ein
  • Nun muss der satte 50MB wiegende Infrastructure Client heruntergeladen werden
  • Die Installation klappt (für einmal kein Neustart nötig), die Applikation lädt
  • Wie lauten schon wieder die Zugangsdaten zum ESX-Server (Server, Username, Passwort)? Zurück zum PowerMac und dort den Mailverkehr abgesucht. Dank IMAP und einer ordentlichen Sortierung der eingegangenen Mails in aussagekräftige Unterordner finde ich das gesuchte Mail schnell
  • Es klappt, meine VMWare-Instanzen werden angezeigt. Ich wechsle auf die Konsole des fehlerhaften virtuellen Servers und sehe die Bescherung:
    Apr 27 14:38:02 server kernel: NETDEV WATCHDOG: eth0: transmit timed out
    Apr 27 14:38:02 server kernel: eth0: transmit timed out, status 0073, resetting.

    Das virtuelle Netzwerkinterface streikt – was ist denn los? Andere Instanzen auf demselben Server funken tadellos in die weite Welt hinaus.

  • Als ich die Einstellungen der VM durchsehe, fällt mir auf, dass zwei Häkchen nicht gesetzt sind (vgl. Screenshot). Äusserst fahrlässig von mir – wieso habe ich das bei der Installation damals übersehen? Rätselhaft! Nachdem ich beide Häkchen gesetzt habe und den Server vorsichtshalber neu booten lasse, ist endlich wieder alles im grünen Bereich – das Wiki kann wieder angesurft werden.

Das Wochenende konnte gerade noch rechtzeitig gerettet werden. Puuuh! Auch die Dummen haben manchmal ein wenig Glück …

Tags:
Labels: IT

Keine Kommentare | neuen Kommentar verfassen