Archiv für die Kategorie „Virtualisierungssoftware“

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

Nachdem die letzte halbe Stunde mit Grübeln vergangen ist, fällt es mir eben wie Schuppen von den Augen. Wovon ist die Rede? Migration eines vCenter von einem englischen W2K3 System auf ein deutsches W2K8 System. Danach konnten sich einige Admins noch anmelden, andere – und auch der lokale Administrator – jedoch nicht. Was war passiert?

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.

Typisches Szenario: vCenter 4.0 ist auf einem 32-Bit System installiert und das anstehende Upgrade auf 4.1 benötigt ein 64-Bit System, auf welches migriert werden muss. Fährt man dabei eine MS SQL Express 2005 Datenbank als Unterbau, kann man das Data Migration Tool nutzen, um die Migration durchzuführen. Außer man stolpert dabei über folgenden (wohl bekannten) Fehler.

[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. Diesen Beitrag weiterlesen »

2010 ist vorbei, der weihnachtliche Winterschlaf auch, und 2011 wird fraglos wieder im Zeichen von Virtualisierung und der vielbemühten – aber deutlich handfester werdenden – Cloud stehen. Während andere in der V-Blogosphäre über 2010 resümieren (u.a. hier, hier, hier, hier oder bei John Troyer’s VMware-Communities-Roundtable-Jahres-Review), wollen wir einen kurzen Blick nach vorne werfen und uns kurz eine Idealwelt ausmalen, in der Hersteller etwas von dem umsetzen, was man so braucht. Wie sähe so ein Wunschzettel aus? Diesen Beitrag weiterlesen »

vCenter kommt bekanntlich von Haus mit der kostenfreien SQL Express 2005 Edition zur Datenhaltung daher. Neben weichen Dimensionierungsrichtlinien wie max. 5 ESX Hosts und 50 VMs, gibts eine sehr harte Richtlinie und die lautet: max 4GB an Daten.

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. Diesen Beitrag weiterlesen »