• über unseren Newsletter sowie
• in unseren Webcasts

zu veröffentlichen.

Abonnieren Sie unsere Info-Mailings!

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

Die Webcast-Inhalte:

• Warum ist Monitoring gerade auch im Virtualisierungsumfeld wichtig?
• Was gilt es in VMware Umgebungen im Blick zu behalten?
• Wie realisiert man dies mit Nagios?
• Ausblick: Schnittstellen, Erweiterungsmöglichkeiten und weitere Bausteine

Termin: Dienstag, 19.07.,11 10:00 Uhr. Zur Anmeldung gehts hier. Wir freuen uns wie jedes Mal über rege Teilnahme!

System Wide versus Self Contained

Man sollte dabei beachten, dass die vorkompilierten Pakete normalerweise in der Installationsversion „System Wide“ verfügbar sind und auf den Einsatz der Umgebungsvariable „ONE_LOCATION“ verzichten. Das gilt sowohl für die Pakete aus den Repositories als auch für die auf der Opennebula.org Seite verfügbaren (Stand 1.6.2011).

Bei dem Einsatz der VMWare Drivers Version 2.2.0 ist aber die Verwendung der „Self Contained“ Installation notwendig, da  „ONE_LOCATION“ zwingend ausgewertet wird. Hierfür mussten wir die Software neu kompilieren und installieren.

Fehler im Installationsskript von VMware Drivers

Nach der Installation der VMWare Drivers müssen noch einige Dateien umkopiert werden:

mkdir -p $ONE_LOCATION/var/remotes/im/vmware.d

cp –r $ONE_LOCATION/lib/remotes/im/vmware.d/*  $ONE_LOCATION/var/remotes/im/vmware.d

und

mkdir -p $ONE_LOCATION/var/remotes/vmm/vmware

cp -r $ONE_LOCATION/lib/remotes/vmm/vmware/* $ONE_LOCATION/var/remotes/vmm/vmware

Dieser Fehler soll in der Version 3.0 der Treiber behoben sein.

(http://dev.opennebula.org/issues/593)

Libvirt ohne ESX Unterstützung

Eine (vorerst) letzte Hürde betrifft die Verwendung von libvirt bzw. virsh als Schnittstelle zum ESX. Bei den von uns verwendeten Ubuntu Versionen 11.04 und 10.04 LTS werden libvirt Versionen kleiner 0.8.3 zur Verfügung gestellt. Alle hatten den ESX-Treiber deaktiviert.

Das oned.log hatte deshalb die Einträge:

error: Cannot access CA certificate ‘/etc/pki/CA/cacert.pem’: No such file or directory

Versionen ab 0.8.3 würden in dem selben Fall die hilfreichere Zeile:

error: invalid argument in libvirt was built without the ‘esx’ driver

ausgeben.

Abhilfe schafft nur das Kompilieren einer neueren libvirt mit ESX Unterstützung.

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.