Immer das gleiche mit den SSH,SCP Befehlen

Wenn man sie braucht sind sie einfach nicht mehr direkt im Kopf abrufbar!

Deswegen hier die Gedächtnisstütze fürs nächste mal..

tar -cvf - /var/lib/mysql | ssh admin@10.10.2.2 \ 'cat - > mysql.tar.gz'

Wenn man mal wieder eine Datei von einem Server zum anderen üdertragen muss und der alte nicht mehr genügend Speicher hat. In dem
Fall muss man den Output direkt via SSH auf den Zielhost senden.

 scp -P 1483 admin@10.10.2.2:/home/admin/file.tar.gz file.tar.gz

Alternativ wenn genügend Platz auf dem alten System ist kann man natürlich die Daten auch via SCP übertragen. Wenn allerdings der Port
nicht der Standart SSH Port ist muss man hier noch entsprechend das -P unterbringen.

VMware vSphere Hypervisor (ESXi) 6.5 U1 ist verfügbar

Der U1 des VMware vSphere Hypervisor ist seit gestern verfügbar. Für alle die schnell ihre 6.5er Installation mit einem Offline Bundle aktualisieren wollt hier eine kleine Anleitung. Achtung! Solltet ihr zufälligerweise eigene Treiber verwenden kann es durchaus sein das diese nach einem Update nicht mehr funktionieren. 

Nun ladet ihr über den Datenspeicherbrowser der ESXi Web UI das ZIP File auf den lokalen Datastore des ESXi. 

Nun brauchen wir ein Shellzugang zum ESXi. Hierzu öffnen wir Putty oder das Terminal eurer Wahl und verbindet euch.

Nun wechselt ihr in das Verzeichnis des Local Datastores. Alle Datastores findet ihr unter /vmfs/volumes/

Hier wird grundsätzlich jedes Laufwerk das dem ESXi zur Verfügung gestellt wird angezeigt. Einmal mit UUID und einem mit dem Alias.

Nun lasse ich mir den Paketinhalt meiner Zip Datei anzeigen um auch zu prüfen das beim Upload alles gut gegangen ist.

esxcli software sources profile list -d /vmfs/volumes/LOCAL-DS01/ISOs/update-from-esxi6.5-6.5_update01.zip

Nun wird es spannend wir wählen das passenden Image für uns aus. Grundsätzlich sollte man hier über das „standard“ Image wählen es sei denn man möchte die VMware Tools separat aktualisieren.

 esxcli software profile update -p ESXi-6.5.0-20170702001-standard -d /vmfs/volumes/LOCAL-DS01/ISOs/update-from-esxi6.5-6.5_update01.zip

Ich habe den Output an der Stelle abgeschnitten da er doch einige VIBs aktualisiert. Anschliessend müsst ihr natürlich den Host noch neustarten.

Was ihr mit „reboot“ machen könnt. Wichtig! Ihr solltet natürlich alle VMs runtergefahren haben.

Wenn alles gut verlaufen ist sollte euer ESXi nun folgende Versionsnummer anzeigen.

VMware PSOD Exception 14 in world..

Ein Pink Screen of Dead ist schon ärgerlich. Noch ärgerlicher ist es wenn dieser einfach sporadisch alle paar Wochen mal auftaucht und man gefühlt keine Ahnung hat wo genau das Problem liegt. Es gibt zwar von VMware direkt ein KB der Understanding Exception 13 and Exception 14 purple diagnostic screen events in ESX 3.x/4.x and ESXi 3.x/4.x/5.x/6.x (1020181)   sehr aufschlussreich war in meinem Fall, allerdings hat mich erst der Support dann auf die richtige fährte gebracht.

Mit dem Update auf ESXi 6.5 werden die legacy USB Treiber ( xhci, ehci-hcd, usb-uhci, usb, usb-storage) durch einen einzelnen USB Treiber vmkusb ersetzt. Leider scheint dieser in einigen Umgebungen und unter bestimmten umständen Probleme zu verursachen. Wir haben hier Dell PowerEdge R710 im Einsatz.

Um das Problem zu lösen, habe ich den Host in den Wartungsmodus versetzt und anschliessend via ESXCLI den alten USB Treiber wieder aktiviert.

esxcli system module set -m=vmkusb -e=FALSE

Danach muss der Host neugestartet werden. Solltet ihr den neuen Treiber wieder aktivieren wollen könnt ihr das mit folgenden Befehl.

 esxcli system module set -m=vmkusb -e=TRUE

das Problem soll in einer der nächsten Releases auf alle fälle gefixt sein.

Von MBR zu GPT ohne Datenverlust

Beim erstellen einer VM plant man eigentlich immer den zu verwendbaren Speicherplatz so optimal das man nicht unbedingt alle 2 Wochen erneut an die VM hand anlegen muss um den Speicherbedarf
anzupassen. So zumindest die Theorie. In der Praxis kommt dann ein Exchange Server und eine immer kleiner werdende physikalische Festplatte die einem das Leben etwas erschweren. Das Problem der immer kleiner werdenden physikalischen Festplatte wurde durch ein neues Storage behoben. Allerdings musste nun auch der VM entsprechend mehr Speicherplatz zugewiesen werden. In VMware einer virtuellen Festplatte meher Speicher zu geben ist eine Leichtigkeit. Das ist in diesem Fall eher die Windows Seite. Alles was über 2 TB Datengröße kommt braucht nämlich eine GPT Partitionstabelle. Microsoft bietet zwar mit Diskpart eine Lösung an um aus Festplatten mit MBR welche mit GPT Partitionstabellen zu machen aber das geht nur wenn keine Partition vorhanden sind bzw. er löscht die bestehenden.

Achtung meine Vorgehensweise nicht direkt mit Festplatten umsetzbar auf denen euer Betriebssystem läuft.

Nach etwas suche bin ich auf ein Linux Tool gestossen das es auch für Windows gibt. gptgen
Als erstes müsst ihr die mit diskpart herausfinden ob es sich um disk0, disk1 oder ähnlich handelt. Wichtig ist eigentlich nur die Zahl. Mit list disk bekommt ihr hier eine schöne übersicht.

gptgen.exe \\.\\physicaldrive1
Write primary.img to LBA address 0.
Write secondary.img to LBA address 4395431903.

GPTGEN macht seine Anpassungen nicht direkt auf die Festplatte. Er erstellt von seinen änderugen entsprechende Datei. Einmal vom Primären MBR und eine Datei vom Backup MBR. Wichtig ist dies für deswegen da GTPGEN ausgibt an welche Stelle sich der Backup MBR befindet auf der Festplatte. Damit können wir im Fall das GPTGEN misst baut den Original MBR wiederherstellen.

Dazu müssen wir aber erst mal ein Backup von dem bestehenden MBR machen. Idealerweise mit dd

dd if=\\.\\physicaldrive1 of=primary-backup.img bs=512 count=34
dd if=\\.\\physicaldrive1 of=secondary-backup.img bs=512 count=33 skip=4395431903

Nun können wir GPTGEN auch wirklich schreiben lassen. Dazu führt ihr folgenden Befehl aus.

gptgen.exe -w \\.\\physicaldrive1

In der Datengrägerverwaltung sollte die Festplatte nach einem Aktualisieren ( F5 ) nun entsprechend als dynamischer Datenträger mit GPT Partitionstabelle zu finden sein.

Sollte tatsächlich etwas schief gegenangen sein könnt ihr mit folgenden Befehl den MBR wiederherstellen.

dd if=primary-backup.img of=\\.\\physicaldrive1 bs=512 count=34
dd if=secondary-backup.img of=\\.\\physicaldrive1 bs=512 count=33 seek=4395431903

VMware ESXi 5.x-6.x Hostname/FQDN ändern via CLI

Manchmal steht man vor Aufgaben die eigentlich sehr einfach sind wenn man einen Webbrowser hat. Wenn man aber so wie ich in diesem Fall keinen wirklich anwendbaren Browser sondern nur ein iPad hat genügt auch ein Terminal.

Mit diesen zwei Befehlen lässt sich via ESXCLI der Hostname sowie den Full Qualified Domain Name anpassen.

esxcli system hostname set --host=hostname
esxcli System hostname set --fqdn=fqdn

Wichtig ist das der Host nicht mit einem vCenter verbunden ist. Würde man den Hostnamen ändern und der Host wäre noch mit eine vCenter verbunden würde dieser eben den Host nicht mehr finden. Vorausgesetzt man hat Best Practice den Host auch nicht via IP sondern via hostname.fqdn verbunden 😉

Das entfernen des Hosts aus dem Cluster sollte über den vSphere Client passen. Egal ob nun Web oder C# Client. Der Host muss dazu im den Wartungszustand versetzt werden(Rechtsklick aus dem Host und Wartungsmodus) und alle VMs verschoben oder Ausgeschaltet sein. Danach könnt ihr den Host mit einem Rechtsklick und entfernen aus dem Cluster lösen.

Den Wartungsmodus könnte ihr auch über die ESXCLI aktivieren und beenden.

Zum aktivieren

esxcli system maintenanceMode set --enable true

Zum deaktivieren

esxcli system maintenanceMode set --enable false

Wichtig ist das alle VMs vorher beedet sind sonst schlägt das versetzen in den Wartungsmodus über CLi fehl.