Fullmoon System

Startprobleme im VirtualBox-Labor — Aufbau von Rocky 10.2 und PXE

AI_Manager

Bevor NetBox, Zabbix und AWX installiert werden konnten, musste ein Problem gelöst werden. Neue VMs blieben beim Kernel-Boot hängen, der Netzwerk-Bootpfad von UEFI öffnete sich nicht und das PXE-Installationsimage passte nicht in den Arbeitsspeicher. Dieser Beitrag fasst die Probleme zusammen, die in der VirtualBox-Praxisumgebung aufgetreten sind, und führt sie nicht auf Fehler im Dienst selbst zurück.

Die Umgebung besteht aus Windows 11 Pro, einem Intel Core Ultra 9 185H, ca. 31,4 GiB verfügbarem Arbeitsspeicher, VirtualBox 7.2.18 und Rocky Linux 10.2. Die nachfolgenden Lösungsbedingungen basieren auf den Beobachtungen auf diesem PC und lassen sich nicht verallgemeinert auf alle VirtualBox- und UEFI-Umgebungen übertragen.

1. Kernel-Boot harrt bei mehreren vCPUs aus

Symptome und Beobachtungen

Einige VMs blieben während des Bootvorgangs hängen, nachdem die Anzahl der CPUs erhöht wurde. In der letzten Zeile der seriellen Konsole verblieb eine Initialisierungsmeldung für erweiterte EVM-Attribute. Allein die Tatsache, dass die letzte Ausgabe EVM betrifft, lässt jedoch nicht den Schluss zu, dass EVM oder SELinux die Ursache sind.

Der Paravirtualisierungsanbieter und die Bedingungen für die virtuelle CPU wurden geändert und verglichen. Die zentrale VM bestätigte das Booten und Neustarten mit gateway 2 vCPU und ops01 4 vCPU im CPU-Profil Intel Core i7-6700K. Im Gegensatz dazu blieb der Installationskernel für das neue BIOS-PXE-Ziel selbst im selben Profil bei 2 vCPU stehen, weshalb der Fortgang mit 1 vCPU erfolgte.

Angewandte Maßnahmen

# Nur bei ordnungsgemäß heruntergefahrener VM anwenden.
$VBox = 'C:\Program Files\Oracle\VirtualBox\VBoxManage.exe'
& $VBox modifyvm fml-ops-01 --cpu-profile 'Intel Core i7-6700K' --cpus 4
& $VBox modifyvm fml-dev-app-01 --cpus 1

Dieses Profil stellt die Kompatibilitätsbedingung für virtuelle CPUs dar. Die physische Host-CPU wechselt dadurch nicht zu einem i7-6700K. Da das Modell der virtuellen CPU in den Ergebnissen der Gasterfassung erscheint, wurde es von den physischen PC-Spezifikationen im Portfolio unterschieden.

Hyper-V, VBS und die Windows-Speicherintegrität wurden nicht deaktiviert. Es wird nicht pauschal behauptet, dass das Ausschalten dieser Funktionen das Problem behebt; stattdessen wurden die Bedingungen für jede erfolgreich passierte VM protokolliert. Die finale Anzahl der vCPUs berücksichtigte neben einem erfolgreichen Start auch die für die Dienstvorgänge erforderlichen Ressourcen.

2. UEFI-Firmware-Ausnahmen und der Netzwerk-Bootpfad

Symptome und Beobachtungen

Bei bestimmten Grafik- und Firmware-Kombinationen neuer EFI-VMs trat eine CpuDxe-Ausnahme auf. Die Kombination aus EFI64, VMSVGA und 16 MiB VRAM vermied diese Ausnahme, zeigte jedoch nicht das erwartete native PXE-Bootmenü an.

Zusätzlich war das vorhandene Extension Pack auf Version 7.1.10, während die VirtualBox-Hauptanwendung Version 7.2.18 aufwies. Es wurde der Versionskonfliktfehler VERR_VERSION_MISMATCH festgestellt. Es wurden weder das Extension Pack installiert noch Lizenzvereinbarungen bestätigt.

Die EFI- und Legacy-EFI-Bootpfade des offiziellen iPXE wurden ebenfalls getestet, führten auf diesem PC nach der Initialisierung jedoch nicht zur Installation. Dies wurde nicht zu dem Schluss ausgeweitet, dass „UEFI-PXE generell nicht funktioniert“.

Der für die tatsächliche Installation verwendete Pfad

Unter BIOS + offizieller ipxe-legacy.iso liefen DHCP → Kernel/initrd des internen HTTP → Rocky-Kickstart-Installation ab. Als Ziel wurde nur eine Netzwerkschnittstelle im internen Netz verwendet, und die Betriebssystempakete wurden vom Provision-Server bezogen.

& $VBox modifyvm fml-prod-app-01 --firmware bios --cpus 1 --memory 4096
& $VBox modifyvm fml-prod-app-01 --boot1 disk --boot2 dvd --boot3 net --boot4 none

Der Nachweis der PXE-Installation im Praktikum ist dieser BIOS-Pfad. Das bedeutet nicht, dass UEFI, Secure Boot, NIC Option ROM oder RAID-Konfigurationen physischer Server verifiziert wurden. Bei der Anwendung auf physische Hardware müssen die unterstützten Pfade dieser Geräte separat getestet werden.

3. Herunterladen des Installationsimages schlägt bei 2 GiB Arbeitsspeicher fehl

Symptome und Ursachen

Nach dem Empfang von PXE-Kernel/initrd trat No space left on device während des Schritts auf, in dem das etwa 750 MiB große install.img heruntergeladen wurde. Das Problem war kein Mangel an Speicherplatz auf der zu installierenden virtuellen Festplatte, sondern ungenügender tmpfs-Speicherplatz in der initialen Installationsumgebung.

Maßnahmen und Überprüfung

Der RAM für das Installationsziel wurde von 2 GiB auf 4 GiB erhöht. Im selben internen Speicher wurden das Installationsimage sowie 309 RPMs heruntergeladen und die Rocky-Installation abgeschlossen. Nach der Installation wurden SSH-Zugriff, Betriebssystemversion, Management-IP, SELinux Enforcing sowie die Installationsmarkierung überprüft, woraufhin die VM ordnungsgemäß heruntergefahren und der RAM auf 1 GiB reduziert wurde.

& $VBox showvminfo fml-prod-app-01 --machinereadable
# Nach dem ordnungsgemäßen Herunterfahren des Gasts
& $VBox modifyvm fml-prod-app-01 --memory 1024
& $VBox startvm fml-prod-app-01 --type headless

Der für die Installation benötigte Arbeitsspeicher unterscheidet sich von dem für den Betrieb von Diensten nach der Installation erforderlichen Speicher. Da die gleichzeitige Zuweisung von 4 GiB für die Installation an mehrere Ziele die Ressourcenpuffer von Windows und zentralen Diensten verringerte, wurden die Zielinstallationen nacheinander ausgeführt.

4. Der Installationsbildschirm scheint über längere Zeit einzufrieren

Im 1-vCPU-Praktikum nahmen die Konfiguration von kernel-core, die Erstellung von initramfs und das Anwenden von SELinux-Richtlinien viel Zeit in Anspruch. Die Stromversorgung der VM wurde nicht sofort abgeschaltet, nur weil sich der letzte Bildschirm nicht veränderte. Anhand der Protokollzeiten im seriellen Log, des Status der Installationsprozesse und der Festplattenaktivität wurde zwischen laufenden Installationen und einem Stillstand beim Booten unterschieden.

Ein erzwungenes Ausschalten erfolgte ausschließlich bei den Bedingungen, bei denen ein neues, leeres Festplattenziel bereits vor Beginn der Installation beim Kernel-Boot hängen geblieben war. VMs, bei denen gerade Pakete installiert oder Dateisysteme aktualisiert wurden, wurden auf diese Weise nicht unterbrochen.

5. Nach dem Klonen einer VM unbedingt zu überprüfende Werte

Prüfpunkt Grund
hostname/FQDN Konsistenz zwischen Umgebungs- und Asset-Namen
MAC- und Verwaltungs-IP Übereinstimmung von DHCP-Reservierung, Umweltnetzwerk und Bastion-Zulassungszielen
machine-id Vermeidung von Duplikaten bei den Kennungen des geklonten Betriebssystems
SSH-Host-Key Verhinderung der Wiederverwendung geklonter Keys, Überprüfung des Vertrauenspfads
Verbindung der virtuellen NIC Überprüfung, ob sich NAT/Bridge-NICs im Ziel vermischt haben
Boot-Reihenfolge und Datenträgersignatur Vorrang für das bestehende Betriebssystem beim Neustart, Vermeidung des Überschreibens von Daten durch Neuinstallation
Speicher- und CPU-Profil Getrennte Protokollierung von Installations- und Betriebsbedingungen

In der seriellen Konsole wurden der von der Installation generierte öffentliche SSH-Host-Key sowie der Fingerabdruck hinterlassen. Die Automatisierung der Verwaltung überprüft diesen Wert und registriert ihn in known_hosts, ohne StrictHostKeyChecking zu deaktivieren, um Authentifizierungsfehler zu beheben.

6. Warum dieser Bericht von den Artikeln zum Service-Aufbau getrennt wurde

Virtuelle CPUs, Firmware und Installations-RAM sind Probleme einer VM-basierten Umgebung. NetBox-Health-Checks, Redis-Verbindungs-Timeouts, die Weitergabe von AWX-Berechtigungen sowie API-Token- und Speicherpfade sind hingegen Probleme beim Aufbau und Betrieb von Diensten. Die Trennung beider Kategorien ermöglicht es bei der nächsten praktischen Übung, schnell zu entscheiden, ob „zuerst die VM korrigiert werden muss“ oder ob „die Dienstkonfiguration überprüft werden muss“.

Für offizielle Boot-Dateien und Funktionsweisen wurde auf iPXE-Downloads, iPXE-Boot-Dateien und iPXE-Chainloading verwiesen. Die Erfolgs- und Fehlerbedingungen im Hauptteil stellen die tatsächlichen Praxisergebnisse auf diesem PC dar.

Weiterführende Lektüre und Konfigurationsmaterialien

Portfolio-Originaltext · Leitfaden zum Aufbau von Online- und isolierten Netzwerken · Fehlerszenarien und Verifizierungsprotokolle · Protokoll zur Behebung von VirtualBox-Konfigurationsproblemen

ZIP-Datei mit Übungskonfiguration und Automatisierungsquellcode · ZIP SHA-256

Die öffentliche ZIP-Datei enthält Konfigurationsvorlagen und Automatisierungsquellcode. Sie enthält keine Betriebssysteme, RPMs, Container-Images oder Anmeldedaten. Die Anwendung erfolgt nach der Konfiguration mit Ihren eigenen Adressen, öffentlichen CAs, autorisierten SSH-Schlüsseln und Secret Stores.