VMDK Archives - ElasticSky

27. Oktober 201424. Januar 2018

ESXi: kritischer Fehler in CBT kann Backups unbrauchbar machen

Changed-Block-Tracking (CBT) ist eine sehr nützliche Funktion, um beispielsweise einer Backup Software mitzuteilen, welche Blöcke sich seit einen Zeitpunkt [t] verändert haben. Somit können gezielt diese Blöcke gesichert werden, was natürlich erheblich Zeit spart.
Genau in dieser CBT Funktion gibt es einen Fehler, der lange unerkannt blieb. Er tritt nach Angaben von VMware dann auf, wenn eine vDisk über 128 GB vergrößert wurde.
VMware und Veeam empfehlen, nach einer Vergrößerung der vDisk einer VM, einen CBT reset durchzuführen. Beim nächsten Durchgang von Veeam Backup wird CBT wieder aktiviert und arbeitet korrekt.

Alternativ kann auch ein PowerCLI Skript verwendet werden, das CBT im laufenden Betrieb zurücksetzt. Das Skript resetCBT wurde vom Veeam Support erstellt. Der Aufruf erfolgt mit Parametern. Es funktioniert nur bei eingeschalteten VMs.

Verwendung auf eigen Gefahr !

-vcenter: <FQDN vCenter>

-vms: Liste der VMs durch Komma getrennt (keine Leerzeichen!)

resetCBT.ps1 -vcenter example.vcenter.local -vms "vmname1,vmname2,vmname3,vmname4"

Update:

Möglicherweise löst VMware das Problem in ESXi5.5 mit aktuelltem Patchlevel (2143827) automatisch (?). Nach der Vergrößerung einer vDisk meldete Veeam Backup (v7) folgende Warnung:

Wurde von Seite des ESXi Servers das CBT automatisch deaktiviert?

Update 17. Nov 2014

Veeam hat einen Hotfix für B&R Version 7 veröffentlicht. Er besteht aus 4 DLL Dateien, die getauscht werden müssen. Voraussetzung ist Veeam Backup and Replication 7.0.0.871 (patch 4).

Sicherstellen dass Version 7.0.0.871 installiert ist
Veeam Dienste stoppen
DLLs im Verzeichnis “C:\Program Files\Veeam\Backup and Replication\Backup” mit den Hotfix DLLs ersetzen.
Veeam Dienste wieder starten

VMDK umbenennen

Mit vSphere 5.1U1 wurde ein Feature wieder eingeführt, welches für einige Versionen deaktiviert war. Die automatische Umbenennung der VM Dateien bei einem Storage vMotion Prozess.

Bei Namensänderung der VM bewirkt zunächst noch keine Umbenennung der zugrunde liegenden VM Dateien. VM Template01 wurde in Dummy01 umbenannt. Die VM Dateien tragen jedoch weiterhin den ursprünglichen Namen Template01.

Erst ein Storage vMotion (svMotion) der VM korrigiert den Namen.

Kein Storage vMotion

Manchmal ist eine VM einfach zu groß, oder es steht nicht genügend Speicherplatz für ein svMotion zur Verfügung. Auch dann kann man die Diskfiles einer VM umbenennen. Es ist allerdings etwas weniger komfortabel.

vmkfstools

Für die beschriebene Prozedur muss die VM ausgeschaltet sein und man benötigt die vSphereCLI oder die vMA.

Das Verfahren wird bei VMware unter KB 1002491 beschrieben.

VSphere5.1: VMDK oder RDM?

Eine Diskussion, die immer wieder geführt werden muss, ist die Entscheidung ob für spezielle Anwendungen ein Raw Device Mapping (RDM) anstatt vDisk Containern (vmdk) eingesetzt werden soll. Die Debatte bekommt nun neue Argumente zugunsten der VMDK. Tatsächlich sieht ein neuer Benchmark im vSphere-Blog beide Alternativen auf Augenhöhe, jedoch gewinnt der vmdk Container wegen seiner höheren Flexibilität.

blogged somewhere in time…

25. Februar 2012

Storage DRS default affinity

Mit Einführung von vSphere5 kam Storage-DRS als eine neue Funktionalität hinzu. Ähnlich dem herkömmlichen DRS, welches die VM Lastverteilung bezüglich Arbeitsspeicher und CPU zwischen den ESXi Knoten regelt, ermöglicht Storage-DRS eine automatische Lastverteilung in Bezug auf Speicherplatz und I/O.

In der Praxis beobachtet man jedoch häufiger, daß VMs oder einzelne ihrer vDisks nicht migriert werden, obwohl erhöhte Last über einen längeren Zeitraum auftritt. Die Ursache, warum Storage-DRS beispielsweise nicht die vDisk einer VM verschiebt, welche die stark beanspruchte Datenbank enthält, fand ich durch einen Blogartikel von Duncan Epping auf Yellow-Bricks.

Die Standard Einstellung eines jeden Storage Clusters ist “VMDKs zusammenhalten” bzw. “keep VMDK’s together”. Eine Default Einstellung, die sicherlich dem Admin entgegenkommen soll, damit er nicht alle Disks seiner VM auf mehrere LUNs verteilt suchen muß. Der Preis für diese “Ordnung” ist allerdings, daß die Dateien einer VM nur komplett oder gar nicht verschoben werden. In der Praxis bedeutet dies, daß z.B. eine VM mit 5 vDisks von je über 100 GB nur unter extremsten Bedingungen auf eine andere LUN wandern würde. Wünschenswert wäre jedoch, daß beispielsweise nur eine einzelne VMDK Datei verschoben wird, da diese gerade unter erhöhten I/O Druck geraten ist.

Die nett gemeinte, aber etwas unflexible Standardeinstellung dieses Verhaltens läßt sich leicht ändern:

Ansicht Datenspeicher und Datenspeicher Cluster
Kontextmenü von Datenspeicher-Cluster öffnen und “Einstellungen bearbeiten” wählen
Einstellungen der VM
Haken bei “VMDKs zusammenhalten” entfernen. Entweder für einzelne VMs oder global für den gesamten Storage-Cluster.

Weiterführende Literatur

Frank Denneman zum Thema impact of intra vm affinity rules on storage drs.

Schlagwort: VMDK