Beiträge

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
Veröffentlicht am

NSX-T Integration im vSphere-Client

Eine der Neuerungen von vSphere 7.0 Update 3 ist, dass man künftig NSX-T direkt aus dem vSphere-Client administrieren kann. Tatsächlich findet man im neuen Menü des vSphere-Clients auch eine Sektion zu NSX.

Wenn man versucht, diesen Abschnitt zu öffnen so erhält man derzeit eine Informationsseite zum NSX-T Status. An dieser Stelle könnten wir zwar NSX-T neu bereitstellen, bestehende NSX-T Installationen werden jedoch nicht erkannt.

Warum ist das so?

Wie meistens hilft ein Blick in die Release Notes. Dort steht für vCenter 7 Update 3 folgende Aussage:

You can see the vSphere Client NSX-T home page that enables the feature, but it does not work with NSX-T Data Center 3.1.x or earlier.

Die derzeit aktuelle NSX-T Version ist 3.1.3 [Stand 15.11.2021]. Das bedeutet, wir müssen auf NSX-T Version 3.2 warten bis die Integration funktioniert.

Veröffentlicht am

VMware Validated Design Guide (VVD) wurde abgekündigt

Wer sich schon einmal mit der Planung und dem Design von IT-Konzepten auf Basis von VMware Produkten beschäftigt hat, dem sollte der VMware Validated Design Guide (VVD) ein Begriff sein.

VMware Validated Design ist eine Sammlung von Empfehlungen für das Datacenter-Design in den Bereichen Compute, Storage, Networking und Management, die als Leitfaden für die Implementierung eines Software-Defined Data Center (SDDC) herangezogen werden können. Die Unterlagen des VVD bestehen aus aufeinander aufbauenden Dokumenten für alle Phasen des SDDC-Lebenszyklus. Die VVD-Dokumentation kann als Erweiterung der VMware Cloud Foundation (VCF) Dokumentation verwendet werden. Jede Version des VVD Guides korreliert genau mit einer bestimmten VCF Version.

Die VVD Version 6.2 für VCF 4.2 wird die letzte bleiben und der Leitfaden wird nicht mehr weitergeführt. Das Erbe des VVD treten die VMware Validated Solutions (VVS) an.

VMware Validated Solutions

VMware Validated Solutions sind technisch validierte Implementierungen, die beim Aufbau einer sicheren und stabilen Infrastruktur auf Basis von VCF unterstützen sollen. Jede VVS umfasst ein detailliertes Design mit Designentscheidungen, sowie eine Implementierungsanleitung. Zur Umsetzung von VMware Validated Solutions ist VMware Cloud Foundation SDDC Manager erforderlich.

Übersetzt bedeutet dies, dass jeder der sich künftig für eine VMware validierte Lösung interessiert, einen Blick auf VCF werfen muss.

Veröffentlicht am

GPU enabled K8s Cluster in vSphere mit Tanzu

Der Einsatz von GPUs in Container-Workloads ist eine wichtige Anforderung von Entwicklern, die mit Machine Learning und künstlicher Intelligenz arbeiten.

Sie können benutzerdefinierte VM-Klassen erstellen, in der ein VI-Administrator eine vGPU-Spezifikation für diese Klasse definiert. Entwickler können diese Klasse verwenden, um ihren Workloads GPU-Ressourcen zuzuweisen. Die VM-Klasse definiert z.B. die Knotenplatzierung und das vGPU-Profil.

Dies gilt nicht nur für GPU-fähige TKG-Cluster, sondern auch für VMs. Durch die Verwendung von benutzerdefinierten Klassen wird die Nutzung von GPU-Ressourcen in ML/AI-Anwendungen vereinfacht.

Unten ist beispielhaft eine VM Klasse dargestellt.

kind: TanzuKubernetesCluster
apiVersion: run.tanzu.vmware.com/v1
metadata:
  name: GPU-Cluster
spec:
  topology:
    workers:
      count: 3
      class: gpu-vmclass
  distribution: v1.20.2

Diese Klasse kann beispielsweise für die Bereitstellung einer VM genutzt werden.

kind: VirtualMachine
metadata:
  name: gpu-vm
  namespace: tkg-dev
spec:
  networkInterfaces:
  - networkName: "dev-network"
    networkType: vsphere-distributed
  classname: gpu-vmclass
  imageName: ubuntu-custom-gpu    
  storageClass: GPU-vm-policy

Dieser Beitrag war ursprünglich Teil meines Artikels über die Neuerungen in vSphere7 Update3. Auf Wunsch von VMware wurde der Inhalt bis zum 5. Oktober 2021 zurückgezogen und hiermit als eigener Artikel veröffentlicht.