- El hardware debe soportar IOMMU (VT-d o AMD-Vi) y contar con CPU multinúcleo, suficiente RAM y al menos una GPU dedicada por VM de juegos.
- El passthrough de GPU con vfio en KVM o Xen permite a Windows usar la gráfica física y lograr un rendimiento muy cercano al nativo.
- Asignar correctamente núcleos de CPU, RAM, almacenamiento SSD y herramientas VirtIO es esencial para una experiencia de juego fluida.
- La gestión de USB, audio, vídeo y compartición de datos entre host y VM se resuelve combinando controladoras dedicadas, SAMBA y soluciones como SPICE o Synergy.
Montar una máquina virtual preparada para jugar hoy en día es mucho más viable que hace unos años, pero sigue teniendo sus truquitos. Si vienes de una época en la que jugabas en PC, te alejaste del mundillo y ahora quieres montar una sala de juegos para tus hijos o para ti mismo, es normal que estés un poco perdido entre tanta sigla rara: VT-d, AMD-Vi, IOMMU, passthrough de GPU, KVM, Xen…
La idea de tener dos o más máquinas virtuales Windows en un mismo PC físico, cada una con su propia gráfica dedicada para jugar a Minecraft, Fortnite o títulos de exigencia media, es perfectamente realista siempre que elijas bien el hardware y ajustes el sistema con cabeza. Además, puedes aprovechar para correr una VM extra sin monitor (headless) para utilidades domésticas, copias de seguridad o simplemente para trastear con Linux sin tocar tu instalación principal.
Requisitos básicos de hardware para gaming en máquina virtual
El punto de partida es tener un equipo anfitrión suficientemente potente como para repartir recursos entre varias VMs sin que nadie se quede corto. Esto significa una CPU moderna con varios núcleos, bastante RAM, almacenamiento rápido y, en el caso del gaming, al menos una GPU dedicada por máquina virtual que quieras destinar a juegos.
Para un escenario típico con dos VMs de juegos para niños (por ejemplo, para Minecraft, Fortnite y otros juegos similares) más una VM ligera para servicios, puedes pensar en algo como:
- CPU de 6 a 8 núcleos físicos (12-16 hilos) de última o penúltima generación.
- Un mínimo de 32 GB de RAM si vas a tener dos VMs de Windows encendidas a la vez.
- Al menos dos tarjetas gráficas: una para el sistema anfitrión y otra (o varias) para las VMs.
- Almacenamiento preferiblemente en SSD (M.2 NVMe si es posible) tanto para el host como para las VMs.
Mucha gente se pregunta si con un portátil con CPU i5, GTX 1650 y 16 GB de RAM merece la pena intentar GPU passthrough. Aunque una 1650 mueve bien títulos como Palworld o Fallout 76 en Windows nativo, en portátil el margen es más ajustado: normalmente solo tienes una GPU dedicada, el sistema de refrigeración va al límite y la RAM se queda corta para una VM de juegos más el host. Se puede probar, pero hay que asumir que el rendimiento y la estabilidad pueden no ser ideales.
En una torre de sobremesa, en cambio, la cosa cambia mucho. Puedes montar una configuración parecida a esta, que es un buen ejemplo realista para gaming en VM de gama media:
- CPU: Intel Core i5 o i7 moderno, o un Ryzen 5/7 con soporte de virtualización completa.
- Gráfica integrada o una GPU muy básica para el host Linux.
- Una o dos GPUs dedicadas (por ejemplo, una AMD R7/RX de gama media o una NVIDIA tipo 1660/3060) para asignar a las VMs Windows.
- RAM: mínimo 16 GB si vas justo y solo levantas una VM de juegos, pero 32 GB es lo recomendable para ir cómodo.
- Discos: un M.2 para el sistema anfitrión, un SSD SATA para la VM Windows principal y discos adicionales (HDD o SSD) para datos.
Un ejemplo de máquina que funciona bien para este tipo de montajes sería algo en la línea de un Intel i5 7600K, 16 GB de RAM, placa compatible con IOMMU, gráfica integrada para el host y una GPU AMD dedicada para la VM, con un M.2 para Linux y un SSD para Windows. No es un monstruo de gama alta, pero bien afinado permite jugar en la VM con un rendimiento sorprendentemente cercano a nativo.
Tecnologías clave: VT-d, AMD‑Vi e IOMMU
Para que una máquina virtual pueda usar directamente una tarjeta gráfica física u otros dispositivos PCI, hace falta algo más que potencia bruta. Necesitas que tu CPU y tu placa base soporten las tecnologías de virtualización de entrada/salida adecuadas, que en Intel se llaman VT-d y en AMD se conocen como AMD-Vi (o simplemente IOMMU).
IOMMU (Input-Output Memory Management Unit) es lo que permite asignar dispositivos físicos concretos (como una GPU, un controlador USB, una tarjeta de sonido) a una máquina virtual, aislando su acceso a memoria y evitando que interfiera con el resto del sistema. Sin ello, el passthrough de GPU no es posible, así que es la primera casilla a marcar.
Tu procesador debe soportar VT-d en Intel o AMD-Vi en AMD. Casi todos los modelos modernos lo traen, pero conviene confirmarlo en la hoja de especificaciones del fabricante. Ojo: no es lo mismo que VT-x o AMD-V/SVM; estas últimas se refieren a la virtualización básica de CPU para poder ejecutar VMs de 64 bits, mientras que VT-d/AMD-Vi añaden la parte de redirección de dispositivos de entrada/salida.
En la placa base, tienes que entrar en la BIOS o UEFI y localizar una opción que se llame algo como “VT-d”, “AMD-Vi” o directamente “IOMMU”. Si está desactivada, la activas, guardas cambios y arrancas el sistema anfitrión. En placas relativamente modernas, encontrar este ajuste suele ser sencillo, pero en hardware muy antiguo puede que ni exista, y en ese caso no hay truco posible: si no hay soporte de IOMMU, no podrás hacer passthrough de GPU y tocará cambiar de placa y, posiblemente, de procesador.
Passthrough de GPU (VGA passthrough) para jugar en la VM
El corazón de una configuración de gaming en máquina virtual es la posibilidad de pasar una GPU física a la VM para que Windows la use como si estuviera instalado directamente en el hardware. A esto se le llama VGA o GPU passthrough y es lo que marca la diferencia entre una VM “para trastear” y una VM realmente jugable.
La idea es que el sistema anfitrión (normalmente Linux, ya sea Unraid, una distro con KVM o Xen) se quede con una gráfica, mientras que la VM Windows se lleva otra distinta. Lo ideal es tener dos tarjetas gráficas independientes: por ejemplo, la integrada del procesador para el host y una GPU PCIe dedicada para la VM. Se puede intentar hacer malabares con una sola GPU, pero el proceso se complica mucho y pierde parte de la gracia práctica.
Para hacer el passthrough de la GPU se usan principalmente dos mecanismos bajo Linux:
- pci-stub: el sistema “clásico” o legado, útil en equipos antiguos o sin UEFI moderna.
- vfio: el método actual recomendado para tarjetas PCI-Express, mucho mejor soportado hoy en día.
Con vfio, lo que haces es “secuestrar” la tarjeta gráfica en el arranque del sistema anfitrión para que el driver estándar (por ejemplo, el de Linux) no la toque. Luego, a través de libvirt o del gestor de máquinas (como Virt-Manager) asignas esa GPU a la VM Windows junto con su dispositivo de audio asociado. El resultado es que, dentro de la VM, instalas los drivers de la gráfica igual que en un Windows normal y el sistema la ve como hardware real.
En plataformas como Unraid, gran parte de este proceso está ya integrado en la interfaz gráfica, lo que simplifica bastante la vida. El requisito sigue siendo el mismo: que tu hardware soporte IOMMU y separaciones de grupos PCI adecuadas. Algunas placas agrupan demasiados dispositivos en un solo grupo IOMMU y eso puede complicar el aislamiento de la GPU; en esos casos toca experimentar con parches de ACS o elegir mejor la placa base desde el principio.
Elección del hipervisor: KVM, Xen, VMware y compañía
En el mundo de la virtualización hay distintas formas de organizar las cosas. Para gaming, te interesa principalmente la virtualización de tipo 1, es decir, aquella en la que el hipervisor se ejecuta casi directamente sobre el hardware, reduciendo al mínimo las capas intermedias y acercando el rendimiento al de un sistema instalado “a pelo” en el PC.
Las opciones más habituales para quien monta su propia máquina son:
- VMware ESXi: muy potente en entornos de servidor, pero orientado a montar hosts accesibles desde clientes remotos. Para un PC de casa con todo en la misma caja suele ser más aparatoso de lo que compensa.
- Xen: incluye un hipervisor que se inserta en el propio núcleo y convierte a Linux en una VM más. Es muy seguro y potente, pero algo más complejo de configurar para passthrough y con documentación menos amigable para el usuario doméstico.
- KVM/QEMU: se integra directamente con el kernel de Linux, tiene un enfoque más cercano al del usuario de escritorio y, a día de hoy, un rendimiento muy cercano o incluso superior en algunas tareas respecto a Xen.
Para la mayoría de usuarios que quieren una máquina virtual Windows potente para jugar, KVM suele ser la opción más equilibrada entre rendimiento, facilidad de uso y documentación. Si por lo que sea no te funciona o te gusta cacharrear más, puedes probar Xen como alternativa, pero empezar por KVM es lo habitual.
Sobre KVM se apoyan herramientas como libvirt y Virt-Manager, que proporcionan una interfaz gráfica razonablemente simple para crear, arrancar y tunear VMs, añadirles dispositivos PCI, discos, redes, etc. Es en ese entorno donde harás buena parte de la magia del passthrough sin tener que pelearte solo con comandos.
Optimización general del rendimiento de las máquinas virtuales
Más allá de la GPU, una VM de juegos agradece todas las mejoras de rendimiento típicas de la virtualización. Son ajustes que se aplican tanto si usas VirtualBox, VMware, Hyper‑V o KVM, y que marcan la diferencia entre una experiencia torpe y algo fluido.
Lo primero es comprobar que en tu BIOS/UEFI están habilitadas las extensiones de virtualización de CPU: VT-x en Intel o SVM/AMD‑V en AMD. Sin esto, muchas soluciones ni siquiera arrancan, o lo hacen en modo software con un rendimiento lamentable. En AMD suele venir activo por defecto; en Intel es frecuente que VT-x esté desactivado y tengas que encenderlo a mano, lo que evita los clásicos errores extraños al crear VMs de 64 bits.
Otro punto crítico es cómo gestionas el almacenamiento de las máquinas virtuales. Casi todas las herramientas permiten elegir entre discos de tamaño fijo o dinámico. Es muy tentador usar discos dinámicos que crecen según los vas llenando, pero un disco virtual con tamaño fijo preasignado es más rápido y se fragmenta menos. Si vas justo de espacio no tendrás más remedio que tirar de dinámicos, pero si puedes reservar, merece la pena.
En la misma línea, siempre que sea posible conviene poner las VMs en la unidad de almacenamiento más rápida que tengas. Instalar el host en un SSD M.2 y las VMs en un SSD SATA, por ejemplo, da un salto de rendimiento brutal frente a usar un disco duro mecánico. Y si piensas ejecutar VMs intensivas, evita usar discos externos lentos o conectados por USB 2.0; solo tiene sentido recurrir a unidades externas rápidas (USB 3.1, Thunderbolt) cuando el rendimiento esté a la altura.
Después de instalar el sistema operativo invitado, es recomendable añadir las “guest additions” o herramientas específicas de la solución de virtualización que uses. En VirtualBox se llaman Guest Additions, en VMware son VMware Tools, en KVM/libvirt se usan drivers VirtIO y agentes especiales… Todas estas piezas mejoran el rendimiento de vídeo, red y discos, y permiten una integración más suave entre host e invitado. Además, puedes usar Windows Performance Recorder para detectar cuellos de botella.
Ajuste de CPU y RAM para VMs de gaming
La memoria RAM es uno de los recursos que más condiciona la experiencia en una VM con un sistema completo como Windows. Cada máquina virtual se lleva su porción fija de RAM, que deja de estar disponible para el host, y los juegos modernos no son precisamente ligeros.
Como referencia muy general, para una VM con Windows 10 o 11 destinada a juegos ligeros o medios, deberías pensar en al menos 8 GB de RAM dedicados. Si el host tiene 16 GB en total, esto deja relativamente poco margen para el resto de tareas, así que no podrás tener varias VMs pesadas a la vez. Con 32 GB, ya puedes repartir 10‑12 GB a cada VM de juegos y seguir teniendo holgura en el host.
El procesador también cuenta, y mucho. En una VM de gaming, el CPU hace la mayor parte del trabajo de lógica, física y gestión, así que agradecerá que le asignes varios núcleos. Si tu CPU física tiene, por ejemplo, 8 núcleos/16 hilos, puedes asignar 4 núcleos/8 hilos a una VM de juegos sin dejar al host seco. Lo ideal es ir probando diferentes configuraciones hasta encontrar el punto en que la VM va fluida sin arrastrar el resto del sistema.
Para mejorar todavía más el rendimiento de memoria, existe la opción de usar huge pages estáticas, que consiste en reservar una parte de la RAM del sistema exclusivamente para una VM, mediante páginas de memoria de mayor tamaño. Esta memoria no puede ser usada por Linux aunque la VM esté apagada, pero el rendimiento del invitado mejora, especialmente si la VM Windows va a estar encendida casi siempre. Si solo usas la VM a ratos, suele ser más cómodo dejar que la RAM sea compartida y no complicarse demasiado.
Si te entra el gusanillo de separar al máximo los recursos entre host y VMs, otra vía es usar Xen con asignación física de RAM, donde la separación entre dominios (máquinas) es todavía más rígida. Pero, para la mayoría de usuarios caseros, KVM con huge pages bien configuradas es más que suficiente.
Gráficos, audio y dispositivos de entrada en la VM
Una vez tienes tu GPU en passthrough, toca pulir cómo te conectas visualmente a la VM y cómo gestionas teclado, ratón y sonido. De serie, las VMs suelen incluir una tarjeta gráfica virtual genérica (QXL, Cirrus, etc.) que se usa para ver la consola a través de VNC o SPICE en Virt‑Manager. Cuando añades la GPU física como dispositivo PCI, Windows verá dos gráficas: la virtual y la real.
Para la parte de vídeo tienes varias opciones prácticas:
- Usar dos monitores físicos, uno conectado a la gráfica del host y otro a la GPU de la VM.
- Usar un único monitor con dos entradas (por ejemplo, HDMI y DisplayPort) y cambiar de una a otra según quieras usar Linux o Windows en VM.
- Comprar un switch KVM hardware que te permita alternar entre salidas de GPU y, en algunos modelos, compartir teclado y ratón a la vez.
En el ámbito del teclado y ratón, tienes dos familias de soluciones. Por hardware, puedes usar un switch KVM que comparta periféricos entre host y VM, o simplemente conectar dos juegos de teclado/ratón diferentes, asignando uno de ellos directamente a la VM a través de un controlador USB dedicado. Esta segunda opción es un poco más enrevesada si tu placa solo tiene un controlador USB, pero con una controladora USB PCIe barata puedes separar muy bien ambos mundos.
Por software, puedes quedarte con el acceso mediante SPICE a través de Virt‑Manager, que es lo más sencillo y cómodo a costa de consumir algo más de recursos, o usar herramientas como Synergy, que permiten compartir teclado y ratón entre varias máquinas en la misma red como si tuvieras una especie de escritorio extendido. Synergy funciona muy bien, aunque es software propietario y requiere algo de configuración extra si quieres que arranque como servicio.
El sonido añade otra capa de complicación; si quieres mejorarlo puedes consultar cómo mejorar el sonido de tu PC con FxSound. Si pasas una tarjeta de sonido física directamente a la VM, perderás audio en Linux mientras Windows esté encendido. Si usas la salida de audio de la GPU por HDMI hacia un monitor con altavoces integrados, es bastante cómodo porque imagen y sonido van juntos. En otros casos, una solución rápida es mantener abierta al menos una conexión con la VM mediante SPICE o un cliente similar, que reenvíe el audio aunque la ventana de la consola esté minimizada.
Gestión avanzada de USB y acceso a datos entre host y VM
Los dispositivos USB son otro punto delicado cuando quieres que la VM de juegos tenga acceso directo a mandos, impresoras, relojes deportivos y otros cacharros. Virt‑Manager permite añadir dispositivos USB individuales a la VM a través de la opción “USB Host Device”, igual que harías en VirtualBox: seleccionas el dispositivo, lo conectas a la VM y listo… en teoría.
En la práctica, este enfoque genérico no siempre va fino. Impresoras y algunos dispositivos sencillos suelen funcionar, pero con otros, como ciertos pendrives, dispositivos de almacenamiento o hardware específico, la cosa se complica. Además, en sistemas como Ubuntu, para que el acceso USB desde la VM sea estable a veces conviene desactivar o ajustar APPARMOR, el sistema de perfiles de seguridad. Puedes deshabilitarlo por completo para ir a lo rápido, aunque lo más limpio es configurar sus perfiles para que no interfiera con libvirt y los dispositivos PCI/USB pasados a las VMs.
Una alternativa muy robusta es pasar a la VM un controlador USB físico completo. Usando herramientas como lspci identificas el ID del controlador (por ejemplo, 00:14.0), lo añades a la VM como dispositivo PCI y todos los puertos que cuelgan de esa controladora pasan a ser “propiedad” de la VM. Esto deja a Linux sin esos USB, claro, pero garantiza compatibilidad casi perfecta con lo que conectes ahí.
Si tu placa solo tiene un controlador USB integrado, al pasarle ese controlador entero a la VM te puedes quedar sin ratón o sin algunos puertos críticos en el host. Una solución elegante y barata es comprar una controladora USB PCIe adicional, por pocos euros, con varios puertos traseros y frontales, y dedicarla exclusivamente a la VM Windows. Así conectas en esos puertos los mandos, teclados, ratones o dispositivos que quieras usar dentro de la máquina virtual sin tocar los del host.
Para compartir datos entre el host Linux y la VM Windows tienes varias opciones. Desde Linux hacia Windows, lo más simple es usar compartición de carpetas vía red con SAMBA: compartes un directorio del host y lo montas en Windows como recurso de red. Funciona bien, está muy documentado y no necesitas inventar nada raro. Desde Windows hacia Linux, puedes montar directamente el disco o fichero de imagen de la VM cuando esta está apagada, aunque para el día a día es más cómodo seguir usando el intercambio por red.
Además de SAMBA, muchas soluciones de virtualización permiten crear carpetas compartidas específicas entre host e invitado o montar dispositivos de bloque virtuales visibles en ambos lados, pero para un escenario doméstico de gaming y almacenamiento multimedia, una buena configuración de red interna y recursos compartidos suele ser más que suficiente.
Cuando juntamos todo lo anterior —hardware compatible con IOMMU, GPUs en passthrough, afinado de CPU/RAM, gestión cuidadosa de USB y un acceso cómodo a los datos— acabamos teniendo una máquina que se siente casi como si tuviera dos PCs completos metidos en una sola caja, con cada uno de ellos orientado a un uso distinto. Para gaming, esto te permite que tus hijos jueguen juntos desde un único equipo físico con dos VMs independientes, mientras tú sigues usando el host para tus cosas o dejas corriendo servicios en segundo plano. No es magia, pero con paciencia se consigue un resultado muy cercano al de un PC dedicado para cada uno.