Total Verfriemelt

Ich hatte heute neben dem sehr ernüchternden Spiel GER-SRB eine kleine vCenter hinter Firewall Verfriemelung. Dabei bin auf der Suche nach Ports neben einem meiner eigenen Posts, über diese Map in der VMWare Online Lib gestolpert…

Gute Übersicht der Ports auch nochmal hier.

Firewalls for Configurations with vCenterServer

Dann mal allen ein schönes Wochenende und Kopf hoch.

Willkommensbildschirm ist vielleicht etwas undeutlich ausgedrückt, mir ist aber gerade keine bessere Bezeichnung eingefallen. Gemeint ist jedenfalls die Startseite, die im Browser erscheint, wenn man den ESXi via HTTPs aufruft. Aus ganz unterschiedlichen Gründen möchte man diese Seite vielleicht verbergen, z.B. wenn man einen ESXi bei Hetzner gehosted hat und er mit nacktem Pöter im Netz steht.

ESXi "Willkommensbildschirm"

Um diese Seite zu entfernen, reicht es aus, die /usr/lib/vmware/hostd/docroot/index.html umzubenennen:

mv /usr/lib/vmware/hostd/docroot/index.html /usr/lib/vmware/hostd/docroot/index.html.bak

Wer abgesehen vom ESXi bei Hetzner oder sonstwo noch einen Server mit fester IP hat, sollte sich vielleicht überlegen, das Routing dahingehend zu ändern, dass der ESXi nur via dieser anderen statischen IP erreichbar ist. Denn die Konsole des ESXi direkt im Netz halte ich für keine besonders gute Idee… Just my 2 cent.

Da ja doch der ein- oder andere VMware Admin mitliest, möchte ich mal auf die kürzlich erschienenen Patches hinweisen. Unter den folgenden Links kommt ihr zu den KB Artikeln.

ESX:

ESXi:

Ich für meinen Teil, lasse Patches meist ne Woche oder auch zwei liegen wenn es nicht wirklich kritisch ist. Schon oft vorgekommen, dass Patches eher etwas kaputt patchen. Wie verhaltet ihr euch bei neuen Patches und wieso gerade so?

VMWare Produkte hinter einer Firewall oder durch eine Firewall hindurch zu administrieren war bisher immer ein Trial and Error zwischen Firewall-Log beobachten und Regeln anpassen. VMWare hat sich aber endlich erbarmt und einen KB Eintrag erstellt. Wer also schonmal auf der Suche nach den verwendeten Ports der ESX, ESXi, Orchestrator oder dergleichen war, wird jetzt hier fündig.

[VMWare KB1012382]

Anscheinend total an mir vorrüber gegangen ist VMware MVP. Ein Bare-Metal-Hypervisor für Handys. Da die Handys von Heute schon einiges unter der Haube haben, war es eigentlich nur eine Frage der Zeit bis so etwas kommt. Da habe ich eine VM mit meinen Handyspielchen und allerlei Schnickedöns für zu Hause  und eine für die Firma, die blank nur zum kommunizieren ist. Lese heute zum ersten mal davon. Komisch, muss anfang des Jahres im Feedreader an mir vorbeigerauscht sein.

Auf meiner Workstation im Home Office läuft momentan noch das 7100 Build des Windows 7 Release Candidate und werde wohl auch bei Windows 7 bleiben. Gefällt mir diesmal wirklich gut, ist halt das, was Vista hätte werden sollen. Naja um aber auch wirklich produktiv damit arbeiten zu können, ist es für mich unbedingt notwendig, dass der VMware Infrastructure Client läuft. So habe ich ihn gestern mal installiert und wurde mit einer erfolgreichen Installation belohnt. Doch jetzt kommt das Aber. Den VI-Client starten, hat auch noch geklappt, doch beim verbinden mit einem ESXi poppten 2 Fehlermeldungen auf und nichts passierte.

Nach kurzem googlen fand ich auch schon den KB1011329 bei VMware. Und was soll ich sagen, die Methode mit der system.dll eines nicht- Windows 7 ist zwar nicht offiziell supported, funktioniert bei mir aber einwandfrei…

Raid im Arsch, keine Backups, ESX/ESXi bootet nicht mehr… Es gibt ne Menge Szenarien, die einem Admin den Schweiß auf die Stirn zaubern. Oder wie kommt man an die virtuellen Maschinen auf dem Vmware File System ran wenn man nur die Platte und keine passende Hardware hat z.B.?

Hier kommt der VMFS Treiber von fluid Operations ins Spiel. Er setzt auf Java auf und ist somit nicht Abhängig von der Wahl des Betriebssystems. Ich habe mir eine SLAX BootCD gebastelt, mit man im Notfall Zugriff auf die Dateien hat. Ein passendes Howto wie man sich eine solche Notfall CD/USB Stick baut gibt es hier.

Leider ist das mounten des VMFS noch nicht möglich, soll aber in einem späteren Release folgen. So kann man bisher aber immerhin einen WebDAV Server starten und sich die VMs runterziehen. Wobei man sich dann ja das WebDAV lokal mounten kann… Naja ist zwar ein kleiner Umweg, sollte aber dennoch funktionieren.

Die CLI Referenz gibts hier.

Achja, per Default startet der WebDAV auf dem Localhost Interface, um ihn an eine andere IP zu binden reicht es die IP hinten dran zu hängen…

java -jar fvmfs.jar /dev/sda3 webdav 192.168.20.11

VMFSTools (C) by fluid Operations (v0.9.8.15 r87 / 2009-09-24_16-12-03)

http://www.fluidops.com

*** Serving WebDAV/HTTP at http://192.168.20.11:50080/vmfs
log4j:WARN No appenders could be found for logger (org.mortbay.log).
log4j:WARN Please initialize the log4j system properly.

Ich mag es eigentlich nicht so gerne wenn SSH auf dem Standardport läuft. Ein bisschen Paranoia kann nie schaden. Also habe ich bei dem ESXi im Hetzner RZ den SSH Port umgebogen.

Hierzu in der /etc/services die Zeilen für den SSH Dienst suchen:

ssh             22/tcp                         # SSH Remote Login Protocol
ssh             22/udp                         # SSH Remote Login Protocol

und die Ports auf die gewünschten und noch verfügbaren Werte abändern.

Anschließend die inetd Prozessnummer suchen:

~ # ps |grep inetd
4891 4891 busybox              inetd

und den Dienst einmal abschießen.

kill -HUP 4891

Der ESXi lauscht auf einem anderen Port und ist somit schonmal ein Stück weit sicherer geworden, zumindest was Portscans gezielt auf Port
22 angeht. Über sichere Kennwörter muss ich hier hoffentlich niemanden aufklären.

Vorgestern habe ich auf meinem neuen Rootserver den ESXi installiert. An dieser Stelle möchte ich mich nochmal bei dem Hetzner Support bedanken, der meiner Meinung nach wirklich flott gearbeitet hat.

[14:13 Uhr]

Anfrage zur zusätzlichen Buchung des Flexipack + Intel NIC abgeschickt. In der gleichen Mail bereits geschrieben, dass ich den ESXi installieren möchte, für meine IPs jeweils MAC Adressen brauche sowie die LARA Console.

[14:39 Uhr]

Anfrage des Support wann es losgehen kann. 10 – 15 Minuten später ein GO geantwortet.

[15:25 Uhr]

Zugangsdaten zur LARA erhalten und gleich angefangen zu installieren.

[15:36 Uhr]

Email mit den gewünschten MAC Adressen.

[16:45 Uhr]

Installation abgeschlossen… Alleine das Booten von einem Lokal liegenden ISO hat ca. ne Stunde gedauert, danach ging alles recht flott. Passwort eingestellt, SSH aktiviert, ein Reboot und fertig.

Wenn man weniger als 1Mbit Upload hat, sollte man vielleicht nachfragen ob der Support ein USB Cdrom mit der ESXi Installations CD anklemmen kann, bei 1 Mbit reichen die 2 Stunden LARA vollkommen aus.

Also beide Daumen hoch !!!

Der Linuxclient soll sich ja bereits in der Entwicklung befinden, doch bis es so weit ist und er endlich erscheint, nutze ich einen Trick, der zumindest den Anschein hat als würde der Client nativ unter Linux laufen.

Ist natürlich ganz schön gemogelt aber was tut man nicht alles…

1. Unter Linux installiert man sich den RDP Client RDesktop.

2. Auf dem Windowsserver, wo auch der vSphere Client installiert ist, das Paket seamlessrdp.zip von Cendio herunterladen und entpacken.

3. Auf dem Linux einen Programmstarter, Link oder was auch immer mit folgendem Inhalt erstellen:

rdesktop -A -s "c:\seamlessrdp\seamlessrdpshell.exe C:\PROGRA~1\VMware\INFRAS~1\VIRTUA~2\Launcher\vpxClient.exe" 192.168.20.14

Die Pfade und die IP des Windowsservers müssen eventuell angepasst werden.