Seit dem Update auf Version 6 funktioniert anscheinend der Zugriff auf die VMFS nicht mehr per Direct SAN Access, sondern nur noch übers Netzwerk.
Das Problem ist bei Veeam bekannt. Ein entsprechender KB Artikel ist auch bereits veröffentlicht. In meinem Fall hat die Installation des Hotfix 1 für Veeam Backup 6.0.0.153 das Problem behoben
Das bekannte Performance Troubleshooting for VMWare vSphere 4 Guide wurde überarbeitet und liegt jetzt in einer Version für vSphere 4.1 vor. Schritt für Schritt wird erklärt, wie eine Fehlersuche bei Performanceproblemen durchgeführt werden sollte.
Auf meiner VMware Site habe ich noch mehr interessante Tools / Guides aus der VMTN Community zusammengestellt.
Ist in einem ESX(i) Server ein Tape Laufwerk eingebaut, konnte dies bisher relativ problemlos einer VM zugewiesen werden. Voraussetzung dafür ist natürlich ein unterstützter SCSI / SAS Controller (siehe HCL).
Nach einem Upgrade auf vSphere 4.1 ist es möglich, dass das Laufwerk nicht mehr richtig erkannt wird. Ein Blick in die Speichergeräteverwaltung des ESX zeigt zwar den Controller, aber nicht mehr das Gerät selbst an. Der Pfad zum Gerät wird als “Broken” angezeigt.
Die Ursache liegt in einer “falschen” Einstellung der Pluggable storage architecture (PSA). Der Controllertreiber wird als ALUA SATP Modul geladen. Da hier aber kein Multipathing unterstütz wird, kann das Gerät nicht richtig angesprochen werden.
Um das zu beheben muss eine SATP Regel erstellt werden.
Eine genaue Anleitung gibt es in meinem Wiki.
Auch mit Version 7 der VMware Workstation kann nicht von USB gebootet werden. Einen kleinen Workaround möchte ich aber kurz beschreiben. Mit einem ISO Image (CD) kann ein Bootloader gestartet werden, der wiederum von USB starten kann.
Benötigt wird dazu natürlich ein CD-Rom LW in der VM. Mit einem kostenlosen Bootloader als ISO File wird die VM gestartet, der USB Stick verbunden und schon kann von USB gebootet werden. Eine ausführlichere Anleitung findet ihr im Amrila Wiki.
Mit dem Release von vSphere 4.1 hat VMware angekündig, künftig keine ESX Server mit Service Console mehr zu vertreiben. Künftig wird es nur noch den VMware Hypervisor (ESXi) geben. Viele ESX Admins müssen sich nun entscheiden, ob Sie den Schritt zur ESXi Variante jetzt, oder der nächsten Version gehen wollen. Meiner Erfahrung nach gehen viele bereits beim Wechsel auf 4.1 zur schlanken Hypervisor Edition über.
Ein direktes Upgrade von ESX 4.0 auf ESXi 4.1 ist nicht möglich. VMware hat dem Thema ein eigenes Upgradeportal gewidmet. Die sauberste Variante für einen Wechsel ist die Neuinstallation. Je nach Anzahl der vorhandenen Server ist dies mit mehr oder weniger Zeitaufwand verbunden.
Vorstellen möchte ich hier die Variante USB Stick. Da ich selber nur mit HP Hardware zu tun habe, bietet sich hier eine interessant Möglichkeit an. Nämlich das Kombinieren der USB Boot Sticks (Smart Start / DVD Firmware Upgrade) mit dem VMware Installations Image.
Alles was wir benötigen ist das USB Key Utility und ein ISO Image einer Smart Start. So lässt sich in kurzer Zeit ein bootfähiger USB Stick erstellen. Anschließend natürlich noch das VMware ISO Image darauf entpacken. Nun noch ein paar kleine Anpassungen durchführen und fertig ist der “HP Multi Installation USB Stick”.
Eine genaue Anleitung zum Erstellen habe ich in meinem Wiki hinterlegt.
Soll VMotion auf ESX Hosts mit unterschiedlichen CPU Typen eines Herstellers funktionieren, muss ein EVC Cluster unter VMware konfiguriert werden. Damit lässt sich der “kleinste gemeinsame Nenner” der CPU Befehle konfigurieren.
Vorteil : VMotion funktioniert mit unterschiedlichen CPU Generationen
Nachteil : Um die Kompatibilität zu gewährleisten werden CPU Befehle neuerer Prozessoren werden nicht verwendet (u.U. Performancenachteile)
Eine ausführliche Beschreibung (KB1003212) befindet sich in der VMware Knowledge Base.
Viele Admins setzen Virtualisierung mit zentraler Storage ein. Oftmals kommt eine Kombination VMware vSphere und HP EVA zum Einsatz. Um ein optimales Zusammenspiel beider Komponenten zu erreichen sind bei der Installation / Konfiguration einige Dinge zu beachten. Wichtig ist eine richtige Konfiguration / Präsentation der LUNs, aber auch am Multipathing von VMware sollten Änderungen vorgenommen werden. Außerdem kann eine enorme Performancesteigerung erreicht werden, wenn an den richtigen Schrauben gedreht wird.
Eine Zusammenfassung der wichtigsten Einstellungen / Empfehlungen habe ich in meinem Wiki hinterlegt.
Seit heute ist VMware vSphere 4.1 verfügbar. Ein ausführlicher Artikel folgt heute noch. Inzwischen gibt es ja genug Informationen zu den technischen Neuheiten auf den verschiedenen Blogs oder VMware. Daher werde ich euch jetzt eine Auflistung ersparen.
Sehr interessant ist, dass VMware die Lizenzierung ein klein wenig umgestellt hat. Es gibt immer noch die gleichen Lizenzen ABER in der Standard Version ist ab sofort VMotion enthalten. Anbei noch eine Übersicht der Editionen und Funktionen.
Über den Punkt Advanced LVM Settings wird unter ESX / ESXi 3.5 das Verhalten bei erkannter Snapshot LUN konfiguriert. Zum einen gibt es EnableResignature. Bei Aktivierung kann der ESX Server eine neue Signatur auf die LUN schreiben. Dies passiert wenn z.B. eine bekannte Partition unter einer anderen LUN ID erscheint. Zum anderen wird mit DisallowSnapshotLUN das Mounten eines Replicas einer bereits bekannten LUN gesteuert.
Beide Optionen gelten systemweit für jede erkannte LUN.
Unter ESX / ESXi 4 gibt es diese Parameter nicht mehr. Statt dessen wird die Konfiguration in die Konsole verlagert. Somit kann jede LUN unterschiedlich angepasst werden. Zusätzlich kann auch über den vSphere Client eine Konfiguration vorgenommen werden. Beim Hinzufügen neuer LUNs können z.B. Replicas eingebunden werden.
Anzeige der Erkannten LUNs
esxcfg-volume –l
Mount der LUN bis zum nächsten Reboot
esxcfg-volume –m “<VMFS UUID|label>”
Dauerhafter Mount der LUN
esxcfg-volume –M “<VMFS UUID|label>”
Resignatur der LUN
esxcfg-volume –r “<VMFS UUID|label>”
Aktuell kommt es bei vielen vSphere Installationen zu Fehlern beim Starten des Clients. Der Client bricht mit folgender Meldung ab :
Schuld daran hat ein Microsoft Windows Update (KB980773). Nach einer Deinstallation funktioniert es in den meisten Fällen wieder.
Alternativ wird die Installation des neuesten vSphere Clients empfohlen
Einen entsprechenden VMware KB Artikel gibt es bereis. Betroffen sind alle Versionen vor Update 1 (Build Nummer 208111).
Nähere Informationen stehen auch in meinem Wiki.
Letzte Kommentare