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.

VMware Horizon View 6.2.4 Uprade und TLSv1.0

Eigentlich gibt es eine goldene Regel in der IT. Freitag ist Read Only Friday und weil man kein Bock hat auf Panik am Wochenende hält man die Finger still. Leider musste ich unsere angestaubte VMware Horizon View Farm aber mal eben schnell aktualisieren weil das verwenden von Windows 10 Enterprise als Gastsystem nicht möglich war. Ich wollte nicht direkt mit der Brechstange auf Version 7 gehen und da es sich nur um ein Bugfix Release handelte und der eh schon überfällig war dachte ich mir dabei auch sehr wenig.

Mein Gastbetriebssystem lief nach einer kurzen Updatephase einwandfrei. Leider haben wir bei manchen Hubs eine ältere Version vom VMware View Client im Einsatz und hier kam es auch zur ersten Meldung das eine Verbindung nicht möglich war. Kein Problem, dachte ich! In der Softwareverteilung war schon ein neues MSI Paket von mir für unseren Standort bereitgestellt. Einfach GPO’s anpassen und spätestens Montag oder nach einem Neustart ist alle wieder gut.

Dann kam aber leider der Anruf den ich Freitag Mittag 14:30 nicht mal meinen Feinden wünsche :-). In einem Aussenlager war ein HP Thinclient im Einsatz und der verweigerte wegen einem SSL/TLS Fehler den Zugriff auf dem View Securityserver.

Jetzt kommt ein gut gemeinter Ratschlag von mir an euch! Lest vor einem Upgrade immer die Release Notes. Wenn ich das gemacht hätte wäre mir schon vorher die Problematik bewusst geworden. Ein Remoteupdate war aus mehreren Gründen so nicht möglich. Ich musste also den View Server dazu bewegen, wenn auch mit eine bösen herhobemen Security Zeigefinger, das er das TLSv1 Protokoll sowie diverse Cipher wieder annimmt.

Erster Schritt war das anlegen der Datei locked.properties im Ordner c:\Program Files\VMware\VMware View\Server\sslgateway\conf

Die Datei bekommt folgenden Inhalt:


# Liste der möglichen Protokolle

secureProtocols.1=TLSv1.2
secureProtocols.2=TLSv1.1
secureProtocols.3=TLSv1
secureProtocols.4=SSLv3
secureProtocols.5=SSLv2Hello

# Wähle das bevorzugte Protkoll aus. Das sollte auch in der Liste ganz oben stehen.

preferredSecureProtocol=TLSv1.2

# aktiviere folgende Chiper

enabledCipherSuite.1=TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
enabledCipherSuite.2=TLS_DHE_DSS_WITH_AES_128_CBC_SHA
enabledCipherSuite.3=TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
enabledCipherSuite.4=TLS_DHE_DSS_WITH_AES_256_CBC_SHA
enabledCipherSuite.5=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
enabledCipherSuite.6=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
enabledCipherSuite.7=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
enabledCipherSuite.8=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
enabledCipherSuite.9=TLS_RSA_WITH_AES_128_CBC_SHA
enabledCipherSuite.10=TLS_RSA_WITH_AES_256_CBC_SHA
enabledCipherSuite.11=SSL_RSA_WITH_RC4_128_MD5
enabledCipherSuite.12=SSL_RSA_WITH_RC4_128_SHA
enabledCipherSuite.13=TLS_RSA_WITH_AES_128_CBC_SHA
enabledCipherSuite.14=TLS_DHE_RSA_WITH_AES_128_CBC_SHA
enabledCipherSuite.15=TLS_DHE_DSS_WITH_AES_128_CBC_SHA
enabledCipherSuite.16=SSL_RSA_WITH_3DES_EDE_CBC_SHA
enabledCipherSuite.17=SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
enabledCipherSuite.18=SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA

Anschliessend nehmen wir noch einen Registry Eintrag vor:

HKLM\Software\Teradici\SecurityGateway
Name: SSLProtocol
Type: REG_SZ
Value: tls1.2:tls1.1:tls1.0

Wenn das erledigt ist starten wir den Dienst des Verbindungssicherungsserver neu. Die ThinClients sollten sich jetzt wieder verbinden können. Dies sollte aber nur eine temporäre Lösung sein bis ihr einen passenden Austausch ThinClient mit entsprechenden Update vor Ort installiert habt.

Quelle:

https://thatonecomputerguy.wordpress.com/2016/04/22/ssl-settings-to-allow-connection-from-old-view-clients-on-view-horizon-6-2/

https://pubs.vmware.com/Release_Notes/en/horizon-6-view/624/horizon-view-release-notes.html

Cisco 1841 – Back 2 Back Configuration SHDSL

Als freund gut abgehangener DSL Technik habe ich es mir für mein Lab nicht nehmen lassen 2 SHDSL Karten zuzulegen um damit zwei Router zu verbinden.

Nach etwas suchen im Internet habe ich auch entsprechend eine nette Seite gefunden die das ganze auch schon einmal versucht hat. Ich habe die Config mal aufs wesentlich gekürzt. Einmal die Vermittlungsstelle und einmal das Kundengerät:

Router1#sh run

controller DSL 0/0/0
mode atm
line-term co <= Central Office
line-mode 4-wire enhanced
dsl-mode shdsl symmetric annex B
ignore-error-duration  15
!
interface ATM0/0/0
no ip address
load-interval 30
no atm ilmi-keepalive
!
interface ATM0/0/0.1 point-to-point
ip address 10.0.0.1 255.255.255.0
no snmp trap link-status
pvc 2/100
no oam-pvc manage
encapsulation aal5mux ip
!
Router2#sh run

controller DSL 0/0/0
mode atm
line-term cpe <= Customer Premises Equipment
line-mode 4-wire enhanced
dsl-mode shdsl symmetric annex B
ignore-error-duration  15
!

interface ATM0/0/0
no ip address
load-interval 30
no atm ilmi-keepalive
!
interface ATM0/0/0.1 point-to-point
ip address 10.0.0.2 255.255.255.0
no snmp trap link-status
pvc 2/100
no oam-pvc manage
encapsulation aal5mux ip
!

Quelle: http://www.computecnetworks.com/?q=node/52