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 …

Ein neues VLAN über den vCenter-Server zu einem oder allen ESXi-Hosts im Cluster hinzufügen

Man fügt ja eine neu getaggte VLAN Portgruppen zur Segementierung auf jedem ESXi-Host einzeln zum vSwitch hinzu, es sei denn man verfügt üben den zentralisierten NSX/Distributed-Luxus. Oder macht gleich SDN überall 🙂

Der Vorgang an sich kann je nach Clustergröße etwas dauern und zudem sehr ermüdent sein. Das folgende PowerCLI-Script vereinfacht diese Arbeit deutlich und erledigt den Job in wenigen Sekunden.

„Stelle ein neues VLAN unserer Switches am bestehenden vSwitch ALLER Hosts zur Verfügung“

PowerCLI C:\> Connect-VIServer vcenter01.localnetwork.local
PowerCLI C:\> get-cluster -name MEINSEXYCLUSTER | Get-VMHost | Get-VirtualSwitch -name "vSwitch1" | New-VirtualPortGroup -Name "NEUES_SEXY_SEGMENT_LAN33" -VLanId "1607"

„Stelle ein neues VLAN unserer Switches am bestehenden vSwitch an EINEM Hosts zur Verfügung“

PowerCLI C:\> Connect-VIServer vcenter01.localnetwork.local
PowerCLI C:\> get-cluster -name MEINSEXYCLUSTER | Get-VMHost SEXYHOSTNAME | Get-VirtualSwitch -name "vSwitch1" | New-VirtualPortGroup -Name "NEUES_SEXY_SEGMENT_LAN33" -VLanId "1607"

„Entferne ein VLAN an den bestehenden vSwitches ALLER Hosts“

PowerCLI C:\> Connect-VIServer vcenter01.localnetwork.local
PowerCLI C:\> get-cluster -name "MEINSEXYCLUSTER " | Get-VMHost | Get-VirtualSwitch -name "vSwitch1" | Get-VirtualPortGroup -Name "NEUES_SEXY_SEGMENT_LAN33" | Remove-VirtualPortGrou

PowerCLI rockt einfach. Mehr zum Thema:

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:

[[email protected]:~] esxcfg-volume -M <DATASTORENAME>

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

[[email protected]:~] 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: