Wenn sich in den Logs eines ESXi Hosts die Meldung:

“Unable to apply DRS resource settings on Host. Another task is already in progress. This can significantly reduce the effectiveness of DRS.”

findet, hilft es einen Blick auf die virtuellen Maschinen des betroffenen Hosts zu werfen.

Mit grosser Wahrscheinlichkeit versucht eine der VMs die VMWare Tools zu installieren. Wenn diese Installation aus welchen Gründen auch immer auf einen Fehler läuft und hängen bleibt kommt es zu dieser Fehlermeldung.

Man kann die fehlerhafte VMWare Tools Installation per rechtsklick auf die VM – “Guest” – “End VMWare Tools Install” abbrechen:

Beim Upgrade der VMWare Tools ging die Datei \windows\system32\Drivers\vmci.sys kaputt.

Mit der sehr unangenehmen Auswirkung, dass man die virtuelle Maschine weder im normalen noch im abgesicherten Modus hochfahren konnte ohne bei dieser Fehlermeldung hängen zu bleiben:

Die Lösung war in diesem Fall, die virtuelle Festplatte der VM an einem anderen virtuellen Servern anzuhängen und dann die betroffene Datei vmci.sys auszutauschen.

Bei der Datei vmci.sys handelt es sich um den VMWare Virtual Machine Communication Interface (VMCI) Driver.

Dieser ist für die Kommunikation zwischen der virtuellen Maschine und dem Host Betriebssystem bzw. zwischen zwei oder mehreren virtuellen Maschinen am gleichen Host zuständig.

Um die VMWare Tools auf einer virtuellen Maschine mit einer Windows Server Core Version zu installieren benötigt man die folgenden Parameter:

setup64.exe /s /v /qn

Nach der Installation wird die virtuelle Maschine automatisch neu gestartet.

die defekte Disk wird nicht durch ein LED angezeigt:

Es kann passieren, dass eine defekte Disk nicht durch ein gelbes LED markiert wird.

In diesem Fall kann man mit Hilfe des led_on Befehls das LED der defekten Disk aktivieren. Dazu ist es allerdings notwendig den Namen der Disk zu kennen.

Diesen sieht man in der Autosupport Message bzw. man kann ihn mit Hilfe des Befehls “sysconfig -r” herausfinden (in der Sektion Broken Disks).

Bevor man Led_on ausführt muss man den Diagnostic Modus aktivieren:

priv set diag
led_on Disk_name

Vorsicht:
wenn eine LED mit led_on aktiviert wurde muss man sie nachher wieder mit led_off deaktivieren!
Den Diagnostic Modus verlässt man wieder mit “priv set”.

die defekte Disk tauschen und zuweisen:

“priv set diag” um in den Diagnostic Modus zu wechseln

“sysconfig -r” um eine Liste der Disken anzeigen zu lassen
(die defekte Disk sollte in der Sektion “Broken Disks” aufscheinen)

• dann die defekte Disk tauschen:
nach dem Entfernen der defekten Disk mind. 30 Sekunden warten bevor man die Neue hinzufügt – ungefähr solange dauert es bis das Enclosure Service die Änderung bemerkt)

“disk assign disk_name -o owner_name” um die Disk zuzuweisen

“sysconfig -r” um zu prüfen ob die Disk den Spare Disks zugewiesen wurde (Sektion “Spare Disks)

“not zeroed” Disk:

Sollte neben der Disk “not zeroed” angezeigt werden ist es notwendig die Spare Disk mit Nullen zu beschreiben damit diese im Fehlerfall sofort verwendet werden kann.

Dies passiert mit Hilfe des Befehls: disk zero spares

Wenn alle Disken sauber zugeordnet sind den Modus wieder zurücksetzen mit: priv set

Übersicht über die Unterschiede der verschiedenen virtuellen Hardware Versionen:

Bevor man ein Upgrade der virtuellen Hardware durchführt sollte man die VMWare Tools auf neuesten Stand bringen.

Empfehlenswert ist auch (neben einem sauberen Backup) vor dem Upgrade einen Snapshot zu ziehen.

So kann man bei einem Problem/Fehler jederzeit schnell wieder auf die vorherige Version zurücksteigen.

Um das Upgrade anzustarten einfach per Rechtsklick auf die ausgeschaltete Maschine klicken und “Upgrade virtuelle Hardware” auswählen:

Das Upgrade dauert nur wenige Sekunden – danach kann die VM sofort wieder gestartet werden.

Will man eine LUN sauber unter vSphere 5 entfernen, darf man sie auf keinen Fall einfach auf Storageseite löschen.

Bevor man die LUN am Storage entfernt sind unter vSphere 5.x folgende Schritte auszuführen:

1. NAA-ID der zu entfernenden LUN herausfinden:

Im vSphere Client im Configuration Tab eines ESXi Hosts auf Storage wechseln. Rechtsklick auf die zu entfernende LUN und “Properties” auswählen um die Eigenschaften der LUN anzuzeigen.

Im Feld “Extends” kann man nun den NAA-ID ablesen (naa…)

2. Sicherstellen, dass die LUN nicht mehr verwendet wird:

Bevor man die nächsten Schritte ausführt muss sichergestellt werden, dass sie nicht mehr in Verwendung ist:

• es dürfen keine virtuellen Maschinen bzw. Templates auf der LUN liegen
• die LUN darf nicht mehr als RDM verwendet werden
• die LUN darf nicht mehr Mitglied eines Datastore Clusters sein
• Storage I/O Control für diese LUN muss disabled werden
• die LUN darf nicht mehr per Storage DRS verwaltet werden
• die LUN darf nicht für den Datastore Heartbeat verwendet werden
(Ein How-to um heraus zu finden welche LUNs für Datastore heartbeat verwenden werden findet man hier)

3. Unmount der LUN durchführen:
(sollte die LUN als RDM verwendet werden entfällt dieser Schritt -> weiter zu Schritt 4)

Im vSphere Client auf Home – Inventory – “Datastore and Datastore Clusters” wechseln und dort einen Rechtsklick auf die zu entfernende LUN und “Unmount” durchführen:

Es öffnet sich der “Unmount Datastore Wizzard”.
Hier kann man die ESXi Hosts auswählen von denen die LUN entfernt werden soll:

Im nächsten Schritt wird überprüft, ob alle notwendigen Bedingungen für ein sauberes entfernen erfüllt werden:

4. Detach der LUN auf allen ESXi Hosts durchführen:

Im vSphere Client auf unter Configuration – Storage auf die Device-Ansicht des ESXi Hosts wechseln.
Dort die unter Schritt 1 ermittelte NAA-ID der LUN auswählen und per Rechtklick – “detach” entfernen:

Es wird auch hier wieder überprüft ob alle Bedingungen für ein gefahrloses Entfernen der LUN gegeben sind:

5. Entfernen der LUN vom Storage

6. Rescan der Datastores auf allen ESXi Hosts ausführen

Weitere Infos zu diesem Thema findet man im KB-Artikel 2004605 von VMWare:
Unpresenting a LUN in ESXi 5.x)

Seit vSphere 5 verwendet HA (High Availability) zum Erkennen eines Hostausfalls neben dem bekannten Netzwerk Heartbeat auch einen Datastore Heartbeat.

Dazu werden standardmässig zwei zufällig gewählte Datastores verwendet auf denen jeder Host ein dezidiertes File anlegt und in Zugriff behält.

Solange dieses File im Zugriff bleibt kann HA davon ausgehen, dass der jeweilige Host noch läuft.

Will man sich die dazu verwendeten Datastores anzeigen lassen geht dies zb. per vCenter Client:

Rechtsklick auf den Cluster – “Edit Settings”:

Es öffnet sich ein Fenster mit den Cluster Einstellungen. Hier auf der linken Seite “Datastore Heartbeating” auswählen und im rechten Bereich den Link “Cluster Status dialog” öffnen:

Man bekommt nun den HA Cluster Status angezeigt, im Reiter “Heartbeat Datastores” werden die gesuchten Datastores aufgelistet:

————————————–

Für Datastore Heartbeat verwendete Datastores selber festlegen:

Wer die für den Datastore Heartbeat verwendeten Datastores selber festlegen will kann dies im Fenster “Datastore Heartbeating” einstellen.

Es werden dazu drei mögliche Einstellungen angeboten:

Select only from my prefered datastores:

Es werden nur Datastores für den Heartbeat verwendet die in der Auflistung darunter markiert wurden.

Select any of the cluster datastores:

Aus allen im Cluster verfügbaren Datastores werden zwei zufällig gewählte verwendet.

Select any of the cluster datastores taking into account my preferences:

Es werden aus allen im Cluster verfügbaren Datastores zwei ausgewählt wobei in der Auswahl darunter markierte Datastores bevorzugt verwendet werden.

Wer gerne jede Menge Icons auf seinem Desktop nach eigenen Kritierien anordnet kennt das Dilemma:

Sobald sich die Bildschirmauflösung ändert oder die Datenquelle bei einem Shared Desktop verloren geht ist die mühsam erarbeitete Anordnung der Icons Geschichte.

Mit dem Freeware Tool DeskSave von Thorsten Blauhut gehört dieses Problem der Vergangenheit an!

Denn das gerade einmal 80 KB grosse Programm macht es möglich das Desktop Layout zu sichern und jederzeit wieder herzustellen.

How to – Anleitung zum Installieren eines ESXi 5.0 Hosts auf einer HP DL380 G7 Hardware (auf SD Card bzw. USB Stick):

Download der Binaries vom HP Portal: HP ESXi Offline Bundle

Bei den USB Sticks bzw. SD-Cards sollte man darauf achten HP-zertifierte Sticks/Cards zu verwenden. Genaue Infos zu zertifizierter Hardware findet man hier.

Beim Installieren des Hosts wird das ausgewählte Installationsmedium neu partitioniert und formatiert.

Daher ist es ratsam bestehende SAN Verbindungen abzustecken um die Installation nicht unabsichtlich auf einer mit Produktivdaten belegten LUN durchzuführen.

Nachdem man den Server vom Installationsmedium gebootet hat kommt man zum Begrüssungsbildschirm:

Mit Enter bestätigen um fortzufahren…

Nachdem man die EULA mit F11 akzeptiert hat wird der Host nach installationsfähige Medien gescannt:

Im nächsten Fenster werden alle möglichen Installationsziele zur Auswahl angezeigt:

Das gewünschte Medium auswählen und mit Enter bestätigen. Es kommt noch einmal eine Sicherheitsabfrage – diese wieder mit Enter bestätigen:

Im nächsten Schritt das gewünschte Keyboard Layout auswählen und mit Enter bestätigen:

Jetzt das gewünschte Root Passwort zwei Mal eingeben:

Nach Bestätigen des nächsten Fensters mit F11 wird die Installation gestartet:

Nach Abschluss der Installation wird das Installationsmedium ausgeworfen und der Host neu gestartet.

Nachdem dem der Host wieder hochgefahren ist kommt man mit F2 und Eingabe des Root Passworts zur Konfigurationsoberfläche:

Nun kann man die notwendigen Einstellungen für den Host setzen (Netzwerkkonfigurationen, Hostname, usw.).

Wenn beim Sicherungslauf mit snapshotbasierender Backupsoftware (zb. Veeam, TSM,..) beim Löschen des Backupsnapshots etwas schiefläuft kann es passieren, dass bei der betroffenen VM ein Snapshot mit der Bezeichnung “Consolidate Helper-0″ bestehen bleibt.

Versucht man diesen zu löschen kommt es u.U. zur folgenden Fehlermeldung:

“Unable to access file unspecified filename since it is locked”

Um diesen Snapshot wieder weg zu bekommen helfen folgende Schritte (wobei spätestens ab Schritt drei die virtuelle Maschine ausgeschalten werden sollte bzw. muss):

Schritt 1 – vMotion der VM auf einen anderen Host und wieder retour

Migriere die betroffene VM auf einen anderen Host (einfach vMotion – kein Storage vMotion!) und dann wieder zurück auf den ursprünglichen Host.
Danach sollte sich der Consolidate Helper-0 Snapshot per Snapshotmanager “Delete All” löschen lassen.

Schritt 2 – neuen Snapshot erstellen – dann “Delete All”

Sollte der erste Schritt keinen Erfolg gebracht haben bzw. hat man überhaupt die Situation dass kein Snapshot mehr angezeigt wird obwohl am Storage noch Deltafiles vorhanden sind hilft möglicherweise folgendes:

Erstelle einen neuen Snapshot der betroffenen VM. Spätestens jetzt sollte ein nicht mehr angeführter Snapshot wieder im Snapshot Manager sichtbar sein.
Danach per “Delete All” alle Snapshots löschen.

Schritt 3 – Storage vMotion

Sollten die beiden ersten Schritte nichts gebracht haben bleibt noch die Fehlerbehebung per Storage vMotion. Dazu sollte man die VM allerdings ausschalten da dadurch der Rollback Vorgang der Deltafiles beschleunigt wird.

Schritt 4 – Klonen der VM bzw. v2v per Converter

Als letzte Möglichkeit gibt es nur noch das Erstellen eines Klons bzw. ein v2v Vorgang per Converter.

Beim Klonen der Maschine werden keine Snapshots mit übernommen – so sollte man den unerwünschten Snapshot auf jeden Fall weg bekommen.
Eine andere Möglichkeit ist ein v2v Vorgang mit dem VMWare Converter. Auch hier bleiben keine Snapshots bestehen.