Se le rompió el portátil: convirtió Proxmox en estación de trabajo y arrancó macOS

Puedes usar Proxmox VE como anfitrión para un escritorio diario asignando una GPU física a una máquina virtual, pero esta configuración implica concesiones en la visualización y la recuperación. Un administrador sustituyó un portátil averiado por un sistema invitado con Arch Linux mientras mantenía además una VM con macOS Tahoe para tareas de CI/CD.

Los detalles importan más que la anécdota: una pantalla negra en NoVNC de Proxmox no significa necesariamente que el sistema invitado haya fallado, el invitado con macOS no era el escritorio gráfico principal del usuario y el almacenamiento base consistía en una única unidad NVMe de 512 GB.

¿Puede Proxmox sustituir un ordenador o portátil averiado?

Un host de Proxmox puede ejecutar una VM de escritorio con passthrough de GPU, pero no recrea la movilidad ni la vía de recuperación de un portátil convencional.

El atractivo surge de un fallo cotidiano. Un portátil murió y su dueño no contempló sustituirlo por otro portátil. En su lugar, puso el servidor Proxmox existente a funcionar como estación de trabajo. Arch Linux pasó a ser el entorno de escritorio operativo; el passthrough de GPU permitió a la máquina virtual comunicarse de forma directa con el hardware gráfico. Al mismo tiempo, macOS Tahoe continuó disponible como un sistema invitado independiente.

Se trata de una forma muy flexible de responder ante un equipo averiado. Un equipo de sobremesa convencional suele obligar al usuario a elegir un sistema operativo al arrancar, o bien a ejecutar un sistema secundario mediante virtualización de escritorio común. Aquí, el hipervisor mantiene el control. Cada invitado cumple una función clara y ninguno necesita convertirse en el sistema operativo del host. Para quien ya administra máquinas virtuales, la idea no resulta extraña. Para quien depende a diario de un escritorio predecible, supone un salto mucho mayor.

Un comentarista que acababa de reinstalar Proxmox tras cambiar de SSD quería añadir VMs de escritorio con Linux y Windows. Otro tenía un portátil Tuxedo estropeado que tal vez acabaría siendo un servidor. Ninguno de los dos casos demuestra que los escritorios virtualizados sean una opción predeterminada mejor; ambos muestran con qué facilidad quienes gestionan un homelab reutilizan el hardware.

No obstante, esta estructura cambia lo que sucede cuando el host necesita mantenimiento. Reiniciar Proxmox puede interrumpir la sesión de trabajo además de los servicios que aloja. Un fallo de almacenamiento ya no afecta únicamente a un servidor; también puede dejar al usuario sin su escritorio. La comodidad de consolidar máquinas acarrea una nueva dependencia. El problema del portátil puede estar resuelto, pero el impacto potencial de un fallo del host es mucho mayor.

¿Por qué NoVNC muestra una pantalla negra con passthrough de GPU?

Tras un passthrough completo de GPU, la salida de vídeo del sistema invitado suele aparecer en el conector físico de la tarjeta en lugar de en la consola emulada NoVNC de Proxmox.

El passthrough de GPU parece sencillo hasta que alguien abre la consola en el navegador de Proxmox y no ve nada. Un participante pidió un tutorial, recordando una pantalla en negro de un despliegue anterior. Otro asumió que usar una VM de escritorio requeriría siempre un segundo ordenador para acceder a ella. Esa suposición era comprensible, y las respuestas aclararon la diferencia.

Para los conceptos básicos de asignación de dispositivos, consulta este caso de resolución de problemas con passthrough de GPU, que explica por qué los ajustes de firmware y pantalla del invitado son determinantes.

Con PCIe passthrough, un sistema invitado toma el control de una tarjeta gráfica física. Su señal de vídeo puede enviarse directamente a un monitor conectado a esa tarjeta, en vez de mostrarse dentro del visor integrado del hipervisor. Tal como explica la documentación de PCI passthrough en Proxmox, el framebuffer de la GPU cedida no se muestra mediante NoVNC ni SPICE. Por tanto, una consola en negro no demuestra por sí sola que el sistema invitado no haya arrancado.

Ese detalle resulta clave porque los dos métodos de acceso ofrecen experiencias muy distintas. Una VM controlada por escritorio remoto sigue siendo útil, pero el usuario necesita un dispositivo cliente y una conexión de red operativa. Una VM que envía señal a un monitor físico conectado se percibe de forma mucho más cercana a una estación de trabajo convencional. Un usuario describió cómo conectó una pantalla directamente a la GPU, mientras que otro comentó que su propia estación con Proxmox utiliza una tarjeta gráfica económica para el host y una RTX 3060 para jugar. También señaló que una configuración con una sola GPU puede funcionar, aunque suele dejar al host sin su salida gráfica local habitual una vez que el invitado toma el control.

El passthrough sigue requiriendo hardware compatible, configuración de IOMMU, controladores en el sistema invitado y un plan para asignar la GPU. Por lo general, el host no puede utilizar una tarjeta gráfica mientras esté asignada de forma exclusiva a una VM. Los dispositivos de entrada y el acceso de recuperación también exigen planificación.

La corrección clave: una pantalla conectada físicamente puede dar servicio directo al sistema invitado con passthrough. Un servidor puede convertirse en el ordenador sobre el escritorio incluso cuando la consola web de Proxmox se vea vacía.

Queda un inconveniente: si algo falla con el passthrough, la vía de rescate más sencilla suele ser un dispositivo de gestión independiente o una consola alternativa. Un experimento pierde su gracia cuando la máquina que necesitas para reparar tu estación de trabajo es tu propia estación de trabajo. Quien dependa de un entorno así debe planificar cómo recuperar el control antes de que la configuración gráfica se rompa.

¿Puede funcionar macOS Tahoe junto a una VM con Arch Linux?

La instalación descrita ejecutaba macOS Tahoe como una VM separada para CI/CD, aunque las restricciones de licencia y hardware de Apple continúan siendo una limitación relevante.

El escritorio con Arch explicaba cómo su dueño podía seguir trabajando. El sistema invitado con macOS Tahoe despertó una curiosidad distinta. Varias personas querían saber cómo se había instalado. Una de ellas había probado Tahoe sin éxito. A otra le sorprendía que macOS pudiera funcionar en una VM de Proxmox. Las preguntas giraron en torno a los servicios de Apple, la aceleración gráfica y si una futura versión de macOS dejaría todo el método obsoleto.

El autor señaló una guía externa de instalación de macOS en Proxmox que, según indicó, le había funcionado. También mencionó ajustes posteriores para hacer funcionar Apple ID, incluyendo parches y una herramienta de configuración auxiliar. Se trata de observaciones de una configuración concreta y no de una receta probada para cualquier host. Hasta el título de la guía llama al sistema «Tahoma», cuando el nombre oficial de la versión de Apple es Tahoe. Solo por eso conviene revisar versiones y comandos con cuidado en lugar de copiar una secuencia de instalación a ciegas.

Llegó una aclaración útil cuando alguien preguntó por el rendimiento de Tahoe. Otro participante comentó que su propio invitado, con una tarjeta AMD Radeon RX 6800 XT, 64 GB de RAM y 16 núcleos, resultaba utilizable pero podría ir más fluido. El dueño original respondió que su GTX 1650 no era compatible con el gestor de ventanas de macOS. De forma determinante, no dependía de ese sistema como un escritorio refinado: la VM de macOS existía para pipelines de CI/CD. Dicho de otro modo, «funciona» y «sirve como buena estación Mac para el día a día» nunca fueron la misma afirmación.

Un usuario preguntó por iMessage; otro señaló que sus VMs con Sequoia y Tahoe conectaban con iCloud sin problemas. El propietario necesitó ajustes adicionales para Apple ID. Estas experiencias no garantizan la compatibilidad de los servicios de Apple entre distintos hosts ni ante futuras actualizaciones.

Existe un límite más fundamental. La licencia de software de Apple macOS Tahoe permite usos específicos de virtualización de macOS en ordenadores de la marca Apple. Por tanto, lograr que macOS arranque en un host Proxmox genérico que no sea de Apple dista mucho de tener autorización según la licencia estándar de Apple para ejecutarlo allí. Quienes consideren macOS para pipelines de compilación comerciales deben revisar la licencia y usar infraestructura conforme a la norma, en lugar de tomar una experiencia entusiasta como un visto bueno legal.

La comunidad también percibió el fin de ciclo para la compatibilidad con Intel. Al usuario le preocupaba que Tahoe supusiera el final del camino para su instalación, y Apple ha confirmado que Tahoe es la última versión principal de macOS para equipos Mac con Intel. Eso no demuestra que un invitado actual con Tahoe vaya a dejar de funcionar, pero sí implica que una solución orientada a Intel tiene una vía de actualización más limitada de lo que sugiere una captura de pantalla.

¿Conviene confiar en un único host de Proxmox como estación de trabajo?

Emplea esta configuración solo si cuentas con una vía de gestión independiente, copias de seguridad y una respuesta clara ante fallos del host o del almacenamiento.

Hacia el final del debate, la conversación pasó de una virtualización llamativa a un tema menos vistoso: el almacenamiento. El usuario comentó que todo residía en una unidad NVMe de 512 GB comprada cuando montó el equipo unos cuatro años atrás. Bromeó con que sustituir un disco estropeado o memoria RAM defectuosa sería un golpe económico duro. La broma funcionó porque el riesgo era lo bastante evidente como para admitirlo.

Una estación de trabajo también necesita un plan de backup y recuperación probado, sobre todo si el host y el escritorio comparten un único dispositivo de almacenamiento.

Contar con un único disco no equivale automáticamente a perder datos, y en la conversación no se aclaró si existían copias de seguridad. Aun así, una VM de escritorio, un entorno de compilación y cualquier otro servicio que comparta ese host heredan el mismo punto físico de fallo. Una snapshot en el mismo disco no protege contra la pérdida de la unidad. Un diseño sensato separa el estado recuperable de las VMs de los archivos de trabajo insustituibles, exporta copias de seguridad a otro almacenamiento y comprueba si un equipo de sustitución puede arrancar los sistemas invitados.

No se aportaron pruebas de rendimiento comparativas que demuestren que esta estación supere a una instalación nativa de Arch, ni un inventario completo de hardware, ni pruebas de que la VM con macOS sobreviva a la próxima transición de plataforma. Fue la configuración funcional de un usuario, respaldada por las experiencias de varios administradores más.

Eso basta para que la historia merezca ser contada. Un portátil murió. Ya había un servidor allí. Una VM con Arch Linux asumió el papel de escritorio, mientras que un invitado con macOS permaneció disponible para una tarea de desarrollo concreta. Quienes pensaban que el passthrough de GPU implicaba quedarse mirando una consola negra en el navegador aprendieron que la pantalla física era la clave. Otros vieron un sistema ingenioso con demasiadas responsabilidades concentradas en una sola máquina.

Ambas reacciones tienen sentido. Proxmox permite tratar el hardware como un conjunto de capacidades en lugar de como un ordenador atado a una identidad fija. Esa flexibilidad puede salvar una jornada de trabajo y prolongar la vida útil del equipo. También hace que planificar la recuperación sea más importante, porque la máquina que ejecuta todo puede interrumpirlo todo.

La conclusión no es que todo el mundo deba sustituir un portátil por un hipervisor. Es que una estación de trabajo improvisada puede resultar verdaderamente práctica, siempre que quien la use entienda qué partes tienen soporte, cuáles son experimentos y qué ocurrirá cuando falle el siguiente componente.

Yo mantendría el escritorio Linux como invitado principal solo si la salida de pantalla local y la gestión remota del host se hubieran probado por separado. Para un trabajo dependiente de un portátil o para aplicaciones críticas, elegiría una estación de trabajo convencional y dejaría Proxmox para alojar los servicios adicionales.