Virtual OS Museum auf Proxmox ist Retro-Himmel mit einem Netzwerk-Kobold im Inneren

Die Idee ist unwiderstehlich: das Virtual OS Museum nehmen, in eine Proxmox-VM stopfen, und plötzlich wird Ihr moderner Hypervisor zur Zeitmaschine für VAX/VMS, OS/2, Windows 2.11, BBC-Micro-Erinnerungen und all die schrägen alten Systeme, die das Computing prägten, bevor alles zu abgerundeten Rechtecken und Abo-Logins wurde. Die ursprüngliche Frage klang simpel genug: Hat das schon mal jemand als Proxmox-VE-VM zum Laufen gebracht, und wie bringt man eine .vdi dazu, auf PVE zu booten? Der Thread entwickelte sich dann schnell zu etwas Besserem, nämlich einer Mischung aus Nostalgie, praktischen Konvertierungstipps, Nested-VM-Philosophie und einer erschreckenden Warnung darüber, versehentlich ein ganzes LAN zu vergiften.

Das Museum traf einen Nerv

Der emotionale Sog war offensichtlich. Der Threadstarter hatte das Museum bereits auf einem Windows-11-PC laufen lassen und war fasziniert, in VAX/VMS zu booten, das erste System, mit dem er beruflich gearbeitet hatte. Für ihn öffnete das Basteln eine Falltür in die eigene Erinnerung. Ein anderer schrieb, moderne Technik sei erstaunlich, aber die alten Tage fühlten sich anders an. Jemand anderes wollte sofort Windows 2.11, OS/2 und BBC-Micro-Zeiten neu erleben und versprach, den Torrent dauerhaft zu seeden. Das ist die beste Art von Retrocomputing, weil man mit den Systemen wirklich herumspielen kann.

Genau deshalb passte der Proxmox-Winkel so gut. Proxmox-Nutzer verwandeln Server ohnehin schon in Spielplätze für alte, seltsame, nützliche und zum Scheitern verurteilte Dinge. Ein Museum aus Betriebssystemen auf derselben Plattform laufen zu lassen, die auch heutige Dienste hostet, fühlt sich wie die homelab-hafteste Sache überhaupt an. Es ist auch von Natur aus komisch. Ein Kommentator fand die ganze Sache urkomisch, und er hatte recht: Virtualisierung in Emulation in Virtualisierung, nur damit jemand ein totes Betriebssystem besuchen kann wie ein konserviertes Insekt in Bernstein.

Die einfache Antwort war qm importdisk

Die praktische Antwort kam schnell: qm importdisk kann VDI-Dateien nativ verarbeiten. Das ist die Art Kommentar, die zu kurz klingt, bis man merkt, dass sie im Grunde die ganze Tür öffnet. Man erstellt eine leere VM in Proxmox, importiert die .vdi in den Ziel-Storage, hängt sie als Disk ein und beginnt dann, sich mit der Seltsamkeit auseinanderzusetzen, die folgt. Jemand anderes schlug eine Konvertierung nach qcow2 vor, was ebenfalls ein natürlicher Reflex ist, sobald Proxmox, QEMU und importierte Appliance-Images im selben Raum landen.

Der Thread machte aber klar, dass „lässt sich importieren" und „läuft schmerzfrei" zwei verschiedene Versprechen sind. Ein Nutzer stieß an eine Storage-Wand, weil ein Gast-Image eine virtuelle Größe von 5 TB meldete, obwohl die tatsächliche Disk-Nutzung viel kleiner war. ZFS versuchte, diesen Import zu behandeln, als bräuchte er die riesige Allokation, und Proxmox warf einen Out-of-Space-Fehler, obwohl mehrere Terabyte frei waren. Das ist der lästige Teil an Appliance-Images: Sie bringen Annahmen aus der Umgebung mit, aus der sie stammen, und Proxmox tut nicht immer so, als seien diese Annahmen vernünftig.

Die Netzwerkwarnung war der eigentliche Plot-Twist

Der wichtigste Kommentar war eine öffentliche Warnung mit Horrorfilm-Timing. Ein Nutzer konvertierte die Virtual-OS-Museum-Appliance in eine Proxmox-VM und brückte ihre NIC direkt an das Haupt-LAN. Etwa 30 Minuten lang war alles wunderbar. Dann fing das interne emulierte Netzwerk des Museums an, Chaos zu verursachen. Es umfasste MAME-Netplay-Links, Hercules-Mainframe-Schnittstellen, einen VDE-Virtual-Switch, der sich selbst 172.16.0.1 zuwies, sowie eine interne Bridge. Sobald es dem echten LAN ausgesetzt war, begann es, ARP für die Hälfte des DHCP-Pools und sogar für die Gateway-IP zu beantworten.

So ein Fehler führt zu der Art von Ausfall, bei der man erst die eigene Dockingstation, das WLAN, die Identitätsplattform, den Mac, die Switches und vielleicht den Mond verdächtigt, bevor man merkt, dass sich das Retro-OS-Museum als eigenes Netzwerk ausgibt. Der Nutzer verbrachte zwei Tage damit, die falschen Verdächtigen zu jagen, bevor er die Spur zur VM zurückverfolgte. Sein schneller Fix war einfach: die Proxmox-NIC der VM löschen. Sein besserer Plan für die Zukunft war noch klarer, nämlich ein VLAN zu nutzen, falls er jemals wieder mit den historischen Netzwerkfunktionen spielen will.

Nostalgie sollte Ihr Haupt-LAN nicht berühren

Diese Warnung teilte die Diskussion auf gesunde Weise. Das Museum ist großartig, sollte aber wie ein in sich geschlossenes Lab behandelt werden und nicht wie eine vertrauenswürdige Appliance. Ein Kommentator schrieb, er werde nach der Warnung vorsichtig vorgehen. Ein anderer meinte, das erkläre wahrscheinlich, warum sein Desktop ständig die Verbindung verlor, während er in QEMU damit herumspielte. Das ist der Moment, in dem der Thread von „Wie bringe ich das zum Booten?" zu „Wie halte ich dieses niedliche Monster eingesperrt?" wechselte.

Die Antwort ist langweilig und richtig: Nicht direkt an das Hauptnetzwerk brücken, es sei denn, man weiß genau, was es tut. Ohne NIC laufen lassen, auf eine isolierte Bridge setzen oder ihm ein dediziertes VLAN geben, das den Rest des Subnetzes nicht vergiften kann. Wer alte Netzwerk-Stacks erkunden möchte, soll das gerne tun, das gehört zum Spaß dazu. Altes Netzwerkverhalten in moderner Infrastruktur kann trotzdem überraschend aggressiv sein. Ein Museumsexponat ist charmant, bis es anfängt, für Ihr Gateway ARP zu beantworten.

Nesting könnte der vernünftigere Weg sein

Manche Kommentatoren stellten infrage, ob es sich lohnt, Nesting zu vermeiden. Jemand fragte, warum man nicht einfach eine Linux-VM erstellt und den Installer darin laufen lässt. Der Threadstarter sagte, er wolle das zusätzliche Nesting lieber vermeiden, weil der Installer seine eigene virtuelle Umgebung erzeuge. Das ist verständlich, denn jeder, der Proxmox betreibt, entwickelt irgendwann eine leichte Allergie gegen unnötige Schichten. Ein anderer Kommentator brachte allerdings einen starken Punkt: Bei alten Betriebssystemen fragt sich, welches Problem man durch den Verzicht auf Nesting eigentlich vermeidet. Die Performance wird immer noch absurd schneller sein als auf Originalhardware, und die Umgebung ist ohnehin schon in sich geschlossen.

Dieses Argument ist schwer zu schlagen, denn die flachste Architektur ist nicht immer die sauberste. Wenn das Museum als Linux-VM konzipiert wurde, die emulierte Systeme startet, ist es vielleicht der schmerzärmste Weg, es einfach so zu belassen. Ein Nutzer tat genau das, indem er den Installer in einer Debian-VM unter Proxmox laufen ließ. Die verschachtelte VM ließ sich problemlos erstellen, allerdings hatte die VNC-Konsole ein Mausproblem. Er umging es, indem er scripts/run_qemu so bearbeitete, dass QEMUs eingebautes VNC-Display statt des SDL-Display-Pfads genutzt wurde. Das war unschön, aber machbar.

Die Storage-Wahl ist wichtiger als gedacht

Das vollständige Museum ist nicht klein. Ein Kommentar erklärte, die Vollversion sei rund 170 GB groß und enthalte den Installer plus alle Gast-VMs, während die Lite-Version rund 14 GB groß sei und Gast-VMs bei Bedarf nachlade. Das ist relevant, weil der „einfach importieren"-Ansatz bei großen Sparse-Images und ZFS schnell zu einem Storage-Buchhaltungschaos werden kann. Wer das zu Hause ausprobieren möchte, fährt mit der Lite-Version vielleicht klüger. Erst das Museum beweisen lassen, dass es sich benimmt, bevor man einen riesigen Teil des eigenen Pools der Retrocomputing-Archäologie spendet.

Der beste Rat des Threads war deshalb eine Haltung: experimentieren, aber isolieren. Importieren Sie die VDI, wenn Sie wollen, konvertieren Sie nach qcow2, wenn das zum eigenen Storage passt, probieren Sie eine Debian-VM mit dem Installer darin, wenn Nesting akzeptabel ist, und nutzen Sie den eingebauten VNC-Workaround, wenn die Konsole zickt. Egal welchen Weg Sie wählen: Lassen Sie das Museum nicht wie eine normale Appliance auf der Hauptbridge sitzen, denn normal ist daran nichts, und genau das macht Spaß und Gefahr zugleich aus.

Die Zeitmaschine braucht eine Sandbox

Virtual OS Museum ist genau die Art von Projekt, das Infrastruktur-Menschen grinsen lässt. Es ist lehrreich, nostalgisch, technisch seltsam und gerade unpraktisch genug, um unwiderstehlich zu sein. Es lässt jemanden, der einst in VAX/VMS lebte, diesen alten Funken wieder spüren, es lässt andere sich an BBC-Micro-Netzwerke und OS/2-Träume erinnern, und es macht aus Proxmox eine Retrocomputing-Ausstellungshalle. Das ist wunderschön.

Die Lektion des Threads ist trotzdem unverblümt: Auch eine Zeitmaschine braucht eine Sandbox. Nutzen Sie ruhig qm importdisk, konvertieren Sie Formate, testen Sie Nesting, kämpfen Sie mit VNC, wählen Sie Lite oder Full, und genießen Sie das Museum. Brücken Sie es nur nicht direkt in das Netzwerk, das Ihr Zuhause betreibt. Die alten Systeme mögen Museumsstücke sein, aber das Netzwerkchaos, das sie entfesseln können, ist sehr modern. Das richtige Setup ist isoliert, reversibel und wird mit derselben Vorsicht behandelt, die man jedem seltsamen Appliance-Image entgegenbringt, das man nicht selbst gebaut hat. Retrocomputing sollte Erinnerungen wecken und nicht Ihr Gateway lahmlegen.