Folgende Staffelung ist aktuell vorgesehen (Je Lizenz)

• Essentials, Essentials Plus oder Standard = 1 x Socket + 24 GB vRAM
• Enterprise: 1 x Socket + 32 GB vRAM
• Enterprise Plus: 1 x Socket + 48 GB vRAM

Wenn man ein vCenter verwendet werden die vRAM Kapazitäten der gesamten Infrastruktur zur Verfügung gestellt, d.h. es wird ein vRAM Pool gebildet.

Um auszurechnen ob man für Version 5 aktuell genug Lizenzen zur Verfügung hat könnte man nun eine Liste aller Maschinen exportieren und selbst zusammenrechnen - oder man verwendet gleich das von VMware bereitgestellte Lizenz-Überprüfung-Script ^^

Vorraussetzungen

• vSphere 4 und Virtual Center
• VMware vSphere PowerCLI
• Das vSphere 5 Licensing Powershell Script

Nach dem starten des Scripts öffnet sich eine selbstsprechende GUI über die eine Verbindung zum VC hergestellt wird. Wenn die Auswertung abgeschlossen ist bekommt man einen schönen HTML Report mit allen relevanten Lizenzierungsinformationen.

Öfter mal was neues, die ganzen vSales Experts müssen ja von irgendwas leben. Irgendwie führt das aber das Shared Memory Konzept ad absurdum... naja

Als ich mir die Konfiguration der Hosts angeguckt habe ist mir folgendes aufgefallen:

ESX1

vmk0: Management Network

ESX 2 und 3

vmk0: vMotion Network

d.h. ein Neustart über die GUI startet bei 2/3 nicht das Management Network sondern die vMotion Network neu (Lt. VMware wohl ein bereits bekanntes Problem). Um die Maschinen ohne neustart wieder ans Netz zu bekommen habe ich folgende Aktionen durchgeführt:

• Per Remote Consolen Mngmt Software auf den Server schalten (ILO oder ähnliches)
• Den Local Tech Support Mode aktivieren
• Über die Console das bestehende Management Network löschen

  • esxcfg-vmknic -d "<Name des Management Network>"

• und  neu erstellen:

  • esxcfg-vmknic -a "<Name des Management Network>" -i <IP Adresse> -n <Netzwerkmaske>

Sofort danach waren die Maschinen wieder ansprechbar. Jetzt muss ich nur noch raus finden woran genau der Connection Lost herkommt.

A general system error occurred: Migration failed while copying
data. Already disconnected.

Mit folgenden Fehlerdetails

Migration to host <<unknown>> failed with error Already disconnected (195887150).
vMotion migration [-1407644152:1291646678441186] write function failed.
vMotion migration [-1407644152:1291646678441186] failed to flush channel: Already disconnected
vMotion migration [-1407644152:1291646678441186] socket connected returned: Already disconnected

Die behebung dieses Problems ist ein wenig aufwendig. Zuerst scheint der mit 4.1 eingesetzte nx_nic Treiber in Version 4.0.550 Probleme mit NC375x Quadport Karten zu haben.
KB 1027206: Determining NIC firmware and driver version in ESX/ESXi 4.x

Nach dem Update der nx_nic Treiber auf Version 4.0.570 ist das Problem gelöst.
Aktuelle VMware Treiber für die QLogic Netzwerkkarte gibt es hier. Installationsanleitung liegt bei (Bei ESXi einfach das vSphere CLI verwenden)

Das gesamte Problem ist auch hier beschrieben: KB 1026021: vMotion fails on ESX/ESXi 3.5 and 4.0 with some versions of nx_nic and unm_nic drivers

1. Der Host geht auf Status rot da wärend des Snapshot entfernen keine automatische Lastverteilung funktioniert.

DRS-Ressourceneinstellungen können nicht auf dem Host 'xyz' in 'Datacenter' angewendet werden (Ursache: Ein allgemeiner Systemfehler ist aufgetreten: Invalid fault). Dies kann die Effektivität von DRS erheblich beeinträchtigen.

2. Das Snapshot entfernen dauert zu lange fürs Virtual Center, d.h. es gibt eine Fehlermeldung sowie einen Timeout.
Tipp: Um zu sehen was los ist, direkt auf den entsprechenden ESX Host gucken, denn da läuft das entfernen weiter.

 3. Das Entfernen dauert eine halbe Ewigkeit, aber da muss ich jetzt wohl durch. Ich brauch ein schnelleres Storage, blödes Ding

So ein Snapshot entfernen kann schonmal ne Stunde dauern, ich darfs wohl nicht mehr vergessen. ^^

rpm -i /mnt/cdrom/VMware/RPMS/telnet-0.17-26.EL3.3.i386.rpm

und danach mit

rpm -e telnet-0.17-26.EL3.3

wieder runterwerfen.