Guía paso a paso basada en Proxmox VE 7.4 con notas para las versiones actuales.
Proxmox VE permite virtualizar principalmente de dos formas: mediante máquinas virtuales QEMU/KVM y mediante contenedores LXC. Una máquina virtual es la opción adecuada cuando queremos ejecutar un sistema operativo completo con su propio kernel, por ejemplo Windows, GNU/Linux, FreeBSD, pfSense o RouterOS.
Esta guía documenta el proceso de creación de una VM en Proxmox VE 7.4, utilizando el asistente web de aquella versión. El flujo continúa siendo reconocible en Proxmox VE 9.2: General, OS, System, Disks, CPU, Memory, Network y Confirm.
Para una introducción a la plataforma actual consulta Proxmox VE 9.2: qué es, cómo funciona y qué podemos hacer con él. Si todavía necesitas reproducir una instalación antigua, también conservamos nuestra guía histórica de instalación de Proxmox VE 7.4.
Necesitamos un nodo Proxmox VE operativo, almacenamiento con espacio disponible y, si vamos a instalar desde una imagen, una ISO ya subida a un almacenamiento que tenga habilitado el contenido ISO image.
Desde la interfaz web accedemos normalmente mediante:
https://IP_O_HOSTNAME_DEL_PROXMOX:8006Para una administración real conviene utilizar un hostname válido, certificado TLS correcto y una red de gestión protegida. No recomendamos publicar el puerto 8006 directamente en Internet.
En la captura vemos la interfaz 7.4. En Proxmox VE 9.x la apariencia ha cambiado en detalles, pero el botón de creación y la organización general continúan siendo muy similares.
En un clúster podemos seleccionar el nodo donde se creará inicialmente la máquina.
El VMID identifica de forma única a cada VM o contenedor. En instalaciones antiguas era habitual trabajar a partir de 100. Las versiones actuales permiten configurar en Datacenter → Options el rango utilizado para proponer el próximo VMID libre, aunque el identificador sigue teniendo que ser único en todo el clúster.
El nombre debe permitir reconocer fácilmente el propósito del servidor. En infraestructuras grandes conviene adoptar una convención consistente, por ejemplo:
srv-dns-01
web-prod-02
db-postgresql-01La casilla de opciones avanzadas muestra parámetros adicionales del asistente. No es obligatorio cambiar valores avanzados solo porque estén disponibles.
El asistente permite instalar desde una ISO, utilizar determinados dispositivos físicos o crear la VM sin medio de instalación para configurarla después.
En el ejemplo original se utilizó una ISO de Kubuntu almacenada en local. Para una nueva VM seleccionamos la ISO apropiada y el tipo de sistema operativo más cercano al huésped que vamos a instalar.
En Proxmox VE actual también podemos importar máquinas desde determinadas fuentes y utilizar imágenes Cloud-Init, pero esta guía se centra en una instalación tradicional desde ISO.
i440fx ofrece una plataforma virtual más antigua y conserva valor para compatibilidad con sistemas legacy. q35 emula una plataforma más moderna con PCI Express y suele ser la opción preferible para sistemas operativos recientes cuando no existe una razón de compatibilidad para utilizar i440fx.
En Proxmox VE 9.2 no debemos interpretar i440fx como “la opción normal” y q35 como algo excepcional: para Windows moderno, passthrough PCIe y hardware virtual reciente, q35 suele encajar mejor.
SeaBIOS proporciona arranque BIOS/Legacy. OVMF proporciona UEFI.
Para Windows 11 y numerosos sistemas modernos es habitual utilizar q35 + OVMF. Con UEFI debemos añadir un EFI Disk para guardar variables persistentes del firmware.
El TPM virtual no es necesario para todas las VMs. Es especialmente relevante para sistemas que lo exigen o aprovechan, como Windows 11 con TPM 2.0 y determinadas soluciones de cifrado.
Una corrección importante respecto al texto original: QEMU Guest Agent no es el software que hace funcionar la máquina virtual. La VM funciona sin él.
El agente se instala dentro del sistema invitado y permite una mejor comunicación entre Proxmox y la VM. Entre otras cosas puede facilitar apagados limpios, mostrar direcciones IP, ejecutar ciertas órdenes y coordinar el congelado del sistema de archivos durante backups.
En Debian/Ubuntu podemos instalarlo dentro del huésped con:
sudo apt install qemu-guest-agent
sudo systemctl enable --now qemu-guest-agentDespués debemos tener habilitada también la opción QEMU Guest Agent en la configuración de la VM.
Este es uno de los apartados donde más conviene actualizar la recomendación.
En el artículo original proponíamos VirtIO Block. En la documentación actual de Proxmox, para máquinas nuevas se recomienda normalmente SCSI utilizando el controlador VirtIO SCSI single. Esto conserva el rendimiento de VirtIO y permite utilizar IO threads de forma eficiente.
Una configuración actual típica sería:
Windows puede necesitar los controladores VirtIO durante la instalación para detectar un disco SCSI/VirtIO o utilizar la tarjeta de red VirtIO.
El proyecto oficial publica una ISO con los controladores:
En esta revisión la URL estable redirige a la serie 0.1.302. No conviene fijar el artículo a una compilación antigua como 0.1.229.
La recomendación antigua “Write back si hay UPS, Write through si no” es demasiado simplificada. En Proxmox moderno lo más prudente es mantener el valor predeterminado salvo que entendamos la combinación concreta entre almacenamiento, caché del host, controlador y política de durabilidad.
El modo óptimo puede cambiar entre ZFS, Ceph, LVM-thin, almacenamiento de directorio, NFS o SAN.
Discard permite que el huésped informe al almacenamiento de bloques que ya no utiliza. Es especialmente útil con almacenamiento thin-provisioned, pero requiere soporte en toda la cadena: sistema de archivos del huésped, controlador virtual y backend de almacenamiento.
En una VM normalmente preferimos pocos sockets y varios cores, salvo que el software invitado tenga requisitos específicos de licenciamiento o topología.
El tipo host expone al huésped prácticamente todas las capacidades de la CPU física y ofrece excelente rendimiento. Sin embargo, puede limitar la live migration hacia nodos con procesadores diferentes.
La recomendación actual de Proxmox es utilizar host cuando todos los nodos relevantes disponen del mismo modelo de CPU y no existe problema de compatibilidad. En clústeres heterogéneos conviene utilizar un modelo genérico común, por ejemplo una familia x86-64-v* compatible con todos los nodos.
La guía antigua recomendaba habilitar NUMA por el simple hecho de usar más de un core. Eso no es correcto.
NUMA resulta principalmente útil en VMs grandes que deben reflejar la topología NUMA del host y repartir memoria/CPU entre múltiples nodos NUMA. Para una VM pequeña de 2, 4 u 8 vCPU normalmente no es necesario activarlo automáticamente.
Tampoco recomendamos activar flags como aes “por si acaso”. Si usamos host, las capacidades soportadas ya se exponen según la CPU física. Con modelos virtuales debemos elegir deliberadamente el baseline apropiado para compatibilidad y migración.
La memoria configurada es el máximo que la VM puede utilizar según esta sección.
El ballooning no significa que “3 GB se comparten” como una memoria común entre VMs. El dispositivo balloon permite que el host recupere memoria del invitado cuando la configuración y los drivers lo permiten, respetando el mínimo definido.
Debemos evitar sobreaprovisionar memoria sin entender el comportamiento de nuestras cargas. Un host que se queda sin RAM puede sufrir swapping, latencias severas o activar el OOM killer.
La VM se conecta normalmente a un bridge como vmbr0. Podemos además establecer un VLAN Tag si la red está preparada para ello.
Para sistemas compatibles, VirtIO continúa siendo la opción preferida por su bajo overhead y rendimiento. Windows requiere el driver NetKVM incluido en virtio-win.
La casilla Firewall habilita la integración de esa interfaz con el firewall de Proxmox VE. Activarla no crea por sí sola una política segura: las reglas se gestionan en los niveles Datacenter, nodo y VM/NIC según el diseño.
Multiqueue puede mejorar el rendimiento de red de VMs con tráfico elevado y múltiples vCPU, pero no existe una regla universal de que el número de colas deba ser siempre idéntico al número de cores. Más colas también generan más procesamiento.
Para una VM pequeña o con poco tráfico, el valor predeterminado suele ser suficiente.
Revisamos especialmente:
Podemos marcar Start after created si queremos que arranque inmediatamente.
Una vez creada, podemos revisar las secciones de la VM.
Algunos nombres y opciones han cambiado desde Proxmox VE 7.4, pero los conceptos principales se mantienen:
Una corrección importante: Cloud-Init no es “el servicio de nube de Proxmox”. Es un estándar ampliamente utilizado para inicializar automáticamente máquinas virtuales a partir de plantillas, configurando usuarios, claves SSH, red y otros parámetros.
Desde aquí veremos el instalador del sistema operativo como si estuviéramos frente al monitor de un equipo físico.
El rendimiento de una VM moderna con KVM y dispositivos VirtIO puede acercarse mucho al hardware nativo, pero no existe un porcentaje universal de “3 % de pérdida”. El overhead depende de CPU, almacenamiento, red, tipo de carga, passthrough, configuración NUMA y otros factores.
Como punto de partida en Proxmox VE 9.2, una VM Linux moderna puede configurarse así:
La interfaz ha evolucionado, pero las decisiones fundamentales continúan siendo las mismas: elegir correctamente firmware, máquina, CPU, almacenamiento, red y dispositivos paravirtualizados.
Precisamente por eso conservamos las capturas originales. Ayudan a reconocer el flujo de Proxmox 7.4 y permiten comparar cómo se ha refinado el asistente hasta Proxmox VE 9.2.
Guía completa de PHP 8.5: fundamentos, instalación, Composer, PSR, Laravel, Symfony, APIs, seguridad, rendimiento y…
Guía actualizada para instalar y diagnosticar Oracle VirtualBox Guest Additions 7.2.20 en GNU/Linux: headers, módulos,…
Guía de introducción a Kali Linux 2026.2: historia, rolling release, usos legítimos, herramientas, metapaquetes, VMs,…
Guía práctica para elegir herramientas de automatización de pruebas: unitarias, integración, API, contratos, Selenium, Playwright,…
Roadmap completo para aprender redes desde cero y prepararse como sysadmin: Ethernet, IPv4/IPv6, subnetting, VLAN,…
Historia y arquitectura del sistema de reservas de United Airlines diseñado por Evelyn Berezin, diferenciándolo…