Beiträge

Veröffentlicht am

VM mit falscher Changed Block Tracking Information

Im Protokoll einer Veeam Sicherung trat neulich folgende Meldung auf:

Verifying changed block tracking…
Disk “Festplatte 2” has incorrect changed block tracking configuration.

Den Lösungsansatz lieferte das Protokoll selbst.

One or more VM disks have incorrect changed block tracking configuration. To resolve this, open VMware vSphere Client, right-click the VM, choose Edit Settings, Options tab, select General, click Configuration Parameters, and set all entries with ‘ctkEnabled’ substring to false. Veeam Backup will then automatically re-enable changed block tracking with the correct settings during the next job run.

Um dies zu korrigieren verfährt man folgendermaßen:

vSphere Client Offnen und die VM markieren. [Einstellungen bearbeiten] > Tab [Optionen] > [Allgemein] > [Konfigurationsparameter]. Sollte das Feld [Konfigurationsparameter] grau sein, so liegt es daran, daß die VM noch läuft. Für Modifikationen muß diese zuvor herunter gefahren werden.

Dort alle SCSI-Nodes suchen und den Wert bei ctkEnabeled auf “false” setzen. CTK wird beim nächsten Backup automatisch wieder auf “true” gesetzt.

 

Die VM darf zu diesem Zeitpunkt keine Snapshots haben. Vgl. hierzu KB Artikel 1020128.

Veröffentlicht am

Windows 7: CAPI2 Fehler 4107

Auf Windows 7 Systemen kommt es gelegentlich zu vielfachen CAPI2 Fehlern im Systemprotokoll mit der Event ID 4107.

A required certificate is not within its validity period when verifying against the current system clock or the timestamp in the signed file.

Ursache ist offenbar ein abgelaufenes Zertifikat in der Trust List. Microsoft KB 2328240.

Die manuelle Korrektur ist etwas mühsam, da sie für jeden Benutzer des Systems ausgeführt werden muß. Etwas komfortabler ist da das auf der selben Seite angebotene Fixit Tool. Für die Ausführung empfiehlt sich die Verwendung des IE, da man es unter z.B. Firefox nur abspeichern kann. Im IE läßt es sich direkt ausführen. Die Sicherheitswarnung am unteren Bildschirmrand muß man quittieren.
Nach dem Klick auf “Ausführen erhält man den unten dargestellten Dialog. Der EULA muß zugestimmt werden, sonst geht es nicht weiter. 😉

Veröffentlicht am

vSphere5: VCP Upgrade

Als VCP4 möchte man natürlich relativ zeitig seine Qualifizierung auf VCP5 erhöhen. Bis Februar 2012 besteht eine Übergangsperiode, in der Personen mit VCP4 Qualifikation lediglich das Examen auf VCP5 ablegen müssen. Der Kurs “vSphere5, what’s new” ist optional. Nach Ablauf der Übergangsfrist ist der Besuch des Kurses zwingend erforderlich.
VMware hat eine FAQ ins Netz gestellt, die die häufigsten Fragen beantwortet.

Veröffentlicht am

Storage: Berechnung Tablesize für Spiegel

Bei der Einrichtung eines Synchronspiegels zwischen zwei Eternus DX90 wird an einer Stelle nach der Tablesize gefragt.

Als Vorgabe steht dort 32MB “for day to day operation” – also für den alltäglichen Gebrauch. Damit fiel neulich ein Spiegelversuch auf die Nase. Erst die Erhöhung auf 64MB brachte die zweite Spiegelgruppe ins Rennen. Die dritte scheiterte wieder und ließ sich erst nach einer weiteren Erhöhung auf 128MB (Maximum) aktivieren.

Die Frage ist nun, wie berechnet man die notwendige Tablesize?

Auszug aus Fujitsu Eternus DX90 Web GUI User Guide

S1 EC/REC table size
M Bitmap ratio setting (Resolution)
C1 EC/REC copy capacity [GB]
N1 Number of EC/REC sessions

 

S1 [MB] = ((2 * C1 / M) + N1) * 8 [KB] / 1024 (counting fractions as one)

Beispiel mit 3 Copygruppen:

  • Gruppe1:   1 Spiegelpaar mit 1 TB
  • Gruppe2:   3 Spiegelpaare a 1,5 TB
  • Gruppe3:   3 Spiegelpaare a 1,3 TB

Gesamtvolumen C1 = 1 + 3*1,5 + 3*1,3 TB = 9,4 TB (=9625 GB)

Damit ergibt sich für für die Tablesize (mit Resolution =2):

S1 = ((2*9625/2)+7)*8[kB]/1024 = 75MB

Damit ist auch klar, warum die dritte Spiegelgruppe bei 64MB Tablesize nicht mitkam.

Referenzen

Fujitsu Eternus Web GUI User Guide