Neuer Patch von VMware: ESX(i) 4.0.0U1a

Friday, 11 December 2009 18:07:42 (W. Europe Standard Time, UTC+01:00)


Nachdem es doch einige Probleme mit dem neusten Updatepaket von VMware gibt, hat der Softwarehersteller eine zweite Auflage des Update1 Paketes für ESX(i) 4.0.0 herausgebracht. Der Patch ist vornehmlich an alle Kunden gedacht, die zum Einen Hardwareagenten in der Service Console oder modifizierte ESX(i) Varianten einsetzten und zum Zweiten die Updatepakete per Updatemanager installieren.
Neben dem ersetzenden Update1 Paket kommt direkt noch ein weiterer Patch für das GLIBC Paket mit, das auch außer der Reihe publiziert worden ist.
Kunden die bereits Update1 auf den ESX(i) ausgebracht haben erhalten lediglich ein Update der GLIC Bibliothek und eine Änderung in der Paketverwaltung von RedHat (RPMD).
Das Updatepaket kann jetzt, wie gewohnt über den UpdatemNager auf die Hosts ausgebracht werden.

Alle Knowledgebase Artikel zum Patch:

KB1016070

Due to a possible dead lock on rpmdb, upgrading ESX 4.0 to 4.0 Update 1 can fail or time out and leave the host in an unusable state

http://kb.vmware.com/kb/1016070

KB1016262

vCenter agent service does not install or upgrade on ESXi 4.0 hosts

http://kb.vmware.com/kb/1016262

KB1014842

VMware ESX 4.0, Patch ESX400-Update01a

http://kb.vmware.com/kb/1014842

KB1014797

VMware ESX 4.0, Patch ESX400-200912101-UG: Updates Service Console glibc

http://kb.vmware.com/kb/1014797


APC PowerChute neue Version 2.2.4

Monday, 07 December 2009 12:43:41 (W. Europe Standard Time, UTC+01:00)

Heimlich, still und leise hat der USV Hersteller eine neue Version von PCNS heraugebracht. Neben der Unterstützung von Windows & Co. gibt es das neue Paket auch für Linux.
In der Knowledgebase von APC befinden sich zudem einige PDF Dokumente zum Gebrauch der Software in Verbindung mit VMware ESX(i) Systemen. Insbesondere die Verwendung mit ESXi ist etwas neues, wobei diese Variante auch schon für die Hypervisor der Generation VMware ESX(i) 3.5.x verfügbar war.
Wir schauen dem Paket mal unter die Haube... .
Das Paket kann nicht direkt auf dem ESX(i) Server installiert werden, dazu benötigt man nachwievor die Vorgängerversion 2.2.3 Neu ist, dass man zur USV Steuerung einfach eine vMA Appliance verwendet und die Software einfach in das Linux dieser speziellen VM installiert und konfiguriert. Neben dieser vom Hersteller propagierten Version bevorzuge ich allerdings die parallele Installation auf mehrere Systeme:

  • Installation Version PCNS 2.2.3 auf alle ESX Server
  • Installation Version PCNS 2.2.4 in eine vMA Appliance pro Cluster (Redundanzgründe) bei ESXi Umgebungen
  • Installation Version PCNS 2.2.4 in die vCenter VM und dann Hinterlegung von PowerShell Skripten zum gesteuerten Herunterfahren von allen VMs, ja allen VMs auch vom SQL Server und dem vCenter Systems, wie das funktioniert erläutere ich in einem separaten Blogeintrag (später) :-)

Die Installationsquellen befinden sich auf einem gesicherten FTP Server, der Einstigespunkt für den Downlaod erreicht man über:
https://www.apc.com/tools/download/index.cfm

Voraussetzung für den Zugriff auf den Download ist eine Registrierung unter der Website apc.com.

PSOD nach Update auf VMware ESX 4.0.0 Update1

Wednesday, 25 November 2009 12:54:20 (W. Europe Standard Time, UTC+01:00)
Gestern erhielt ich eine E-Mail von Kollegen aus den Staaten, dass es derzeit zu Problemen mit dem Einspielen des Update1 Paketes über den VMware Update Manager für den ESX Server kommen kann.
Die Probleme können genau dann entstehen, wenn auf der Service Console eines ESX 4.0 Systems Drittanbieter Agenten installiert worden sind und diese im Status "laufend" sich befinden.
Inwiefern auch ein Upgrade der Version ESX 3.x auf ESX 4.0.0U1 betroffen ist oder die manuelle Installation in der SC selber oder über das "Host Update Utility" des vSphere 4.0 Clients betroffen ist, kann ich und konnten meine Kollegen weder bestätigen noch ausschließen. Generell empfehle ich mit dem Update auf Version ESX 4.0.0 U1 und auf ESXi 4.0.0 U1 zu warten.
Als Workaround bietet der Hersteller Vmware untwer dem folgenden KB Artikel eine Lösung für das Problem an:

http://kb.vmware.com/kb/1016070

Will man also ein System aktualisieren, auf dem zum Beispiel eine Hardwareüberwachung wie DELL OMSA oder HP Insight Manager installiert worden ist, so sollten diese Dienste vor dem Start der Aktualisierung in der SC deaktiviert werden. Nach der Installation und dem Neustart des Hosts können die Agenten wieder gestartet werden.
Hat ein Kunde bereits die Installation ausgelöst, so ist umgehend ein Support Call bei VMware zu eröffnen, da es ansonsten zu Datenverlust kommen kann. Betroffen davon sind insbesondere Systeme mit lokal angeschlossenem Storage. iSCSI und FC Laufwerke sollen allerdings nicht dieses Fehlerbild aufweisen. Wir bleiben dran...

911 - VMware ESX/ESXi 4.0 on Engeneering Hold

Saturday, 01 August 2009 13:47:10 (W. Europe Daylight Time, UTC+02:00)
Seit dem 21. Juli verdichten sich die Gerüchte um ein großes Treiberproblem innerhalb der Standardtreiber für VMware ESX 4.0.0. :-S
Dabei handelt es sich wohl um ein Problem mit lokal eingebauten und eingebundenen Bus Adaptern zur Massenspeicheranbindung, näher um LSI und Adaptec basierte Controller für SAS, (Parallel-) SCSI und S-ATA Festplatten. Werden diese in einem Host verwendet, so kann es unter Umständen dazu kommen, dass im Falle einer Abschaltung des Servers der Cache der Adapter nicht ordnungsgemäß auf die angeschlossenen Festplatten geschrieben wird. Das führt wiederum unweigerlich zu korrupten Daten, wenn die Batterie der RAID Controller leer läuft und im Fall von lokal angeschlossenen VMFS Laufwerken auf einem Host wahrscheinlich zu Datenverlust!
Da beim ESX 4.0 Server die SC als VMDK Datei auf dem lokalen VMFS Laufwerk vorgehalten wird, sollte der Patch unverzüglich auf alle ESX 4.0.0 Systeme gleich welcher Patch- / Buildstand ausgebracht werden. Der ESXi Server ist davon zur Zeit nicht betroffen.



Der Fehler wurde von VMware bereits veröffentlicht:
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1012794


Gestern habe ich dazu eine sehr wichtige E-Mail über meine DELL Kanäle erhalten.
DELL geht davon aus, dass in den nächsten Tagen (03.08.) ein ausserplanmäßiges Update bereitgestellt wird, das den Fehler im Treiber behebt.
Die Tests laufen wohl schon, dauern allerdings bis zu 2 x 48h, da der RAID Controller/Cache nur alle 48h eine vollständige Entladung der Batterie erfährt.

Man sollte jetzt nicht panisch reagieren und ein Downgrade auf die Version ESX 3.5.0U4 durchführen, sondern dafür sorgen, dass die Server am (Strom-)Netz bleiben und nicht längerfristig vom Strom getrennt werden. Dazu sollte man die DPM Funktion in vSphere 4.0 temporär auf manuell setzen oder komplett abschalten. ;-)

DELL OMSA Software Installation mit Hindernissen

Tuesday, 28 July 2009 07:41:34 (W. Europe Daylight Time, UTC+02:00)
Die neuen Pakete für DELL OMSA 6.1.0 erkennen bei einer ESX 4.0.0build164009 Basisinstallation fälschlicherweise eine bestehende OMSA 5.3.0 Installation, da der Installer die Abhängigkeiten in der RPM Datenbank abfragt.




Dazu habe ich einen Call bei DELL eröffnet und zusätzlich in den VMware Foren ein Workaround gefunden:

VMware Community vSphere 4.0 | ESX 4: http://communities.vmware.com/message/1321651#1321651
Alternativ hier als pdf Dokument: dell-omsa-6.1.0-on-esx-4.0.0-classic.pdf (71,51 KB)
Die interessante Passage habe ich mit einem gelben Textmarker markiert.

Der Installer denkt, es gäbe bereits eine alte Version von OMSA auf dem System und kommt aus dem Tritt. Abhilfe schafft hier das direkte installieren der RPM Pakete für "ESX40" und das manuelle öffnen der Firewall. ESX 3.5.0 Update 4 Systeme sind von dem Fehler nicht betroffen. Damit eine Installation des OMSA Clients auf den ESX 4.0.0build164009 reibungslos ablaufen kann muss man zuvor über folgende Befehlszeile als Administrator 'root' absetzen:

OSX-1057-XSTCGN:~ carsten$ ssh root@esx-400-xstcgn.xsteam.eu
root@esx-400-xstcgn.xsteam.eu's password:
Last login: Tue Jul 28 09:11:37 2009 from 10.2.110.121
[root@esx-400-xstcgn ~]# rpm -e --noscripts `rpm -qa | grep srvadmin`

Bei der neuen ESX 4.0.0 ISO Image Installation mit dem Build Stand: esx-DVD-4.0.0-171294.iso klappt die Installation auf Anhieb:

OSX-1057-XSTCGN:~ carsten$ ssh root@esx-400-xstcgn.xsteam.eu
root@esx-400-xstcgn.xsteam.eu's password:
Last login: Tue Jul 28 09:28:53 2009 from 10.2.110.121
[root@esx-400-xstcgn ~]# cd /tmp/
[root@esx-400-xstcgn tmp]# ls -alh
total 104M
drwxrwxrwt  5 root root  28K Jul 30 09:31 .
drwxr-xr-x 26 root root 4.0K Jun 25 12:54 ..
-rw-r--r--  1 root root 1.9K Jul 27 18:54 hostCompatList
drwxr-xr-x  2 root root 4.0K Jul 27 11:06 hsperfdata_root
drwxrwxrwt  2 root root 4.0K Jun 25 12:54 .ICE-unix
-rw-r--r--  1 root root 104M Jul 30 09:32 OM_6.1.0_ManNode_A00.tar.gz
drwxr-xr-x  3 root root 4.0K Jul 30 08:57 sfcb
[root@esx-400-xstcgn tmp]# tar -xvzf OM_6.1.0_ManNode_A00.tar.gz
[root@esx-400-xstcgn tmp]# .linux/supportscripts/srvadmin-install.sh -d -w -r -s <--- !!!Neu!!! Die Option 'd' (DELL agent) ersetzt die alte Option 'b' (base packages)

Installing the selected packages.

warning: srvadmin-cm-6.1.0-648.i386.rpm: Header V3 DSA signature: NOKEY, key ID 23b66a9d
Preparing...                ####################################### [100%]
   1:srvadmin-omilcore      ####################################### [  6%]
     To start all installed services without a reboot,
     enter the following command:  srvadmin-services.sh  start
   2:srvadmin-omcommon      ####################################### [ 12%]
   3:srvadmin-hapi          ####################################### [ 18%]
   4:srvadmin-syscheck      ####################################### [ 24%]
   5:srvadmin-deng          ####################################### [ 29%]
   6:srvadmin-omacore       ####################################### [ 35%]
   7:srvadmin-isvc          ####################################### [ 41%]
   8:srvadmin-omauth        ####################################### [ 47%]
   9:srvadmin-wsmanclient   ####################################### [ 53%]
  10:srvadmin-rac5-component####################################### [ 59%]
  11:srvadmin-jre           ####################################### [ 65%]
  12:srvadmin-cm            ####################################### [ 71%]
  13:srvadmin-iws           ####################################### [ 76%]
  14:srvadmin-omhip         ####################################### [ 82%]
  15:srvadmin-racadm5       ####################################### [ 88%]
  16:srvadmin-racdrsc5      ####################################### [ 94%]
  17:srvadmin-storage       ####################################### [100%]
[root@esx-400-xstcgn supportscripts]#
[root@esx-400-xstcgn supportscripts]# mv /vmfs/volumes/esx-400-xstcgn-local/DELL_OMSA.xml /etc/vmware/firewall/.
[root@esx-400-xstcgn supportscripts]# esxcfg-firewall -e 'DELL OpenManage Request'
[root@esx-400-xstcgn supportscripts]# service mgmt-vmware restart
Stopping VMware ESX Management services:
   VMware ESX Host Agent Watchdog                          [  OK  ]
   VMware ESX Host Agent                                   [  OK  ]
Starting VMware ESX Management services:
   VMware ESX Host Agent (background)                      [  OK  ]
   Availability report startup (background)                [  OK  ]
[root@esx-400-xstcgn supportscripts]# ./srvadmin-services.sh start
Starting Systems Management Device Drivers:
Starting dell_rbu:                                         [  OK  ]
Starting ipmi driver: Already started                      [  OK  ]
Starting snmpd:                                            [  OK  ]
Starting Systems Management Data Engine:
Starting dsm_sa_datamgr32d:                                [  OK  ]
Starting dsm_sa_eventmgr32d:                               [  OK  ]
Starting dsm_sa_snmp32d:                                   [  OK  ]
Starting DSM SA Shared Services:                           [  OK  ]
Starting DSM SA Connection Service:                        [  OK  ]
[root@esx-400-xstcgn supportscripts]#

Danach kann man wie gewohnt die lokale DELL OpenManage Installation über einen unterstützten Webbrowser aufrufen:
https://esx-400-xstcgn.xsteam.eu:1311

DELL OpenManage OMSA Security Profile

Friday, 24 July 2009 17:37:47 (W. Europe Daylight Time, UTC+02:00)
Ein kleines Goodie am Rande:
Wer Anwendungenn in die SC installieren muss der weiß, dass die Firewall zumeist auch angepasst werden muss. Dabei kann man über das Kommandozeilenwerkzeug von VMware esxcfg-firewall die eingebaute Firewall manipulieren.
Leider sieht man im vSphere Client nicht, dass es ein weiteres Sicherheitsprofil gibt und ahnt, wenn man nur auf der GUI agiert nicht, dass im System weitere Änderungen an der Firewall vollzogen worden sind.

Auf der Kommandozeile würde man wie folgt den einzelnen OMSA Port freigeben können:
esxcfg-firewall -o 1311,tcp,in,OpenManageRequest

Wer gerne auch "sieht" was er einrichtet kann gerne ein Sicherheitsprofil anlegen und über dieses dann die Portkontrolle ausüben:
<!-- Firewall configuration information for DELL OpenManage SystemAdaministrator -->
<ConfigRoot>
    <service>
    <id>DELL OpenManage Request</id>
        <rule id='0000'>
            <direction>inbound</direction>
            <protocol>tcp</protocol>
            <port type='dst'>443</port>
            <flags>-m state --state NEW</flags>
        </rule>
        <rule id='0001'>
            <direction>inbound</direction>
            <protocol>tcp</protocol>
            <port type='dst'>1311</port>
            <flags>-m state --state NEW</flags>
        </rule>
        <rule id='0002'>
            <direction>outbound</direction>
            <protocol>tcp</protocol>
            <port type='dst'>443</port>
            <flags>-m state --state NEW</flags>
        </rule>
        <rule id='0003'>
            <direction>outbound</direction>
            <protocol>tcp</protocol>
            <port type='dst'>1311</port>
            <flags>-m state --state NEW</flags>
        </rule>
    </service>
</ConfigRoot>

Und wer will kann auch die fertige Datei direkt hier herunterladen: DELL_OMSA.xml (,80 KB)
Das fertige Profil muss dann nur noch in der SC abgelegt werden und mit der Firewall geladen werden:
root@esx40 #cp ./DELL_OMSA.xml /etc/vmware/firewall/.
root@esx40 #esxcfg-firewall -e "DELL OpenManage Request"
root@esx40 #service firewall restart
root@esx40 #service mgmt-vmware restart <-- sorgt dafür, dass der vSphere Client das neue Profil auch anzeigt! (!!!Achtung, bei direkten Connect auf den ESX wird vSphere Client Sitzung getrennt!!!)

Viel Erfolg beim umsetzen

Hostprofiles oder "was geht konkret" (nicht)?

Wednesday, 22 July 2009 07:12:34 (W. Europe Daylight Time, UTC+02:00)
Mit VMware vSphere 4.0 wurde zum ersten Mal ein Werkzeug eingeführt, mit dessen Hilfe ein Anwender überprüfen kann, ob alle Hosts eines Clusters die identische Konfiguration halten. Bisher musst man entweder auf der Kommandozeile im VI Toolkit oder über die BASH skripten, um eine einheitliche Konfiguration zu erzielen.
Jetzt ist alles anders, wirklich Alles?

Die VMware Host Profiles sind ein ideales Überwachungswerkzeug, dass man direkt aus der GUI des vSphere Clients starten kann. Allerdings ist diese Funktion nur für Kunden verfügbar, die die Version Enterprise Plus lizenziert haben.
Leider werden nicht alle Einstellungen eines Referenz ESX Servers von den Host Profiles übernommen und dann auf andere Hosts übertragen.
Die nachfolgende Auflistung gibt Punkte wieder, die nicht über diese Funktion ausgerollt werden können:
Netzwerkkonfiguration:
  • Statische Routen für IPv4 und IPv6 Netzkonfigurationen
  • Zuordnung der vmnics (physische Netzadapter) zu vSwitches auf Basis der PCI Slotordnung
Speicheranbindung:
  • iSCSI HBA and targets
  • LUN Multipathing Richtlinie (PSP)
    • Fixed
    • Round-Robin
    • MRU
  • PSA Konfigurationen außerhalb der automatischen Konfiguration (NMP)
Sicherheitsprofile:
  • Administrative Passwörter
  • Host UUID (Unwichtig, eher besser)
  • selbst generierte Sicherheits Profile

An dieser Stelle sollte man die Hostprofiles als "Richtschnur" nutzen und die Feinkonfiguration über Skripte organisieren, damit eine einheitliche Konfiguration aller Hosts möglich ist.

Erste Updates für vSphere 4.0

Friday, 17 July 2009 22:10:15 (W. Europe Daylight Time, UTC+02:00)
Nachdem die RTM / GA Version von VMware vSphere 4.0 seit dem 22. Mai verfügbar ist wurden die ersten Updates für den ESX(i) Server 4.0.0 veröffentlicht. Das Updatepaket beinhaltet dabei einige wichtige Sicherheitsupdates für Linux Module innerhalb der aktuellen SC mit dem modifizierten RHEL 5.1 für x86-64.

Das Updatepaket von VMware für die einzelnen Varianten von VMware ESX 4.0.0 wurde mit Größen zwischen 163,4MB und 377,9MB nicht gerade klein.
Parallel dazu wurden die ISO Dateien auf der Downloadseite angepasst und tragen nun den folgenden Build-Stand:
VMware ESXi installable VMware-VMvisor-Installer-4.0.0-171294.x86_64.iso
VMware ESX "Classic"    esx-DVD-4.0.0-171294.iso

Ich bin gespannt wann das vCenter geupdatet wird, da es zur Zeit zwei kleinere Probleme gibt:
  1. Reboot der vCenter VM an einem dvSwitch schlägt fehl, genau wie das Clonen / Deploy an eine dvSwitch Portgruppe
  2. Memory-Leak in der Tomcat Server Engine
Es bleibt also spannend!

DELL OpenManage 6.1 für VMware ESX Server 4.0.0

Friday, 17 July 2009 16:18:20 (W. Europe Daylight Time, UTC+02:00)
Nachdem ein paar Wochen ins Land gegangen sind, ohne dass man seine DELL Server mit OMSA ausstatten konnte, hat DELL mit der Version 6.1 eine unterstütze Version von OpenManage veröffentlicht, die VMware ESX(i) Server 4.0.0 unterstützt.
Dabei kann das Paket als einzelnes Installationspaket über die DELL Website heruntergeladen werden.



Die Installation erfolgt aus der SC heraus und bedarf keines Neustarts des Servers. Nach der Installation ist die ESX Server Firewall noch zu konfigurieren. Die Installation erfolgte über das Installationspaket „OM_6.1.0_ManNode_ A00.tar.gz“ Die Software kann wie gewohnt kostenlos über die DELL Website heruntergeladen werden.

Download Link OMSA Installationsquelle:
ftp://ftp.us.dell.com/sysman/OM_6.1.0_ManNode_ A00.tar.gz

Download Link OMSA Installationsanleitung:
Für ESX Server Version 3.0: http://www.dell.com/downloads/global/solutions/Installing_Dell_OpenManage_50_on_ESX_3.pdf
Für ESX Server Version 3.5 und 4.0 "Classic": http://support.dell.com/support/edocs/software/smsom/6.1/en/ug/html/instlx.htm#wp1054425

Für die ESXi Varianten bietet DELL mittlerweile eine eigene Kompilierung des Paketes für ESXi embedded an, bei der die OM Ageneten bereits integriert sind. Damit hat DELL mit HP gleichgezogen, die diese Verknüpfung für OpenView bereits seit einiger Zeit über die HP und VMware Website anbietet.
Neben der embedded Variante von DELL gibt es noch ein weiteres Paket für die Variante ESXi "installable". Dazu wird ein Frontend auf einem entferneten System installiert, das dann wiederum die ESXi OpenIPMI Schnittstelle DELL spezifisch abfragt und so den konkreten Maschinenzustand an OM weiterleiten kann. Der Anwender kann über diese Webschnittstelle zentral alle ESXi Systeme mit DELL Hardware abfragen. Es bleibt abzuwarten, wann die neuen Funktionen von vSphere 4.0 in der neuen DELL Management Console zusammengeführt werden.

Tar, Komprimieren und Archivieren auf der Kommandozeile

Monday, 13 July 2009 07:06:32 (W. Europe Daylight Time, UTC+02:00)
Dieser Artikel ist eine kleine Anleitung zum Archivierungswerkzeug “Tar”. Hier werden die “Basisfunktionen” kurz erläutert und darüber hinaus einige Kniffe und sinnvolle Anwendungsbeispiele vorgeführt. Tar ist ein Archivierungswerkzeug, das heißt man kann beliebig viele Dateien zu einer Datei, einem Archiv, zusammenfügen. Tar an sich ist kein Komprimierungstool, aber mit der “Erweiterung”/Option gzip und anderen kann man ein Archiv auch komprimieren. Den folgenden Artikel habe ich auf einem Blog im Internet gefunden und fand diesen so gut, dass ich den direkt eingebaut habe, alles was in den Beispielen für ubuntu beschrieben wurde gilt, wenn man mal über die Pfadangaben hinweg sieht uneingeschränkt für VMware ESX Server, deren SC Betriebssystem entweder RHEL 5.0 (ESX Server 4.0.0) oder RHEL 3 Update 9 (ESX Server 3.x.0)

Neuinstallation eines ESX Servers mit FC-SAN Anschluss

Thursday, 09 July 2009 14:31:00 (W. Europe Daylight Time, UTC+02:00)
Bisher war es immer sehr mühselig einen Host neu zu installieren, wenn dieser Host komplett gezont war und noch Zugriff auf die SAN hatte. Früher musste man am besten den Host entweder ohne verbundene FC Kabel starten, oder aus der Zone nehmen (FC-Fabric) oder eben auf der SAN selber den Zugriff für den Host auf die LUNs verhindern.

Dieser Prozess bedarf immer der Zusammenarbeit über Abteilungen hinweg, da in der Regel die Serveradministratoren keinen Zugriff auf die SAN Verwaltung besitzen und umgekehrt. Im Web gabe es Anleitungen, wie man von der ESX Server CD die SAN Treiber Optionen beim Installationsstart  entfernt, aber dass war natürlich mit jedem Versionswechsel erneut durchzuführen und damit sehr Pflege intensiv.

Mit vSphere 4.0 wird alles besser!
Wie ich in den vergangenen Wochen erfreulich feststellen konnte, erkennt der ESX Server jetzt alle LUNs, auch die lokale LUN (vmfs) und ändert die Reihenfolge der Laufwerke nicht mehr, denn mit ESX 4.0 wurde die Identifizierung der LUNs / Laufwerke auf NAA-Format umgestellt und die LUN / Laufwerkszuordnung ist und bleibt persistent!

Damit kann man nun ohne Eingriff in die SAN Verwaltung ESX Server installieren, sehr cool :-)

VMDK Festplattendateien Optionen unter vSphere 4.0

Friday, 12 June 2009 07:31:56 (W. Europe Daylight Time, UTC+02:00)

VMDK Dateien bilden den Standard bei der Konfiguration von VMs. Egal mit welchem Hypervisor von VMware ein Anwender eine VMDK erstellt, kann diese auch auf einem anderen Hypervisor genutzt werden. Dazu gibt es einige Einschränkungen.

Bisher konnte man nur mit den Desktop-Versionen so genannte "Thin-Provisioned" VMDKs also wachsende VMDK Dateien erstellen. Das funktioniert jetzt auch unter VMware vSphere 4.0 mit ESX 4.0. Im Prinzip konnte das der ESX Server ja schon immer, wenn man daran denkt, wie die Snapshotfunktion unter ESX funktioniert.

Was steckt aber hinter den einzelnen Optionen zum Anlegen einer neuen VMDK, insbesondere auf der Kommandozeile:

Thick:

Diese "dicken" Festplatten bezeichnen alle Formatierungsoptionen, bei denen die definierte Festplattengröße beim Anlegen der VMDK direkt auf dem Laufwerk allokiert wird.

Ist der Speicherplatz auf der LUN voll wird es nicht mehr möglich weitere VMDK Dateien zu erstellen. Eine Fragmentierung der Datendatei auf Ebene des VMFS Dateisystems ist nahezu ausgeschlossen. Nachteilig ist, dass der teure SAN-Speicherplatz direkt verloren geht.

Zerodthick:

Der Speicherplatz der VMDK wird komplett belegt beim erstellen der VMDK. Eventuell vorhandene Daten werden erst beim ersten Lesezugriff überschrieben. Dies ist der Standardmodus beim Anlegen einer VMDK. Der Vorteil ist die schnelle Bereitstellung der neuen VMDK, allerdings mit dem Nachteil, dass ein „data leaking“ möglich ist.

Eagerzeroedthick:

In diesem er wird ebenfalls der gesamte Speicherplatz direkt beim erstellen der VMDK belegt und direkt alles mit Nullen vollgeschrieben. So ist sichergestellt das keine Daten mehr vorhanden sind und auch nicht ausgelesen werden können. Das lesen solcher Daten wird auch „data leaking“ genannt, allerdings kann das Erstellen der VMDK sehr lange dauern.Diese VMDK Dateien werden auch benötigt, um etwa den FT "Fault Tolerance" Modus für eine VM zu nutzen.

Thin:
Nur der wirklich verwendete Speicherplatz wird belegt. Je nach Blockgröße wird dann bei Bedarf mehr Speicherplatz hinzugefügt. Der Speicherplatz auf dem VMFS Laufwerk wird dabei sehr effektiv genutzt, allerdings muss der Speicherplatz überwacht werden, da er plötzlich, schnell volllaufen kann. Zusätzlich benötigt man für die Vergrößerung der VMDK Datei eine SCSI Reservierung, das kann auf großen VMFS Laufwerken zu Problemen führen, da das Laufwerk für dieses Metadaten-Update "angehalten" werden muss.

Über die VMKFSTOOLS lassen sich die VMDK Dateien jederzeit in ein anderes Format klonen, über den vSphere 4.0 Client kann mit "Migrate" nicht nur der Speicherplatz der VMDK Datei verlagert werden, sondern jetzt auch der Festplattenmodus von Thin auf Thick gesetzt werden. Allerdings benötigt man dafür genügend Platz auf dem Ziellaufwerk.

Fault Tolerance Checkliste für den Einsatz

Thursday, 11 June 2009 08:10:08 (W. Europe Daylight Time, UTC+02:00)

VMware Fault Tolerance bietet kontinuierliche Verfügbarkeit bei Hardwareausfällen – ohne Datenverlust oder Ausfallzeit für alle Anwendungen. Folgende Punkte müssen erfüllt sein damit eine VM im Fault-Tolerance Modus betrieben werden kann:

Allgemein:

  • Shared Storage (NFS, iSCSI, FC)

ESX Host:

  • Minimal drei ESX 4.0 Server mit gleichen Prozessorfunktionen
  • Der Build-Stand des VMware Kernels muss auf den ESX Servern installiert sein
  • Hyperthreading im BIOS der physischen Server muss deaktiviert sein
  • Eine Netzschnittstelle für FT (aktivierte VMkernel Port Group) muss auf jedem ESX Host konfigueriert sein. Die Bandbreite muss zwei Gigabit-Ethernet betragen!
  • Eine Netzschnittstelle für vMotion (aktivierte VMkernel Port Group) muss vorhanden sein
  • Power Management (Power-Capping) im BIOS der Server sollte deaktiviert sein
  • Hardware Virtualisierung muss im BIOS des ESX Server aktiviert sein

Cluster:

  • Der HA Modus muss aktiviert sein
  • Server Zertifikate müssen verwendet werden
  • Der Anwender, der den FT Modus einstellen will, muss die Berechtigung / Benutzerrolle "Cluster Administrator" konfiguriert haben

VM:

  • Die einzelne VM darf maximal 1 vCPU konfiguriert haben
  • Die Port Group der VM braucht einen Uplink analog zu vMotion
  • Die VMDK Dateien (alle!!!) müssen im Eagerzeroedthick Modus angelegt worden sein
  • Es können keine RDMs im Modus "Physical RDM" genutzt werden
  • Die VM muss nicht ausgeschaltet sein, wenn man den FT-Modus aktivieren möchte
Beim Anlegen einer VM über den vSphere Client wird direkt abgefragt, ob die VM im Kompatibilitätsmodus für FT erstellt werden soll. Diese Option verhindert allerdings, dass die Option Thin Provisioned genutzt werden kann. Ist man sich nicht hundertprozent sicher, ob man die neue VM im FT Modus nutzen möchte, so sollte man den FT Kompatibilitätsmodus immer auswählen. Dabei sollte man immer bedenken, dass es neben FT und geclusterten VMs auch die Option zur redundanten Vorhaltung von Diensten und Anwendungen gibt, der die Hostkonfiguration erheblich erleichtert, denn realistisch betrachtet bindet man mit FT immer gleich zwei Hosts! Wichtig ist, dass FT eine Clusterfunktion ist und so nicht über Clustergrenzen funktioniert. Ferner ist ein Spiegeln von VMs über eine Weitverkehrsstrecke weder von VMware unterstützt noch ratsam.

vCPUs Multikern CPUs in einer VM

Monday, 25 May 2009 06:52:13 (W. Europe Daylight Time, UTC+02:00)
Seit dem es VMware Infrastructure gibt, kann man einer VM auch mehrere vCPUs präsentieren. Dabei war es bisher so, als gäbe es für die VMs keine Multi-Kern Optionen. Innerhalb der Beta Tests zu vSphere 4.0 hat dann einer der Entwickler Sean Borman einen Hinweis zur Multi-Kern Option in ESX 4.0 gegeben, der seitdem auch eingesetzt werden kann.
Diese Anforderung resultiert aus der Notwendigkeit, dass bestimmte Betriebssysteme eine harte Limitierung bei der Anzahl der unterstützten, genutzten CPUs haben. Beispielsweise kann Windows Server 2003 Standard Edition nur mit maximal 4 CPUs genutzt werden. Moderne Server haben allerdings schon mal gerne 12 bis 24 Kerne, eine VM ann davon allerdings nur vier nutzen!
Mit Hilfe der Option zur Multi-Kern Unterstützung kann man nun einer VM mit Windows Server 2003 Standard Edition acht vCPUs geben und diese über Multi-Kern auf entweder vier oder zwei Sockel zusammenschließen. Bei Anwendungen innerhalb der VM kann es zu erhöhten Kosten kommen, wenn diese per Sockel lizenziert werden muß.

So kann man diese Option nutzen:

  1. Herunterfahren / Ausschalten der VM
  2. Über das Kontextmenü der VM mit "Edit Settings" die Konfiguration der VM öffnen
  3. "Options" Karteikartenreiter auswählen
  4. Auf General unter den Advanced Options gehen
  5. Den "Configuration Parameter" auswählen
  6. Mit "Add Row" eine neue Zeile in der KOnfigurationsdatei erstellen
  7. In der Spalte "Name" folgende Option „cpuid.coresPerSocket“ hinzufügen
  8. In der Spalte "Value" einen Wert von 2, 4 oder 8 eintragen <-- !!! Achtung !!! Auch bei Hexacore Systemen kann der Wert von sechs nicht eingetragen werden !!! Achtung !!!
  9. Mit "OK" Die Änderungen an der VM Konfiguration abspeichern
  10. Starten der VM und das Betriebssystem erkennt nun zwar im Gerätemanager weiterhin zum Beispiel acht CPUs, allerdings findet man unter Systemeigenschaften nun den Eintrag, das es ein Zweisockelsystem ist mit vier Kernen.
Ob das ganze auch so von VMware unterstützt wird muss noch geklärt werden. Duncan Epping von yellowbricks.com will dazu bald ein Update bringen.

Originalthread aus dem Beta Tester Forum:

esx4-multicore.pdf (63,04 KB)

VMware HA Konfiguration und Fehlermeldungen

Saturday, 07 February 2009 11:42:17 (W. Europe Standard Time, UTC+01:00)
Hier ist er der zweite Teil zum Thema HA Konfigurationen. Immer wieder melden sich Kunden bei mir, dass die HA Konfiguration ihrer Cluster nicht konsistent funktioniert, ESX Server einen Fehler in der HA Agentenkonfiguration melden oder das HA Cluster anscheinend Warnungen ausgeben, da nicht genügend "FailOver"-Kapazitäten vorhanden sind. Im ersten Teil des Berichts bin ich näher auf die einzelnen Parameter der HA Konfiguration zu sprechen gekommen. In diesem zweiten Teil dreht sich alles rund um die Fehleranalyse und Behebung.

DELL OpenManage 5.5.0 OMSA Modul unter VMware ESX 3.5.0 installieren

Tuesday, 03 February 2009 13:33:01 (W. Europe Standard Time, UTC+01:00)
In der jüngeren Vergangenheit hatte ich über die Problematik mit der Installation von DELL OMSA unter VMware ESX 3.5.0 bereits berichtet. Das Problem liegt dabei an zwei Stellen. Zum Einen unterstützt DELL offiziell RHEL 3 Update9 nicht mehr als Plattform und zum Anderen nutzt VMware eine eigene IPMI Integration in den ESX Server und damit in das speziell für VMware geschnittene RHEL 3U9. Daraus ergibt sich zwangsläufig eine Sackgasse, wenn man den bisher gültigen Weg der Installationsanweisung folgte und das DELL IPMI Paket mit dem Kernel verheiraten wollte. Das Ergebnis, eine nicht mehr funktionierende Hardwareüberwachung, die sich nicht mehr deinstallieren lies!



Die Lösung war so einfach, wie überraschend, denn DELL veröffentlichte ohne Benachrichtigung ein Update seines Installationsleitfadens, indem diese Prozedur einfach ausgelassen wurde und siehe da, OMSA funktioniert. Manchmal sind es die kleinen Dinge im Leben, auf die es ankommt. Für alle die keine Lust haben zu warten, so geht's:

1. DELL OMSA Paket für Linus von der bekannten Website support.dell.com herunterladen
2. Das Archiv auf den ESX Server kopieren, ambesten nach /tmp oder /root
3. Das Archiv entpacken
root# tar -xvzf OM****.tar.gz
4. In der ESX Server Firewall sowohl snmp als auch den OMSA Port freigeben:
root# esxcfg-firewall -e snmpd
root# esxcfg-firewall -o 1311,tcp,in,OpenManageRequest
5. OMSA Module installieren
root# ./linux/supportscripts/srvadmin-install -b -w -r -s
root# ./linux/supportscripts/srvadmin-services start
!!!Die Option -r nur verwenden wenn eine DRAC Karte im Server installiert ist!!!
6. Webbrowser starten und die Installation kontrollieren, das war's

vMotion zwischen ESX 3.0.x und ESX 3.5.0 Servern

Tuesday, 03 February 2009 09:36:40 (W. Europe Standard Time, UTC+01:00)
In der Vergangenheit hatten einige Kunden bei der Aktualisierung der bestehenden ESX Server auf einen aktuellen Ausgabe-Stand Probleme mit der Übernahme der bestehenden virtuellen Systeme auf die aktualisierten ESX Server. Der VMotion-Prozess bricht in der Regel immer nach 10 Prozent in der Anzeige des VI-Clients mit einem unbekannten Fehler ab. So ließen sich alte Umgebungen schwer aktualisieren, da die fließende Übernahme der VMs nicht möglich war.

Einige Knowledgebase Artikel zu dem Thema und Beiträge im VMware Anwenderforum ließen offen, warum genau dieses Phänomen auftritt und vor allen Dingen, wie man das Problem umschiffen kann.

Die Lösung zu dem Problem ist dabei denkbar einfach, nur Schade, dass genau solche wichtigen Fragen in einem offiziellen Migrationshandbuch leider vom Hersteller nicht beantwortet werden.
Da der komplette VMware Kernel zwischen den Versionen 3.0 und 3.5 eine größere Überarbeitung erfuhr und die entsprechenden Komponenten und Software-Module eine Anpassung erfuhren ergeben sich prinzipiell kleinere Inkompatibilitäten zwischen den Versionen. Generell funktioniert VMotion zwischen 3.0 und 3.5 Systemen ohne Abstürze von VMs oder Datenverlust.



Durchläuft man den Assistenten für die manuelle Initiierung von VMotion, dann muss lediglich in der Priorität des Prozesses das Auswahlfeld "Low Priority / Niedrige Priorität" ausgewählt werden. Durch diese Auswahl wird erreicht, dass Ziel- und Quell-ESX-Server eine längere Time-Out Wartephase zur Erstellung des Arbeitsspeicherabbildes erhalten und der Handshake Prozess bei der Initiierung des Prozesses nicht frühzeitig terminiert.

EVC - Oder wie man vMotion über verschiedene Host CPU Typen nutzen kann

Monday, 02 February 2009 11:58:16 (W. Europe Standard Time, UTC+01:00)
EVC - Enhanced vMotion Compatibility ist eine der Funktionen die im Laufe der ESX 3.5.0 und VC 2.5.0 Pflege in das vCenter gewandert sind. Eigentlich sollte diese Funktion erst mit der Version 4, also dem großen neuen System ausgerollt werden, aber da war die Marketing Abteilung wohl vor der Technik schon unterwegs und hat den großen und ganz großen Kunden den Mund so wässrig gemacht, dass es schon jetzt integriert wurde und auch supportet wird, was nicht zwangsläufig bei VMware der Fall ist, man erinnere sich nur an das "Green IT" - Debakel mit DPM - Distributed Power Management von VMware, was im jetzigen RC für vSphere schon etwas besser funktioniert, aber dann doch nicht ganz soviel Strom spart; dazu aber später mehr.

Die EVC Einrichtung
Eigentlich eine einfach Clusterkonfiguration, die als Punkt einfach über den VI-Client aktiviert werden kann; aber in der Regel nicht läuft, da dazu alle VMs aus sein müssen. Warum? Und wie soll ich diese Funktion dann wieder einschalten, wenn mein vCenter Server auch eine VM ist?
Dieser Frage habe ich mich auch in der jüngeren Vergangenheit auch gestellt und bin auf eine interessante Lösung zu dieser Herausforderung gestoßen.
In der Regel werden zunächst die ESX Server installiert und konfiguriert und danach als erste VM das VC installiert und im Anschluss konfiguriert. Genau dann haben wir den Salat, es gibt ein Cluster und das VC läuft, jetzt kann EVC eben nicht eingeschaltet werden, daher die

Lösung auf Umwegen
Man benötigt dazu einen einzelnen Host. Dieser Host wird einem neuen Cluster zugeordnet und im Anschluss wird das Cluster konfiguriert - mit EVC!!!
Das klappt natürlich jetzt einwandfrei, da keine VM auf dem ESX Server eingeschaltet oder registriert ist. Im Anschluss fährt man das VC einfach herunter, registriert diese VM an dem neuen Host in dem neuen Cluster und startet diese VM. Dabei kann der ESX Server die fehlenden Zeilen in der VMX Datei anhängen und die EVC Funktion wird anschließend genutzt.
Ist das vCenter einmal gestartet, werden die anderen Hosts aus dem alten Cluster dem neuen Cluster zugeordnet und voila unser Cluster nutzt ab sofort für alle Hosts die EVC Konfiguration.
 

VMware vSphere - Der Release Candidate 1 ist geschlüpft

Monday, 19 January 2009 13:16:35 (W. Europe Standard Time, UTC+01:00)
Nachdem die letzten Telefonkonferenzen zur Beta 2 abgeschlossen und auch sonst keine neuen Themen in der beta Community aufgetaucht waren, haben die Entwickler wohl einen kleinen Zwischenspurt eingelegt und pünktlich zum Ende der Weihnachtsferien in den USA den ersten Release Candidate (RC 1) an die Beta-Tester verteilt. Der eigentliche Veröffentlichungstermin 16. Januar 2009 wurde von mir wegen Urlaub zwar verschlafen, dafür hatte ich dann in dieser Woche keinerlei Probleme mit überlasteten Download Servern.



Interessant ist, dass die Linux Appliance zur Verwaltung anscheinend tatsächlich kommen soll, diesen Download habe ich dann mal getätigt und werde sobald die Freigaben dazu vorliegen im Detail über diese interessante Neuerung berichten.

VMware ESX / ESXi Virtual Hardware Memory Corruption Vulnerability

Thursday, 04 December 2008 11:44:28 (W. Europe Standard Time, UTC+01:00)
Heute Nacht hat VMware einen Fehler in der Hauptspeicherverwaltung für virtualisierte / emulierte Treiber veröffentlicht, der auf den ersten Blick nur nicht gepatchte Systeme der aktuellen Versionen von ESX(i) betreffen.


Bei secunia wurde der Fehler als weniger kritisch eingestuft. Ich unterstütze diese Ansicht in Teilen. Für virtualisierte Serverumgebungen ergibt sich ein deutlich geringeres Gefährdungspotential, als für virtualisierte Arbeitsplatzumgebungen unter VMware View alias VDI.

http://secunia.com/advisories/32965/

http://lists.vmware.com/pipermail/security-announce/2008/000046.html

Update der VMware Tools notwendig!
Liest man sich die entsprechenden Knowledgebase Artikel durch, fällt direkt auf, dass die VMware Tools geupdatet werden und das neue Paket in alle Gäste ausgerollt werden muss, damit die Systemintegrität wieder hergestellt werden kann.

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1007501

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1007504

Administratoren der Umgebungen sollten zeitnah das Update testen und verproben und gegebenfalls ausrollen.

Schon wieder Pegasus Fehler - trotz Update 2

Tuesday, 18 November 2008 11:04:50 (W. Europe Standard Time, UTC+01:00)
Nachdem das Update 2 für ESX Server 3.5.0 verfügbar war, hatte ich den alten Pegaus Fehler wieder verdrängt, oder war der damit nicht behoben?
Bei den Neuinstallationen trat der Fehler auch nicht mehr auf, dies habe ich in mehreren Projekten verifiziert.

Bei einem meiner Kunden hatte ich Probleme in der snmp Überwachung, Ergebnis der alte Pegasus Fehler war nach dem Update auf U2wieder da!!!! und noch andere, ohne dass der UM meldete, das ein Modul oder Paket nicht in Ordnung sei.
Jetzt die Horrornachricht für alle, die niemals auf die direkte Konsole ihres ESX Server gucken und diesem beim Booten zuschauen, okay beobachten und analysieren:
Der Fehler bleibt auch nach dem Update von 3.5.0U1 auf 3.5.0U2 erhalten. Damit sollte jeder seinem Kunden empfehlen:
  1. UpdateManager nur für security und major fixes bei Problemen verwenden
  2. Updatebundles von VMware immer von Hand als komplettes System ausrollen!!!!
    Keine Updates (Pierre hat das schon immer gewusst, ich ziehe meinen Hut) von laufenden Systemen machen!
Fazit, das Patchen von ESX ist nach wie vor ein Drama und die Installationsanleitungen müssen selbst innerhalb eines Releases überarbeitet werden, aufgrund der schlechten Informationspolitik von VMware!
Mal schauen ob das Ganze in Version 4.0 besser wird. :'(

ESX Server reagiert nicht COS - VMs laufen weiter

Monday, 17 November 2008 10:55:30 (W. Europe Standard Time, UTC+01:00)
Ich hatte gerade einen schönen Support Call, einer meiner Kunden berichtete, dass ein ESX Server "steht", sich nicht mehr richtig steuern lässt, die VMs liefen aber wie die Hölle weiter.
Wie immer hat der Kunde nichts geändert - bei diesem Kunden glaube ich das auch - und dem war anscheinend auch so. Ein kleiner Blick in das Dateisystem offenbarte, dass die /VAR Partition, die ich als paranoider Admin schon mit 8GB angelegt hatte vollgelaufen war. Lustiges Detail, es gab dort ein Unterverzeichnis ./core, in dem hunderte 35 MB große 12345.core Dateien lagen, die anscheinend alle innerhalb von einer Minute angelegt worden waren.

Analyse
Auf der VAR Partition wurden innerhalb von einigen Minuten zirka 6,5 GB Daten angelegt, deren Muster in etwa 12345.core war. Diese lagen alle in einem von mir niemals zuvor gesehenen Verzeichnis /var/core
Die Dateien konnten sofort gelöscht werden und ein Neustart der Dienste
service mgmt-vmware restart
service vmware-vpxa restart
führte dazu, dass der ESX Server ohne Neustart einfach weiter lief und in der Folge wieder über das VC verwaltet werden konnte.

Das Handbuch (google) ergab:
http://communities.vmware.com/message/1080791;jsessionid=1D9C8527320ADDA1891D81FB1F3E3C95
http://communities.vmware.com/thread/55607

Treffer!!!!
laut dem Support kann es passieren, dass der hostd in diesem Verzeichnis seine App daemon crash infos pumpt und der esx danach zwar noch läuft aber die COS nicht mehr mit anderen ESX oder dem VPX reden wollte. Das Update 3 soll das fixen, da bin ich mal gespannt, viel interessanter finde ich allerdings, dass mal wieder ohne Dokumentation (ich hasse sowas) eine Info nach außen drang, die mich veranlasst sieht die Aussage über Partitionsgößen zu revidieren:

Ab sofort sollte man eine /var/core Partition anlegen. Größe 8 GB

VMware ESX Server 3.5.0 Update 3

Friday, 07 November 2008 23:19:22 (W. Europe Standard Time, UTC+01:00)
Nachdem das Update 3 Paket für das VirtualCenter 2.5 schon länger verfügbar ist, kommt jetzt das Update 3 für den ESX(i) Server; hier




Diese Version ist ein weiterer Maintenance Release von VMware und behebt zahlreiche Fehler.
Zusätzlich wird neue Hardware untertützt. die wichtigste neue Funktion ist aber mit Sicherheit die hochgesetzte Grenze auf 20 vCPUs pro CPU Kern. In Verbindung mit den neuen Hexacore Systemen auf INTEL Basis ergibt sich damit ein Maximum von 6 x 4 x 20 = 480 vCPUs auf einem Host mit Vierfach-Sockel Hauptplatine. Das ist eine echte Herausforderung und absolut genial für VDI Projekte!


VMware EVC einschalten

Thursday, 30 October 2008 18:41:25 (W. Europe Standard Time, UTC+01:00)
Mit der Version VMware Infrastructure 3.5 Update 2 wurde die erweiterte VMotion Kompatibilität eingeführt.
Dahinter verbirgt sich eine sehr interessante Funktion, die es ermöglicht in mixed INTEL Clustern oder mixed AMD Clustern VMs von einem Host zum anderen zu migrieren.
Diese Funktion ist alt bekannt, hat aber ihre Tücken im Detail.

Anforderungen für vMotion:
Neben der Erfordernis, dass lediglich CPUs eines Herstellers in einem Cluster verwendet werden, kommt erschwerend hinzu, dass die CPUs aller Hosts eines Clusters aus der selben Familie / Serie stammen müssen, damit vMotion und damit auch DRS funktionieren können.
In der Version ESX Server 3.0.x konnte man die CPU Maske pro Host manipulieren, damit nur gemeinsame CPU Funktionen allen VMs präsentiert werden.
Da das Anlegen einer CPU Map nicht trivial ist, hat wohl kaum jemand von dieser Option Gebrauch gemacht.

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1993

Der EVC Ansatz:
EVC ist eine Clusterfunktion und wird daher direkt über das VC gesteuert. Neu ist die Änderung in der Art und Weise der Festlegung der möglichen gemeinsamen CPU Funktionen. Wurde das bisher pro Host gesetzt, so wird jetzt die Konfiguration pro VM in der .VMX Datei gesetzt. Damit diese Option gesetzt werden kann, muss die betreffende VM, bzw. alle VMs des Clsuters ausgeschaltet sein.

hostCPUID.0 = "0000000a756e65476c65746e49656e69"
guestCPUID.0 = "0000000a756e65476c65746e49656e69"
userCPUID.0 = "0000000a756e65476c65746e49656e69"
hostCPUID.1 = "0001067600040800000ce3bdbfebfbff"
guestCPUID.1 = "000006f800010800000022010febbbff"
userCPUID.1 = "0001067600040800000022010febbbff"
hostCPUID.80000001 = "00000000000000000000000120100000"
guestCPUID.80000001 = "00000000000000000000000120100000"
userCPUID.80000001 = "00000000000000000000000120100000"
evcCompatibilityMode = "TRUE"


Je nachdem wie viele vCPUs in der Vm gebunden sind - im vorliegenden Fall sind es zwei vCPUs - werden Zeilen am unteren Ende der .VMX-Datei hinzugefügt.

NLB Cluster mit virtuellen Maschinen

Tuesday, 16 September 2008 00:13:17 (W. Europe Daylight Time, UTC+02:00)
Seit der Einführung Windows 2000 wurde das NLB Cluster als Loadbalancing Cluster von Microsoft für stateless Applications eingeführt. Was unter Windows 2000 nur den Kunden der Advanced Server Edition vorbehalten war, ist seit der Version Windows Server 2003 in allen Varianten verfügbar. Einziges Manko ist, dass diese preiswerte Clustermethode von Microsoft in den Handbüchern und technischen Referenzen etwas stiefmütterlich behandet wird und die wichtigsten Punkte nur über die Support Webseiten von Microsoft zu finden sind. Unter VMware möchten viele Kunden auf diese Option nicht verzichten, als Lösung innerhalb einer Virtualisierungsumgebung müssen allerdings zusätzlich zu den bestehenden Restriktionen weitere Punkte beachtet werden, damit ein NLB Cluster unter Windows stabil betrieben werden kann.

VM mit mehr als 16 GB RAM zugeteilt startet sehr langsam

Monday, 15 September 2008 00:00:59 (W. Europe Daylight Time, UTC+02:00)
Seit der Version 3.5 können mehr als 16 GB RAM einer einzelnen VM zugeordnet werden. In den VMware Foren kann man dazu einige Einträge finden. Was steckt dahinter? Ist die Aussage einer VM bis zu 64 GB RAM zuweisen zu können nur eine Markting Aussage (als Ausblick in Zukunft kann man dynamisch bis zu 256 GB RAM zuordnen)?

Weder noch, es gibt de facto eine signifikante Änderung wenn man VMs mit mehr als 10 GB RAM ausstattet. Fehlerbilder sind eindeutig, der Boot des Systems dauert über eine halbe Stunde, oder bricht sogar ab, nimmt man der VM wieder diese Summe an RAM weg, so dass diese nur noch zwei bis vier GB RAM hält, dann startet dieses System ohne das Fehlerbild schnell und konsistent.

Als Lösung ist folgende Vorgehensweise meistens von Erfolg gekrönt:

  1. Einer VM nicht einfach so mehr als vier GB RAM zuweisen! Planen Sie den Einsatz von "großen" VMs.
  2. Soll eine VM sehr viel RAM und / oder zusätzlich vCPU Ressourcen erhalten, so sollte das Pagefile auf eine dedizierte VMDK verlagert werden.
  3. Als Faustformel sollte man bei 16 GB RAM eine 20 GB Pagefile Date auf eine dedizierte 30 GB VMDK verlegen.
  4. Wird die RAM-Größe deutlich überschritten, so muss auch das Pagefile mitwachsen, aber nicht dynamisch! Die Größe sollte fix eingestellt sein und
    immer größer als der physische RAM sein. Als Anhaltspunkt kann der Vorschlag des OS dienen.

PSOD beim Rescan der HBAs

Monday, 01 September 2008 23:02:55 (W. Europe Daylight Time, UTC+02:00)
Das will niemand sehen, aber es passiert! Der PSOD schlägt zu und der ESX Server steht, wie einst das gute alte Windows NT 4.0.
Im Gegensatz zu Windows NT damals, tritt der PSOD (Purple Screen Of Death) zum Glück sehr selten beim ESX Server auf, aber wir wollen es nicht verheimlichen, es gibt ihn diesen Albtraum eines Systemadministrators! Leider gibt es einen echten Bug in VMware ESX Sever Version 3.5.x.

Dieser Fehler tritt in folgender Hardwarekonfiguration auf:
DELL PE 29x0 III Server mit PERC/6i S-AS Controller.

Von VMware gibt es dazu keinen Knowledgebase Eintrag, lediglich ein Eintrag im VMware Forum deutet auf das Problem hin.

Scannt man unter dem VI Client unter Configuration / Hardware / Storage Adapters die HBAs nach neuen VMFS Volumes oder LUNs, so stoppt der ESX Server mit einem PSOD!
Dieser Fehler ist bereits bei VMware bekannt und adressiert. Laut VMware wird dieser Fehler mit dem anstehenden Update 3 für VMware ESX 3.5.0 behoben. Bis dahin gibt es einige obskure Anleitungen in den VMware Communities für dieses Problem, die soweit gehen in Systemdateien des ESX Servers einzugreifen, dass ist unnötig und hilft in Abhängigkeit zur verwendeten BIOS Version der Servr auch überhaupt nicht.

Lösung:

Im BIOS der DELL Server ist nach der Basisinstallation der integrierte S-ATA Controller auszuschalten. Dadurch verliere ich zwar den Zugriff auf das lokale CD-ROM Laufwerk (S-ATA seit Version III der PE 29x0 Server), aber dafür kann man im laufenden Betrieb nach neuen SAN LUNs suchen und diese gefahrlos mounten. Diese Lösung funktioniert mit den genannten DELL PE Servern mit den BIOS Versionen 2.1.0, 2.2.6 und 2.3.1.

Alternative:

Wer unbedingt auf das integrierte CD-ROM Laufwerk nicht verzichten kann, der muss zur SAN Erweiterung jeden Host einmal neu starten. Beim Systemstart scannt der Server die SAN auf verfügbare / konfigurierte LUNs ab und kann in dieser Prozedur ohne Absturz auch neue LUNs persistent mounten.

Unattended installation ESX Server

Sunday, 17 August 2008 19:57:50 (W. Europe Daylight Time, UTC+02:00)
As many of You suffer from the pain of the most boring part of VMware VI 3.5 - the installation of the hosts - I'm tryig to bring up a version of a kickstart script I wrote to install DELL PowerEdge Servers. In the early future I will adopt this for the unattended installation of FSC Primergy Servers as well. Let's have a closer look at it, but in German.

Mein Netzwerksenf! - virtual networking in VMware VI 3.5

Sunday, 17 August 2008 16:34:51 (W. Europe Daylight Time, UTC+02:00)
In den meisten Projekten werde ich immer wieder mit Fragen zum Thema Netzkonfiguration in virtuellen Umgebungen konfrontiert. Aus den Projekten hat sich im Laufe der Zeit eine Art Best Practise entwickelt, den ich gerne in der Reihe "Mein Netzwerksenf!" an dieser Stelle veröffentlichen möchte.

Installing ESX Server 3.5, Patch ESX350-200806812-BG

Wednesday, 13 August 2008 21:26:27 (W. Europe Daylight Time, UTC+02:00)
As we now have the patch, how to install the patch in the Enterprise with a minimum of downtime?

It's possible to do it as followed with a minimum of downtime for your VMs.

  1. Set your DRS cluster in "Manual" Mode to ensure, that VMs are not moved to other hosts!
  2. shutdown all VMs on the chosen ESX(i) host and set the host into maintenance mode!
    A very cool small script can be seen at Duncans blog
  3. copy the patch into the /tmp directory or any other ext3 filesystem location on the host with appropriate free disk space!
  4. install the patch and reboot your host.
    [root@esx]#unzip ESX350-200806812-BG.zip
    Archive:  ESX350-200806812-BG.zip
       creating: ESX350-200806812-BG/
      inflating: ESX350-200806812-BG/VMware-esx-vmx-3.5.0-110181.i386.rpm
      inflating: ESX350-200806812-BG/VMware-hostd-esx-3.5.0-110181.i386.rpm
      inflating: ESX350-200806812-BG/descriptor.xml
       creating: ESX350-200806812-BG/headers/
     extracting: ESX350-200806812-BG/headers/VMware-esx-vmx-0-3.5.0-110181.i386.hdr
     extracting: ESX350-200806812-BG/headers/VMware-hostd-esx-0-3.5.0-110181.i386.hdr
      inflating: ESX350-200806812-BG/headers/header.info
      inflating: ESX350-200806812-BG/headers/contents.xml
      inflating: ESX350-200806812-BG/headers/contents.xml.sig
      inflating: ESX350-200806812-BG/contents.xml
      inflating: ESX350-200806812-BG/contents.xml.sig

    [root@esx]#cd ESX350-200806812-BG
    [root@esx]#esxupdate --noreboot -v 6 update

    Wait for the entire process to end & if "FinalState: SuccessState" reboot the host

    [root@esx]#reboot
  5. After the successfull reboot, end the maintenance mode.
    [root@esx]#vmware-vim-cmd hostsvc/maintenance_mode_exit
VMotion to this host is now again possible!!!
After the first host is considered as working "normal" You can go ahead with patching the rest one-by-one. Good luck, I'm with You!

Changing time on ESX hosts

Wednesday, 13 August 2008 14:18:06 (W. Europe Daylight Time, UTC+02:00)
As I mentioned yesterday there is a very big influence on how You set and change time information on an ESX host and the impact on VMs.
What I hardly learned was, that changing the ESX time information within the VI Client has direct impact on ALL running VMs on the particular host.

Whether or not You checked "sync time with host" feature in VMware Tools, the time information is directly submitted into the VM, when the VMware tools service is running within the VM. This behavior is NOT as expected and described in the VMware Guides, so don't change time information on any running ESX(i) in a productive environment.

In the VMware communities, there is a solution that might work:
The real trick is to use the direct ssh access and change time information within the COS:
Be sure You are root
service ntpd stop
date -s 08/10/2008
esxcfg-firewall -d ntpClient

This changes also the time on the host, but has in the end the same effect on running machines!!!

The best solution is (if you cannot install the patches) to move all running VMs of the host and change the time on this particular host temporary:
Be sure to disable VMware DRS, so that no VM is being scheduled back on this host and that You are again root.

service ntpd stop
service ntpd status
esxcfg-firewall -d ntpClient
date -s 08/10/2008
----> break, switch to VI Client
right click VM | Edit Setting | Options | Boot Options | check "Force BIOS Setup"
wait untill the task completed successfully
break, switch back to ssh session<---

vmware-cmd /vmfs/volumes/[LUN]/[VM folder]/VM.vmx start --trysoft
wait for result = 1 (success)
esxcfg-firewall -e ntpClient
service ntpd star
Now You can set back the sdate within the VMs BIOS and start your VM; reenable DRS

OKay, I know VMotion will not work also, so DRS settings are not really necessary to be changed. :-)

ESX Server 3.5, Patch ESX350-200806812-BG

Wednesday, 13 August 2008 13:40:05 (W. Europe Daylight Time, UTC+02:00)
Early this morning I noticed, that the patches for ESX(i) are available for download and I did it!

I installed the patch on three new hosts in a running customer environment and from my point of view everything works as expected, but let's wait for a while...
The new build version is ESX 3.5.0.110181

Timebomb in VMware VI 3.5 Update2 (1st solution)

Wednesday, 13 August 2008 07:01:21 (W. Europe Daylight Time, UTC+02:00)
Yesterday was one of those days I will not forget very soon. so what happened exactly, I don't know, but a lot of glass is being broken on that VMware "Dooms-Day".
But they worked hard to fix it up:

  1. Make sure You don't turn back time in your environment!!!
    Some customers reported, although having NO time sync within the VMs running towards the hosts, time is being set back! One of my customers ran in this nightmare :'(.
    I don't know what really happened exactly and I'm still wondering about this and this is still under investigation with the DELL Pro Support EMEA team.

  2. Be patient and install the fixes as needed. But please test these patches carefully, because it seems that the complete kernel of VMware is being superseeded by these patches!
    Nobody knows (outside VMware) what was the real issue of this bug and from what point of kernel-build they fixed and recompiled the kernel sources. I'm looking forward to getting any information about this special issue from my sources at VMware.
    I'm testing this patch today in the morning and will give a fast feedback on my first impressions.

    Fix for ESX 3.5 Update 2 can be found here.
    The description of the patch is here.

    Fix for ESXi 3.5 Update 2 can be found here.
    The description of the patch is here.

  3. Follow the guidelines from VMware to installing these very critical patches!
    Instructions can be found here.

Timebomb in VMware VI 3.5 Update2 (with workaround)

Tuesday, 12 August 2008 10:29:02 (W. Europe Daylight Time, UTC+02:00)
As several news services report, there is a timebomb within the licencing System of VMware Infrastructure.
VMware has not found the source for the bug and claims for using an earlier time period within VMware ESX(i) Hosts and VC Server as well.

Be very careful in doing so, because of the logging of the VC database can be corrupt, or lose data because of rewriting the "real" old data with the new ones.
I'm trying to figure out how far you can go back (or may be into the future!)

The link to the knowledge base article is here

To workaround do as followed:

  1. stop ntpd service on each ESX host with version mentioned above (ESX 3.5.0.103908). service ntpd stop
  2. check that the service isn't running anymore. service ntpd status
  3. set a date in the past maybe something like june 12th 2008, same time!

Then please go to your updatemanager to prevent systemes to install ESX 3.5.0 Update 2!

  1. Open VI Client and install and enable the update manager client.
  2. Navigate to the update manager (click the button!).
  3. Change the default baseline for non critical host updates and exclude the esx 3.5.0 Update 2 patch.
  4. the baseline should now show the annex "modified" in brackets behind the baseline type.

That's it for the very first time, so stay tuned on any broadcasting service for updates :-)

VMware closed download section for Update 2 installable Versions

Tuesday, 12 August 2008 07:06:01 (W. Europe Daylight Time, UTC+02:00)
From yesterday in the morning until now the Update 2 sources on the VMware website are still disabled!