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.

… sowie – ebenfalls bereits online – die vertonte Aufzeichnung des Webcasts. Wir wünschen erfolgreiches Backup!

“Cannot create a quiesced snapshot because the create snapshot operation exceeded the time limit for holding off I/O in the frozen virtual machine.”

Vorschläge wie disk.EnableUUID auf “False” zu setzen oder Quiesce VM zu deaktivieren führen dabei natürlich zu einem erstellbaren Snapshot sind aber gleichzeitig zu kurz gegriffen, weil damit die Anwendungskonsistenz deaktiviert (EnableUUID) oder gleich ganz auf Crash-Konsistenz umgestellt wird (Quiesce deaktiviert).

Abhilfe schaffen das kürzlich erschienene vSphere 4.1U1 …

Cannot take quiesced snapshots of Microsoft Windows Server 2008 R2 virtual machine running vCenter Server 4.1
When creating a snapshot of a Microsoft Windows Server 2008 R2 virtual machine that has vCenter Server 4.1 installed, the snapshot operation might fail to complete. This issue occurs on Microsoft Windows Server 2008 R2 virtual machines when the ADAM database is installed. The issue is resolved in this release.

… oder aber ein dem VMware-Support bekannter Workaround. Falls jemand also noch auf 4.1 gefangen ist und VSS benötigt: SR eröffnen – die Dateien aus dem Blog-Eintrag würde ich nicht so ohne weiteres auf meine Produktiv-Umgebung schmeißen. Mehr zum Thema VSS gibts in unserem Themen-Webcast nächste Woche.

Termin: Donnerstag, 03.03., 10:00. Zur Anmeldung gehts hier. Wir freuen uns wie jedes Mal über rege Teilnahme.

Ist das der Fall, verbringt Veeam nicht unerhebliche Zeit damit, den noch nicht genutzten (sparse) Plattenplatz zu verarbeiten (veeamagent32.exe bei 100% CPU). Im konkreten Fall einer VM mit 200 GB konfiguriertem und 25 GB genutztem Plattenplatz, bedeutet das in Zahlen:

• 3-4 Minuten Sicherung der tatsächlichen belegten 25GB.
• 4-5 Minuten Verarbeitung der restlichen, nicht existenten Daten.
• > 100% Overhead.

Die 4-5 Minuten Overhead fallen mit CBT komplett weg … was sich bei einer entsprechenden Anzahl an VMs und provisioniertem Plattenplatz summieren kann. Was für Veeam gilt, kann wegen VADP natürlich auch für andere Backup-Hersteller gelten (muss aber nicht).

Relativ simpel: Die vCenter Datenbank und damit auch die Berechtigungen aus VPX_ACCESS wurden übernommen. Damit kannte vCenter zwar wie gehabt die englische Gruppe ‘Administrators’ mit vollen Privilegien … die jedoch mit den deutschen ‘Administratoren’ auf dem neuen System relativ wenig zu tun hatte. Und ebendiese standen somit plötzlich ausgesperrt da. Nicht so weit her mit der Völkerverständigung, was?

Aus Englisch mach Deutsch

Zur Abhilfe in solch einem Fall also die deutsche Gruppe “Administratoren” mit Berechtigungen im vCenter ausstatten oder aber gleich nach vCenter Best Practices handeln und eine dedizierte Gruppe anlegen – mit der sich so ein Problem erst gar nicht ergibt. Im konkreten Fall gab es ein paar individuell mit Rechten ausgestattete Admins, die noch zugreifen und die Berechtigungen nachziehen konnten. Alternativ hätte auch manuelles Anpassen des Gruppennamens in VPX_ACCESS geholfen.

[INFO] [INFO] Msg 8114, Level 16, State 1, Server VCENTER\SQLEXP_VIM, Line 1 Error converting data type bigint to int. Msg 3013, Level 16, State 1, Server VCENTER\SQLEXP_VIM, Line 1 RESTORE FILELIST is terminating abnormally.
[ERROR] Error: vCenter Server DB backup failed
[ERROR] Exiting…

Der genaue Verursacher ist unbekannt, das soll jedoch nicht stören, denn immerhin gibt es einen recht einfachen Workaround.

Manuelle Datenmigration in 8 Schritten

Das Data Migration Tool automatisiert – wenn es denn funktioniert – das Backup/Restore der Datenbank und der Zertifikats-Dateien. Also gilt es diese Schritte per Hand durchzuführen.

Auf dem alten System:

1. vCenter Dienst stoppen.
2. vCenter Datenbank sichern. Entweder mit dem SQL Server Management Studio Express (Rechtsklick DB -> Tasks -> Back Up) oder mit SQL Backup and FTP.
3. Zertifikatsdaten aus “%PROGRAMDATA%\VMware\VMware VirtualCenter\SSL” sichern.
4. Sicherungsdaten auf das neue System kopieren. Das alte System abschalten.

Auf dem neuen System:

5. vCenter mit MS SQL Express installieren.
6. vCenter deinstallieren (DB bleibt erhalten), Datenbank-Backup vom alten System wiederherstellen und damit die kurz vorher installierte Datenbank überschreiben.
7. Zertifikatsdaten vom alten System nach “%PROGRAMDATA%\VMware\VMware VirtualCenter\SSL” kopieren.
8. vCenter wieder installieren und dabei die bereits vorhandene ODBC Verbindung nutzen. Der Installer erkennt die alten Daten und aktualisiert sie auf 4.1.

Dabei gilt es nach wie vor die Rahmenbedingungen aus #1021635 zu beachten, also entweder IP-Adresse und Name des alten Systems auf dem neuen System beizubehalten oder alternativ die im KB-Eintrag erwähnten Nacharbeiten durchzuführen. Schlussendlich sind die Daten umgezogen, und einem frohen Werkeln mit 4.1 sollte nichts mehr entgegenstehen.

#1: (Besser) Integrierte Tools

Jeder kennt das. Je mehr vertikale Layer (Storage, Netzwerk, OS, Anwendungen) durchschnitten werden, desto wahrscheinlicher sind Informationen, die man benötigt, nicht dort auffindbar, wo man sie bräuchte. Stattdessen muss man auf separate Dialoge oder auf Zusatz-Tools ausweichen. Wobei die Tools untereinander leider noch zu selten integriert sind und man sich deshalb in fensterwechselnder Manier durch zwar zusammengehörige, aber leider nicht verknüpfte Daten hangelt.

vCommander, vFoglight (for Storage), Orion & Co sind Beispiele für die erkannte Notwendigkeit der Daten-Integration, was schon mal löblich ist. Aber selbst da fehlt oft so etwas Simples wie eine beidseitige Verlinkung der Tools, die es ermöglichen würde, für ein Element im vSphere Client das übergreifende Tool aufzurufen und umgekehrt.

Hoffnung besteht dennoch, immerhin mehren und verbessern sich die hilfreichen Tools langsam, aber stetig. Weitere kritische Gedanken zum aktuellen Stand beim Thema Integration finden sich übrigens bei den Kollegen von ACM Queue.

#2: Gepflegte Feedback-Kanäle / Transparenz

Es dürften sich ruhig mehr Hersteller ein Beispiel an Veeam nehmen, die mit ihrem Produkt-Management ganz nah am Markt, und damit an den Anforderungen sitzen. Oder haben Sie schon einmal gegenüber ihrem Presales- oder Sales-Ansprechpartner erwähnt, welche Features für sie praktisch oder dringend hilfreich wären? Hatten sie dabei den Eindruck, ihr Anliegen kommt an?

Veeam hat vorgemacht, wie es funktionieren kann. Die Foren sind ein direkter Zugang zum Produkt Manager Gostev, und bei zu setzenden Entwicklungsschwerpunkten wird die öffentliche Meinung eingeholt (“What should the Veeam Backup & Replication Team Focus On?“).

Um Missverständnissen vorzubeugen: das ist nicht gleichzusetzen mit “Herstellern, die alles umsetzen was man möchte”, sondern lediglich mit klaren Kommunikationskanälen und ehrlichem Feedback.

Logische Kombination von #1 und #2

Wenn wir nun diese Idealwelt fertig zeichnen und Punkte 1 & 2 kombinieren, d.h. die Bedürfnisse der Anwender nach Integration quer durch die vertikalen Layer mit einem Produktmanagement zusammenbringen, das diese Bedürfnisse aufnimmt, dann müssten langfristig gesehen genau die Tools herauskommen, die wir benötigen. In diesem Sinne. Auf ein gutes 2011.

Wie man diese Grenze schneller erreicht als geplant (sprich mit einem deutlich höheren Bedarf als vom DB Calculator veranschlagt), haben wir die Tage unfreiwillig bei einem Testsetup herausgefunden: 7 ESX Hosts und 162 VMs, testweises Monitoring durch Nagios und OP5s check_esx3.pl, bei Datenmigrationsarbeiten dann plötzlich die Datenbank am Anschlag.

Event Type:	Error
Event Source:	MSSQL$SQLEXP_VIM
Event Category:	(2)
Event ID:	1827
Date:		12/15/2010
Time:		3:28:11 PM
User:		VMLAB\skayser
Computer:	VCENTER
Description:
CREATE DATABASE or ALTER DATABASE failed because the resulting cumulative database size would exceed your licensed limit of 4096 MB per database.

Auf der Suche nach dem Übeltäter

Event-Retention war keine aktiviert (das sollte auch so bleiben), aber auf Performance-Daten konnte verzichtet werden. Also kurzerhand diese auf die letzten 15 Tage gestutzt, was jedoch lediglich 100MB mehr an freiem Platz brachte. Bei der Suche nach sonstigen, prall gefüllten Tabellen fielen VPX_EVENT und VPX_EVENT_ARGS – zuständig fürs Event Logging – mit 2.6 GB an Daten und Indizes böse ins Auge. Wohlgemerkt von den 4GB die der DB überhaupt zur Verfügung stehen.

Etwas SQL später war klar, dass das Grande der Events (mit Abstand) durch Logins/Logouts gestellt wurde …

select event_type, count(*) as count from dbo.vpx_event
  group by event_type
  order by count desc

vim.event.UserLoginSessionEvent         1390049
vim.event.UserLogoutSessionEvent        1388743
vim.event.AlarmStatusChangedEvent	54588
vim.event.AlarmActionTriggeredEvent	36740
...

… und zwar ganze 2.8 Millionen (??). Auch unter Berücksichtigung der Anzahl an Admins, die auf der Umgebung werkelt, eine fragwürdig hohe Anzahl. Also weitergesucht und den verursachenden User ausgemacht. Der hieß “svc-nagios” … genau jener der fürs Nagios-Monitoring eingerichtet wurde. Und dieses Monitoring war gerade mal 2,5 Wochen in Betrieb.

Und nun?

Mit etwas unorthodoxer Lötarbeit (ähnlich diesem Ansatz) haben wir selektiv die svc-nagios Events aus der Datenbank gelöscht, Nagios abgeklemmt und sind nun wieder bei ca 3GB Datenbank Füllstand. Was lernen wir daraus? Die tatsächliche vCenter-Datenbank-Nutzung kann bei hoher Anzahl von Events eindeutig von kalkulierten Kenngrößen abweichen und das Nagios-Monitoring von ESX-Umgebungen kann gut noch etwas Hirnschmalz vertragen.

Denn dass die Nagios-Verbindungs-Anfragen an die vCenter-Webservices hohen SOAP-Overhead erzeugen, hatten wir ja bereits mal angeschnitten. Dass nun auch die Menge der Logins einen nicht unerheblichen Einfluss haben kann, ist nur ein weiteres Indiz dafür, dass ein wie auch immer gearteter, noch zu entwickelnder Nagios-vSphere-Verbindungs-Broker einen gewissen Charme hätte.

• Ausgesprochener Freund, weil dabei der Lösungsinstinkt anspringt.
• Kein Freund, weil solche Meldungen klarerweise nicht sonderlich benutzerfreundlich sind.

Neulich beim VM-Deployment von einem fremderstellten 2008 Template gab es wieder eine besonders hübsche Fehlermeldung nach dem Klick auf ‘Finish’. Lösung anbei, um zukünftigen Problemsuchenden schneller auf die Sprünge zu helfen:

Clone virtual machine w2k8-se-de-64bit Customization of the guest operating system ‘winLonghorn64Guest’ is not supported in this configuration. Microsoft Vista (TM) and Linux guests with Logical Volume Manager are supported only for recent ESX host and VMware Tools versions. Refer to vCenter documentation for supported configurations.

Zugrunde lag dem keinesfalls eine Inkompatibilität, sondern lediglich eine fehlende VMware Tools Installation im Template … und ohne die Tools funktioniert das Customizing klarerweise nicht, denn dazu müssen Dateien und Befehle ins Gast-OS injiziert werden (ähnlich wie das übrigens die Virtual Guest Console macht und diese benötigt auch zwingend die Tools). Also VMware Tools installiert, weitere individuelle Anpassungen am Template vorgenommen und sich am einwandfrei funktionieren Deployment erfreut.