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:

VMware vSphere „Der Vorgang ist im aktuellen Zustand nicht zulässig“

Problem:

Unter VMware lässt sich *auf einmal* kein Snapshot einer Maschine mehr erstellen oder löschen. Das Betrifft selbstverständlich auch Snapshot-basierte Backuplösungen.

Auch eine Migration der Maschine auf einen anderen Host oder Datastore ist nicht mehr möglich.

Es wird die Meldung „Der Vorgang ist im aktuellen Zustand nicht zulässig.“ („The operation is not allowed in the current state.“) angezeigt und auf dem zugehörigen ESX-Host findet man im hostd.log folgenden Eintrag:

error 'Vmsvc.vm:/vmfs/volumes/DATASTORE/VMNAME/VMNAME.vmx'] Invalid transition requested (VM_STATE_ON_SHUTTING_DOWN -> VM_STATE_CREATE_SCREENSHOT): Invalid state

Lösung:

Das Problem lässt sich in der Regel durch einen Neustart der Management-Agents auf dem jeweiligen ESX-Host beheben.

Dazu zunächst SSH auf dem ESX aktivieren (vSphere Client am Host anmelden -> Konfiguration -> Sicherheitsprofil)
und sicherstellen, dass die VMs nicht mit dem Host Starten/Herunterfahren (vSphere Client am Host anmelden -> Konfiguration -> VM starten/herunterfahren -> Virtuelle Maschinen mit dem System starten und beenden auf Deaktiviert stellen)

Dann per SSH auf den Host verbinden und die Management-Agents neustarten:

/etc/init.d/hostd restart
/etc/init.d/vpxa restart

vmware „Diese virtuelle Maschine konnte nicht von vSphere HA geschützt werden …“

Problem

Nach dem anlegen einer neuen virtuellen Maschine jammer der vSphere[Web]Client herum:

Diese virtuelle Maschine konnte nicht von vSphere HA geschützt werden und daher ist
es möglich, dass HA nicht versucht, sie nach einem Ausfall neu zu starten.

 

Lösung

Es gibt mehrere Ursachen für diesen Fehler. In der Regel stehen diese im Logfile des Fault Domain Manager (FDM), auf dem vCenter unter /var/log/fdm.log. Unter vSphere 5.5U1+ und 6.0+ haben wir häufiger diesen Fehler im Log:

error fdm[PID] [[email protected] sub=Cluster] stat(/vmfs/volumes/DS-ID/.vSphere-HA/FDM-GUID-NAME) failed with Permission denied

Es scheint so, als ob sich der FDM manches mal nicht ganz sicher ist, wo er den DS-Heartbeat ablegen soll. Und manchmal wir der HB umgelegt, aber der alte Ordner nicht gelöscht. Ist der Ordner noch da, verweigert der FDM den Dienst mit dem oben genannten Fehler.

  1. vSphere HA ausschalten
  2. Den Ordner „.vSphere-HA“ auf den angegebenen Datastore löschen
  3. vSphere Ha wieder einschalten.

Alternativ kann man auch alle unbenutzten .vSphere-HA Ordner löschen (da ist nichts wichtige drin):

rm -rf /vmfs/volumes/*/.vSphere-HA

 

VMware ESX5.1/5.5 Warnung: „Systemprotokolle auf dem host foo.bar werden in einem nicht beständigen Speicher gespeichert“ [update]

Frische Neuinstallationen des ESXi 5.1/5.5 auf einem USB-Stick oder einer SD-Karte behaupten gerne mal „Systemprotokolle auf dem host foo.bar werden in einem nicht beständigen Speicher gespeichert„. Das ist auch fast korrekt – USB-Speicher und Sd-Karten sind nach VMWare-denke „volatil“. Nur Festplatten (respektive Datastores) sind beständig.

Lösungsmöglichkeit 1 (EMPFOHLEN, BRAUCHT NEUSTART)

Einen Speicherort für die Scratch-Files für jeden betroffenen ESX(i)-Host auf einem Datastore erstellen. Das geht direkt im vSphere Client und im laufenden Betrieb – die Änderung wird nur erst bei einem Neustart des Hosts aktiv.

  1. Auf dem jeweiligen ESX(i)-Host unter Konfiguration/Speicher den passenden Datastore Durchsuchen und einen Ordner erstellen. VMWare schlägt einen Namen wie .locker-ESXHOSTNAME vor, denn Ordner die mit einem „.“ beginnen werden im Browser nicht angezeigt. Jeder Host braucht einen eigenen Scratch-Ordner.
  2. Diesen neuen Ort dann in die ESX(i) Konfiguration der Hosts eintragen: Unter Konfiguration -> Software -> Erweiterte Einstellungen -> ScratchConfig -> ScratchConfig.ConfiguredScratchLocation auf den neuen Pfad setzen, z.B. /vmfs/volumes/DATASTORENAME/.locker-ESXHOSTNAME

Der Defaultwert ist /tmp/scratch, was in einer Standardinstallation auf der Ramdisk liegt. Eine Möglichkeit diese Warnung ohne die solche Anpassung des Setups auszuschalten ist (mir) nicht bekannt.

Lösungsmöglichkeit 2 (OHNE NEUSTART)

  1. Auf dem jeweiligen Host auf dem Tab „Konfiguration“ > unter „Software“ auf „Erweiterte Einstellungen“
  2. In der Baumstruktur links „Syslog“ aufwählen
  3. In dem Feld „Syslog.global.loghost“ die Adresse des vCenter-Servers eintragen
    1. Das Format lautet: udp://<IP-VCENTER-SERVER>:514

vSphere Webclient „Erste Schritte“ ausblenden

Der „Erste Schritte“ Tab im vSphere Webclient nimmt unglaublich viel Platz und Performance. Hilfreich sind die Inhalte wie „Was ist eine virtuelle Maschine“ für den tagtäglichen Einsatz nun beim besten Willen auch nicht.

„Erste Schritte“ Tab entfernen

  • Oben rechts im Webclient auf den Link „Hilfe“
  • Darunter „Alle Erste-Schritte-Seiten ausblenden“ wählen

Windows Server 2012R2 verliert sporadisch Netzwerkverbindung „Die IP-Adresse für die Isatap-Schnittstelle LAN-Verbindungwurde nicht aktualisiert.“

Ein sehr seltsames Problem, aber eine einfache Lösung.

Wir haben einen Windows Server 2012 R2 (Domain Controller), der früher auf einem vSphere 5.5 lief. Später wurde der darunterliegende ESXi auf ein vSphere 6 aktualisiert. Sporadischen („random“) traten unter beiden ESX-Versionen Ausfälle bei ebendiesem DC auf; die Netzwerkkarte war plötzlich nicht mehr erreichbar.

Die Netzwerkkarte war im Fehlerfall tot, sprich von außen nicht mehr pingbar. Mann konnte sich auf der Konsole des Servers problemlos einloggen und die Karte sehen, aber keine Pakete wurden mehr verschickt oder empfangen. Nach einem Reboot klappte wieder alles einwandfrei, mal für ein paar Stunden, mal für ein paar Tage.

Im Ereignisprotokoll war nichts zu finden (wenn doch nur alle Logs so sauber wären …), außer:

Log Name:      System
Source:        Microsoft-Windows-Iphlpsvc
Date:          2/1/2017 5:01:51 PM
Event ID:      4202
Task Category: None
Level:         Error
Keywords:      
User:          SYSTEM
Computer:      MYSERVER.MYDOMAIN
Description:
Unable to update the IP address on Isatap interface isatap.{<SID>}. Update Type: 0. Error Code: 0x57.

und

 Log Name: System
 Source: Microsoft-Windows-Iphlpsvc
 Date: 2/1/2017 4:49:33 PM
 Event ID: 4202
 Task Category: None
 Level: Error
 Keywords:
 User: SYSTEM
 Computer: MYSERVER.MYDOMAIN
 Description:
 Unable to update the IP address on Isatap interface isatap.{<SID>}. Update Type: 1. Error Code: 0x490.

Lösung

Die Netzwerkkarte in dem System war eine vmware INTEL E1000. Diese durch einen VMXNET-Adapter (idealerweise VMXNET3) austauschen und der Fehler ist verschwunden.