Total Verfriemelt

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]

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 habe gerade an einem Webinar zum Thema Storage in Verbindung mit vSphere teilgenommen. Die wichtigsten Neuerungen in meinen Augen sind wohl Chap/mutual Chap Secrets bei iSCSI über ein vmkernel Interface und ThinProvisioning mit vergleichsweise niedrigem Perfomanceverlust.

Die Best Practice Guides empfahlen in der Vergangenheit immer auf ThinProvisioning zu verzichten, laut Chat- Antworten der Moderatoren wird durch einen neuen opportunistic locking Mechanismus verhindert, dass sich die Fragmentierung auf die Perfomance des VMFS auswirkt und somit kaum Geschwindigkeitsverluste zu erwarten sind. ThinProvisioning hat den entscheidenden Vorteil, dass der physisch verbrauchte HDDSpace auf dem Storage dynamisch mitwachsen kann und nicht gleich das komplette Storage vollgeballert wird.

Es wird zudem noch einen neuen paravirtualisierten Treiber für W2K3, W2K8 und RHEL5 geben, der sich deutlich positiv auf die Perfomance der VM auswirkt.

Tolle Artikel bei Gabe entdeckt… Über die meisten Sachen habe ich mir ebenfalls schon Gedanken gemacht, Gabe bringt es aber auf den Punkt.

My conclusion, on the hypervisor hardware is that the VMware HCL is not limiting me in choosing my hardware at all. In fact, choosing a system that is on the VMware HCL makes me more confident that I have reliable hardware that will perform without issues and I can’t get this with Hyper-V.

Teil 1: Hardware

Teil 2: Guest OS and Memory overcommit

Teil 3: Motions and storage

Da ich noch einen Intel Core2Duo E6400 sowie 4 GB DDR2 Ram rumfliegen habe werde ich mir mal ein Testsystem zusammenbasteln um nicht ständig wilde Experimente auf den Produktivsystemen fahren zu müssen. Jedem der ähnliches vor hat, kann ich nur einen Blick in die inoffizielle Whitebox-HCL nahe legen.

Alles was mir fehlt ist also ein Mainboard, glaube ich werde auf das Gigabyte EP35-DS3L setzen. Das sollte bestückt mit 2 Intel oder 3COM NICs anständig zu gebrauchen sein.

Das Webgebrabbel über Microsofts Hyper-V nimmt allmählich zu und sicher fragen sich viele wie es mit der Perfomance im Vergleich zum ESX Server aussieht. Kenon Owens von VMware hat einen lesenswerten Artikel veröffentlicht, der beide Produkte in Benchmarks gegenüberstellt. Leider sind nicht die gleichen Konfigurationen benutzt worden, trotzdem könnte es bei gleichem Setup zumindest so ähnlich aussehen. Die Benchmarks selbst, sind übrigens von einer unabhängigen Firma

Die Ergebnisse sprechen aber für sich… Naja wir werden sehen was noch kommt.