Verschachteltes VMware-ESXi-Lab auf STACKIT erstellen
Zuletzt aktualisiert am
Zweck und Grenzen
Abschnitt betitelt „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.
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
Abschnitt betitelt „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
Abschnitt betitelt „Hardwarevirtualisierung prüfen“Führen Sie dies auf dem dedizierten Ubuntu-Linux-Host aus, nicht in ESXi oder im Docs-Container:
set -euo pipefailgrep -qw vmx /proc/cpuinfogrep -qw ept /proc/cpuinfosudo -n modprobe kvm_inteltest -c /dev/kvmtest "$(cat /sys/module/kvm_intel/parameters/nested)" = Ytest "$(cat /sys/module/kvm_intel/parameters/ept)" = Ysudo -n apt-get updatesudo -n apt-get install --yes qemu-system-x86 qemu-utilsqemu-system-x86_64 --versionStoppen 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
Abschnitt betitelt „Disks und Netzwerk vorbereiten“Funktionierendes Storage-Profil verwenden
Abschnitt betitelt „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.
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" 32Gsudo -n qemu-img create -f qcow2 "$ESXI_DIR/datastore.qcow2" 32GErzeugen 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
Abschnitt betitelt „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:
ip -br addressip -4 route show table allip -6 route show table allip link showErstellen Sie erst nach dieser Prüfung das isolierte Netzwerk:
sudo -n ip link add scf-esxi-br type bridgesudo -n ip address add 10.0.2.2/24 dev scf-esxi-brsudo -n ip link set scf-esxi-br upsudo -n ip tuntap add dev scf-esxi-tap mode tapsudo -n ip link set scf-esxi-tap master scf-esxi-brsudo -n ip link set scf-esxi-tap upip -br address show scf-esxi-brBinden 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
Abschnitt betitelt „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.
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:56Verwenden 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:
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"- 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 vmtoolsdallein bewies keinen Hänger. - Lesen und akzeptieren Sie die EULA selbst. Prüfen Sie CPU/RAM, VMXNET3 und beide Diskidentitäten.
- Installieren Sie nur auf
SCFESXISYSTEM; erhalten SieSCFESXIDATASTORE. Setzen Sie das Root-Passwort privat in der Konsole, nie in Argumenten, geteilten Screenshots oder Git. - Schließen Sie die Installation ab. Die Referenz zeigte einen Legacy-BIOS-Hinweis, keinen fatalen CPU-Fehler.
- Fahren Sie ESXi sauber herunter und starten Sie dieselben Images ohne ISO: Ersetzen Sie
-cdrom "$ESXI_ISO" -boot order=d,menu=offdurch-boot order=c,menu=off. - 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 zu10.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
Abschnitt betitelt „Management und Datastore prüfen“Prüfen Sie in der ESXi-Konsole oder zeitweise aktivierter, eingeschränkter ESXi Shell NIC, Managementadresse und Virtualisierungsfähigkeit:
localcli network nic listesxcli network ip interface ipv4 getesxcli hardware cpu global getDie 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:
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:
esxcli storage core device listesxcli storage filesystem listDie 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
Abschnitt betitelt „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
RestrictedVersionbei 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
Abschnitt betitelt „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.