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? Aber der Thread entwickelte sich schnell zu etwas Besserem: 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. Das ist nicht nur Basteln. Das ist eine Falltür in die eigene Erinnerung zu öffnen. 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: nicht nur Screenshots, sondern Systeme, mit denen man 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. Es ist 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.

Aber der Thread machte klar: „lässt sich importieren" und „läuft schmerzfrei" sind zwei verschiedene Versprechen. 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 drehte sich nicht um Disk-Konvertierung. Es 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.

Das ist kein kleiner Ausrutscher. Das ist die 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: ein VLAN 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, 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 – gerne. Das gehört zum Spaß dazu. Aber altes Netzwerkverhalten in moderner Infrastruktur kann ü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. Jeder, der Proxmox betreibt, entwickelt irgendwann eine leichte Allergie gegen unnötige Schichten. Aber ein anderer Kommentator brachte einen starken Punkt: Bei alten Betriebssystemen – welches Problem vermeidet man eigentlich durch Verzicht auf Nesting? 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. Manchmal ist nicht die flachste Architektur 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. 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ür den ist die Lite-Version vielleicht der klügere erste Schritt. Erst das Museum beweisen lassen, dass es sich benimmt, bevor man einen riesigen Teil des eigenen Pools der Retrocomputing-Archäologie spendet.

Deshalb war der beste Rat des Threads auch kein einzelner magischer Befehl. Es war eine Haltung: experimentieren, aber isolieren. VDI importieren, wenn man will. Nach qcow2 konvertieren, wenn das zum eigenen Storage passt. Eine Debian-VM ausprobieren und den Installer darin laufen lassen, wenn Nesting akzeptabel ist. Den eingebauten VNC-Workaround nutzen, wenn die Konsole zickt. Aber egal welchen Weg man wählt: das Museum nicht wie eine normale Appliance auf der Hauptbridge sitzen lassen. Es ist nicht normal. Das ist der Spaß daran – und die Gefahr.

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. Es macht aus Proxmox eine Retrocomputing-Ausstellungshalle. Das ist wunderschön.

Aber die Lektion des Threads ist 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, nicht Ihr Gateway lahmlegen.