Beiträge

Veröffentlicht am

ESXi iSCSI Troubleshooting

Für jemanden, der hauptsächlich im FibreChannel Protokoll zu Hause ist, dem bereitet iSCSI immer wieder Spaß und Kurzweil. So geschehen in der vergangenen Woche, als wir ein verzwicktes Phänomen bei der Einbindung eines iSCSI Targets hatten. Auch wenn es eine gute Fingerübung für Troubleshooting war, so brachte es einige graue Zellen zum Rauchen.

Das Szenario

  • Zwei ESXi 5.5 Server mit je 2x1Gbit LAN Adapter für iSCSI
  • je 2 Kernelports in unterschiedlichen Subnetzen (10.0.0.x und 10.0.1.x) unabhängig von Management Network und VM-Network (192.168.1.x)
  • keine Jumboframes (MTU 1500)
  • zwei LAN Switches für Redundanz
  • 2 Datacore Server mit SANsymphony-V 10 und je 2 x 1Gbit für iSCSI Frontend Ports [FE]
Host iSCSI1 iSCSI2
ESX4 10.0.0.14 (vmk4) 10.0.1.14 (vmk5)
ESX5 10.0.0.15 (vmk4) 10.0.1.15 (vmk5)
SDS1 10.0.0.31 10.0.1.31
SDS2 10.0.0.32 10.0.1.32

 

DatacoreiSCSI2

Das Phänomen

Bei der Konfiguration des Software iSCSI Adapters kam jeweils nur für einen Kernelport eine iSCSI Verbindung zustande. Das Verhalten war auf beiden ESXi Servern gleich. „ESXi iSCSI Troubleshooting“ weiterlesen

Veröffentlicht am

Windows Updates automatisch deinstallieren

Erst kürzlich hatte Microsoft große Probleme mit einigen Patches des August Patch-Days. Es kam dabei zu Problemen mit den folgenden Sicherheitsupdates:

  • KB2982791
  • KB2970228
  • KB2975719
  • KB2975331

Insbesondere ersteres sogte auf einigen Systemen für den gefürchteten Bluescreen of death (BSOD). Die Patches wurden von Microsoft kurz danach zurückgerufen. Glück für jene, die mit Sicherheitspatches immer ein wenig warten. Andererseits sollten kritische Sicherheitslücken immer sehr zeitnah gestopft werden. Und genau dies tun zum Beispiel WSUS Server. Hier kann man einstellen, daß kritische Sicherheitspatches automatisch für die Installation genehmigt werden, was dazu führt dass eine große Anzahl Systeme mit den problematischen Updates versorgt wurde. „Windows Updates automatisch deinstallieren“ weiterlesen

Veröffentlicht am

Reset root password CentOS Appliance

Dies ist wieder einmal ein sehr gutes Beispiel, warum man den Zugang zu Server Konsolen unbedingt schützen muss. Das betrifft natürlich nicht nur Virtuelle Server, jedoch ist hier der Missbrauch besonders einfach, da die Konsolen über LAN erreichbar und nicht mit einer Tür verschlossen sind.

Kennt hier jemand root?

Eine etwas ältere PanoLogic Appliance (Zero-Client Manager) eines Kunden sollte aktualisiert werden. Die Firma gibt es inzwischen nicht mehr und das Produkt wird weder vertrieben noch unterstützt. Dennoch wird es noch oft produktiv eingesetzt. Für die Arbeiten an der Appliance benötige ich den root Login. Leider konnte sich niemand an den root Login erinnern, oder wer diesen gesetzt haben könnte. Der Default Login „password“ wurde verändert. Eine Kollektion weiterer möglicher Passworte wurde durchprobiert – jedoch ohne Erfolg. Folglich musste ein Weg gefunden werden, das Kennwort neu zu vergeben. Die Panomanager Appliance basiert auf einem CentOS 2.6.18. Das Verfahren ist geradzu erschreckend simpel.

Einfach zu einfach

Wer erstmal Zugang zur Konsole hat, dem stehen alle Türen offen. „Reset root password CentOS Appliance“ weiterlesen

Veröffentlicht am

DataCore SANsymphony-V 10 – possible data corruption

DataCore meldet ein mögliches Treiber-Problem mit dem erst kürzlich veröffentlichten SANsymphony-V 10. Ein entsprechender Customer Alert würde heute versendet:

Potential for Data Corruption – Hotfix Available
In SANsymphony-V 10.0.0.0 we changed the way we work in order to support VMware Thin Provisioning Thresholds. In doing so, we have seen that there is now the potential for a timing issue to take place that can cause data corruption. In order to protect against the possibility of corrupting data, we have redesigned and tested a new driver. The revised driver will be included in SANsymphony-V 10.0 Update1, which we are hopeful will be released in early September, and we suggest holding back any upgrades to SSV10 until that update is available. If you already have customers running SSV 10.0 there is a Hotfix we can provide to protect against this until Update1 is released. Please open an incident and contact support requesting this hotfix for those customers, and when Update1 is released please upgrade as soon as possible after its release.

Es wird nicht genau erklärt, welcher Treiber problematisch ist und unter welchen Umständen. Die Haupaussage ist jedoch, man solle mit der Migration auf SSY10 abwarten bis das Update 1 veröffentlicht wurde. Interne Quellen hatten dies für Oktober 2014 angekündigt, möglicherweise wurde es jetzt aufgrund der Wichtigkeit auf September vorgezogen.

Ich konnte bis jetzt in der Testumgebung mit VMware und SSY10 keine negativen Auswirkungen sehen, obwohl diese unter Last arbeitet. Dennoch hat sich die Zurückhaltung bei der Migration von produktiven DataCore Umgebungen auf neue Hauptversionen wieder einmal bestätigt. Im Labor immer die neuste Version – beim Kunden das erste Update abwarten. 😉