vSphere HA konnte kein Konfigurations-vVol für diesen Datenspeicher erstellen und kann daher die virtuellen Maschinen auf dem Datenspeicher so lange nicht schützen, bis das Problem behoben wurde. Fehler: (vim.fault.InaccessibleDatastore)

Problem

Man hat grade ein nagelneues SAN mit vvol Feture im vCenter Server bereitgestellt. Das vvol möchte abe rnicht so recht und wird mit einem Fehler angezeigt:

vSphere HA konnte kein Konfigurations-vVol für diesen Datenspeicher erstellen und kann daher die virtuellen Maschinen auf dem Datenspeicher so lange nicht schützen, bis das Problem behoben wurde. Fehler: (vim.fault.InaccessibleDatastore)

Lösung

Zu schnell! Entferne deine vvols wieder. Warte eine Minute. Füge Sie wieder hinzu. die PEs (Protocol-Endpoints) brauchen eine ganze Weile, bis die Speicherrichtlinie mit dem vCenter abgegleichen ist.

Nutzt du eine Nimble? Wenn ja, erstelle auf jeden Fall eine neue Speicherrichtlinie vom Typ „Nimble“. Erst dann hast du in deinen vvols vollen Feature-Zugriff, wie auf die Deduplizierung, Pureflash, Durchsatzbeschränkungen und so weiter.

VMware ESXi: mehrere VIBs auf einmal deinstallieren (remove multiple VIB)

Diesen Trick kannte ich nicht: Man kann in der Kommandozeile gleich mehrere VIBs auf einmal deinstallieren. ESXCLI kann das sowohl remote, als auch lokal auf dem Host (z.B. via SSH):

~:# esxcli software vib remove -n vibname1 -n vibname2 -n vibname3

So kann man diese fiesen alten HPE-Zugaben vor Inplace-Hostupgrades alle auf einmal schnell entfernen:

~:# esxcli software vib remove -n char-hpcru -n net-mst -n char-hpilo -n hp-ams -n hp-esxi-fc-enablement

Und schon steht demUpgrade nichts mehr im Wege 🙂

vSphere storage motion „Fehler 195887250. Migration determined a failure by the VMX“

Problem

Eine VM möchte sich nicht via StorageMotion nicht auf ein VVOL verschieben lassen. Im Aktivitätsprotokoll sieht man den Fehler:

Fehler beim Warten auf Daten. Fehler 195887250. Migration determined a failure by the VMX.

und/oder

Migration determined a failure by the VMX. Storage vMotion konnte die Zielfestplatte /vmfs/volumes/vvol:0000000200004004-825d720126911b58/rfc4122.16630ae1-3756-4e47-b932-cdebf5862fd7/SERVERNAME.vmdk nicht erstellen.

und/oder

Erstellen einer oder mehrerer Zielfestplatten fehlgeschlagen. Es ist ein schwerwiegender interner Fehler aufgetreten. Weitere Details finden Sie im Protokoll der virtuellen Maschine.

Spannend zu suchen ist der Fehler 195887250. Der VMKernel meint damit „VMK_MIGRATE_VMX_FAILURE“, oder in ausgeschrieben „Migration determined a failure by the VMX“.

Lösung

Der weitaus häufigste Grund ist relativ einfach: Eine der Festplatten der betroffenen Maschine hat eine größe, die nicht durch 1Mbyte teilbar ist. VVOLs können nur vielfaches von 1Mbyte allokieren, daher schlägt das anlegen der Platte fehl.

Das sieht man auch im vmware.log der betroffenen Maschine:

2018-08-06T11:50:01.264Z| worker-2161938| I125: DISKLIB-LIB_CREATE : CREATE: Creating disk backed by 'vvol'
2018-08-06T11:50:01.265Z| worker-2161938| W115: OBJLIB-VVOLOBJ : VVolObjCheckSize: Requested size (32217052160) is not an MB multiple.
2018-08-06T11:50:01.265Z| worker-2161938| W115: OBJLIB-VVOLOBJ : VVolObjDetermineSizeInMB: Requested size (32217052160) is not a MB multiple.
2018-08-06T11:50:01.265Z| worker-2161938| W115: Mirror: scsi0:0: SVMotionLocalDiskCreate: Failed to create destination disk: The requested size is not a multiple of 1MB
2018-08-06T11:50:01.265Z| worker-2161938| W115: Mirror: scsi0:0: Failed to create disk from /vmfs/volumes/.../NAME.vmdk to /vmfs/volumes/.../NAME.vmdk.

Ärgerlicherweise behauptet die VCSA stattdessen: „No space left on device“

Der zweite Fall der ich einmal untersuchen durfte, war eine „kaputte“ Netzwerkkarte. Alles lief einwandfrei, nur storage motion auf dieser Karte nicht. NIC ausgetauscht, alles wieder fertig.

vmware vCenter VCSA root-Partition vollgelaufen (Audit.log riesig)

Problem

Eine vmware VCSA ist vollgelaufen. Die root-Partition („/“) hat noch 0 Byte frei und die Appliance bootet nicht mehr richtig. Eine Anmeldung ist nicht mehr möglich, sogar der Bash-Zugang via

shell.set --enabled true

schlägt fehl.

Lösung

Es muss erst Platz auf der Partition gemacht werden, sonst ergeben alle weiteren Reparaturversuche keinen Sinn.

  1. Ein Linux mit einer Shell booten (z.B. ein Ubuntu, Debian oder ähnliches)
  2. Mounten der Root-Partition
    mkdir /pladde
    mount /dev/sda3 /pladde
  3. Platz schaffen
    rm -rf /pladde/var/log/audit/*
    rm -rf /pladde/var/log/audit/*
  4. Reboot, fertig

Danach empfielt es sich, entweder den Fehler zu beheben (https://kb.vmware.com/s/article/2149278), die Root-Platte zu vergrößern (https://blog.mwpreston.net/2015/10/05/resizing-the-root-partition-of-the-vcenter-server-appliance-vcsa/) oder eigene Jobs zum aufräumen hinzuzufügen …

vmware vSphere Storage migration „Fehlgeschlagen beim Warten auf Daten. Fehler 195887107. Not found.“

Problem

Einige virtuelle Maschinen lassen sich nicht via Storage Motion oder Storage vMotion auf einen neuen VVOL-Datastore verschieben. Mit andere klappt das fehlerfrei, auch zwischen klassischen Datastores gibt es kein Problem.

Ist die VM eingeschaltet gibt es im Aktivitätsprotokoll die Fehlermeldung

Fehlgeschlagen beim Warten auf Daten. Fehler 195887107. Not found. 

Oder auf English:
A fatal internal error occurred. See the virtual machine’s log for more details.

Ist die VM ausgeschaltet sieht das so aus:

Ein allgemeiner Systemfehler ist aufgetreten: Launch failure

Im /var/log/vmkernel.log stehtm ebenso wenig hilfreich:

OSFS_Lookup:2579: Lookup error: file = rfc4122.b4401030-3010-43a9-8d68-5a76251e5e62, status = Failure
Mirror: scsi0:1: SVMotionLocalDiskCreate: Failed to create destination disk

Spannender ist da schon die Fehlersuche im Protokoll der Maschine, in /vmfs/volumes/<DATASTORE>/<VMNAME>/vmware.log

OBJLIB-VVOLOBJ : VVolObjCheckSize: Requested size (######) is not an MB multiple.

VVolObjDetermineSizeInMB: Requested size (#####) is not a MB multiple.

Mirror: scsi0:1: SVMotionLocalDiskCreate: Failed to create destination disk: The requested size is not a multiple of 1MB.

Lösung

Das Log hat recht: aus irgendeinem Grund hat die virtuelle Maschine eine Festplatte, deren Größe kein ganzzahliges vielfaches von einem Mebibyte ist (1MB).

  • Bearbeiten der virtuellen Maschine
  • Vergrößern der Festplatte auf ein ganzzahliges vielfaches
  • Übernehmen

Fertig, die Maschine kann nun verschoben werden. Man kann der vollständigkeit halber natürlich auch noch das Dateisystem innerhalb der VM vergrößern, aber für den Storage(v)Motion-vorgang ist das nicht notwendig.

Man kann mit PowerCLI auch auf die schnelle herausfinden, welche Maschinen alle betroffen sind:

PC C:\> Get-Datastore | Get-HardDisk | Select Parent, Filename, @{N="Remainder";E={$_.CapacityKB % 1024}} | Where {$_.Remainder -ne 0}

Vielen Dank an den Benutzer in der ehemaligen Nimble-Community, der das herausfand und dokumentierte. Bevor HPE das ganze Forum löschte *seufz*

vmware Template (Vorlage) auf anderen Datastore verschieben

Problem

Virtuelle Maschinen (Gäste) lassen sich im Gegensatz zu Templates problemlos zwischen Datastores verschieben. Je nach Lizenz mal ein-, mal ausgeschaltet, aber verschieben geht immer. Aus uns nicht bekannten Gründen fehlt die „Migrieren“ Option aber für Vorlagen vollständig. Das gilt sowohl für alle GUIs als auch für das PowerCLI.

Natürlich könnte man diese Vorlagen in Maschinen konvertieren, dann auf dem Storage verschieben und dann wieder zurückkonvertieren, aber geht das nich einfacher?

Lösung

Das geht, kein Problem – im Datastore-Browser.

  • Das Template aus dem Inventar entfernen („Aus Bestandliste entfernen“)
  • Zum Datastore wechseln, wo das Template liegt, zur Inhaltansicht
  • Auf der linken Seite des Datastore-Browsers den Eltern-Ordner des Template-Ordner auswählen
  • Auf der rechten Seite des Datastore-Browsers den Template-Ordner auswählen
  • Oben auf den nun verfügbaren Button „Verschieben nach …“ klicken und das Ziel auswählen
  • Nach dem vollständigen verschieben, zum Ziel-Datastore wechseln, in den nun verschobenen Vorlagen-Ordner
  • Die *.VMTX Datei auswählen und „Zur Bestandliste hinzufügen“

Windows 2012 unter vSphere ohne Netz „Gigabit-Netzwerkverbindung Intel(R) 82574L Network link is disconnected.“ (Event ID 27)

Problem

An diesem Effekt hier habe ich mich grade viel zu lange aufgehalten:

Eine Windows Server 2012 Gast-VM unter vSphere 5.1/5.5 mit der Intel E1000 NIC mag auf diesem Netzwerkadapter kein stabiles Netzwerk haben. Verbindungen brechen random ab, aber Pings funktionieren hingegen meistens (eingehend). Die Verbindung läuft eine Weile, dann stirbt Sie wieder. Unabhängig von VLAN und phasikalischem Link. Stabil bleibt es dmit nie.

Es gibt beim Abbruch auch einen Eintrag im Eventlog:

Protokollname: System
Quelle:        e1iexpress
Ereignis-ID:   27
Aufgabenkategorie:Keine
Ebene:         Warnung
Schlüsselwörter:Klassisch
Beschreibung: Gigabit-Netzwerkverbindung Intel(R) 82574L
Network link is disconnected.

Lösung

Ausgelöst werden die Abbrüche durch den von Windows 2012 standardmäßig verwendeten Treiber (Intel(R) 82574L, Version: 12.0.150.0). Damit treten bei „hoher Netzwerklast“ an der VM Verbindungsfehler auf.

Möglichkeit 1: Einen neuen Ersatztreiber installieren.

Möglichkeit 2 (empfohlen): Die NIC einfach durch eine vmxnet3 ersetzten …