NIC Reihenfolge bei VCF Erweiterung

VMware Cloud Foundation (VCF) ist die einheitliche SDDC-Plattform für die Hybrid Cloud. Sie basiert auf der Compute-, Storage- und Netzwerkvirtualisierung von VMware.

VMware Cloud Foundation kann modular um weitere Workload Cluster erweitert werden, oder eine vorhandene Management-Domain über eine zweite Availability-Zone (AZ) gestreckt werden. Der Erweiterungsprozess wird über den SDDC-Manager gesteuert. Der Ablauf hierzu ist im Prinzip recht einfach und der SDDC-Manager übernimmt im Hintergrund alle Konfigurations-Aufgben, wie z.B. die Erzeugung des vSAN Clusters, der Netzwerke, Kernelports, vCenter umd NSX-Manager.

  • Hosts mit ESXi Basisimage installieren
  • Management IP definieren
  • root Login definieren
  • DNS und NTP konfigurieren
  • neue Hosts in den SDDC-Manager importieren
  • WLD erzeugen

Es gibt jedoch einen kleinen Stolperstein, der leicht übersehen wird: Die NIC Reihenfolge der neuen Hosts. Vor dem Import der Hosts wir eine Checkliste angezeigt, die uns darüber informiert, welche Eigenschaften die Hosts haben müssen. Gefordert werden zwei physische NICs mit mindestens 10 GBit.

Was jedoch oft überlesen wird, ist das Prädikat “traditional numbering“. Das bedeutet, die beiden 10 GBit NICs müssen die Nummern vmnic0 und vmnic1 haben. Eine Information, die leider allzuleicht überlesen wird. Diese Reihenfolge ist hart-verdrahtet und läßt sich nicht auswählen. Erschwerend kommt hinzu, dass viele Serversysteme Onboard-Netzwerkadapter haben, die zum Teil in 1 GBit ausgelegt sind. ESXi beginnt bei der Nummerierung der vmnics bei diesen Onboard-Adaptern. In solch einem Fall hätten dann also die geplanten 10 GBit NICs höhere Nummern wie z.B. vmnic2 oder vmnic3. Damit scheitert das Rollout der VCF Erweiterung.

Es ist in der aktuellen VCF Version 4.2 nicht möglich, die NICs explizit zu wählen, wie dies beispielsweise im Bringup-Sheet der Fall ist. Auch die Verwendung von mehr als 2 NICs geht nur über API-Calls und nicht über den SDDC-Manager.

Ausweg

Der einzige Ausweg besteht gegenwärtig darin, die Onboard Adapter im BIOS der Server zu deaktivieren und ggf. den PCIe LAN Adapter in einen Slot mit niedriger Nummer zu stecken, damit die NICs die Nummern 0 und 1 erhalten.

VMware Cloud Foundation 4.2 angekündigt

VCF 4.2 steht kurz vor der Veröffentlichung und bringt einige lange erwartete Verbesserungen mit sich.

[Update: seit dem 9. Februar 2021 ist VCF 4.2 allgemein verfügbar.]

  • vSAN HCI Mesh
  • NSX-T 3.1 Federation
  • vSAN Data Persistence platform (DPp)
  • vRealize Automation for VCF
  • IP Pools für NSX-T Tunnel Endpoints (TEP)
  • Release Versionsüberblick im SDDC Manager
  • Pre-Upgrade Checks
  • Advanced Security Add-on for VMware Cloud Foundation
    • Carbon Black Workload Advanced
    • Advanced Threat Prevention Add-on for NSX Data Center
    • NSX Advanced Load Balancer with Web Application Firewall
„VMware Cloud Foundation 4.2 angekündigt“ weiterlesen

VCF 4 Cloud Builder zurücksetzen

Im Rahmen eines VMware Cloud Foundation (VCF) Greenfield Deployments wird die Cloud Builder Appliance zum einmaligen Gebrauch verwendet. Diese stellt automatisiert die Management Infrastruktur eines VCF Clusters bereit und kann danach verworfen werden.

Idealerweise wird das zuvor erstellte Workbook bzw. JSON abgearbeitet und der Cluster erfolgreich erstellt.

In der UI des Cloud Builders gibt es jedoch keine Möglichkeit den Assistenten zurückzusetzen und komplett neu zu starten. Beispielsweise weil sich Anforderungen verändert haben und ein neues oder angepasstes Workbook verwendet werden soll. Oder man mächte die Appliance für einen weiteren Rollout verwenden. In diesem Fall müsste die Appliance komplett neu bereitgestellt werden. Auch eventuelle Fehler im JSON File können so nicht korrigiert werden.

Es gibt jedoch einen Trick, um den Cloud Builder wieder auf Null zu setzen und ihn mit einem veränderten JSON File zu füttern. Zu verdanken ist dies einem API Call, der möglicherweise währen der Entwicklung ‘vergessen’ wurde. Dazu müssen wir uns als User root auf der Konsole des Cloud Builders anmelden.

[Optional] Hier ist es unter Umständen einfacher, wenn man dem root User temporär SSH Zugriff erlaubt. Dazu meldet man sich als root an der VM Konsole an und editiert die sshd Konfiguration.

sudo vi /etc/ssh/sshd_config

Innerhalb des Config-Files folgende Zeile finden und mit einem # auskommentieren.

# PermitRootLogin no

Die Konfiguration speichern und eine SSH Verbindung als root aufbauen. In diesem Kontext führen wir dann einen internen API Call aus.

curl -X GET http://localhost:9080/bringup-app/bringup/sddcs/test/deleteAll

Danach loggen wir uns auf der Web-GUI des Cloud Builders ein und können diesen wieder von Anfang an ausführen.

Links

VMware Cloud Platform Tech Zone – Re-use Cloud Builder for Another Deployment