Virtual OS Museum on Proxmox Is Retro Heaven With a Network Gremlin Hiding Inside

# Virtual OS Museum on Proxmox Is Retro Heaven With a Network Gremlin Hiding Inside The idea is irresistible: take the Virtual OS Museum, stuff it into a Proxmox VM, and suddenly your modern hypervisor becomes a time machine for VAX/VMS, OS/2, Windows 2.11, BBC Micro memories, and all the weird old systems that shaped computing before everything became rounded rectangles and subscription logins. The original question sounded simple enough: has anyone gotten it running as a Proxmox VE VM, and how do you get a `.vdi` to boot on PVE? But the thread quickly turned into something better: a mix of nostalgia, practical conversion tips, nested-VM philosophy, and one terrifying warning about poisoning an entire LAN by accident. ## The Museum Hit a Nerve The emotional pull was obvious. The poster had already run the museum on a Windows 11 PC and was amazed to boot into VAX/VMS, the first system they’d worked on professionally. That’s not just tinkering. That’s opening a trapdoor in your own memory. Another person said modern tech is amazing, but the old days hit different. Someone else immediately wanted to relive Windows 2.11, OS/2, and BBC Micro days, promising to keep the torrent permanently shared. This is the best kind of retrocomputing: not just screenshots, but systems you can poke. That’s why the Proxmox angle made sense. Proxmox users already turn servers into playgrounds for old, weird, useful, and doomed things. Running a museum of operating systems inside the same platform that hosts today’s services feels like the most homelab thing possible. It’s also inherently funny. One commenter said there was something hilarious about the whole thing, and they were right. It’s virtualization inside emulation inside virtualization, all so someone can visit a dead OS like a preserved insect in amber. ## The Easy Answer Was `qm importdisk` The practical answer arrived fast: `qm importdisk` can handle VDI files natively. That’s the kind of comment that sounds too short until you realize it’s basically the whole door opening. You create a VM shell in Proxmox, import the `.vdi` into the target storage, attach it as a disk, and then start dealing with the weirdness that follows. Someone else suggested converting to `qcow2`, which is also a natural instinct when Proxmox, QEMU, and imported appliance images enter the same room. But the thread made it clear that “can import” and “will be painless” are different promises. One user hit a storage wall because a guest image reported a 5TB virtual size even though its actual disk usage was much smaller. ZFS tried to treat that import like it needed the giant allocation, and Proxmox threw an out-of-space error despite several terabytes free. That’s the annoying part of appliance images: they carry assumptions from the environment they came from, and Proxmox doesn’t always politely pretend those assumptions are sane. ## The Network Warning Was the Whole Plot Twist The most important comment wasn’t about disk conversion. It was a public service announcement with horror-movie timing. One user converted the Virtual OS Museum appliance into a Proxmox VM and bridged its NIC straight to the main LAN. For about 30 minutes, everything was wonderful. Then the museum’s internal emulated network started causing chaos. It included MAME netplay links, Hercules mainframe interfaces, a VDE virtual switch assigning itself `172.16.0.1`, and an internal bridge. Once exposed to the real LAN, it began answering ARP for half the DHCP pool and even the gateway IP. That is not a small oops. That’s the kind of failure that makes you accuse your dock, your Wi-Fi, your identity platform, your Mac, your switches, and maybe the moon before you realize the retro OS museum is impersonating your network. The user burned two days chasing the wrong suspects before tracing it back to the VM. Their quick fix was simple: delete the VM’s Proxmox NIC. Their better future plan was even clearer: use a VLAN if they ever want to play with the historic networking features. ## Nostalgia Should Not Touch Your Main LAN That warning split the conversation in the healthiest way. The museum is amazing, but it should be treated like a self-contained lab, not a trusted appliance. One commenter said they’d tread cautiously after reading the warning. Another said it probably explained why their desktop kept losing connection while they were messing with it in QEMU. That’s the moment the thread shifted from “how do I boot this?” to “how do I keep this adorable monster contained?” The answer is boring and correct: don’t bridge it directly to your main network unless you know exactly what it’s doing. Run it without a NIC, put it on an isolated bridge, or give it a dedicated VLAN that can’t poison the rest of your subnet. If you want to explore old networking stacks, great. That’s part of the fun. But old network behavior inside modern infrastructure can be surprisingly aggressive. A museum exhibit is charming until it starts answering ARP for your gateway. ## Nesting Might Be the Saner Path Some commenters questioned whether avoiding nesting was worth the pain. One person asked why not just create a Linux VM and run the installer inside it. The poster said they’d rather avoid the extra nesting because the installer creates its own virtual environment. That’s understandable. Everyone who runs Proxmox eventually develops a mild allergy to unnecessary layers. But another commenter made a strong point: for old operating systems, what problem are you avoiding by not nesting? Performance will still be absurdly faster than original hardware, and the environment is already self-contained. That argument is hard to beat. Sometimes the cleanest architecture is not the flattest one. If the museum was designed as a Linux VM that launches emulated systems, maybe letting it stay that way is the least painful option. One person did exactly that by running the installer in a Debian VM under Proxmox. It created the nested VM fine, though the VNC console had a mouse issue. They worked around it by editing `scripts/run_qemu` to use QEMU’s built-in VNC display instead of the SDL display path. Ugly, but workable. ## The Storage Choice Matters More Than Expected The full museum is not tiny. One comment explained that the full version is around 170GB and includes the installer plus all guest VMs, while the lite version is around 14GB and downloads guest VMs on demand. That matters because the “just import it” approach can turn into a storage accounting mess, especially with large sparse images and ZFS. For anyone trying this at home, the lite version may be the smarter first move. Let the museum prove it behaves before donating a giant chunk of your pool to retrocomputing archaeology. That’s also why the thread’s best advice wasn’t one magic command. It was a posture: experiment, but isolate. Import VDI if you want. Convert to `qcow2` if that fits your storage. Try a Debian VM and run the installer if nesting is acceptable. Use the built-in VNC workaround if the console gets weird. But whatever path you take, don’t let the museum sit on your main bridge like a normal appliance. It is not normal. That’s the fun part and the danger. ## The Time Machine Needs a Sandbox Virtual OS Museum is exactly the kind of project that makes infrastructure people grin. It’s educational, nostalgic, technically strange, and just impractical enough to be irresistible. It lets someone who once lived in VAX/VMS feel that old spark again. It makes other people remember BBC Micro networks and OS/2 dreams. It turns Proxmox into a retrocomputing exhibit hall. That’s beautiful. But the thread’s lesson is blunt: a time machine still needs a sandbox. Use `qm importdisk`, sure. Convert formats, test nesting, fight VNC, choose lite or full, and enjoy the museum. Just don’t bridge it straight into the network that runs your house. The old systems may be museum pieces, but the network chaos they can unleash is very modern. The right setup is isolated, reversible, and treated with the same caution you’d give any weird appliance image you didn’t build yourself. Retrocomputing should bring back memories, not take down your gateway.