Kategorie-Archiv: VMware

vmware Freie Blöck auf Datastore als frei markieren (Reclaim wasted Space, vmkfstools punchzero, storage unmap)

Veröffentlicht am von — 1 Kommentar ↓

Problem

NetAPP Nimble iSCSI Storage Platz freigebenEine 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

Veeam v8 „Post-job script timed out“

Veröffentlicht am von — Keine Kommentare ↓

Problem

Seit dem Update auf Veeam v8 läuft die Sicherung von virtuellen Maschinen zwar fehlerfrei („SUCCESS“) durch, trotzdem erhält der Job am Ende aber den Status „Warning“. Grund ist die Meldung „Post-job script timed out“.

veeam-post-job-timeoutLösung

In v8 wurde ein Timeout eingeführt, das nach 15 Minuten für Scripts die nach der Sicherung abläuft. Die zeit ist reichlich knapp bemessen. Das Timeout lässt sich in der Registry zum Glück ändern:

HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup and Replication

Einen REG_DWORD (32bit) Wert „PostJobScriptTimeoutSec“ hinzufügen und das Timeout in Sekunden angeben. Beispiel für fünf (5) Stunden:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup and Replication]
"PostJobScriptTimeoutSec"=dword:00004650

Nach der Änderung müssen die Backup-Services neu gestartet werden.

Windows Server Event 58 von partmgr (Die Signatur des Datenträgers …)

Veröffentlicht am von — 1 Kommentar ↓

Problem

Dateisystems-Snapshots eines Windows-Gastsystems welche VSS nutzen (sollen) funktionieren nicht korrekt. Die jeweiligen VSS-Trigger geben eine wirre Fehlermeldung aus (vCenter Quiescence error/KVM Ruhelage fehler/Hyper-V Snapshot Abbruch). Das Gast-Windows zeigt im Ereignisprotokoll einen „Event 58“ von der Quelle „partmgr“. Der Inhalt lautet

Die Datenträgersignatur von Datenträger <foo> ist mit der Datenträgersignatur von Datenträger <bar> identisch.

Der Fehler im (zum Beispiel) vmware-Gastprotokoll lautet:

Beim Stilllegen der virtuellen Maschine ist ein Fehler aufgetreten.
Weitere Informationen finden Sie im Ereignisprotokoll der virtuellen Maschine.

Under den Details ergänzt sich dies noch um folgendes:

Das Gastbetriebssystem hat während der Stilllegung einen Fehler gemeldet.
Der Fehlercode lautet: 3 Die Fehlermeldung lautet: Error when notifying the sync provider.

Lösung(en)

Es gibt mehrere möglich Ursachen. Eine Lösung dieser Liste hat bei unseren Fehlern bisher immer geholfen, wenn das bei dir nicht helfen sollte, schreibe einen Kommentar. Wir sind neugierig was noch so gibt.

1. Doppelte SCSI-ID (vmware)

Eine Pfad-ID (nicht Disk-ID!) für ein virtuelles Laufwerk kann unter bestimmten, aber ziemlich wirschen, Bedingungen auch mehrfach vergeben werden. Zum Beispiel wenn eine Disk auf der ESX-Shell kopiert (Bit-Copy) oder via abgestürztem Transport-Proxy in Veeam gesichert werden sollte.

Lösung: Eine neue Pfad-ID erzeugen, indem das Laufwerk von der VM getrennt wird (nicht löschen!), das Fenster geschlossen und dann das Laufwerk mit einer neuen SCSI-ID wieder angehöngt wird. Dann gibt es es einen komplett neuen Pfad und Windows findet die Platte beim nächsten Reboot zuverlässig am „neuen“ Strang. Fehler behoben.

2. Doppelte Disk-ID

Es ist technisch möglich, das eine Disk-ID zweimal vergeben wird. Das passiert schon mal unbeabsichtigt bei P2V/V2V oder P2P vorgängen, oder wenn man den Haken bei „Volumenidentifizierung beibehalten“ setzt. In seltenen Fällen auch mal dazwischen, wenn dd im Spiel ist. Achtung: Unter Hyper-V und vmware betrifft das auch die Disk-ID von Remote-Laufwerken (SAN/NAS via FC und iSCSI, vor allem RAW) – also alles was der jeweilige Host „sehen“ kann.

Lösung: Eine neue Disk-ID vergeben. An einem Administrator-Prompt die passende Disk auswählen und mit uniqueid behandeln:

C:\>DISKPART
DISKPART> list disk
  Datenträger ###  Status         Größe    Frei     Dyn  GPT
  ---------------  -------------  -------  -------  ---  ---
  Datenträger 0    Online          949 GB  1024 KB
  Datenträger 1    Online         1965 GB  1024 KB
DISKPART> select disk 0
Datenträger 0 ist jetzt der gewählte Datenträger.
DISKPART> uniqueid disk
Datenträger-ID: 5044D2AF
DISKPART>

Um dise ID zu ändern:

UNIQUEID DISK ID=DEADBEEF

Möglicherweise bootet Windows danach nicht mehr freiwillig. Einfach von einem passenden Installationsdatenträger booten, die Kommandozeile öffnen und den BCD wieder auf die korrekte (neue) ID einschiessen lassen:

X:\SOURCES> bootrec /fixboot
X:\SOURCES> bootrec /scanos
X:\SOURCES> bootrec /rebuildbcd

Dann klappts auch wieder mit dem Windows.

3. Der Geist eines toten Volumens

Eventuell hängen im Gerätemanager („ausgebelndete Geräte anzeigen“) ja auch noch ein paar tote Volumen herum, die sich aber auch äußerst hartnäckig dem entfernen wiedersetzen. Diesen rückt man besten mit Microsoft DevNodeClean zuleibe. Seltsame Devices entfernen (lassen), Reboot und alles ist wieder gut.

  1. DevNodeClean bei Microsoft herunterladen
  2. An einer Administrativen Shell mit 
    DevNodeClean /N

    die Devices auflisten (wenn nichts angezeigt wird, gibt es keine verwaisten Eintröge)

  3. Wenn notwendig, direkt an der Shell mit 
    DevNodeClean

    die Devices entfernen. Der Erfolg lässt sich mit /N kontrollieren.

  4. Reboot, fertig 🙂

 

Eine bestehende Thin Provisioned Virtual Disk (VMDK) verkleinern

Veröffentlicht am von — Keine Kommentare ↓

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]

HP Custom vSphere ESXi Image 5.5 Upgrade Fehler

Veröffentlicht am von — Keine Kommentare ↓

Problem

vsphere55-hp-iso-upgrade-errorSowohl ein Upgrade auf vSphere Version 5.5 mittel VUM (Update Manager) als auch das „harte“ booten des Hosts von einer Upgrade CD/ISO schlägt mit Warnungen fehl:

Compliance State: Incompatible

The upgrade contains the following set of conflicting VIB’s:
[Je nach Datum kann die Liste der VIBs variieren, aber es geht immer um Broadcom NIC Driver]

Lösung

Da scheint hp bei der Nummerierung der Versionen durcheinander gekommen zu sein. Einfach den aktuellen passenden Treiber VOR dem Update installieren, der ist korrekt benannt, fertig.

  1. Die „richtigen“ VMware-VIBs herunterladen Broadcom NetXtreme II Network/iSCSI/FCoE Driver Set
  2. .zip auspacken und das Offline Bundle (in einer weiteren .zip in der .uip) auf den betroffenen Host nach /tmp/ hochladen und installieren:
  3. esxcli software vib install -d –depot=/tmp/offline-bundle.zip -f
  4. Reboot, Rescan, läuft.

Trotzdem raten wir uggli-Admins zur customized HP-ISO. Die ganzen Sensoren in der HP-Hardware lassen sich dann vom Start weg nutzen und das ist der einzige [uns bekannte] Weg, alle Energiesparfeatures der DL und BL-Serie zu nutzen.