Migrationsoptionen („Migrieren“) für eine virtuelle Maschine sind ausgegraut

Manchmal kommt es vor, dass eine VM „überraschend“ nicht mehr migriert werden will. Die VM wurde aber schon mal migriert, vMotion ist lizenziert (meint: korrekt eingerichtet), andere VMs migrieren auch, nur diese eine hat die Option im Menü grau („ausgegraut„). Es laufen auch keine Jobs mehr, die die Migration verhindern können. Also keine andere (Storage/vmotion-) Migration, kein Backup oder andere Replikationsaufgaben.

Wie passiert das?

Das Problem kann auftreten, wenn eine Sicherungs- oder Storage-Motion-Vorgang einer VM zwar abgeschlossen ist, aber und die Einträge in der (PostgreSQL-) Tabelle aus dem vCenter Server nicht entfernt wurden. Das kann auch mal passieren, wenn Backup-Ende und vCenter-Reboot unglücklich zusammenfallen.

Wer das genau warum gewesen ist und wer noch betroffen ist, kann man in der Datenbank zum Glück schnell nachschauen. Auf der Shell des vCenter Servers gibt dieses Statement die entsprechende Liste für alle Objekte aus:

/opt/vmware/vpostgres/current/bin/psql -d VCDB -U postgres -c "select * from vpx_disabled_methods;"

Lösung

Wie bekommt man jetzt die Migrieren-Funktion zurück?

1. Man besorge sich die MO-ID („Managed Object“) ID der VM. Entweder aus dem MOB-Browser (https://VCENTER.EXAMPLE.COM/mob) oder direkt aus der URL vom vCenter GUI. Die URL enthält die MO-ID, wenn man im vCenter zu dem betreffenden Objekt navigiert und den Parameter „VirtualMachine:vm-1234568“ kopiert.

2. Man öffne das VM Ops Manager Interface unter:

https://VCENTER.EXAMPLE.COM/mob/?moid=AuthorizationManager&method=enableMethods

3. In selbigen fügt man oben („entity“) für „MOID“ die MO-ID (aus Schritt 1) ein und in der Mitte („method“) die Methode zum reversen des Feldes für „RelocateVM_Task“. Also genau dieses XML:

Oben („entity“)

<!-- array start -->
<entity type="ManagedEntity" xsi:type="ManagedObjectReference">vm-12345678</entity>
<!-- array end -->

Mitte („method“)

<Methode>RelocateVM_Task</Methode>

4. Unten rechts „Invoke Method“ führt die Methode aus und setzt die Felder zurück.

Der Erfolgsbericht folgt auch sofort, in maschinenlesbarer Form. Ein „Refresh“ im vCenter danach offenbart auch sofort die vermisste „Migrieren“ Funktion wieder.

HPE Alletra (Nimble) NCM auf ESXi Hosts installieren/aktualisieren

Das Alletra Multipath-IO (MPIO) braucht den „Nimble Connection Manager“ (NCM) für vSphere. Das ist ein kleines VIB auf dem ESXi Host.

⚠️ Die Installation des selbigen erfordert zwei (!) reboots des Host.

Das VIB kann man aber zum Glück auch ohne offline-Zauberei, Download aus dem Infosight-Support-Center und so weiter installieren. Noch nicht alle Teile von HPE wurden vom Greenlake-Virus zerstört 🙂

Lösung

Den NCM an der Konsole installieren oder aktualisieren:

esxcli software component apply -d https://update.nimblestorage.com/esx8.0/ncm

Dazu muss der ESXi Hosts selbstverständlich (temporär) ins Internet dürfen. Obwohl die Installation nach dem Abschluss behauptet Reboot Required: false ist dieser notwendig, sonst greifen die MPIO-Policies nicht.

vCenter lässt plötzlich root Login nicht mehr zu „Unable to authenticate user“

Vor ein paar Tagen hatten wir Probleme mit der Anmeldung beim vCenter Appliance Management Interface („VAMI“). Statt der Dienste-Gui sehen wir nur die Fehlermeldung

Unable to authenticate user

Das Passwort für den Root-Benutzer war ganz sicher war. Die Verbindung via SSH funktioniert problemlos.

Lösung

Der Dienst „applmgmt“ ist vermutlich abgestürzt. Der Dienst kann aber an der Shell neu gestartet werden und ist praktisch sofort wieder verfügbar.

  1. Als root (oder [email protected]) via SSH einloggen und mit shell die Shell starten. Sollte die Shell nicht freiwillig wollen, lässt sich diese mit shell.set --enabled true einschalten und danach starten.
  2. Den Dienst starten:
    service-control --start applmgmt

Und schon geht das GUI wieder.

Sollte das wider erwartend nicht funktionieren oder in einer Fehlermeldung enden, loht eventuell ein Blick auf https://knowledge.broadcom.com/external/article?legacyId=68149

vCenter Update 8.0.3 schlägt fehl „Pre-Install failed for vmidentity:Expand“

Das Upgrade auf den neuen vCenter Server 8.0.3 („U3“) bleibt gerne mal mit diesem Fehler stehen:

Pre-install failed for vmidentity:Expand

Das Logfile in /var/log/vmware/applmgmt/Patchrunner.log verrät auch ein paar mehr Details:

vmidentity:Expand INFO vmidentity Found ssoserver cert in TRUSTED_ROOTS, This will be deleted from store
vmidentity:Expand INFO vmidentity.utils Deleting cert from TRUSTED_ROOTS VECS store
vmidentity:Expand ERROR vmidentity.utils Failed to execute command '['/usr/lib/vmware-vmafd/bin/dir-cli', 'trustedcert', 'unpublish', '--cert', '/storage/seat/software-updateub8jty50/stage/scripts/patches/payload/components-script/vmidentity/<Cert_filename.pem>', '--login', '<VC FQDN>']'
vmidentity:Expand ERROR vmidentity.utils dir-cli failed. Error 1168: Operation failed with error ERROR_NOT_FOUND (1168)

Lösung

Es gibt da noch eine Bug im Update-Setup, das das Zertifikat „ssoserver“ nicht aus dem Certificate-Store gelöscht bekommt. Aber man kann das einfach manuell machen und das Setup danach fortsetzen.

  1. Alias des „ssoserver“ Zertifikates besorgen (Die Zahlenkette hinter der Bezeichnung „Alias“)
    /usr/lib/vmware-vmafd/bin/vecs-cli entry list --store TRUSTED_ROOTS --text | egrep 'Alias|ssoserver|Key Usage' -A 1 | egrep -v 'Entry type|--'
  2. Das falsche Zertifikat löschen („<ALIAS>“ durch die Zeichenkette von 1. ersetzen)
    /usr/lib/vmware-vmafd/bin/vecs-cli entry delete --store TRUSTED_ROOTS --alias <ALIAS> -y

Danach kann man das Setup mit einem Klick auf „resume“ fortsetzen.

vSphere CD ISO einlegen „Der Steuerungsvorgang für die Verbindung ist für die Festplatte „sata0:0“ fehlgeschlagen.“

Beim Versuch, eine auf einem Datastore gespeicherte ISO-Datei anzuhängen, schlägt der Vorgang mit dem folgenden Fehler fehl:

Der Steuerungsvorgang für die Verbindung ist für die Festplatte „sata0:0“ fehlgeschlagen.

Lösung

Das Problem ist zum Glück schnell gelöst:

  • VM abschalten, an die die ISO angehängt werden soll. Die Anpassung ist (leider) nicht im laufenden Betrieb möglich.
  • vSphere Client öffnen > VM bearbeiten
  • Das CD-Laufwerk aufklappen
  • Den Gerätemodus auf „Passthrough-CD-ROM“ umstellen
  • VM wieder starten

Jetzt kann man auch wieder fehlerfrei ISOs einlegen.

Wir haben auch schon VMs gesehen, wo das CD-Laufwerk nicht änderbar war (ausgegraut). In solchen Fällen haben wir das Laufwerk einfach entfernt und ein neues wieder hinzugefügt …