Virtual OS Museum en Proxmox: un paraíso retro con un gremlin de red escondido dentro

La idea es irresistible: coger el Virtual OS Museum, meterlo en una VM de Proxmox y, de repente, tu hipervisor moderno se convierte en una máquina del tiempo para VAX/VMS, OS/2, Windows 2.11, recuerdos de la BBC Micro y todos esos sistemas antiguos y raros que dieron forma a la informática antes de que todo se volviera rectángulos redondeados e inicios de sesión con suscripción. La pregunta original parecía bastante sencilla: ¿alguien ha conseguido ejecutarlo como VM de Proxmox VE, y cómo se hace arrancar un .vdi en PVE? El hilo se convirtió rápidamente en algo mejor, una mezcla de nostalgia, consejos prácticos de conversión, filosofía sobre VMs anidadas y un aviso aterrador sobre envenenar una LAN entera por accidente.

El museo tocó una fibra sensible

El tirón emocional era evidente. El autor de la pregunta ya había ejecutado el museo en un PC con Windows 11 y le había asombrado arrancar VAX/VMS, el primer sistema con el que trabajó profesionalmente. Es como abrir una trampilla en tu propia memoria. Otra persona dijo que la tecnología moderna es increíble, pero que los viejos tiempos tenían otra cosa. Alguien más quiso revivir de inmediato Windows 2.11, OS/2 y la época de la BBC Micro, y prometió mantener el torrent compartido para siempre. Es la mejor clase de retroinformática, con sistemas que de verdad puedes toquetear en lugar de capturas de pantalla.

Por eso el enfoque con Proxmox tenía sentido. Los usuarios de Proxmox ya convierten sus servidores en patios de recreo para cosas viejas, raras, útiles y condenadas. Ejecutar un museo de sistemas operativos dentro de la misma plataforma que aloja los servicios de hoy es de lo más homelab que existe. También tiene su gracia. Un comentarista dijo que todo aquello tenía algo de hilarante, y tenía razón. Es virtualización dentro de emulación dentro de virtualización, todo para que alguien pueda visitar un sistema operativo muerto como un insecto conservado en ámbar.

La respuesta fácil era qm importdisk

La respuesta práctica llegó rápido: qm importdisk puede manejar archivos VDI de forma nativa. Ese tipo de comentario parece demasiado corto hasta que te das cuenta de que básicamente abre toda la puerta. Creas el esqueleto de una VM en Proxmox, importas el .vdi al almacenamiento de destino, lo conectas como disco y luego empiezas a lidiar con las rarezas que vengan. Otra persona sugirió convertirlo a qcow2, que también es un instinto natural cuando Proxmox, QEMU e imágenes de appliances importadas coinciden en la misma sala.

Aun así, el hilo dejó claro que "se puede importar" y "va a ser indoloro" son promesas distintas. Un usuario se topó con un muro de almacenamiento porque una imagen de invitado declaraba un tamaño virtual de 5TB aunque su uso real de disco era mucho menor. ZFS intentó tratar esa importación como si necesitara la asignación gigante, y Proxmox lanzó un error de falta de espacio pese a tener varios terabytes libres. Esa es la parte molesta de las imágenes de appliances: arrastran suposiciones del entorno del que vienen, y Proxmox no siempre finge con educación que esas suposiciones son sensatas.

El aviso sobre la red fue el gran giro de guion

El comentario más importante fue un aviso de servicio público con ritmo de película de terror. Un usuario convirtió el appliance del Virtual OS Museum en una VM de Proxmox y conectó su NIC en bridge directamente a la LAN principal. Durante unos 30 minutos, todo fue maravilloso. Luego la red emulada interna del museo empezó a sembrar el caos. Incluía enlaces de netplay de MAME, interfaces de mainframe de Hercules, un switch virtual VDE que se asignaba a sí mismo 172.16.0.1 y un bridge interno. Una vez expuesto a la LAN real, empezó a responder ARP por la mitad del pool de DHCP e incluso por la IP de la puerta de enlace.

Ese tipo de fallo te hace acusar a tu dock, a tu wifi, a tu plataforma de identidad, a tu Mac, a tus switches y quizá a la luna antes de darte cuenta de que el museo de sistemas operativos retro está suplantando a tu red. El usuario perdió dos días persiguiendo a los sospechosos equivocados antes de dar con la VM. Su arreglo rápido fue sencillo: borrar la NIC de Proxmox de la VM. Su plan para el futuro fue aún más claro: usar una VLAN si alguna vez quiere jugar con las funciones de red históricas.

La nostalgia no debería tocar tu LAN principal

Ese aviso dividió la conversación de la forma más sana. El museo es increíble, pero hay que tratarlo como un laboratorio aislado y no como un appliance de confianza. Un comentarista dijo que iría con cuidado después de leer el aviso. Otro dijo que eso probablemente explicaba por qué su equipo de escritorio no dejaba de perder la conexión mientras trasteaba con él en QEMU. En ese punto el hilo pasó de "¿cómo arranco esto?" a "¿cómo mantengo encerrado a este monstruo adorable?".

La respuesta es aburrida y correcta: no lo conectes en bridge directamente a tu red principal salvo que sepas exactamente qué está haciendo. Ejecútalo sin NIC, ponlo en un bridge aislado o dale una VLAN dedicada que no pueda envenenar el resto de tu subred. Si quieres explorar pilas de red antiguas, estupendo, es parte de la diversión. Pero el comportamiento de red antiguo dentro de una infraestructura moderna puede ser sorprendentemente agresivo. Una pieza de museo tiene su encanto hasta que empieza a responder ARP por tu puerta de enlace.

Anidar puede ser el camino más sensato

Algunos comentaristas se preguntaron si evitar el anidamiento compensaba el esfuerzo. Una persona preguntó por qué no crear simplemente una VM Linux y ejecutar el instalador dentro. El autor dijo que prefería evitar el anidamiento adicional porque el instalador crea su propio entorno virtual. Es comprensible, ya que todo el que usa Proxmox acaba desarrollando una leve alergia a las capas innecesarias. Pero otro comentarista hizo una observación sólida: con sistemas operativos antiguos, ¿qué problema te ahorras al no anidar? El rendimiento seguirá siendo absurdamente superior al del hardware original, y el entorno ya está aislado.

Ese argumento es difícil de rebatir. A veces la arquitectura más plana no es la más limpia. Si el museo se diseñó como una VM Linux que lanza sistemas emulados, quizá dejarlo así sea la opción menos dolorosa. Una persona hizo exactamente eso ejecutando el instalador en una VM Debian bajo Proxmox. Creó la VM anidada sin problemas, aunque la consola VNC tenía un fallo con el ratón. Lo resolvió editando scripts/run_qemu para usar la pantalla VNC integrada de QEMU en lugar de la ruta de visualización SDL. Feo, pero funciona.

La elección de almacenamiento importa más de lo esperado

El museo completo no es pequeño. Un comentario explicó que la versión completa ocupa unos 170GB e incluye el instalador más todas las VMs invitadas, mientras que la versión lite ocupa unos 14GB y descarga las VMs invitadas bajo demanda. Eso importa porque el enfoque de "importarlo y ya" puede convertirse en un lío de contabilidad de almacenamiento, sobre todo con imágenes dispersas grandes y ZFS. Para quien lo pruebe en casa, la versión lite puede ser el primer paso más inteligente. Deja que el museo demuestre que se porta bien antes de donar un buen trozo de tu pool a la arqueología retroinformática.

Por eso el mejor consejo del hilo fue más una actitud que un comando mágico: experimenta, pero aísla. Importa el VDI si quieres. Conviértelo a qcow2 si encaja con tu almacenamiento. Prueba una VM Debian y ejecuta el instalador si el anidamiento te parece aceptable. Usa el apaño de la VNC integrada si la consola se pone rara. Elijas el camino que elijas, no dejes el museo en tu bridge principal como si fuera un appliance normal. No lo es, y eso es a la vez lo divertido y lo peligroso.

La máquina del tiempo necesita un entorno aislado

Virtual OS Museum es justo el tipo de proyecto que hace sonreír a la gente de infraestructura. Es educativo, nostálgico, técnicamente extraño y lo bastante poco práctico como para ser irresistible. Permite que alguien que vivió en VAX/VMS vuelva a sentir aquella chispa, hace que otros recuerden las redes de la BBC Micro y los sueños de OS/2, y convierte Proxmox en una sala de exposición de retroinformática. Es precioso.

Pero la lección del hilo es tajante: una máquina del tiempo sigue necesitando un entorno aislado. Usa qm importdisk, claro. Convierte formatos, prueba el anidamiento, pelea con la VNC, elige la versión lite o la completa y disfruta del museo. Eso sí, no lo conectes en bridge directamente a la red que hace funcionar tu casa. Los sistemas antiguos pueden ser piezas de museo, pero el caos de red que pueden desatar es muy moderno. La configuración correcta está aislada, se puede deshacer y se trata con la misma cautela que darías a cualquier imagen de appliance rara que no hayas construido tú. La retroinformática debería traerte recuerdos y dejar en paz tu puerta de enlace.