vSphere mountet Datastore nicht „Device detected to be a snapshot“

Problem

Eine LUN will sich auf einem Host nicht mehr als Datastore mounten lassen. Das /var/log/vmkernel.log sagt dazu:

cpu55:34954 opID=da111896)World: 15544: VC opID xxxx-xxxxx-xx-xx-xxxx maps to vmkernel opID daxxxxx
cpu55:34954 opID=da111896)<3>ata6.00: bad CDB len=16, scsi_op=0x9e, max=12
cpu55:34954 opID=da111896)LVM: 10084: Device naa.xxxxxxxxxxxxxx:1 detected to be a snapshot:
cpu55:34954 opID=da111896)LVM: 10091: queried disk ID: <type 2, len 22, lun 5, devType 0, scsi 0, h(id)>
cpu55:34954 opID=da111896)LVM: 10098: on-disk disk ID: <type 2, len 22, lun 5, devType 0, scsi 0, h(id)>

Lösung

Das Volume einfach manuell mounten:

[root@SEVERNAME:~] esxcfg-volume -M <DATASTORENAME>

Man kann sich die Volumen auf dem Bus auch zur Sicherheit vorher anschauen:

[root@SERVERNAME:~] esxcfg-volume -l
Scanning for VMFS-3/VMFS-5 host activity (512 bytes/HB, 2048 HBs).
VMFS UUID/label: xxxxx-xxxxxx-xxxxxxxxxxxxxx/<DATASTORENAME>
Can mount: Yes
Can resignature: No (the volume is being actively used)
Extent name: naa.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:1 range: 0 - 1714687 (MB)

vSphere mountet Datastore nicht, obwohl LUN und Device unter „Geräte“ sichtbar sind

Problem

Ein vSphere 6.x Host sieht einen frisch angeschlossenen VMFS Datastore nicht, der auf einem HP MSA2000fc erstellt wurde. Die VMFS-Version ist aktuell, vSphere 6 ist aktuell, die Firmware ist aktuell, aber der Datastore ist einfach nicht da. Die angeschlossenen LUNs und ihre Pfade sind in der Geräteübersicht sichtbar und werden korrekt angezeigt. Nur das/die VMFS-Volumen werden nicht gemountet.

Das /var/log/vmkernel.log sagt dazu:

2017-06-14T10:09:27.643Z cpu34:33171)ScsiUid: 273: Path 'vmhba37:C0:T0:L0' does not support VPD Device Id page.
2017-06-14T10:09:27.645Z cpu34:33171)VMWARE SCSI Id: Could not get disk id for vmhba37:C0:T0:L0
2017-06-14T10:09:27.765Z cpu8:34953 opID=81e32a6)World: 15544: VC opID 3xxxxxx-xxxxxx-xx-xx-xxxx maps to vmkernel opID xxxxxx
2017-06-14T10:09:27.765Z cpu8:34953 opID=81e32a6)WARNING: HBX: 480: 'DATASTORENAME':
ATS-only volume unable to use ATS due to host-level HardwareAcceleratedLocking configuration.

 

Lösung

Das nette VAAI Feature („VMware vSphere Storage APIs Array Integration“) nutzt eine Technik, die ATS heißt („Atomic, Test and Set“). Dabei werden einzelne Blöcke des Storages („atomic“) durch die Storage-Hardware gelockt, so daß nur ein Host diese exklusiv beschreiben kann. Ohne ATS könnte, in so einem Fall, ein einzelner Host die ganze LUN blockieren. Die MSA2000 G1/G2 Controller beherrschen dieses Feature allerdings leider nicht – um genau zu sein gar keine VAAI-Features.

ATS (pro Host) ausschalten:

Host > Konfiguration > Software/Erweiterte Einstellungen > VMFS3 > „HardwareAcceleratedLocking“ auf „0“ stellen

Mehr Informationen:

Mach mal Speisekarte Facebook

Wir stellen uns das so in etwa vor:

Chef zu Shui-Azubine: „Mach mal Karte in Facebook“

Azubine: „Ey wiiiee denn?“

Chef: „Egal, mach einfach in Facebook“

Azubine *macht Selfie von Speisekarte in Word*

Besonders gelungen finden wir die roten Office Rechtschreib-Wellenlinien. Wenn es doch nur eine Möglichkeit gäbe, von Word nach Facebook zu speichern …

Kein Scherz, das orginal ist noch immer bei „Sumo Sushi“ in Hagen zu finden.

Outlook 2013/2016 mit einer E-Mail crashen

Ein Kunde meldet sich:

Immer wenn ich diese E-Mail öffne, stürzt mein Computer ab.

Wir, als gestandene Admins, glauben natürlich erstmal nichts und schauen uns das an. Stellt sich raus: Der Kunde hat recht. Er hat eine Mail in seinem Posteingang, die seinen Outlook-Client immer crasht, wenn er die Mail anschaut. Wir leiten uns die Mail weiter (OWA ist nicht betroffen) und stellen fest: Outlook 2013 und 2016 lassen sich mit dieser Nachricht reproduzierbar und überall crashen. Unter jedem Windows. In der Voransicht (Standardmäßig eingeschaltet), beim anklicken, als MSG- oder EML-Datei, immer. Sehr schön!

Nach genauer Analyse stellt sich heraus: Es ist „nur“ der HTML-Word-Viewer. Dieser stolpert über eine einzige Zeile:

<style>table {mso-style-name:Standardowy; width:100%;}</style><br>

Wenn man also anderen Leuten das Outlook abschießen möchte verschickt einfach diese Zeile. Eine Beispiel-Crash-Mail.eml sieht zum Beispiel so aus:

From: Teleweed <[email protected]>
To: "Anonymous" <Anonymous>
Subject: This is an outlook crashing example
Date: Fri, 2 Jun 2017 2:22:22 -0200
Content-Type: text/html;

<style>table {mso-style-name:Standardowy; width:100%;}</style><br>

Leider konnten wir den Fehler nicht an Microsoft melden, weil das praktisch unmöglich ist. Weder ein MVP, unser PAM/PSX, die Social-Foren, noch das Feedback, noch die Security noch das Support-Team, noch der Partner-Support konnten oder wollten den Bug annehmen. Also liebe Welt: Happy shooting!

Vielleicht schickt ja mal jemand eine solche Mail an Rajesh Jha oder am besten gleich Satya Nadella 🙂

Update:

Mit dem Code lässt sich scheinbar auch Word an sich zum absturz bringen: Baut man folgendes in den Head eines html-Dokuments und versucht dann, selbiges mit Word zu öffnen kommt es ebenfalls zum Absturz.

<style>table {mso-style-name:Standardowy; width:100%;}</style>

Scheinbar ist das Ganze abhängig von der verwendeten Office-Sprache: Standardowy ist polnisch für „konventionell“. Ersetzt man es z.B. mit „Normale Tabelle“ (mit Anführungszeichen, wegen dem Leerzeichen) lässt es sich mit einem deutschen Word wieder Öffnen. Ein beliebige anderer String (z.B. auch „Table Normal“ aus einem englischsprachigen Word) verursacht den Absturz trotzdem.

Wichtig ist die Kombination aus „mso-style-name:<string>;“ und „width:<size>;“ -> Verwendet man z.B. „height“ gibt es keinen crash. Für <size> spielt es allerdings keine Rolle in welcher Einheit die Angabe erfolgt, Abstürzen tut Word auch mit z.B. 300px

Beispiele (proof of concept) gibt’s hier. („normale-tabelle_prozent.html“ sollte keinen Crash verursachen, der Rest allerdings schon.)

Danke @iSnackyCracky und @teleweed fürs finden und die langwierige Analyse.