Autorenarchiv

postheadericon vCenter 4.1: error accessing directory

Bei einem AD-integrierten vCenter kann man bekanntlich sehr schön vSphere-Privilegien auf Basis vorhandener AD-Benutzer vergeben – außer man bekommt gerade folgende Fehlermeldung vom vSphere Client gemeldet.

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.

postheadericon Slides & Aufzeichnung zu “VSS demystifiziert”

Backup ist gut, konsistentes Backup ist besser. So in etwa lässt sich unser heute stattgefundener Webcast zum Thema MS Virtual Shadow Copy Service und VMware zusammenfassen. Wer diesen verpasst hat oder Revue passieren lassen möchte, findet anbei die dazugehörigen Slides …

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

postheadericon VSS, W2K8R2 und das ‘exceeded time limit’

Mit vSphere 4.1 fand Support für Anwendungs-konsistente Snapshots via VSS Einzug in den VMware-Stack. Dass dabei nicht alles so einwandfrei lief, wussten zahlreiche Leidesgenossen in den Communities zu berichten. Übliches Fehlerszenario bei der Snapshot-Erstellung von ADC- oder vCenter-Servern:

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

postheadericon Upcoming Webcast: VSS demystifiziert

Nach längerer Sendepause wirds mal wieder Zeit für eine weitere Episode unserer Webcast-Serie. Diesmal bestritten vom werten Kollegen Markus Lichterfeld und meiner Wenigkeit. Das Thema: VSS und dessen Zusammenspiel mit Image-basierter Windows-VM-Sicherung – also Pflichtlektüre, wenn man Wert Backups legt, die sich auch wiederherstellen lassen.

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

postheadericon Veeam: CBT spart nicht nur bei Incrementals

Veeams Backup & Replication (und viele andere) nutzen VMwares Changed Block Tracking (CBT), um die übertragene Datenmenge bei inkrementellen Backups zu minimieren. Interessanterweise hilft CBT im Fall von Veeam (getestet mit 5.0.1) jedoch nicht nur bei inkrementellen Backups, sondern auch bei Voll-Backups – und zwar wenn VMs thin provisioned sind und ihren konfigurierten Plattenplatz nicht komplett belegen.

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