Archiv der Kategorie: VMware

Problem

Der Kunde (natürlich NIEMALS ein Admin :-)) hat sich ausversehen aus der vmware vCenter Appliance ausgesperrt. Das Kennwort für root ist abgelaufen. AD-Anmeldungen schlagen ebenfalls fehl. Nach einer „zu langen“ Wartezeit geht nämlich auch die AD-Anmeldung der vCSA verloren – jetzt soll das root-Konto wieder aktiviert werden.

Die Reaktivierung des Kontos und der Kennwort-Zurücksetzen Vorgang sind sich sehr ähnlich, daher hier die Anleitung für die Aktivierung eines abgelaufenen root-Kontos und das zurücksetzen des root-Kennwortes in einem.

Lösung

1. Mit dem vSphere Client auf den Host verbinden, auf dem die vCSA läuft und die Konsole der Appliance öffnen.
2. Wenn der GRUB Bootloader zu sehen ist, mit der Leertaste den automatischen Vorgang anhalten.
3. Den „VMWare VCenter Appliance“-Eintrag (der erste von oben) markieren und „p“ zur Passworteingabe drücken.
4. Das Kennwort für den GRUB-Bootloader lautet „vmware“ (Es sei denn man hat mit VAMI die Kennwörter geändert, dann ist das GRUB-Kennwort das VAMI Systemkennwort)
5. Den „VMware vCenter Server Appliance“ Eintrag wieder markieren und „e“ zum editieren der Bootoptionen drücken
6. Zu den Boot-Optionen hinzufügen:

   init=/bin/bash

7. Mit „Enter“ die Änderung übernehmen und dann mit „b“ den Bootvorgang starten. Achtung, das booten direkt an die Shell geht jetzt sehr schnell (und was sich reimt war schon immer gut)
8. Mit „passwd root“ das Kennwort für den root-Benutzer ändern
9. vCSA Neu starten, fertig.

Um den Root-Zugang im Falle der Sperrung wieder zu entsperren, eingfach bei Punkt 8 (das ist gestartet bash-shell für die VCSA) weitermachen:

1. Die Datei /etc/shadow bearbeiten

   vi /etc/shadow

2. Mit den Pfeiltesten navigiert man in die „root“ Zeile, drückt „i“ für den Insert-Modus und löscht das „x“ vor dem Dollarzeichen. Damit ist Sperrung auc schon aufgehoben.
3. Die drittletzte Zahl der Zeile ist die Anzahl der Tage für den Kennwortablauf, wenn gewünscht kann man hier die Zahl auch direkt ändern (oder löschen für „niemals“)
4. Speichern mit ESC (insert-mode verlassen), dann den „:“ (Doppelpunkt) für die Befehlseingabe drücken und mit dme Befehl „w!q“ (dann Enter) speichern und schliessen.
5. Neu starten, fertig.

Problem

Eine SAN Lun (NetAPP, EMC, Nimble, Nutanix …) die (insgeheim oder nicht) Thin Provisioning auf dem Array (oder Volumen, Aggregat, Shelf, whateveritscalled) macht, läuft seit vSphere 5.x langsam voll. Es ist immer weniger Speicher auf dem Aggregat frei. Die Gastmaschienen bleiben gleich groß, aber jeder Storage-vMotion-Vorgang und jedes erstellen/löschen von Daten auf dem Datastore hinterlässt weniger freien phasikalischen Speicher auf dem Aggregat. Der Datastore wird im vSphere Client aber mit unverändert viel Speicher und unverändert viel freiem Speicher angezeigt. Nur die physikalisch Belegung wird größer und größer.

Lösung

Wenn eine thin provisioned Lun mit Daten beschrieben wird, werden diese Daten „hart“ geschrieben. Werden diese Daten dann wieder gelöscht, werden die Daten aber nicht wirklich gelöscht („mit Nullen überschrieben“), sondern die betroffenen Blöcke werden nur als „frei“ markiert. Ähnlich arbeiten praktisch alle heutigen Dateisysteme, weil ein Löschvorgang andernfall ein Schreibvorgang vollständiger größe und wäre und somit (potentiell) lange dauern würde.

Wenn nun häufig Daten geschrieben und gelöscht werden, werden nach und nach mehr Blöcke mit „als gelöscht“ markierten Daten hinterlassen. Ein SAN kann von aussen nicht unterscheiden, welche Daten echt sind und welche als löschbar markiert – dazu wäre technisch tiefe Einsicht in das Dateisystem notwendig. Tatsächlich freie Bereiche („Nullen“) erkennen SANs aber in der Regel als solche. Dieser Vorgang wird oft als punchzero, zero free space, reclaim wasted space, unmap disk space oder ähnliches bezeichnet.

Windows 2003 und höher

Unter Windows kann das Tool sDelete von Sysinternals den freien Bereich eines Datenträgers mit Nullen füllen.

c:\>sdelete -p 1 -z c:

ESX(i) Instalationen bringen ein entsprechendes Tool ebenfalls mit. Je nach vSphere Release unterscheidet gibt es allerdings etwas andere Namespaces dafür.

vSphere 5.1

vmkfstools -y 95 -d /vmfs/volumes/DATASTORENAME

vSphere 5.5

storage vmfs unmap -l DATASTORENAME

Linux

dd if=/dev/zero of=/DISK/foo.bar bs=4096 && rm -f /DISK/foo.bar

Zum Beispiel lässt sich dieser Vorgang auch via ESXCLI auslösen, zum Beispiel monatlich:

c:\>esxcli -s SERVER -u root -p PASSWD storage vmfs unmap -l DATASTORENAME

VMware Thin Provisioned VMDKs sind ja mittlerweile weder ein Performanceproblem noch eine VCDX Design-Unschicklichkeit, sondern ganz im Gegenteil in vielen produktiven Systemen zu finden. Vor allem temporäre Datenbankexplosionen (Temp Bulk-Inserts oder Exports) lassen sich damit ausgezeichnet vor der teuren Belegung von Produktivstorage abfedern. TEMP-Volumes die zwar in der Regel klein, aber im Notfall dann größer sein müssen sind schon fast „Thin-Standard“.

Oft wird uns die Frage gestellt, wie man eine Thin-Disk, nachdem diese temporär mit Daten belegt worden ist, wieder kleiner bekommt. Die VMDK wächst ja bekanntlich mit, verkleinert sich aber selbstständig nicht. Wie verkleinert man VMDKs?

Lösung

Die entsprechende Partition muss für optimale Ergebnisse erst defragmentiert werden und der freie Speicher dann mit Nullen gefüllt sein. Diese werden von den VMKFSTOOLS dann als solche erkannt. Betriebssystme Nullen ihren Speicher aus performancegründen praktisch nie, daher muss das forciert werden. geht aber recht schnell.

1. Windows: SDelete herunterladen und mit

   sdelete.exe -z <Laufwerk>

   den verbliebenen Restspeicher nullen.
   

2. Linux: Den Platz nullen mit dd:

   dd bs=1M count=8192 if=/dev/zero of=zero

3. VM ausschalten (oder VMDK disconnecten)
4. Via SSH auf einen Host verbinden
5. Disk verkleinern mit

   vmkfstools -K [/vmfs/volumes/lun178/mydisk.vmdk]