Upgrade VMware vCenter 8.0 bleibt bei 80% stehen „Waiting for RPM installation to start. This may take several minutes …“

Problem

Das Upgrade auf vCenter 8.0 bleibt manchmal „kommentarlos“ bei 80% stehen und bewegt sich nicht mehr. Auch nach einiger Zeit nicht. Die neue Appliance wurde aber erfolgreich installiert und botet (scheinbar) auch fehlerfrei.

„Waiting for RPM installation to start. This may take several minutes“ 80%

Man kann die neue virtuelle vCenter-Appliance aber im Inventar sehen, pingen und auch die Konsole öffnen.

Lösung

Was die Ursache für diesen Effekt ist, wissen wir auch nicht genau. Aber man kann die Installation und Datenmigration problemlos über die VCSA-Oberfläche der „neuen“ vCenter-Instanz fortsetzen. Man öffne:

https://<temporäre-vcenter-adresse>:5480

und melde sich mit dem „frisch „alten“ root-Kennwort dort an.

Die zugehörige (temporär) IP-Adresse zeigt die Konsole ja an.

Der vCenter Screen zeigt die Appliance-IP

Wenn man dem Assistent dann dort weiter folgt, läuft das Setup (in aller Regel) problemlos durch.

HPE iLO, Dell iDrac oder andere IPMI IP-Adressen auf VMware ESXi anzeigen (ohne hponcfg)

„ILO Adressen ohne hponcfg anzeigen“

Es gibt einen einfachen Trick, um die IP-Adressen von IPMI (OOBE-) Adaptern direkt auf der Konsole vom ESXi anzuzeigen:

esxcli hardware ipmi bmc get

Ohne umständliche Installation der OEM-Tools, ohne komische neue VIBs, einfach so 😀

VMware vSphere vSwitch Portgruppe(n) und VLANs von einem Host auf einen anderen kopieren

Manchmal möchte man „einfach“ alle Portgruppen von einem vSwitch auf einen anderen kopieren. Entweder auf dem selben ESXi-Host, oder auch gleich auf einen neuen ESXi. Die Inbetriebnahme neuer VMware ESXi-Hosts wird dadurch merklich schneller möglich.

Lösung

Ohne PowerShell (PowerCLI) geht’s natürlich nicht, solange man keine Hostprofile nutzt.

Das Script benötigt das VMware PowerShell PowerCLI Modul:

Install-Module VMware.PowerCLI

Und natürlich eine funktionierende Verbindung zum vCenter Server:

Connect-VIServer <VCENTER-SERVER>

Dann lässt sich mit diesen Zeilen die Konfiguration schnell kopieren:

## ESXi source / destination
$esx_s = Get-VMHost vmware3.pmd5.org
$esx_d = Get-VMHost hhvmware3.pmd5.org

## vSwitch name source / destination
$vswitch_s = "vSwitch0"
$vswitch_d = "vSwitch0"

$portgroup = $esx_s | Get-VirtualSwitch -Name $vswitch_s | Get-VirtualPortGroup | Select-Object Name, vlanid
$vswitch = $esx_d | Get-VirtualSwitch -Name $vswitch_d 

foreach ($pg in $portgroup) {
    Write-Host "Erstelle Portgruppe {0} mit vlanid {1}" -f $pg.name, $pg.vlanid
    try {
        New-VirtualPortGroup -VirtualSwitch $vswitch -Name $pg.name -VlanId $pg.vlanid -ErrorAction Stop
    }
    catch {
        "Gibt es schon"
    }
}

root password in VMware vCenter Server Appliance zurücksetzen „Authentication token manipulation error“

Das lokale root-Kennwort einer VCSA zurückzusetzen ist, Konsolenzugriff vorausgesetzt, gar nicht so schwer. Das „Photon OS“ ist ja auch „nur“ ein Linux mit ein paar Extras.

root Kennwort an der Konsole zurücksetzen

  • vCenter neu starten
  • Beim booten ‚e‘ drücken um die GRUB-Config zu öffnen
  • Den linux call um init=/bin/bash ergänzen
  • Mit STRG+X die VM booten
  • An der daraufhin als root laufenden bash einfach mit passwd das Kennwort zurücksetzen

Wenn man an dieser Stelle (wie ich soeben) das rw in der Zeile vergisst, erhält man statt der Meldung „passwd: password updated successfully“ die zuerst seltsam erscheinende Meldung „passwd: Authentication token manipulation error with password unchanged“.

Man könnte die Appliance natürlich einfach neu starten und die Zeile mit rw init=/bin/bash korrekt ergänzen, aber man kann natürlich die Partition einfach nachträglich als Read/Write mounten, root ist man ja schon:

mount -o remount,rw /

Danach tut es passwd auch wieder wie gewohnt 🤦

Veeam Backup and Replication Logfile Pfade

Veeam B&R schreibt äußerst großzügige Logfiles, die die Fehlersuche in den allermeisten Fällen wesentlich vereinfachen. Das ist großartige – bitte bitte Veeam, ändert das niemals 😉

Früher(TM) war nicht nur alles besser, sondern man konnte über das Hilfe-Menü den Logfile-Ort schnell und komfortabel aufrufen; doch das war eine sinnvolle und hilfreiche Funktion und musste daher selbstverständlich ersatzlos gestrichen werden.

Naja, nicht ganz ersatzlos, denn dafür gibt es jetzt den freundlichen „Support-Assistenten“, der erst (wortwörtlich) Gigabyteweise Diag-Files zusammenkopiert, diese über alle CPU-Kerne verteilt einpackt und dem Informationensuchenden Admin schon nach einigen Minuten (!) ein wieder neu zu entpackendes .zip mit ALLEN logs darin präsentiert. In vielen Fällen eher sinnfrei, wenn Ihr mich fragt.

Lösung: Für das schnelle debuggen sind die Logfiles hier versteckt:

  • Windows Server XP/2003:
    %allusersprofile%\Application Data\VeeamBackup
  • Windows Server 2008/2008R2/7:
    %allusersprofile%\VeeamBackup
  • Windows Server 2026/2019/2022 und Windows 10: (thx Dezibel)
    %allusersprofile%\Veeam
  • Linux:
    /var/log/VeeamBackup/