TrendMicro DeepSecurity failed to prepare ESXi Host

Wednesday, 08 October 2014 17:33:16 (W. Europe Daylight Time, UTC+02:00)
Unter bestimmten Umständen kann es vorkommen, dass die Installation (Prepare) der ESXi Filtertreiber für TrendMicro DeepSecurity nicht erfolgreich abgeschlossen werden.

Der Fehler ist dann in etwa: "The installation transaction failed".Bei diesem Fehlerbild kann der ESXi Filtertrieber manuell auf den ESXi Server ausgebracht werden, dazu ist zunächst der SSH Zugang auf den ESXi Host zu gewähren und der Filtertreiber von TrendMicro auf eine angebundenes VMFS/NFS Repository zu kopieren. Im Anschluss daran wird dann der Filtertreiber über die Kommandozeile manuell installiert und die Installation kontrolliert:

esxi55 ~root# esxcli software vib install -d --maintenance-mode /vmfs/volumes/nfs_export/FilterDriver-ESX-5.0-9.5.2-1933.x86-64.zip

esxi55 ~root# esxcli software vib list

esxi55 ~root# vmkload_mod -l l grep dvfilter

Nachdem der Filtertreiber erfolgreich installaiert worden ist, muss noch überprüft werden, ob auf dem vSwitch für die vShield/vCN&S auch die Portgruppe vmservice-trend-pg angelegt worden ist.
Ist diese nicht vorhanden kann man diese über die GUI des vSphere (Web-)Client auf dem vSwitch als Standard Virtual Machine Network mit dem oben genannten Label ausbringen.

!!!WICHTIG!!! Dieser vSwitch hat keine physischen Uplink Ports gebunden und es existiert eine VMkernel Portgroup auf demselben vSwitch mit der APIPA IP-Adresse 169.254.1.1


  • Die Filtertreiber von TrendMicro findet man direkt hier



  • Eine Anleitung von TrendMicro gibt es hier



  • Eine Anleitung von VMware zur Umgehung des Bugs gibt es hier


Nach dem erforderlichen Systemreboot taucht der ESXi Host dann im DeepSecurity Manager (DSM) als prepared mit einem grünen Symbol auf und die DSVA kann über den DSM ausgebracht werden.

VMware ESXi 5.x SSH Warning

Tuesday, 09 April 2013 13:09:17 (W. Europe Daylight Time, UTC+02:00)
Da es immer wieder vorkommt, dass man vom Kunden auf die automatisierten Warnungen im vSphere Client angesprochen wird, hier einmal die Lösung zum beheben des Warnungsstatusses für eingeschaltete SSH Serverports auf dem ESXi 5.x:


Hinweis:

Generell sollte man die Warnungen und Alarme, insbesondere auf den Hosts nicht einfach arglos, wegklicken oder übergehen. In diesem speziellen Fall kann der Bediener die Warnung aber nicht selbständig "wegklicken", ohne die KOnfiguration des Hosts zu ändern. Wird der gelbe Warnhinweis neben dem Hostsymbol ignoriert, könnte es durchaus passieren, das man andere Warnungen bezüglich RAM, CPU oder nicht redundanten Pfaden zur SAN NICHT mehr sieht oder beachtet.

Die SSH Konsole ist sehr hilfreich für alle, die lieber auf die Shell - als die PowerShell - setzen oder eben manchmal etwas genauer hinschauen wollen.
Zunächst muss man den

SSH Server Dienst starten und anschließend in der Firewall auch die Zugriffe auf Port 22TCP - inbound erlauben

. Das erreicht man über den Menüpunkt:

ESXi Server | Konfiguration | (Software) Sicherheitsprofil



Im Anschluss muss man jetzt den Nag-Screen verhindern. Das geht ebenfalls über die GUI des vSphere Clients am einfachsten:
ESXi Server | Konfiguration | (Software) Erweiterte Einstellungen

User.Vars | User.Vars.SuppressShellWarning = 1



Die Warnungen verschwinden sofort vom ESXi Server Symbol. Die Einstellung ist persistent.

How To: VMs auf einem ESXi Server manuell mounten/starten

Thursday, 15 November 2012 17:31:03 (W. Europe Standard Time, UTC+01:00)
Heute hatten wir einen Stromausfall im RZ, da leider die USV defekt gegangen ist. Neben dem normalen Ärger hatten wir dann noch das Problem, dass zunächst nur ein partieller Neustart der VMs durchgeführt werden sollte, dazu mussten die DCs auf einem dedizierten ESXi Knoten gestartet werden. Über die GUI (VMware vSphere Client) kann man sich einen Wolf suchen, wenn man aus über 40 Volumes eine bestimmte VM (*.VMX) sucht...

Also per SSH auf die Konsole und dann die VM mounten und starten:

~# find /vmfs/volumes/ -iname my-vm
~# vim-cmd solo/registervm /vmfs/volumes/4e087d42-17d5a77b-e9c4-14feb53c0a92/my-vm/my-vm.vmx
~# vim-cmd vmsvc/getallvms | grep my-vm

2832   my-vm    [V-ESX010] my-vm/my-vm.vmx  winNetStandardGuest       vmx-04    Domain Controller for .EU                                                    
~# vim-cmd vmsvc/power.getstate 2832
Retrieved runtime info
Powered off
~# vim-cmd vmsvc/power.on 2832
Retrieved runtime info
Powered on


Mehr Infos zu dem Thema in der VMware Knowledgebase:

http://kb.vmware.com/kb/1038043
http://kb.vmware.com/kb/1006160

Das Ganze geht auch per PowerCLI, dazu an dieser Stelle demnächst mehr [wenn hier wieder alles läuft];-)

Umstellen der MPIO Regeln für alle LUNs eines Clusters

Wednesday, 14 November 2012 11:49:06 (W. Europe Standard Time, UTC+01:00)
Unter Vmware vSphere gibt es seit der Version vSphere 4 einige neue Möglichkeiten zum Einbinden von LUNs für die Benutzung als VMFS Laufwerke.
Leider passt manchmal die eingebaute Variante der Path Selection Policy (PSP) nicht zum aktuellen Storage und dessen Konfiguration. Für die meisten älteren Systeme gab es da eh nur die Varianten VMW_PSP_FIXED_AP oder MostRecentlyUsed so dass im Zweifel eventuell der I/O Traffic von mehreren LUNs über einen Pfad abgewickelt wurde und dieser dann zum Flaschenhals wurde.

Heute können die meisten Systeme entweder vollständig active/active oder zumindest im ALUA Modus betrieben werden. Dadurch kann man erzilen, dass die LUN I/O leistung weiter Richtung konfigurierbares Maximum wächst. Die korrespondierende PSP für diesen Fall wäre Fixed (VMware) oder Round Robin (VMware). Die Umsetzung der PSP Regeln kann über die Shell des ESXi Servers oder den vSphere Client (ab Version 5.0 auch über den Web Client) erfolgen. Zusätzlich zu diesen GUI oder lokalen Möglichkeiten gibt es auch die Powershell, damit kann man diese Aufgaben einfach, schnell und reproduzierbar auf alle ESXi Server eines Clusters übertragen. Hat man in etwa mehr als fünf LUNs und mehr als drei Hosts, dann sollte man auf jeden Fall dem Skript den Vorzug geben, da die manuelle Interaktion zu fehleranfällig ist! Das Verfahren sollte man auch immer anwenden, wenn man neue LUNs in einem existierenden Cluster veröffentlichen!

Der Befehl unter Powershell sieht dann in etw so aus:
Zunächst verbindet man sich am besten zum vCenter Server mit einem administrativen Konto (VMware):
PowerCLI C:\Programme\VMware\Infrastructure\vSphere PowerCLI> Connect-VIServer vcenter.domain.suffix
Name                           Port  User
----                           ----  ----
vcenter.domain.suffix          443   DOMAIN\carsten

Jetzt listet man alle LUNs im Cluster auf, die eine Disk beschreiben, damit wir nicht noch die CD-/DVD-ROm Laufwerke der Hosts und die lokalen Platten(falls vorhanden) erwischen:

PowerCLI C:\Programme\VMware\Infrastructure\vSphere PowerCLI> Get-Cluster CL001 | Get-VMHost | Get-S
CSILun -LunType disk
CanonicalN ConsoleDeviceName              LunType         CapacityGB MultipathPolicy
ame
---------- -----------------              -------         ---------- ---------------
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.024,017 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.024,017 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.536,140 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.024,017 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.536,140 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.536,140 Fixed<--- Ist zu ändern!!!
naa.60a... /vmfs/devices/disks/naa.60a... disk               850,083 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.536,140 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.536,140 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.536,140 Fixed <--- Ist zu ändern!!!
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.024,017 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.024,017 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.536,140 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.536,140 Fixed <--- Ist zu ändern!!!
naa.60a... /vmfs/devices/disks/naa.60a... disk               850,083 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.536,140 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.536,140 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.536,140 RoundRobin

<<< Das ist nur ein Auszug aus der vollständigen Liste aller LUNs >>>

Mit fixed ist die neue LUN im Cluster noch im falschen Modus angesprochen. Diese PSP soll auf Round Robin (VMware) geändert werdenNachdem man jetzt den NAA String exzerptiert hat und damit alle beroffenen LUNS herausfiltern kann, kann in einem zweiten Step die Policy für alle Volumes im gesamten Cluster gesetzt werden:

PowerCLI C:\Programme\VMware\Infrastructure\vSphere PowerCLI> Get-Cluster CL001 | Get-VMHost | Get-S
CSILun -CanonicalName "naa.60a*" | Set-ScsiLUN -MultipathPolicy "roundrobin"
CanonicalN ConsoleDeviceName              LunType         CapacityGB MultipathPolicy
ame
---------- -----------------              -------         ---------- ---------------
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.024,017 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.024,017 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.536,140 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.024,017 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.536,140 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.536,140 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk               850,083 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.536,140 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.536,140 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.536,140 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.024,017 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.024,017 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.536,140 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.024,017 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.536,140 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.536,140 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk               850,083 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.536,140 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.536,140 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.536,140 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.024,017 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.024,017 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.536,140 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.024,017 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.536,140 RoundRobin
<<< Das ist nur ein Auszug aus der vollständigen Liste aller LUNs >>>

Danach kann man das Ganze auf ein zweites Cluster erweitern, für das die LUN sichtbar sein soll. Die NAA IDs sind ja immer identisch auf allen Hosts.

PowerCLI C:\Programme\VMware\Infrastructure\vSphere PowerCLI> Get-Cluster CL002 | Get-VMHost | Get-S
CSILun -CanonicalName "naa.60a*" | Set-ScsiLUN -MultipathPolicy "roundrobin"
CanonicalN ConsoleDeviceName              LunType         CapacityGB MultipathPolicy
ame
---------- -----------------              -------         ---------- ---------------
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.024,017 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.024,017 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.536,140 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.024,017 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.536,140 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.536,140 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk               850,083 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.536,140 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.536,140 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.536,140 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.024,017 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.024,017 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.536,140 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.024,017 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.536,140 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.536,140 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk               850,083 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.536,140 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.536,140 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.536,140 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.024,017 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.024,017 RoundRobin

<<< Das ist nur ein Auszug aus der vollständigen Liste aller LUNs >>>

PowerCLI C:\Programme\VMware\Infrastructure\vSphere PowerCLI>
Viel Erfolg!

Remote Installation ESXi und die F11 Taste

Monday, 15 October 2012 11:48:24 (W. Europe Daylight Time, UTC+02:00)

F11 Taste für die Vollbildschirmfunktion im IE ab Version 7 deaktivieren

Während der manuellen Installation von VMware ESXi 5.1.0 muss man des Öfteren mit den Funktionstasten (F1, F2, F11) arbeiten. Ärgerlich in diesem Zusammenhang bleibt, dass seit dem IE7 eine neue "Vollbildschirmfunktion" auf die Taste F11 gelegt hat :'(
Leider sind viele Server Remotekonsolen (LoM), wie etwa die DRAC von DELL oder die HP iLO dann nicht mehr in der Lage die Tastaturkurzbefehle an die Sitzung zu übertragen, da der Browser sich dazwischen hängt!
Wer jetzt denkt er könne das Thema einfach im IE Menü entschärfen, erlebt eine Überraschung :-o , es geht nur über die GPOs!
Leider kann man nicht mal eben eine GPO anpassen, damit man als technischer Mitarbeiter einfach einmal die Browserfunktion ausschalten kann, zum Glück ist der Weg über die Registry noch geblieben. Dazu müssen folgende Schlüssel angepasst werden:


Die RegistryDatei können Sie bequem hier herunterladen: NoTheaterModeIE7plus.reg (,53 KB)

Oder manuell einfach die Eintrage über den Registryeditor von Windows setzen:







Viel Erfolg beim Einspielen, im Nachgang dann einfach den IE einmal schließen und beim nächsten Start kann man in der Remote Sitzung die F11 Funktion nutzen!

NetApp – New Windows MPIO (V3.5) available

Thursday, 24 November 2011 00:52:03 (W. Europe Standard Time, UTC+01:00)

NetApp has released a new version of their MPIO DSM (Version 3.5) which does include several fixes and simplifies the deployment for NetApp connected Windows systems.

The new features which are included in version 3.5 are:

The Data ONTAP DSM 3.5 for Windows MPIO includes the following changes:

- Data ONTAP operating in Cluster-Mode is now supported, starting with version 8.1. Note the following about Cluster-Mode support:
  – Asymmetric logical unit access (ALUA) is required for all Fibre Channel (FC) paths and for all iSCSI paths to Cluster-Mode LUNs.
  – Mixed FC and iSCSI paths to the same Cluster-Mode LUN is supported.

- New Windows PowerShell cmdlets are available to manage the DSM. The cmdlets replace the dsmcli commands, which are deprecated starting in DSM 3.5. The dsmcli commands will be removed in a future release.
- The Windows Host Utilities are no longer required. The Windows Host Utilities components that enable you to configure Hyper-V systems (mbralign.exe and LinuxGuestConfig.iso) are now included with the DSM. While no longer required, installing the Windows Host Utilities on the same host as the DSM is still supported.
- Hyper-V guests running Red Hat Enterprise Linux (RHEL) are now supported. The Interoperability Matrix lists the specific versions supported.
- The number of reboots required to install or upgrade the DSM is reduced. For example, when you install Windows hotfixes, you can wait to reboot the host until after you install or upgrade the DSM.
- The timeout values set by the Data ONTAP DSM are updated based on ongoing testing.
- The options that you use to specify preferred paths for the Round Robin with Subset policy has changed. Note the following changes:
- The options that you use in the graphical user interface (GUI) to specify preferred paths for the Round Robin with Subset policy has changed. You now use the Set Preferred and Clear Preferred options to specify preferred paths. The Set Active and Set Passive options are no longer available for Round Robin with Subset. Note: These changes do not alter how the Round Robin with Subset policy works. Round Robin with Subset is still an "active/active" policy that enables you to specify preferred and non-preferred paths. The changes align the GUI terminology with how the policy works.

Release Notes can be found here: https://now.netapp.com/NOW/knowledge/docs/mpio/win/reldsm35/pdfs/rnote.pdf

NetApp MPIO Version 3.5 for Windows Systems can be found here:

https://now.netapp.com/NOW/download/software/mpio_win/3.5/

If you deploy MPIO DSM V3.5 from NetApp at a fully patched Windows 2008 R2 SP1 system you will get following “error” if you haven’t installed KB2522766 and KB2528357:

image

KB2522766 – The MPIO driver fails over all paths incorrectly when a transient single failure occurs in Windows Server 2008 or in Windows Server 2008 R2
http://support.microsoft.com/kb/2522766/

KB2528357 – Nonpaged pool leak when you disable and enable some storage controllers in Windows 7 or in Windows Server 2008 R2
http://support.microsoft.com/kb/2528357

image

image

After installing KB2522766 an reboot is required.

Also KB2522766 requires an reboot:

image

image

After 2 reboots you can install now MPIO DSM 3.5:

image

In my case, there is already an “older” version of NetApp MPIO DSM installed which will be automatically detected and upgrade from setup:

image

image

image

image

image

Note: In my case this is an Hyper-V server therefore I do install the Hyper-V Guest utilities which are one of the new features and mentioned above in the feature list.

image

image

……Finally Finished <img alt=" class="wp-smiley">

image

After an 3rd reboot you can now proceed with your SAN configuration.

Please stay tuned for more details around the new utilities and especially around the new Powershell commandlet’s for NetApp which are called “Powershell Toolkit Version 1.6”.

Powershell Toolkit 1.6

http://communities.netapp.com/community/interfaces_and_tools/data_ontap_powershell_toolkit/data_ontap_powershell_toolkit_downloads
http://communities.netapp.com/community/interfaces_and_tools/data_ontap_powershell_toolkit?view=documents

vSphere HA

Tuesday, 25 October 2011 10:48:05 (W. Europe Daylight Time, UTC+02:00)
Bis zur Version 4.1 verwendete VMware die Bezeichnung VMware HA für seine "Hochverfügbarkeitslösung" auf Cluster Ebene. Die verwendete Software war dabei eine Dringabe von der Mutter EMC.
Der HA Agent basierte auf dem Legato AAM <-- Advanced Availability Manager. Dieser wurde durch VMware angepasst und dann für die Clusterumgebung eingesetzt. Dabei besteht die Lösung aus einem Agentensystem, bei dem es Primary und secondary Nodes (Agenten) gibt. Nur die primary Nodes sind dabei fähig HA Fälle zu erkennen und VM-Operationen auszulösen (kurz gesagt).
In der Vergangenheit gab es öfter Probleme mit der HA Konfiguration, da die Funktionsweise des AAM Agenten, eigentlich nicht zu dem Einsatzzweck unter VMware vSphere passte.

Beispiel:

Wenn ein Kunde ein HA Cluster mit acht oder zehn Knoten besitzt und dieses Cluster auf zwei Brandabschnitten liegt <-- innerhalb eines LANs, dann kann es dazu kommen, dass alle funktionsbereiten HA Primary Nodes auf einer Seite sind, da die Auswahl der Primary Nodes einem Automatismus unterlag, analog zu der Master-Browser-Election unter Microsoft Windows Systemen. Das heisst die Primäre Ordnung der HA Agenten passt eventuell nie zu der Lokalisierung der physischen Hosts. Ist kein HA Primary Node verfügbar, dann kann HA nicht reagieren!
Somit kann bei Ausfall eines (Brand-)Abschnitts die skurile Situation entstehen, dass KEINE VM neu gestartet wird!

Mit VMware vSphere HA wurde das gesamte Agentensystem umgeschrieben. Nachwievor gibt es Agenten, die auf den ESXi Knoten installiert werden, allerdings gibt es jetzt eine Master-Slave Situation, bei der es immer nur EINEN Master pro Cluster gibt. Ist der Master nicht erreichbar, wird umgehend eine Wahl / Promotion innerhalb des Clusters durchgeführt, so dass ein Master wieder zur Verfügung steht. Die Slave-Hosts tragen in erster Linie zum Cluster bei, indem sie virtuelle Maschinen lokal ausführen, ihren Laufzeitstatus überwachen und Zustand-Updates an den Master-Host melden. Ein Master-Host kann auch virtuelle Maschinen ausführen und überwachen. Sowohl Slave-Hosts als auch Master-Hosts implementieren die VM- und Anwendungsüberwachungsfunktionen.

Eine der vom Master-Host ausgeführten Funktionen ist das Schützen von virtuellen Maschinen. Wenn eine virtuelle Maschine geschützt ist, garantiert vSphere HA, dass versucht wird, sie nach einem Ausfall erneut zu starten. Ein Master-Host verpflichtet sich, eine virtuelle Maschine zu schützen, wenn erkannt wird, dass als Reaktion auf eine Benutzeraktion der Betriebszustand der virtuellen Maschine von „Ausgeschaltet“ in „Eingeschaltet“ geändert wurde. Wenn ein Failover durchgeführt wird, muss der Master-Host die geschützten virtuellen Maschinen, für die er verantwortlich ist, neu starten. Diese Verantwortung wird dem Master-Host auferlegt, der eine vom System definierte Datei auf dem Datenspeicher exklusiv gesperrt hat, auf dem sich die Konfigurationsdatei der virtuellen Maschine befindet.

vCenter Server meldet anhand des vSphere HA-Hostzustands, ob es sich bei einem Host um einen Master-Host oder einen Slave-Host handelt. Dieser wird auf der Registerkarte Übersicht des Hosts im vSphere-Client und in der Ansicht „Hostliste“ für einen Cluster oder ein Datacenter gemeldet, wenn die Spalte „HA-Status“ aktiviert wurde. Der HA-Status „Wird ausgeführt (Master)“ gibt an, dass der Host als vSphere HA Master-Host dient. Der Zustand „Verbunden (Slave)“ gibt an, dass der Host als vSphere HA-Slave-Host dient. Es gibt weitere Statuszustände, um anzugeben, wann eine Wahl stattfindet oder ein Fehler aufgetreten ist. Die Registerkarte Übersicht des Hosts bietet einen Link neben dem vSphere HA-Zustand des Hosts, der den aktuellen Zustand erläutert

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...

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.

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.

ssh Zugriff für ESXi 4.0.0 Releasebuild-164009

Saturday, 30 May 2009 10:43:55 (W. Europe Daylight Time, UTC+02:00)

Installiert man den ESXi Server, so hat man zur Administration normalerweise keine vollwertige Konsole mehr zur Verfügung. Die Administration erfolgt dabei exklusiv über die GUI des vSphere 4.0 Clients oder über die direkte Konsolenausgabe des ESXi Hypervisors. Für den VMware Support gibt es allerdings die Möglichkeit den ssh Zugriff auf den ESXi Host zuzulassen.

Dieser Modus kann wie folgt freigeschaltet werden:

1. Zunächst muss man einmal an die Originalkonsole kommen:

An der Originalkonsole des ESXi Hosts mit der Tastenkombination ALT-F1 drücken um in die reguläre Konsole zu kommen.

2. Nun muß man blind das Wort unsupported eingeben und danach enter drücken.

Die Aufforderung zur Eingabe des root Passworts erfolgt, hier geben Sie dass vormals konfigurierte root Passwort ein, wichtig ist dabei, dass das Original Tastaturlayout verwendet wird! Wenn nun German Keyboard bei der Basiskonfiguration ausgewählt worden ist, dann finden sich leider die Tasten auf einer anderen Position wieder, wie etwa Y = Z etc. :-)


3. Wenn man sich beim root Passwort nicht vertippt hat, sollte man nun die Kommandozeile des Hosts sehen ~ #. An dieser gibt man nun den Befehl vi /etc/inetd.conf ein.

4. In der Datei initd.conf muß man nun die Zeile finden, die mit #ssh beginnt. Wenn der Kursor auf dem Raute Zeichen steht kann man dieses durch drücken der “x” Taste auf der Tastatur entfernen und die gemachte Änderung danach durch drücken der ESC - Taste und dem Befehl :wq speichern.

5. Man kann die Änderung nun einfach durch einen Neustart aktivieren, oder man arbeitet noch etwas mit der Komandozeile weiter um mit dem Befehl ps | grep inetd die Prozessnummer des inetd raus zu bekommen. Hat man diese kann man diesen mit dem Befehl kill -HUP [Prozessnummer] terminieren und automatisch neustarten. Der SSH-Zugang ist jetzt freigeschaltet.


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.

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.

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.

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. :-)

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!