Kategorie: vSphere

Veröffentlicht am

Fehler beim vCLS Retreat Mode führt zum Verlust aller Privilegien

Mit Einführung von vSphere 7.0 Update 1 erschienen in vSphere-Clustern erstmals die vSphere Cluster Services VMs (vCLS). Damit wurden Cluster Funktionen wie z.B. Distributed Resource Scheduler (DRS) und andere erstmals unabhängig von der Verfügbarkeit der vCenter Server Appliance (VCSA). Letztere stellt im Cluster immer noch einen Single-Point-of-Failure dar. Durch Auslagerung der DRS Funktion in die redundanten vCLS Maschinen wurde ein höheres Maß an Resilienz erreicht.

Retreat Mode

Der vSphere-Administrator hat nur wenig Einfluss auf die Bereitstellung dieser VMs. Gelegentlich ist es jedoch notwendig, diese VMs von einem Datastore zu entfernen wenn dieser beispielsweise in den Wartungsmodus versetzt werden soll. Dafür gibt es eine Prozedur, um den Cluster in den sogenannten Retreat-Mode zu setzen. Dabei werden temporäre erweiterte Einstellungen gesetzt, die zur Löschung der vCLS VMs durch den Cluster führen.

Laut Prozedur von VMware muss für die Aktivierung des Retreat Modes die Domain ID ermittelt werden. Die Domain ID ist der numerische Wert zwischen ‘domain-c’ und dem folgenden Doppelpunkt. Im Beispiel aus meinem Labor ist es der Wert 8, aber die Zahl kann durchaus auch vierstellig sein.

Die Domain ID muss dann in den Advanced Settings des vCenters übergeben werden.

config.vcls.clusters.domain-c8.enabled = false
Korrekte Settings für den Retreat Mode.

Admin Fehler beim Retreat Mode

Nach Aktivierung des Retreat-Modes auf einem vSAN-Cluster hatten Administratoren sämtliche Privilegien auf alle Objekte im vSphere-Client verloren.

Eine Überprüfung der Dienste zeigte, dass der vCenter Server Daemon (vpxd) nicht gestartet war.

„Fehler beim vCLS Retreat Mode führt zum Verlust aller Privilegien“ weiterlesen
Veröffentlicht am

ESXi Bootmedium – Neue Anforderungen in v8

Die Anforderungen an ESXi Bootmedien haben sich mit ESXi v7 Update3 grundlegend gewandelt. Die Partitionierung wurde verändert und auch die Anforderungen an die Belastbarkeit des Mediums waren gestiegen. Ich hatte darüber in meinem Blogartikel “ESXi Bootmedium – Neuerungen in v7” berichtet.

USB-Bootmedien erwiesen sich als nicht robust genug und wurden daher ab v7U3 nicht mehr unterstützt. Es ist zwar immer noch möglich, ESXi auf ein USB-Medium zu installieren, jedoch muss dann die ESX-OSData Partition auf einen dauerhaften Speicher umgeleitet werden.

Achtung! USB-Medien und SD-Karten sollten nicht für produktive ESXi Installationen verwendet werden!

Erlaubte Ziele für die ESXi Installation

SD-Karten und USB-Medien scheiden als Installationsziel wegen ihrer schlechten Write-Endurance aus. Weiterhin erlaubt und empfohlen sind dagegen magnetische Disks, SSD und SATA-DOM (Disk-on-Module).

SATA-DOM auf Supermicro E300-9D

Neue Anforderungen ab ESXi v8

Mein Homelab lief bisher unter vSAN 7 und damit unter der klassischen OSA-Architektur. Um den Cluster unter der neuen vSAN ESA Architektur zu betreiben, brauchte es vSphere 8 und neue Speichergeräte.

Ich habe die Installation und Hardware-Kompatibilität auf einem 64 GB USB-Medium getestet (nicht empfohlen!). Während der Installation gab es erwartungsgemäße Warnungen bezüglich des USB-Mediums. Dennoch konnte ich erfolgreich die Erkennung der NVMe Devices und das vCenter Deployment testen.

Setup Warnung bei installation auf ein USB-Flashmedium

Nach erfolgreicher Testphase installierte ich ESXi 8U2 auf das SATA-DOM meines Supermicro E300 Servers. Zu meiner Überraschung scheiterte das Setup sehr früh mit der Meldung: “disk device does not support OSDATA“.

RTFM

Die Erklärung hierfür ist simpel: “Read the fine manual!”

Mein 16 GB SATA-DOM von Supermicro war schlicht zu klein.

Der Setup-Guide für ESXi 8 benennt die Anforderungen ganz klar inter dem Punkt “Storage Requirements for ESXi 8.0 Installation or Upgrade“:

For best performance of an ESXi 8.0 installation, use a persistent storage device that is a minimum of 32 GB for boot devices. Upgrading to ESXi 8.0 requires a boot device that is a minimum of 8 GB. When booting from a local disk, SAN or iSCSI LUN, at least a 32 GB disk is required to allow for the creation of system storage volumes, which include a boot partition, boot banks, and a VMFS-L based ESX-OSData volume. The ESX-OSData volume takes on the role of the legacy /scratch partition, locker partition for VMware Tools, and core dump destination.

VMware vSphere product doumentation

Mit anderen Worten: Neuinstallationen benötigen ein Bootmedium von mindestens 32 GB (128 GB empfohlen) und Upgrade von einer ESXi v7 Version benötigt mindestens 8 GB, jedoch muss in dieser Installation die OSData Partition bereits auf einen alternativen Datenträger umgeleitet sein.

Dirty Trick?

Natürlich versuchte ich es mit einem schmutzigen Trick. Ich installierte zunächst erfolgreich ein ESXi 7U3 auf dem 16 GB SATA-DOM und führte danach eine Upgrade Installation auf v8U2 durch. Auch dieser Versuch scheiterte, da in der frischen v7 Installation der OSData Bereich nicht umgeleitet wurde.

Ich möchte keine Installation auf einem USB-Medium durchführen, da ich bereits zu viele Fälle gesehen habe, in denen diese Medien versagt haben. Bleibt eigentlich nur die Investition in ein größeres SATA-DOM.

Ich habe mich für das 64-GB-Modell entschieden, da es ein guter Kompromiss zwischen Mindestanforderungen und Wirtschaftlichkeit ist.

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

vExpert 2023 – Nominierungen in den Unterprogrammen

VMware vergibt jährlich die Auszeichnung vExpert an Personen, welche sich in besonderem Maße für die VMware Community eingesetzt haben. Dies kann entweder durch Veröffentlichungen, Vorträge, Blogs, oder durch Arbeit in der VMware User Group (VMUG) erfolgen. Es freut mich, 2023 zum siebten Mal in Folge Teil der vExpert Gemeinschaft zu sein.

Zusätzlich zum allgemeinen vExpert gibt es Unterprogramme für spezielle Anwendungszweige.

Ich hatte mich für die drei Unterprogramme vExpertPro, Application Modernization und Multi-Cloud beworben und wurde in allen drei Kategorien angenommen.

vExpertPro

Die Aufgabe des vExpert PRO-Programms ist es, ein weltweites Netzwerk von vExperts zu schaffen, die bereit sind, neue vExperts in ihren lokalen Gemeinschaften zu finden, sie zu fördern und sie auf ihrem Weg zum vExpert als Mentoren zu begleiten.

Dafür gibt es vExpertPro in vielen Regionen der Welt. Ich selbst gehöre dieser Gruppe seit 2021 an und wurde für ein weiteres Jahr bestätigt.

vExpert Multi-Cloud

Der Bereich Multi-Cloud erstreckt sich über weite Teile des VMware Compute Portfolios. Der Begriff Cloud beinhaltet nicht nur die Public-Cloud, sondern auch lokale Datacenter (Private-Cloud) und Kombinationen aus beiden Ansätzen (Hybrid-Cloud). Darunter fallen zahlreiche Produkte wie vSphere, vSAN, VMware Cloud Foundation (VCF), Aria, VMware Cloud on AWS, Site Recovery Manager (SRM) oder vCloud Director (VCD).

Ich hatte mich 2023 erstmalig für diesen relativ neuen vExpert-Pfad beworben und wurde angenommen. Vielen Dank an die Business Unit für das Vertrauen.

vExpert Application Modernization

Application Modernization dreht sich um die Themenbereiche Tanzu und Kubernetes, sowie das Ökosystem rund um diese Anwendungen. Der Hintergrund wurde sehr ausführlich von Keith Lee beschrieben in seinem Artikel “Announcing the VMware Application Modernization vExpert Program 2023“.