Ich wollte einen ESXi auf 6.5 U1 upgraden – doch das Upgrade auf einem USB-Stick installierten Server ist mit folgender Fehlermeldung abgebrochen:

[InstallationError]
Failed updating the bootloader: Execution of command /usr/lib/vmware/bootloader-installer/install-bootloader failed: non-zero code returned
return code: 1
output: ERROR: ld.so: object ‚/lib/libMallocArenaFix.so‘ from LD_PRELOAD cannot be preloaded: ignored.
Traceback (most recent call last):
File „/usr/lib/vmware/bootloader-installer/install-bootloader“, line 238, in
main()
File „/usr/lib/vmware/bootloader-installer/install-bootloader“, line 223, in main
partType, diskGeom, parts = getDiskInfo(diskPath)
File „/usr/lib/vmware/bootloader-installer/install-bootloader“, line 151, in getDiskInfo
rc, out, err = execCommand(command)
File „/usr/lib/vmware/bootloader-installer/install-bootloader“, line 94, in execCommand
raise Exception(„%s failed to execute: status(%d)“ % (command, process.returncode))
Exception: /sbin/partedUtil getptbl /vmfs/devices/disks/naa.200049454505080f failed to execute: status(255)
vibs = VMware_bootbank_esx-base_6.5.0-1.26.5969303
Please refer to the log file for more details.

Ich habe das Problem mit dem deaktivieren des neuen USB-Treibers gelöst:

esxcli system module set -m=vmkusb -e=FALSE

danach reboot und dann nochmal das Upgrade versucht -> funktioniert.

Nach dem erfolgreichen Upgrade sollte man den Treiber wieder mit

esxcli system module set -m=vmkusb -e=TRUE

aktivieren.

Nach einem weiteren Reboot ist man dann wieder up-to-date 🙂

Quellen: VMWare und VMWare-Forum

Will man einen ESXi-Host updaten oder z.B. von 6.0 auf 6.5 upgraden, kann man das ganz einfach wie folgt über die CLI erledigen:

1) SSH-Dienst auf dem Host starten

Entweder im Web Client unter Aktionen – Dienste – Secure Shell (SSH) aktivieren

ssh-aktivieren-webclient

oder im vSphere Client wie hier beschrieben

2) Anmeldung über SSH

3) Firewall für HTTP freischalten

esxcli network firewall ruleset set -e true -r httpClient

4) Upgrade-Paket suchen – hier als Beispiel die Version 6.5

esxcli software sources profile list -d https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml | grep -i ESXi-6.5

(Für andere Versionen einfach bei dem grep die entsprechende Version abändern)

Dann bekommt man folgende Anzeige

ssh-upgrade-paket-finden

5) Upgrade ausführen

esxcli software profile update -p ESXi-6.5.0-4564106-standard -d http://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml

(Für andere Versionen einfach die entsprechende Version abändern)

Nach dem erfolgreichen update sieht man folgendes

ssh-upgrade-beendet

6) Nestarten

reboot

fertig 🙂

Ich hatte bei einem Kunden das Problem, dass in schöner Regelmäßigkeit die Exchange-Datenbanken, SQL-Datenbanken und auch die Datenbanken des ActiveDirectorys auf den Domain-Controllern, die in VMs unter VMWare liefen, nach der Sicherungen (in meinem Fall mit Veeam) Fehler aufwiesen – oder teilweise sogar ganz defekt waren.

Nach ewiger Sucherei stellt sich heraus: Die eingesetzte VMWare-Version (vSphere 6.0) hatte ein schwerwiegendes Problems mit dem CBT Treibern – betroffen waren Oracle, SQL, AD und Exchange Datenbanken. Hier auch ein Thread zu dem Thema.

Die Lösung ist hier ganz simpel: Update der VMWare-Umgebung (mindestens) auf das Update 1b – den dort ist der Bug behoben.

Seitdem keine Problem mehr 🙂

Bei Installationen des ESXi auf einem USB-Stick oder einer SD-Karte wird die Warnung „Systemprotokolle auf dem host abc.xyz werden in einem nicht beständigen Speicher gespeichert„. VMware logt nämlich nicht auf USB-Speicher und Sd-Karten – den die sind nach VMWare-denke „volatil“. Nur Festplatten (respektive Datastores) sind beständig.

vmwarelogfehler

Das Problem löst man wie folgt in zwei einfachen Schritten:

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

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 Standartinstallation auf der Ramdisk liegt. Danach muss wie gesagt noch neu gestartet werden – danach ist die Meldung verschwunden!

Quelle: ugg.li

Wann man – wie ich – auf einem Rechner VMware Workstation bzw. Player und den integrierten Hypervisor Hyper-V unter Windows verwenden will muss man ein wenig tricksen.
Denn wenn einr der beiden installiert / aktiviert ist, kann man den anderen Hypervisor nicht verwenden.
Um dieses Problem zu lösen muss man den Hyper-V beim booten aktivieren um Hyper-V zu verwenden – bzw. deaktivieren um VMware zu verwenden.

Das funktioniert am einfachsten wenn man eine Powershell als Administrator öffnet und mit

bcdedit /set hypervisorlaunchtype off

Hyper-V beim nächsten booten zu deaktivieren (um mit VMware zu arbeiten), bzw.

bcdedit /set hypervisorlaunchtype auto

um Hyper-V beim nächsten starten zu aktivieren um eben mit Hyper-V zu arbeiten.

Wenn man einen ESXi-Host updaten will und den Update Manager von VMWare nicht verwenden kann oder will, empfehle ich immer das Update mittels dem Offline Bundle.

Das Update mit dem Offline Bundle ist wirklich super einfach und funktioniert eigentlich immer. Ich zeige die Vorgehensweise an einem Upgrade von ESXi 5.1 auf 5.5:

1) Als erstes muss das zu installierende Offline Bundle heruntergeladen werden. Entweder direkt bei VMWare

OfflineBundleDownload

oder beim Hersteller des Servers. Alle großen Hersteller bieten hier auch Offline Bundles an. Wenn der Server mit vorinstalliertem ESXi vom Hersteller läuft, wäre der Hersteller-Download die bevorzugte Wahl.

2) Das Offline Bundle auf den Datastore des ESXi hochladen. Wenn man mehrere ESXi zu upgraden hat, empfiehlt sich da natürlich ein Datastore zu wählen auf den alle ESXi Zugriff haben..

BundleHochladen

BundleHochgeladen

3) Den ESXi-Host in den Wartungsmodus versetzen

Wartungsmodus

4) Mit SSH auf den Host verbinden (falls nötig muss der Dienst noch gestartet werden -> Anleitung wie dies einfach funktioniert)

5) Jetzt geben wir uns alle Profile des Offline Bundle aus

esxcli software sources profile list -d /vmfs/volumes/datastore1/update-from-esxi5.5-5.5_update02-2068190.zip

ShowProfilesBundle

Meistens wird hier das einfache Standard-Profil benötigt – kommt darauf an welches Profil der Host jetzt hat – das sieht man am einfachsten im VMWare Client

ProfileESXi-Host-1

6) Das entsprechende Profil installieren

esxcli software profile update -d /vmfs/volumes/datastore1/update-from-esxi5.5-5.5_update02-2068190.zip -p ESXi-5.5.0-20140902001-standard

Nach kurzer Wartezeit kommt dann folgende Ausgabe

UpdateResultOfflineBundle

Danach den Host rebooten

reboot now

7) Mit dem VMWare-Client anmelden und die Version überprüfen

ProfileESXi-Host-2

8) Wartungsmodus beenden

Jetzt noch den Wartungsmodus beenden

WartungsmodusBeenden

und schon sind wir fertig 🙂

Bei einer Migration von VMWare auf Hyper-V in der man virtuelle Maschinen übernimmt, muss man die VMDK-Dateien der VMs in VHD bzw. VHDX-Dateien umwandeln. Es gibt natürlich hier Tools wie den Starwind V2V Converter – aber wenn man mehrere VMDKs hat ist so ein graphisches Tool in dem ich für jede einzeln das Programm durchklicken muss natürlich nichts. Dafür gibt es beim Microsoft Virtual Machine Converter 2.0 schöne Powershell-Befehle mit denen man das erledigen – und natürlich auch scripten – kann.

Nach der Installation öffnet man eine Powershell als Administrator

Dann muss man erstmal die Module importieren

Import-Module ‚C:\Program Files\Microsoft Virtual Machine Converter\MvmcCmdlet.psd1‘

danach kann konvertiert werden – z.B:

convertTo-MvmcVhd -SourceLiteralPath C:\Migration\sv-db.vmdk -DestinationLiteralPath d:\Hyper-V\VHDs -VhdType FixedHardDisk -VhdFormat vhdx

Der Name der VHDX-Datei ist der der VMDK-Datei – hier also sv-db. Abgelegt wird die in unserem Beispiel also die sv-db-vhdx im Ordner d:\Hyper-V\VHDs.

Aussehen wird das dann zum Beispiel so:

mvmc

Das ganze kann man natürlich auch scripten:

cd /d c:\Migration
Import-Module ‚C:\Program Files\Microsoft Virtual Machine Converter\MvmcCmdlet.psd1‘
gci -Filter *.vmdk | foreach {ConvertTo-MvmcVhd -SourceLiteralPath $_.Fullname -DestinationLiteralPath D:\Hyper-V\VHDs -VhdType FixedHardDisk -VhdFormat vhdx}

Hier wird erst in den Ordner gegangen in dem die VMDK-Dateien liegen – hier also c:\Migration. Danach wird das Cmdlet geladen. mit gci (Alias für get-childitem) werden alle VMDK-Dateien aufgelistet und in den Konvertierungsbefehl geschickt. Es werden dann nacheinander alle VMDK-Dateien in unserem Zielordner (hier d:\Hyper-V\VHDs) als VHDX-Dateien konvertiert abgelegt.

Danach können die Maschinen angelegt werden.

Nähere Infos zu den Powershell-Befehlen gibt es in dem MVMC_cmdlets.doc beim Download.

Nach einem Update eines ESXi 5.1 auf 5.5 bekamm ich im VMWare vSphere Client diese Meldung angezeigt:

VMWareCoredumps1

Das Update hat die Partitons-IDs geändert und deshalb stimmt der Pfad in der Konfig nicht mehr. Das kann man leicht folgendermaßen ändern:

1) per SSH anmelden oder direkt am Server in die Shell
2) die aktuelle Konfiguration mittels

esxcfg-dumppart -l

anzeigen lassen.

3) Alle verfügbaren Partitonen für das Coredump anzeigen lassen

esxcfg-dumppart -f

4) Die angezeigte Partition als Dump-Partition konfigurieren (der Partitonsname fängt immer mit naa. an – den entsprechen anpassen)

esxcfg-dumppart -s partitionsname

z.B. wie in meinem Fall:

esxcfg-dumppart -s naa.600508e00000000071c560f22d78670a:7

5) nochmal die Konfiguration anzeigen lassen

esxcfg-dumppart -l

Jetzt müsste bei „Is Active“ bei der entsprechenden Partiton ein „Yes“ stehen und die Meldung im vSphere Client verschwinden.

Hier nochmal mein Fall als Beispiel:

VMWareCoredumps2

Ich hatte das Problem in einer Umgebung ohne vCenter (ja sowas gibts) mehrere Windows Sever 2012 installieren zu müssen. Normaler weiße mit einem vCenter kein Problem – man macht eine Vorlage und stellt über diese die Server bereit. Ich habe also einen Server installiert und dann mit sysprep vorbereitet. Dann habe ich die Server in VMWare angelegt – ohne Festplatten. Danach habe ich die Festplatte meines „Vorlagen-Servers“ auf dem Datastore in jeden angelegten Server kopiert. Wegen der Optik muss aber die vmdk noch umbenannt werden:

Mit SSH auf dem ESXi anmelden.

dann in das entsprechende Verzeichnis gehen

cd /vmfs/volumes/NAME-DES-DATASTORES/NAME-DES-SERVERS/

dann umbenennen

vmkfstools -E alter-name.vmdk neuer-name.vmdk

Achtung: nur die .vmdk-Datei umbennen – die name-flat.vmdk-Datei wird automatisch mit umbennant.

Jetzt kann in die Festplatte in die VMs hinzugefügt werden.

Quelle: VMWare

Man muss ja öfters mal auf einen VMWare ESXi 5.x per SSH zugreifen. Standardmäßig ist dieser Dienst jedoch aus gutem Grund deaktiviert. Aktivieren lässt sich der Dienst direkt an der Konsole des Server – oder ganz einfach über den VMWare vSphere Client.

Den Dienst kann man im vShpere Client unter Konfiguration – Sicherheitsprofil – Dienste finden. Dort dann rechts oben auf Eigenschaften klicken. Dort kann man dann den Dienst aufwählen (in unserem Fall SSH) und starten – und natürlich auch wieder beenden

ssh-esxi

Ganz ohne zum Server gehen zu müssen 🙂