--- title: "Verschachteltes VMware-ESXi-Lab auf STACKIT erstellen" description: "Erstellen Sie ein verschachteltes VMware-ESXi-Lab auf STACKIT mit QEMU/KVM, geeigneten Disks, privatem Managementnetz sowie klaren Lizenz- und Abnahmegrenzen." scfAsset: managed: false category: "guide" external: false tags: ["design-and-mobilize", "use-cases", "relocate", "vmware", "esxi", "lab", "nested-kvm"] maintainers: - user: "lukas.weberruss" role: true website: true source_url: "https://framework.stackit.cloud/de/migration/assetcontainer/stackit/nested-vmware-esxi-lab-on-stackit/" source_file: "docs/de/migration/assetcontainer/stackit/nested-vmware-esxi-lab-on-stackit.mdx" --- ## Zweck und Grenzen Erstellen Sie eine isolierte VMware-Quellumgebung, wenn im Migrationslab noch kein ESXi-Host vorhanden ist. Ein STACKIT-Linux-Server betreibt QEMU/KVM, darin läuft ESXi und darin wiederum die Test-Workload-VM. Dies ist optionale Laborinfrastruktur, keine Voraussetzung des VMware-Relocate-Trails. Verwenden Sie für echte Migrationen die vorhandene, passend lizenzierte VMware-Umgebung des Kunden. ```d2 direction: down host: "STACKIT-Linux-Host\nUbuntu + QEMU/KVM\nVMX und EPT verfügbar" esxi: "Verschachteltes ESXi\nQ35 + AHCI + VMXNET3\nPrivates Managementnetz" workload: "Test-Workload-VM\nGast-OS, Anwendung und Daten" host -> esxi: "Hardwarebeschleunigte Virtualisierung" esxi -> workload: "ESXi betreibt die innere VM" ``` Der Linux-Host wird gelegentlich **Carrier** genannt: Er stellt Rechenleistung, virtuelle Geräte und das lokale ESXi-Netzwerk bereit. Er ist weder Coriolis-Worker noch migrierte Anwendungs-VM. Unterscheiden Sie alle drei Ebenen bei Speicherplanung, Fehlerdiagnose und Herunterfahren. ## Getestetes Profil und Betriebseingaben Die Referenz verwendete folgendes Profil. Prüfen Sie Katalog, Quoten und CPU-Erweiterungen auf Ihrem tatsächlichen Server erneut; ein erfolgreicher Test garantiert kein identisches Verhalten bei anderer Platzierung. | Ebene | Getestete Konfiguration | Abnahmekriterium | | --- | --- | --- | | STACKIT-Linux-Server | Intel `c3i.8`, 8 vCPU / 16 GiB, `eu01-1`, Ubuntu 24.04, 80-GiB-Boot-Volume. | VMX/EPT verfügbar, ausreichende Kapazität und Linux-/QEMU-Reserve. | | Virtualisierung | QEMU 8.2.2, Q35, verpflichtendes KVM, Host-CPU mit VMX. | Hardwarebeschleunigung aktiv, ohne Software-Ausweichbetrieb. | | ESXi | ESXi 8.0 Update 3e, Build 24677879, 4 vCPU / 10 GiB, BIOS-Boot. | CPU/RAM erkannt und Installation abgeschlossen. | | ESXi-Storage | Zwei separate 32-GiB-QCOW2-Images an Q35-AHCI-Ports. | Systemdisk und leere Datastore-Disk unabhängig identifiziert. | | ESXi-Netzwerk | VMXNET3; ESXi `10.0.2.15/24`, Linux-Bridge `10.0.2.2/24`. | Privates Management funktioniert ohne öffentliche Bridge-Anbindung. | | Erster innerer Gast | Alpine-Live-Boot, 1 vCPU / 512 MiB, 2-GiB-Thin-Disk, E1000E, Hardwareversion 20. | Tatsächliche Gastausführung, noch keine Anwendungs-/Migrationsabnahme. | Der frühere minimale KVM-Test nutzte `c3i.2`; dies war nicht der ESXi-Installationshost. Sparse-Images verbrauchen mit Gastschreibzugriffen echte Kapazität. Der äußere Host benötigt zusätzlich zur ESXi-Zuweisung eigenen Arbeitsspeicher. Bereiten Sie ein freigegebenes Projekt und einen dedizierten Linux-Server über STACKIT Portal oder geprüften Infrastrukturablauf vor. Erfassen Sie Server-, Volume-, Netzwerk-, NIC- und Security-Group-IDs für die Bereinigung. Begrenzen Sie SSH auf freigegebene Adressen, verwenden Sie Schlüssel und prüfen Sie den Hostschlüssel. Veröffentlichen Sie für die Installation keine ESXi-/QEMU-Konsolenports. | Eingabe | Bedeutung und Herkunft | | --- | --- | | `LINUX_HOST` | Verifizierte Managementadresse des dedizierten STACKIT-Linux-Servers. | | `ESXI_ISO` | Absoluter Pfad auf diesem Server zum autorisierten Installer-ISO. | | `ESXI_DIR` | Neues privates Verzeichnis für Images/Socket; hier `/var/lib/scf-esxi`. | | Lab-Adressen | Überschneidungsfreies Subnetz, Linux-Bridge-Adresse und statische ESXi-Managementadresse. | | TLS-Vertrauen | Verifizierter ESXi-Hostname und Zertifikat/CA aus Konsole oder vertrauenswürdigem Verwaltungsweg. | ## Hardwarevirtualisierung prüfen Führen Sie dies auf dem **dedizierten Ubuntu-Linux-Host** aus, nicht in ESXi oder im Docs-Container: ```bash set -euo pipefail grep -qw vmx /proc/cpuinfo grep -qw ept /proc/cpuinfo sudo -n modprobe kvm_intel test -c /dev/kvm test "$(cat /sys/module/kvm_intel/parameters/nested)" = Y test "$(cat /sys/module/kvm_intel/parameters/ept)" = Y sudo -n apt-get update sudo -n apt-get install --yes qemu-system-x86 qemu-utils qemu-system-x86_64 --version ``` Stoppen Sie, wenn Erweiterungen, verschachtelte Seitentabellen oder Gerätezugriff fehlen. Gastkonfiguration kann von der äußeren Plattform verborgene Virtualisierungserweiterungen nicht wiederherstellen. Laden Sie Module auf gemeinsam genutzten Hosts nicht blind neu. Verlangen Sie bei jedem Start `-accel kvm`; ESXi-Boot und innere Gastausführung sind separate Prüfschritte nach dem KVM-Test. ## Disks und Netzwerk vorbereiten ### Funktionierendes Storage-Profil verwenden Die erste NVMe-Konfiguration erreichte den Installer, zeigte aber keine nutzbare Installationsdisk; die genaue Ursache wurde nicht isoliert. PVSCSI scheiterte danach, weil ESXi MSI-X verlangte, während das getestete QEMU-8.2.2-Gerätemodell MSI bereitstellte. Das war eine Controller-Inkompatibilität, kein nachgewiesener CPU-Fehler. Verwenden Sie stattdessen Q35 AHCI. In diesem Maschinenprofil hängen QEMUs `ide-hd`-Geräte an `ide.0` und `ide.1` an AHCI-Ports; ESXi bindet `vmw_ahci`. Ersetzen Sie sie nicht unbegründet durch VirtIO oder PVSCSI. Die Installation nutzte unveränderte Medien ohne zusätzliche Treiber oder Boot-Flags zur Umgehung der CPU-Unterstützungsprüfung. Kopieren Sie autorisierte Medien auf den Host und prüfen Sie verfügbare Herstellerintegritätsangaben. Eine lokale Prüfsumme belegt gleiche kopierte Bytes, nicht Echtheit; der ursprüngliche lokale ISO-Digest des Labs wurde nicht unabhängig gegen eine Herstellerprüfsumme geprüft. ```bash ESXI_ISO='/absolute/path/to/authorized-esxi-installer.iso' ESXI_DIR='/var/lib/scf-esxi' test -f "$ESXI_ISO" sha256sum "$ESXI_ISO" sudo -n install -d -m 0700 "$ESXI_DIR" sudo -n test ! -e "$ESXI_DIR/system.qcow2" sudo -n test ! -e "$ESXI_DIR/datastore.qcow2" sudo -n qemu-img create -f qcow2 "$ESXI_DIR/system.qcow2" 32G sudo -n qemu-img create -f qcow2 "$ESXI_DIR/datastore.qcow2" 32G ``` Erzeugen Sie bei einer aufbewahrten Installation keine Images erneut. Prüfen Sie bestehende Disks und Zugehörigkeit; verwenden Sie `qemu-img check` nur, wenn QEMU die Images nicht geöffnet hält. Bewahren Sie Geräteidentitäten bei Neustarts. ### User-Networking durch Bridge/TAP ersetzen QEMU-User-Networking-Portweiterleitung schloss im Test Management-TCP-Handshakes nicht ab: Paketmitschnitt zeigte SYN und wiederholte SYN-ACK, aber kein finales ACK. Die genaue Ursache blieb unbewiesen. Eine lokale Linux-Bridge mit TAP löste das beobachtete Verbindungsproblem. Prüfen Sie Interfaces und alle Routingtabellen vor Auswahl des Beispielsubnetzes, einschließlich VPN-Routen. Stoppen Sie bei Überschneidungen oder vorhandenen Interfacenamen, statt fremde Konfiguration zu ersetzen: ```bash ip -br address ip -4 route show table all ip -6 route show table all ip link show ``` Erstellen Sie erst nach dieser Prüfung das isolierte Netzwerk: ```bash sudo -n ip link add scf-esxi-br type bridge sudo -n ip address add 10.0.2.2/24 dev scf-esxi-br sudo -n ip link set scf-esxi-br up sudo -n ip tuntap add dev scf-esxi-tap mode tap sudo -n ip link set scf-esxi-tap master scf-esxi-br sudo -n ip link set scf-esxi-tap up ip -br address show scf-esxi-br ``` Binden Sie den STACKIT-Uplink nicht an die Bridge, ersetzen Sie keine Standardrouten und aktivieren Sie für diese Installation weder globales Forwarding noch NAT. Zunächst verbindet das Netz nur Linux und ESXi; Gast-Egress und Coriolis-Worker-Zugriff benötigen ein separates freigegebenes Routing-/Firewall-Design. ## ESXi installieren und starten Der Befehl nutzt getestete CPU-, NIC- und Storage-Modelle. Betreiben Sie nur einen Prozess für diese Images/diesen Socket. QMP bleibt ein privilegierter Unix-Socket. Für interaktive Installation ergänzt das Beispiel eine **nur an Loopback gebundene VNC-Konsole** als Standardalternative zu den QMP-Screenshots und Tasteneingaben der Referenz. ```bash sudo -n test ! -e "$ESXI_DIR/qmp.sock" sudo -n qemu-system-x86_64 \ -name scf-esxi-lab -machine q35 -accel kvm -cpu host,vmx=on \ -smp 4,sockets=1,cores=4,threads=1 -m 10240 \ -no-user-config -nodefaults -vga std -vnc 127.0.0.1:0 \ -qmp "unix:$ESXI_DIR/qmp.sock,server=on,wait=off" \ -serial "file:$ESXI_DIR/serial.log" \ -drive "file=$ESXI_DIR/system.qcow2,if=none,id=system,format=qcow2" \ -device ide-hd,bus=ide.0,drive=system,serial=SCFESXISYSTEM \ -drive "file=$ESXI_DIR/datastore.qcow2,if=none,id=datastore,format=qcow2" \ -device ide-hd,bus=ide.1,drive=datastore,serial=SCFESXIDATASTORE \ -cdrom "$ESXI_ISO" -boot order=d,menu=off \ -netdev tap,id=management,ifname=scf-esxi-tap,script=no,downscript=no \ -device vmxnet3,netdev=management,mac=52:54:00:12:34:56 ``` Verwenden Sie für weitere Lab-Hosts andere MAC-Adressen. Tunneln Sie VNC auf dem **Arbeitsplatz** über verifiziertes SSH und verbinden Sie einen VNC-Viewer mit `127.0.0.1:5900`: ```bash LINUX_HOST='your-verified-linux-host' ssh -o StrictHostKeyChecking=yes -N \ -L 127.0.0.1:5900:127.0.0.1:5900 "ubuntu@$LINUX_HOST" ``` 1. Warten Sie auf den Installer. Bei vermutetem Stillstand öffnen Sie Logs mit Alt+F12 und kehren mit Alt+F2 zurück. Die letzte Meldung `Starting service vmtoolsd` allein bewies keinen Hänger. 2. Lesen und akzeptieren Sie die EULA selbst. Prüfen Sie CPU/RAM, VMXNET3 und beide Diskidentitäten. 3. Installieren Sie nur auf `SCFESXISYSTEM`; erhalten Sie `SCFESXIDATASTORE`. Setzen Sie das Root-Passwort privat in der Konsole, nie in Argumenten, geteilten Screenshots oder Git. 4. Schließen Sie die Installation ab. Die Referenz zeigte einen Legacy-BIOS-Hinweis, keinen fatalen CPU-Fehler. 5. Fahren Sie ESXi sauber herunter und starten Sie dieselben Images ohne ISO: Ersetzen Sie `-cdrom "$ESXI_ISO" -boot order=d,menu=off` durch `-boot order=c,menu=off`. 6. Konfigurieren Sie in der Direct Console User Interface (DCUI) VMXNET3-Management mit der statischen Beispieladresse `10.0.2.15/24`. Übernehmen Sie Änderungen und prüfen Sie den Weg zu `10.0.2.2`. Der ursprüngliche temporäre Start hatte eine Laufzeitgrenze von einer Stunde. Ablauf stoppte QEMU, nicht STACKIT-Abrechnung, und war kein aufgezeichneter VMkernel-Absturz. Betreiben Sie keinen aufbewahrten Host unter einem Wegwerf-Testtimeout. Ein alter Socket erfordert Prozess-/Zugehörigkeitsprüfung, kein blindes Löschen. ## Management und Datastore prüfen Prüfen Sie in der ESXi-Konsole oder zeitweise aktivierter, eingeschränkter ESXi Shell NIC, Managementadresse und Virtualisierungsfähigkeit: ```sh localcli network nic list esxcli network ip interface ipv4 get esxcli hardware cpu global get ``` Die getestete NIC verwendete `nvmxnet3` mit aktivem Link; `HV Support` war `3`. Das API-Feld `nestedHVSupported` beschreibt eine andere Fähigkeit zur Weitergabe von Virtualisierung und ist nicht derselbe Test. Tunneln Sie vom Arbeitsplatz Management-HTTPS zur vom Linux-Host erreichbaren ESXi-Adresse: ```bash ssh -o StrictHostKeyChecking=yes -N \ -L 127.0.0.1:18443:10.0.2.15:443 "ubuntu@$LINUX_HOST" ``` Verwenden Sie Zertifikatshostnamen, passende lokale Namensauflösung und verifiziertes Zertifikat/CA für Host Client über den Tunnel. Beziehen/ersetzen Sie Zertifikate bei Bedarf über unterstützte Verwaltung. Akzeptieren Sie keine Browserwarnungen und deaktivieren Sie TLS-Prüfung nicht als Managementkonzept. Auch ein HTTPS-Reverse-Proxy benötigt verifiziertes Upstream-TLS und leitet keinen VMware-Diskexport über TCP 902 weiter. Erstellen Sie VMFS6 auf der verifizierten leeren `SCFESXIDATASTORE`-Disk, niemals auf der Systemdisk. Bevorzugen Sie erlaubte Host-Client-Storage-Verwaltung. Folgen Sie für eine freigegebene lokale Shell-Prozedur den unten verlinkten Broadcom-Anweisungen zu Identifikation, `partedUtil` und `vmkfstools -C vmfs6`. Prüfen Sie vor Partitionsänderungen: ```sh esxcli storage core device list esxcli storage filesystem list ``` Die getestete 32-GiB-Disk nutzte eine GPT-VMFS-Partition von Sektor 2048 bis zum geprüften letzten nutzbaren Sektor. Leiten Sie Werte von der tatsächlichen Disk ab, nicht von einem anderen Gerät. Prüfen Sie Mount und Kapazität des neuen Datastores. Lokale Shell-Verwaltung ersetzt keine Lizenzrechte für Migrations-APIs. ## Inneren Gast starten und Migrationszugriff qualifizieren Erstellen Sie über Host Client eine kleine Linux-VM mit obigem Profil, binden Sie legitime Gastmedien ein und prüfen Sie tatsächlichen Konsolenboot. Bevorzugen Sie reguläre VM-Erstellung statt einer minimalen handgeschriebenen VMX: Der ersten VMX fehlten PCIe-Root-Ports, wodurch `No PCIe slot available for Ethernet0` auftrat. Standard-PCI-Bridge-/Root-Port-Einträge lösten diesen Konfigurationsfehler, keine Änderung verschachtelter CPU-Virtualisierung. Ein Alpine-Live-Login beweist nur Gastausführung. Installieren Sie für den Migrationstest den Gast auf Disk, konfigurieren Sie Netz und VMware Tools und erfassen Sie Anwendungs-/Datenzustände. Die spätere Spring-Boot-/PostgreSQL-Quelle war eine separate installierte Ubuntu-VM, nicht der Live-Boot-Test. Vor Nutzung von ESXi als Coriolis-Quelle: - Prüfen Sie die **installierte Lizenz**, nicht die allgemeine Evaluationsmeldung des Installers. Die anfängliche Free-Hypervisor-Edition lieferte `RestrictedVersion` bei API-Datastore-Erstellung. Beschaffen Sie passende API-/Snapshot-/CBT-/Exportrechte. Die Referenz verwendete später eine lizenzierte Quelle, keine Umgehung der Beschränkungen. - Erstellen Sie einen dedizierten Migrationsaccount und testen Sie erforderliche Vorgänge damit. - Prüfen Sie Management-HTTPS und NFC/NBD TCP 902 aus dem tatsächlichen Coriolis-Worker-Namespace. Prüfen Sie DNS/TLS, begrenzte Routen/Firewall-Regeln und Rückwege; Browserzugriff genügt nicht. - Verifizieren Sie exakte VM-Identität/Inventar, API-Snapshot-Erstellung/-Entfernung, CBT und Diskexport. Klären Sie installierte Provider-Kompatibilität vor Migration mit dem Herstellersupport. ## Fehlerbehebung und Aufbewahrung | Symptom | Nachweisgestützte Maßnahme | | --- | --- | | KVM lässt sich nicht initialisieren | VMX/EPT, Modulzustand, `/dev/kvm` und Rechte prüfen; nicht auf TCG ausweichen. | | Installer zeigt keine Disks | Getestete Q35-AHCI-Anbindung verwenden und Seriennummern prüfen, statt Prüfungen abzuschwächen. | | PVSCSI lehnt MSI-X ab | Versionsabhängiges Gerätemodell prüfen; AHCI vermied den getesteten MSI-/MSI-X-Konflikt. | | Boot scheint festzuhängen | VMkernel-Logs und äußeren Prozess samt Laufzeitgrenze prüfen, bevor ein Hänger angenommen wird. | | HTTPS-Handshake stockt | Pakete an beiden Enden prüfen; Bridge/TAP ersetzte den fehlerhaften User-Networking-Pfad. | | Innere VM scheitert beim Ethernet-Start | PCI-Bridge-/Root-Port-Konfiguration prüfen oder reguläre Host-Client-Definition erstellen, Disks erhalten. | | API meldet `RestrictedVersion` | Tatsächliche Lizenz prüfen; Shell-/UI-Erfolg beweist keine API-Migrationsrechte. | | UI funktioniert, Diskexport scheitert | TCP 902 zum zuständigen ESXi und Routing des Endpoint-Hostnamens separat prüfen. | Persistieren Sie für Aufbewahrung Bridge/TAP und QEMU-Start von installierten Disks in geprüfter Netzwerk-/systemd-Konfiguration. Netzwerk muss vor QEMU vorhanden sein. Bewahren Sie Geräte-/Diskidentitäten, entfernen Sie Installer-ISO, halten Sie Sockets privat und prüfen Sie Neustartrichtlinien. Sichern Sie QCOW2 konsistenzbewusst, nicht durch beliebige Kopien geöffneter Images. Übergeben Sie Cloud-IDs, ESXi-/QEMU-Versionen, Lizenz, CPU-Erweiterungen, Diskseriennummern, Datastore, Netzwerk, Zertifikat-/SSH-Vertrauen und Gasttest. Reihenfolge zum Herunterfahren: Workloads, regulärer ESXi-Shutdown, dann äußeres QEMU/Linux. Aufbewahrung verursacht Kosten. Löschen Sie nur freigegebene lab-eigene Cloud- und optionale DNS-/Veröffentlichungsressourcen; QEMU-Stopp bereinigt weder STACKIT-Server noch Volumes. ## Primäre Referenzen