A general system error occurred: error accessing directory. Error stack: Call “UserDirectory.RetrieveUserGroups” for object “UserDirectory” on vCenter Server “VCENTER” failed

Dann nämlich kann der vCenter Dienst nicht mit seinem AD kommunizieren und Abhilfe muss her (vpxd.log sagt: “Vmomi.Fault.SystemError: A general system error occurred: error accessing directory” zu dem Problem).

Eine Frage von Service Accounts

In der VMware KB findet sich zur Fehlermeldung etwas zu Timeouts (nicht zielführend) und laut Support sollte das Umstellen auf einen Service-Account aus der Domäne helfen. Das stimmt prinzipiell, ganz so weit greifen muss man jedoch nicht – denn wahrscheinlich trat das Problem bis vor Kurzem noch nicht auf und einen dedizierten Domänen-Account hatte man auch noch keinen in Verwendung … aber ein vCenter 4.1 Upgrade wurde kürzlich durchgeführt.

Klingt bekannt? Falls ja, dann mal einen Blick in die Anmelde-Daten werfen, welche für vCenter und vCenter Web Service verwendet werden. Stehen diese auf “.\Administrator” sind die Kommunikations-Schwierigkeiten erklärt, denn der lokale Administrator hat keine Rechte aufs AD zuzugreifen. Hier schafft bereits das Korrigieren auf den “Local System Account” Abhilfe.

Änderungen an der maximalen Konfiguration:

• Anzahl virtueller Maschinen pro Cluster: 3000 (bei 4.0: 1280)
• Anzahl Hosts pro vCenter: 1000 (bei 4.0: 300)
• Registrierte virtuelle Maschinen pro vCenter: 15000 (bei 4.0: 4500)
• Eingeschaltete virtuelle Maschinen pro vCenter: 10000 (bei 4.0: 3000)
• Gleichzeitig verbundene VI Clients: 120 (bei 4.0: 30)
• Hosts pro Datacenter: 500 (bei 4.0: 100)
• Virtuelle Maschinen pro Datacenter: 5000 (bei 4.0: 2500)

Neues Feature: “Network I/O Control”

Besonders für 10 Gbit – Netzwerke von Interesse. Nun kann die Netzwerkqualität für verschiedene Protokolle (z.B. iSCSI, NFS, usw.) konfiguriert werden. Die Vorteile sind nahezu selbsterklärend: mehr Service-Qualität für entsprechende Business-Anwendungen und die bedarfsabhängige Konfiguration von Netzwerkprioritäten ist nun möglich.

Neues Feature: “Memory Compression”

Eine neue Ebene der Überallozierung des virtuellen Speichers. Memory Compression stellt das Bindeglied zwischen dem bisher bekannten Memory Overcommit, bei dem mittels Page sharing Speicherseiten von mehreren virtuellen Maschinen genutzt werden können und dem platten SWAP, dem Auslagern von Arbeitsspeicher auf die Festplatte dar. Der Komprimierungstechnik selbst ist ein VMware “Safeguard” vorgeschalten, der sicherstellt, dass Daten sicher verwaltet werden.

Neues Feature: “DRS Host Affinity”

Bisher hat eine systemeigene Logik die Verteilung der Maschinen via DRS (Dynamic Ressource Scheduler) übernommen. Nun können wir mittels Policies klar definieren, welche VM auf welchen Host oder welche Gruppe von Hosts verteilt werden darf. Nicht nur die Benennung von Hosts selbst, sondern auch die Verteilung auf Systeme, die definierten Voraussetzungen (z.B. CPU-Typ) entsprechen, soll möglich sein.

Weitere Neuerungen:

“Virtual Serial Port Concentrator (VSPC)” – Nun kann man sich über das Netzwerk (unter Verwendung eines “Serial Port Concentrator”s) auf den seriellen Port verbinden. Das Feature soll eine effizienteres Management und kostengünstigere Remote-Wartungsmöglichkeiten bieten.

“vStorage API for Array Integration (VAAI)” – Ein neues Protokoll-Interface zwischen VMware und Speicher-Arrays.  Diese API bieten Array-basierte Funktionalitäten in Bereichen wie LUN-Provisioning oder Snapshots. VAAI ist in vSphere voll integriert, eliminiert Redundanzen im Storage-Bereich und beschleunigt die Performance von verschiedenen, mit dem Storage verbundenen Vorgängen und Komponenten (z.B.: Storage vMotion, Erstellung neuer VMs, Thin Provisioning und das VMFS).

vMotion-Verbesserungen – Die Geschwindigkeit und Skalierbarkeit von vMotion wurde erhöht. Nun sind parallel bis zu acht vMotion-Vorgänge möglich. Darüber hinaus wurde in den VMware Labors eine Beschleunigung des Vorgangs um ein >4,5-Faches bescheinigt. Gerade bei virtuellen Maschinen, die mit einer nicht unerheblichen Menge an Arbeitsspeicher konfiguriert sind, war vMotion durch lange Übertragungsvorgänge des Arbeitsspeichers, bzw. aller Deltas, bisher ein Abenteuer. Dies soll sich nun spürbar verbessert haben.

HA-Verbesserungen – Zusätzliche Alarmierungen, wie z.B. bei der Verletzung von HA-Konfigurationsparameteren, Einführung eines “not flick Status” zur Überwachung des Clusters und genauere Prüfungen zu “Güte” (Prüfung von Ressourcen, Lokation) des neuen Hosts einer virtuellen Maschine machen die Funktion effektiver. Ein Healthcheck-Status, eine Anzeige aktueller HA- und DRS-Vorgänge und eine angeblich optimalere Zusammenarbeit zwischen HA und DRS erzeugen – mindestens beim Lesen der Feature-Liste – mehr Transparenz.