Schlagwort: powerCLI

Veröffentlicht am

ESXi Config-Backup mit PowerCLI benötigt HTTP

Es gibt einen wirklich nützlichen und komfortablen PowerCLI One-Liner zur Sicherung der Hostkonfiguration. Ich verwende ihn seit Jahren und hatte diesen auch in einem alten Blogpost im Detail erklärt.

Get-Cluster -Name myCluster | Get-VMHost | Get-VMHostFirmware -BackupConfiguration -DestinationPath 'C:\myPath'

Im Rahmen meiner VMware Kurse ist dies ein Befehl, den ich meinen Studenten immer mit auf den Weg gebe. Die Sicherung der Host-Konfiguration ist geradezu Pflicht vor Änderungen am Host, Installation von Patches und Treibern, oder Host-Updates. Nur ein paar Sekunden mehr Aufwand, aber diese Konfigurations-Backups haben mir schon mehr als einmal größeren Ärger und viele Stunden Arbeit erspart.

Kürzlich war ich in einem größeren Datacenter mit der Sicherung der Host-Konfigurationen beschäftigt. Überraschenderweise funktionierte der Befehl auf einigen der vCenter-Instanzen nicht und brach mit einer Fehlermeldung ab.

Get-VMHostFirmware : 18.08.2023 12:05:49 Get-VMHostFirmware An error occurred while sending the request.
At line:1 char:28
+… et-VMHost | Get-VMHostFirmware -BackupConfiguration -DestinationPath …
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Get-VMHostFirmware], ViError
+ FullyQualifiedErrorId : Client20_SystemManagementServiceImpl_BackupVmHostFirmware_DownloadError,VMware.VimAutomation.ViCore.Cmdlets.Commands.Host.GetVMHostFirmware

Um den Fehler zu verstehen muss man zunächst verstehen, wie das PowerCLI Kommando arbeitet. Zunächst wird über vCenter auf dem Host ein Backup der Host-Konfiguration getriggert. Diese legt der Host lokal als gezipptes TAR Archiv (.tgz) ab. Der Name lautet configBundle-HostFQDN.tgz (Beispiel: configBundle-esx01.lab.local.tgz). Das Archiv wird dann in einem zweiten Schritt vom Host geladen. Die URL hierfür lautet:

http://[HostFQDN]/downloads/[Host-UUID]/configBundle-HostFQDN.tgz

Liest man die obige Fehlermeldung, gab es ganz offensichtlich ein Problem beim Download des TGZ-Files. Mit Hilfe der Netzwerk Admins wurde schnell klar, was hier passierte. Meine Arbeitsstation, von der ich den PowerCLI Befehl absendete, versuchte erfolglos eine HTTP Verbindung zum ESXi-Host aufzubauen. Dies wurde jedoch durch eine Firewall Regel geblockt.

Ich fragte mich, warum der Transfer über unverschlüsseltes HTTP abgewickelt wird. Im Log der Firewall sieht man einen Verbindungsversuch zum ESXi-Host mit HTTP und HTTPS.

Gibt es eine Möglichkeit, den Transfer über HTTPS zu erzwingen?

Der erste Gedanke war, dass es vielleicht einen Parameter zum Kommando gibt, der das HTTPS Protokoll erzwingt. Eine Anfrage im VMTN-Forum brachte leider Ernüchterung.

Es ist etwas erstaunlich, dass VMware für diese durchaus sensitiven Daten ein unverschlüsseltes Protokoll verwendet. Umso mehr da die PowerCLI Session zum vCenter ohnehin schon über HTTPS läuft. Die plausibelste Erklärung wäre, dass schlicht ‘vergessen’ wurde bei diesem doch recht alten Befehl, den Transfer über SSL abzusichern.

Es bleibt derzeit also keine andere Wahl, als eine Firewall-Regel zu erzeugen, die den Download über HTTP erlaubt.

Veröffentlicht am

vSAN Cluster Live-Migration in ein neues vCenter

Was kann man tun, wenn die produktive vCenter Server Appliance beschädigt ist und man einen vSAN-Cluster auf eine neue vCenter Appliance übertragen muss?

Im heutigen Beitrag werde ich zeigen, wie man einen laufenden vSAN-Cluster unter vollen Segeln von einer vCenter-Instanz auf ein neues vCenter übertragen kann.

Bei jedem der mit vSAN arbeitet, wird sich bei diesem Gedanken ein flaues Gefühl in der Magengegend verbreiten. Warum sollte man so etwas tun? Wäre es nicht besser, den Cluster komplett in den Wartungsmodus zu fahren? – Prinzipiell, ja. In der Praxis treffen wir aber immer wieder auf Einschränkungen, die in absehbarer Zeit kein Wartungsfenster erlauben.

Normalerweise sind vCenter Server Appliances robuste und wartungsarme Einheiten. Entweder sie funktionieren, oder sie sind völlig zerstört. In letzterem Fall könnte eine neue Appliance bereitgestellt und vom Backup ein Konfiguration-Restore eingespielt werden. Nichts davon traf auf ein kürzlich durchgeführtes Projekt zu. Die VCSA 6.7 funktionierte noch halbwegs, jedoch waren wichtige vSAN-Funktionalitäten im UI nicht mehr verfügbar. Eine erste Idee, das Problem mit einem Upgrade auf vCenter v7 und somit auf eine neue Appliance zu beseitigen scheiterte. Auch eine Cross-vCenter Migration der VMs (XVM) auf einen neuen vSAN-Cluster war nicht möglich, da erstens dieses Feature erst mit Version 7.0 Update 1c integriert wurde und zweitens auch nur zwei neue Ersatzhosts zur Verfügung standen. Zu wenig für einen neuen vSAN-Cluster. Zu allem Überfluss war auch der Quellcluster an seiner Kapazitätsgrenze.

Es gab nur einen Ausweg: Den Cluster stabilisieren und unter voller Last auf ein neues vCenter übertragen.

Zu diesem Thema gibt es einen alten, aber immer noch wertvollen Beitrag von William Lam. Damit, und mit dem VMware KB 2151610 Artikel konnte ich eine Strategie entwickeln, die ich hier skizzieren möchte.

Das Verfahren funktioniert, da ein vSAN-Cluster nach Einrichtung und Konfiguration autonom vom vCenter arbeiten kann. Das vCenter wird lediglich für Monitoring und Konfigurationsänderungen benötigt.

„vSAN Cluster Live-Migration in ein neues vCenter“ weiterlesen
Veröffentlicht am

ESXi Bootmedium – Neuerungen in v7 und Altlasten aus v6.x

Mit vSphere7 kamen grundlegende Veränderungen im Aufbau des ESXi Bootmediums. Eine starre Partitionsstruktur musste einer flexibleren Partitionierung weichen. Dazu später mehr.

Mit vSphere 7 Update 3 kam auch eine schlechte Nachricht für alle, die USB- oder SDCard-Flashmedien als Bootdevice nutzen. Steigende Lese- und Schreibaktivität führte zu schneller Alterung und Ausfall dieser Medien, da sie für ein solches Lastprofil nie ausgelegt waren. VMware hat diese Medien auf die Rote Liste gesetzt und der vSphere Client wirft Warnmeldungen, sollte ein soches Medium noch verwendet werden. Wir werden uns ansehen, wie man USB- oder SDCard-Bootmedien ersetzen kann.

ESXi Bootmedium: Gestern und heute

In der Vergangenheit bis Version 6.x war das Bootmedium relativ statisch. War der Bootvorgang erst einmal abgeschlossen, so war das Medium nicht mehr wichtig. Es gab allenfalls eine gelegentliche Leseanfrage einer VM auf das VM-Tools Verzeichnis. Selbst ein Medium, das im laufenden Betrieb kaputt ging, beeinträchtigte den ESXi Host nicht. Problematisch wurde nur ein Neustart. So konnte man beispielsweise auch bei defektem Bootmedium noch die aktuelle ESXi Konfiguration sichern.

Aufbau eines ESXi Bootmediums vor Version 7

Aufbau des Bootmediums bis ESXi 6.7

Der Aufbau war im Prinzip fast immer gleich: Ein Bootloader von 4 MB Größe (FAT16), gefolgt von zwei Bootbänken mit je 250 MB. Diese enthalten die komprimierten Kernelmodule, die beim Systemstart entpackt und ins RAM geladen werden. Eine zweite Bootbank ermöglicht ein Rollback im Falle eines fehlgeschlagenen Updates. Es folgt eine “Diagnostic Partition” von 110 MB für kleine Coredumps im Falle eines PSOD. Die Locker oder Store Partition enthält z.B. ISO Images mit VM-Tools für alle unterstützten Gast-OS. Von hier aus werden VM-Tools ins die Gast VM eingebunden. Eine häufige Fehlerquelle bei der Tools Installation war ein beschädigtes oder verlorenes Locker Verzeichnis.

Die folgenden Partitionen unterscheiden sich je nach Größe und Art des Bootmediums. Die zweite Diagnostic-Partition von 2,5 GB wurde nur angelegt, wenn das Bootmedium mindestens 3,4 GB groß ist (4MB + 250MB + 250MB + 110MB + 286MB = 900MB). Zusammen mit den 2,5 GB der zweiten Diagnostic Partition erfordert das 3,4 GB.

Eine 4 GB Scratch Partition wurde nur auf Medien mit mindestens 8,5 GB angelegt. Sie enthält Informationen für den VMware Support. Alles darüber hinaus wurde als VMFS-Datenspeicher bereitgestellt. Scatch und VMFS Partition wurden jedoch nur angelegt, wenn das Medium kein USB-Flash oder SDCard Speicher war. In diesem Fall wurde die Scratchpartition im RAM des Hosts angelegt. Mit der Folge, dass bei einem Host Crash auch alle für den Support wertvollen Informationen verloren gingen.

Aufbau des Bootmedium ab ESXi 7

Das oben skizzierte Layout machte die Verwendung großer Module oder Fremdanbietermodule schwierig. Folglich musste das Design des Bootmedium grundlegend verändert werden.

Veränderung des Partitionslayouts zwischen Version 6.x und 7.x

Zunächst wurde die Bootpartition von 4 MB auf 100 MB vergrößert. Auch die beiden Bootbänke wurden auf mindestens 500 MB angehoben. Die Größe gestaltet sich flexibel, abhängig von der Gesamtgröße des Mediums. Die beiden Diagnose-Partitionen (Small Core Dump und Large Core Dump), sowie Locker und Scratch wurden zusammengeführt in eine gemeinsame ESX-OSData Partition mit flexibler Größe zwischen 2,9 GB und 128 GB. Übriger Speicherplatz kann optional als VMFS-6 Datenspeicher bereitgestellt werden.

Unterschieden werden bei vSphere 7 vier Größenklassen für Bootmedien:

  • 4 GB – 10 GB
  • 10 GB – 32 GB
  • 32 GB – 128 GB
  • > 128 GB
Dynamische Partitionierung unter vSphere 7 in Anhängigkeit von der Medienkapazität.

Die oben dargestellten Partitionsgrößen gelten für neu installierte Bootmedien unter ESXi 7.0. Doch wie sieht es für Bootmedien aus, die von Version 6.7 migriert wurden?

„ESXi Bootmedium – Neuerungen in v7 und Altlasten aus v6.x“ weiterlesen
Veröffentlicht am

ESXi Konfigurations-Restore scheitert mit leerer DCUI Seite

Die Sicherung und Wiederherstellung der ESXi Host-Konfiguration ist eine Standardprozedur die bei Wartungsarbeiten am Host eingesetzt werden kann. Gesichert werden nicht nur Hostname, IP Adresse und Passwörter, sondern auch NIC und vSwitch Konfiguration, Object ID und viele weitere Eigenschaften. Selbst nach einer kompletten Neuinstallation eines Hosts kann dieser wieder alle Eigenschaften der ursprünglichen Installation annehmen.

Kürzlich wollte ich im Homelab die Bootdisk eines Hosts neu formatieren und musste herfür ESXi neu installieren. Der Neustart mit der frischen Installation funktionierte problemlos und der Host bezog eine neue IP über DHCP.

Nun sollte über PowerCLI die ursprüngliche Konfiguration wiederhergestellt werden. Dazu versetzt man zunächst den Host in den Wartungsmodus.

Set-VMhost -VMhost <Host-IP> -State "Maintenance"

Die zuvor gesicherte Konfiguration kann nun wiederhergestellt werden.

Set-VMHostFirmware -VMHost <Host-IP> -Restore -Sourcepath <Pfad_zum_Konfigfile>

Der Befehl fordert einen root Login an und macht danach automatisch einen Reboot. Am Ende des Bootvorgangs begrüßte mich eine leere DCUI.

Ich konnte mich zwar einloggen (mit dem ursprünglichen Passwort), jedoch waren sämtliche Netzwerkverbindungen verschwunden. Auch die Konfiguration des Management-Netzwerks war nicht auswählbar (grau). Der Host war blind und taub.

„ESXi Konfigurations-Restore scheitert mit leerer DCUI Seite“ weiterlesen