Kategorie-Archiv: VMware

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

Veröffentlicht am von — 9 Kommentare ↓

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 …“

Veröffentlicht am von — 2 Kommentare ↓

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] [Originator@PID 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]

Veröffentlicht am von — 15 Kommentare ↓

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

Veröffentlicht am von — 2 Kommentare ↓

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.“

Veröffentlicht am von — Keine Kommentare ↓

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.