Kategorie-Archiv: VMware

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.

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 🙂

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.

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 …

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*