Proxmox es la plataforma de virtualización con la que una empresa convierte dos o tres servidores físicos en una veintena de máquinas virtuales administradas desde el navegador. Es software libre, se instala sobre Debian y no cobra por procesador para funcionar. Esta guía reúne lo que un profesional de TI necesita tener a mano: qué hace, cómo se instala, qué comandos se usan a diario y cómo se reparten la memoria, el disco y la CPU entre los servicios.
Está escrita en dos niveles. Si nunca ha tocado un hipervisor, los primeros apartados explican qué es y para qué sirve. Si ya administra uno, encontrará la tabla de comandos, el reparto de recursos, el paso a clúster y la alta disponibilidad.
Dónde encaja esta guía
Es la primera de cuatro guías construidas sobre el mismo inventario: un clúster de tres nodos con doce máquinas. Aquí nace ese inventario; en las siguientes se segmenta, se transforma y se publica como tablero. Las cifras cuadran entre las cuatro.
- Proxmox — está leyéndola: la plataforma, los comandos y el reparto de recursos.
- Firewall de Proxmox — segmentar ese inventario en VLAN y filtrar el tráfico.
- Power Query — llevar el inventario a Excel y dejarlo limpio.
- Power BI — convertirlo en un tablero que se actualiza solo.
Qué es Proxmox y qué resuelve
Proxmox Virtual Environment, abreviado Proxmox VE o PVE, es una distribución de servidor que hace dos cosas a la vez. Por un lado ejecuta máquinas virtuales completas con KVM, el hipervisor que viene dentro del propio núcleo de Linux. Por otro ejecuta contenedores LXC, que son sistemas Linux ligeros que comparten el núcleo del anfitrión. Ambas cosas se administran desde la misma interfaz web, en el puerto 8006.
Se trata de un hipervisor de tipo 1: se instala directamente sobre el hierro, sin un sistema operativo previo que le reste rendimiento. Además incorpora de serie el almacenamiento, las copias de seguridad, el firewall, el clúster y la alta disponibilidad. No hay que comprar módulos aparte para ninguna de esas funciones.
El proyecto lo publica la empresa austriaca Proxmox Server Solutions bajo licencia GNU AGPL v3. El código es abierto y el producto es gratuito. Lo que se paga, si se quiere, es una suscripción de soporte que da acceso al repositorio empresarial, el más probado de los tres que ofrece el proyecto.
Máquina virtual o contenedor: cuándo usar cada uno
Es la primera decisión de cada despliegue y conviene tomarla en frío.
| Criterio | Máquina virtual (KVM) | Contenedor (LXC) |
|---|---|---|
| Sistema operativo | Cualquiera, incluido Windows | Solo Linux |
| Núcleo | Propio y aislado | Compartido con el anfitrión |
| Consumo de memoria | El que se le asigne | Solo lo que usa de verdad |
| Arranque | Decenas de segundos | Uno o dos segundos |
| Migración en vivo | Sí | No: se reinicia en el otro nodo |
| Buen candidato | ERP, base de datos, Windows Server | Proxy, DNS interno, monitoreo |
La regla práctica es sencilla. Si el servicio tiene que seguir en pie durante un mantenimiento del anfitrión, va en máquina virtual, porque solo ella se mueve en caliente. Si es un servicio pequeño, reponible y siempre Linux, el contenedor consume mucho menos.
Sobre qué sistema operativo corre Proxmox
El sistema operativo base de Proxmox es Debian GNU/Linux, con un núcleo mantenido por el propio proyecto y tomado de Ubuntu. Eso importa en la práctica: cualquier herramienta de Debian funciona en el anfitrión, la documentación de Debian sirve, y los comandos que ya conoce de Linux se comportan igual. Si le faltan referencias, en el blog hay una guía de comandos básicos de Linux que aplica tal cual.
La serie 9 de Proxmox se apoya en Debian 13, nombre en clave Trixie. Esta es la correspondencia de las versiones recientes, tomada del registro de publicaciones del proyecto.
| Versión | Publicada | Base | Núcleo | QEMU | Ceph |
|---|---|---|---|---|---|
| Proxmox VE 9.0 | Agosto de 2025 | Debian 13 | 6.14.8-2 | 10.0 | Squid 19.2 |
| Proxmox VE 9.1 | Noviembre de 2025 | Debian 13.2 | 6.17.2-1 | 10.1.2 | Squid 19.2.3 |
| Proxmox VE 9.2 | Mayo de 2026 | Debian 13.5 | 7.0 | 11.0 | Tentacle 20.2.1 |
Conviene comprobar en qué versión está antes de cualquier cambio. Un solo comando lo dice todo.
pveversion -v | head -5
# proxmox-ve: 9.2-1 (running kernel: 7.0.0-1-pve)
# pve-manager: 9.2-1 (running version: 9.2-1)Usos comunes de Proxmox en una empresa
En una organización mediana casi siempre aparece en los mismos escenarios.
| Uso | Qué resuelve |
|---|---|
| Consolidar servidores | Seis equipos físicos al 8 % de uso pasan a ser seis máquinas virtuales en dos nodos |
| Separar servicios | El ERP, el archivo y la web dejan de compartir el mismo sistema operativo |
| Entornos de prueba | Un clon de la base de datos en dos minutos, y se descarta sin tocar producción |
| Recuperación | Restaurar una máquina completa en un nodo distinto, no reinstalar un servidor |
| Escritorios remotos | Servidores de aplicaciones para trabajo remoto, con la sesión en el centro de datos |
| Laboratorio de TI | Probar un parche en una copia antes de aplicarlo al servicio real |
El caso más rentable suele ser el primero. Tres servidores antiguos que consumen electricidad, ocupan rack y se quedan sin garantía se convierten en tres archivos de disco dentro de un equipo nuevo. Si el hardware que los sostiene está pensado con criterio, el conjunto además gana disponibilidad: conviene revisar la elección de niveles de RAID antes de instalar nada.
Beneficios reales frente a servidores sin virtualizar
- Aprovechamiento del hierro. Un servidor dedicado a una sola aplicación desperdicia entre el 80 % y el 90 % de su capacidad.
- Copias de la máquina entera. No se respalda una carpeta, sino el servidor completo con su sistema operativo y su configuración.
- Instantáneas antes de un cambio. Se toma una instantánea, se aplica el parche y, si algo falla, se vuelve atrás en segundos.
- Independencia del hardware. La máquina virtual no sabe qué marca de servidor la ejecuta, así que se mueve a otro sin reinstalar.
- Plantillas. Un servidor base bien configurado se clona cuantas veces haga falta, siempre igual.
- Sin coste de licencia del hipervisor. El presupuesto se va al hierro y al soporte, no al software de virtualización.
Hay un beneficio menos evidente y muy valorado por quien opera: la homogeneidad. Todas las máquinas se crean, se copian y se restauran de la misma forma, con las mismas órdenes. Eso reduce los errores de quien está de turno a las tres de la mañana. En el artículo sobre virtualización de servidores está el detalle de este cambio de modelo.
Cómo se instala Proxmox
La instalación se hace desde una imagen ISO que se descarga del sitio del proyecto y se escribe en una memoria USB. El instalador es gráfico y pide cuatro cosas: el disco de destino, el país y la zona horaria, la contraseña del usuario root y la dirección de red del nodo. En quince minutos el servidor arranca ya con la interfaz web disponible.
Elegir el disco del sistema
Es la decisión que más cuesta cambiar después. El instalador ofrece ext4, XFS, ZFS y Btrfs. En un servidor de producción con dos discos, lo habitual es ZFS en RAID 1: tolera la pérdida de un disco, detecta corrupción silenciosa y habilita instantáneas del propio sistema. A cambio pide memoria, porque su caché de lectura crece con el espacio.
Una advertencia que ahorra disgustos: ZFS no debe ir detrás de una controladora RAID por hardware. Necesita ver los discos en crudo para reparar lo que detecta. Si la controladora admite modo HBA o IT mode, hay que activarlo antes de instalar.
Los repositorios después de instalar
Recién instalado, el nodo apunta al repositorio empresarial, que exige suscripción. Sin ella, cada actualización falla con un error 401 y aparece el aviso de suscripción al entrar. Quien no tenga contrato debe habilitar el repositorio no-subscription, pensado para pruebas y entornos donde se acepte una prueba menos exhaustiva. Es un cambio de dos líneas en la lista de fuentes de Debian.
Cómo se organiza la interfaz de Proxmox
La estructura del panel es una jerarquía de tres niveles y entenderla evita la mitad de las dudas del primer mes.
- Centro de datos. Lo común a todos los nodos: usuarios, permisos, copias programadas, almacenamientos, reglas de firewall y opciones del clúster.
- Nodo. Un servidor físico concreto: su red, sus discos, sus actualizaciones, su consola y sus registros.
- Recurso. Cada máquina virtual o contenedor, identificado por un número único llamado VMID.
El VMID es la clave de todo lo que viene después. Empieza en 100, no se repite en el clúster y es el argumento de casi todos los comandos. Numerar con criterio —por ejemplo, la centena para el tipo de servicio— paga con creces cuando hay cincuenta máquinas.
Los almacenamientos y qué admite cada uno
Un almacenamiento en Proxmox es un sitio donde guardar discos, copias, ISO o plantillas. No todos sirven para lo mismo, y la diferencia que más se nota es si permiten instantáneas.
| Tipo | Dónde vive | Instantáneas | Compartido entre nodos |
|---|---|---|---|
| Directorio | Una carpeta local | Solo con discos qcow2 | No |
| LVM-Thin | Disco local | Sí | No |
| ZFS local | Disco local | Sí | No |
| NFS o SMB/CIFS | Una cabina o un NAS | Con qcow2 | Sí |
| Ceph RBD | Los discos de los propios nodos | Sí | Sí |
| Proxmox Backup Server | Servidor de copias dedicado | No aplica | Sí |
La columna que decide la arquitectura es la última. Sin almacenamiento compartido no hay migración en vivo ni alta disponibilidad de verdad, porque el disco de la máquina solo existe en un nodo.
El inventario de ejemplo que usa toda la serie
A partir de aquí todo se apoya en un caso concreto: tres nodos —pve-01, pve-02 y pve-03—, cada uno con 16 núcleos físicos y 96 GiB de memoria, y doce recursos repartidos entre ellos. Nueve son máquinas virtuales y tres son contenedores. Puede copiar esta tabla tal cual: es el conjunto de datos que reaparece en las otras tres guías.
| VMID | Nombre | Nodo | Tipo | vCPU | RAM (GiB) | Disco (GiB) | VLAN | Servicio |
|---|---|---|---|---|---|---|---|---|
| 100 | erp-app | pve-01 | qemu | 8 | 32 | 200 | 20 | ERP |
| 101 | erp-db | pve-01 | qemu | 8 | 48 | 500 | 20 | ERP |
| 102 | web-01 | pve-02 | qemu | 4 | 8 | 80 | 30 | Web |
| 103 | web-02 | pve-03 | qemu | 4 | 8 | 80 | 30 | Web |
| 104 | file-01 | pve-02 | qemu | 4 | 16 | 2000 | 10 | Archivos |
| 105 | dc-01 | pve-01 | qemu | 2 | 8 | 60 | 10 | Directorio |
| 106 | dc-02 | pve-03 | qemu | 2 | 8 | 60 | 10 | Directorio |
| 107 | mon-01 | pve-02 | lxc | 2 | 4 | 40 | 40 | Monitoreo |
| 108 | proxy-01 | pve-03 | lxc | 2 | 4 | 20 | 30 | Proxy inverso |
| 109 | backup-01 | pve-02 | qemu | 4 | 8 | 4000 | 40 | Respaldo |
| 110 | test-01 | pve-03 | qemu | 4 | 16 | 120 | 99 | Pruebas |
| 111 | helpdesk | pve-01 | lxc | 2 | 4 | 40 | 20 | Mesa de servicio |
Los totales son 46 vCPU, 164 GiB de memoria y 7.200 GiB de disco. Repartidos por nodo: pve-01 tiene 20 vCPU, 92 GiB y 800 GiB; pve-02 tiene 14, 36 y 6.120; pve-03 tiene 12, 36 y 280. Esas cifras vuelven a salir, calculadas de otra manera, en las guías de Power Query y Power BI.
Comandos de Proxmox que se usan a diario
Todo lo que hace la interfaz web tiene su equivalente en la línea de órdenes, y casi siempre es más rápido. Estas son las familias de comandos de Proxmox, con su ámbito.
| Comando | Para qué sirve |
|---|---|
qm | Máquinas virtuales KVM: crear, arrancar, clonar, migrar, instantáneas |
pct | Contenedores LXC, con la misma lógica que qm |
pvesm | Almacenamientos: listar, añadir, ver espacio y contenido |
pvecm | Clúster: crear, unir nodos, ver el quórum |
ha-manager | Alta disponibilidad: qué recursos se recuperan solos y dónde |
vzdump | Copias de seguridad de máquinas y contenedores |
pveum | Usuarios, grupos, roles y permisos |
pvesh | Acceso directo a la API desde el intérprete de órdenes |
pveversion | Versión del nodo y de cada paquete |
pveperf | Prueba rápida de CPU y de disco del nodo |
Merece la pena detenerse en pvesh. Consulta la misma API que usa la interfaz, así que devuelve el estado real del clúster en JSON o en CSV. Es la orden que produce el inventario de la tabla anterior sin escribir una línea a mano.
# Inventario completo del clúster, listo para exportar
pvesh get /cluster/resources --type vm --output-format json > inventario.json
# La versión corta y legible
qm list
pct list
pvecm statusGestión de máquinas virtuales con qm
El comando qm cubre el ciclo de vida completo de una máquina. Estos son los usos que aparecen casi todos los días.
# Crear una máquina con 4 vCPU, 8 GiB y disco de 80 GiB
qm create 102 --name web-01 --memory 8192 --cores 4 \
--net0 virtio,bridge=vmbr0,tag=30 \
--scsihw virtio-scsi-single --scsi0 datos:80
# Arrancar, ver el estado y apagar con orden
qm start 102
qm status 102
qm shutdown 102
# Instantánea antes de un cambio, y vuelta atrás si hace falta
qm snapshot 102 antes-parche --description "Previo al parche de octubre"
qm rollback 102 antes-parche
# Clonar, convertir en plantilla y desplegar desde ella
qm clone 102 120 --name web-03 --full
qm template 102
qm clone 102 121 --name web-04 --full
# Mover la máquina a otro nodo sin apagarla
qm migrate 102 pve-03 --onlineTres apuntes que no están en los menús. qm shutdown pide al sistema invitado que se apague y espera; qm stop corta la alimentación virtual, y eso puede corromper una base de datos. Una instantánea no es una copia de seguridad, porque vive en el mismo disco que la máquina. Y --full en un clon crea discos independientes, mientras que sin esa opción el clon depende de la plantilla para siempre.
Contenedores con pct
La sintaxis es casi idéntica, lo que reduce el esfuerzo de aprender las dos.
# Descargar una plantilla y crear el contenedor
pveam update && pveam available | grep debian-13
pveam download local debian-13-standard_13.0-1_amd64.tar.zst
pct create 108 local:vztmpl/debian-13-standard_13.0-1_amd64.tar.zst \
--hostname proxy-01 --memory 4096 --cores 2 \
--rootfs datos:20 --net0 name=eth0,bridge=vmbr0,tag=30,ip=dhcp
pct start 108
pct enter 108 # entra al contenedor sin SSHGestión de recursos en Proxmox
Aquí es donde un despliegue se gana o se pierde. Asignar de más es tan dañino como asignar de menos, y los síntomas se confunden con un problema de hardware.
CPU: núcleos, tipo y peso
A una máquina virtual se le asignan vCPU, que son hilos de ejecución que compiten por los núcleos reales. Se puede asignar más vCPU de las que existen físicamente —eso es sobrecompromiso— porque casi ninguna máquina usa toda su CPU a la vez.
- Empiece corto. Dos o cuatro vCPU y suba si el monitoreo lo pide. Una máquina con dieciséis vCPU ociosas obliga al planificador a esperar a que haya dieciséis huecos libres.
- Tipo de CPU. El valor
hostda el máximo rendimiento y expone todas las instrucciones del procesador, pero impide migrar a un nodo con otro modelo. En clúster, un tipo común y estable es mejor negocio. - Peso relativo.
cpuunitsreparte la CPU cuando hay contención: el ERP con 200 y el entorno de pruebas con 50. - Límite duro.
cpulimitimpone un techo absoluto, útil para que un servidor de pruebas nunca se lleve el nodo por delante.
Memoria y globo
La memoria admite un mínimo y un máximo. Con el globo activado, el controlador dentro del sistema invitado devuelve al anfitrión las páginas que no usa, de modo que la memoria libre circula entre máquinas. Funciona bien con Linux y con Windows, siempre que estén instalados los controladores virtio.
Dos excepciones que conviene respetar. Las bases de datos no deben tener globo, porque reservan memoria y la gestionan ellas. Y el sobrecompromiso de memoria es mucho más peligroso que el de CPU: cuando falta CPU el sistema va lento, cuando falta memoria el núcleo empieza a matar procesos.
Disco y red
Para el disco, la combinación sensata es controladora VirtIO SCSI single, la opción iothread activada y discard marcado si el almacenamiento admite recuperación de espacio. Sin discard, un disco fino crece y no vuelve a encoger aunque se borren archivos dentro.
Para la red, siempre virtio. Los modelos emulados existen solo para sistemas antiguos y pierden la mitad del rendimiento. Cada tarjeta virtual admite además una etiqueta de VLAN, que es la base de la segmentación que trata la segunda guía de esta serie.
Cómo se reparte la capacidad del ejemplo
Con el inventario anterior, los tres nodos suman 288 GiB de memoria y hay 164 GiB asignados, es decir, el 57 %. Parece holgado, pero la pregunta correcta es otra: ¿qué pasa si se cae el nodo más cargado?
| Nodo | vCPU | RAM asignada | RAM libre | Disco |
|---|---|---|---|---|
| pve-01 | 20 | 92 GiB | 4 GiB | 800 GiB |
| pve-02 | 14 | 36 GiB | 60 GiB | 6.120 GiB |
| pve-03 | 12 | 36 GiB | 60 GiB | 280 GiB |
| Total | 46 | 164 GiB | 124 GiB | 7.200 GiB |
Si pve-01 cae, sus 92 GiB tienen que caber en los otros dos, que suman 120 GiB libres. Cabe, y además la máquina más grande —erp-db, con 48 GiB— entra en un nodo con 60 libres. Esa doble comprobación es la regla N+1: el clúster debe poder perder un nodo entero sin dejar servicios fuera. Un clúster al 85 % de memoria no la cumple, aunque en un día normal funcione perfectamente.
Copias de seguridad en Proxmox
La herramienta se llama vzdump y funciona igual desde la interfaz y desde la consola. Tiene tres modos y elegir mal cuesta o disponibilidad o consistencia.
| Modo | Qué hace | Interrupción |
|---|---|---|
snapshot | Copia en caliente mientras la máquina trabaja | Prácticamente ninguna |
suspend | Suspende, copia y reanuda | Notable, y sin ganar consistencia |
stop | Apaga con orden, copia y vuelve a arrancar | La mayor, y la más consistente |
# Copia en caliente de tres máquinas, comprimida con zstd
vzdump 100 101 111 --mode snapshot --compress zstd --storage pbs
# Retención: 7 diarias, 4 semanales y 6 mensuales
vzdump 100 --prune-backups keep-daily=7,keep-weekly=4,keep-monthly=6Para más de tres o cuatro máquinas, el complemento natural es Proxmox Backup Server, un producto aparte del mismo proyecto. Hace copias incrementales reales gracias al mapa de bloques modificados y deduplica, así que la segunda copia de un servidor de 500 GiB no ocupa otros 500 GiB. Sea cual sea la herramienta, la regla no cambia: una copia que nunca se ha restaurado no es una copia, y conviene leer qué implica un respaldo inmutable antes de darla por buena.
Del nodo único al clúster de Proxmox
Un clúster de Proxmox es un conjunto de nodos que comparten configuración y se administran desde cualquiera de ellos. Lo sostiene corosync, que mantiene sincronizado el sistema de archivos /etc/pve entre todos. Crearlo son dos comandos.
# En el primer nodo
pvecm create kh-cluster --link0 10.10.99.11
# En cada nodo que se une, con la IP del primero
pvecm add 10.10.99.11 --link0 10.10.99.12
# Comprobación
pvecm status
pvecm nodesAntes de ejecutarlos hay que cumplir tres condiciones, según la documentación del proyecto: el reloj de todos los nodos sincronizado, los puertos UDP 5405 a 5412 abiertos entre ellos y una red con latencia por debajo de 5 ms. Corosync gasta muy poco ancho de banda, pero es intolerante a la variación de latencia, así que se recomienda una tarjeta de red dedicada solo para él.
Quórum: por qué tres nodos y no dos
Cada nodo tiene un voto y el clúster necesita mayoría para permitir cambios. Con tres nodos, si uno cae quedan dos votos de tres y el clúster sigue operando. Con dos nodos, la caída de uno deja un voto de dos, que no es mayoría: el superviviente se queda en solo lectura y no puede arrancar nada.
Para quien solo puede permitirse dos servidores existe el QDevice: un tercer votante instalado en cualquier máquina Linux pequeña, incluso un equipo de escritorio o una Raspberry Pi. No ejecuta máquinas virtuales, solo vota, y con eso se recupera la mayoría.
Migración en vivo
Mover una máquina encendida de un nodo a otro es la función que más se agradece cuando toca actualizar el hierro. Requiere almacenamiento compartido y procesadores del mismo fabricante en origen y destino. Con distintos modelos del mismo fabricante funciona, siempre que el tipo de CPU declarado sea compatible con los dos.
Alta disponibilidad en Proxmox
La migración en vivo cubre el mantenimiento planificado. La alta disponibilidad cubre lo otro: que un nodo se apague sin avisar. Se activa recurso por recurso y exige tres nodos como mínimo y almacenamiento compartido.
# Poner el ERP bajo alta disponibilidad
ha-manager add vm:100 --state started --max_restart 2
ha-manager add vm:101 --state started
ha-manager status
ha-manager migrate vm:100 pve-02El mecanismo que lo hace seguro es el watchdog. Cada nodo tiene que reiniciar un temporizador continuamente; si deja de hacerlo, a los 60 segundos el propio nodo se reinicia solo. Así se garantiza que un nodo perdido no siga escribiendo en el disco compartido mientras otro arranca la misma máquina. La detección más la recuperación completa tardan, en la práctica, alrededor de dos minutos.
Desde la versión 9, los antiguos grupos de HA dieron paso a las reglas de afinidad, que expresan mejor lo que se quiere: mantener juntos la aplicación y su base de datos para que no se hablen por la red, o mantener separados los dos servidores web para que un solo nodo no se lleve los dos. El concepto completo, con sus niveles y sus costos, está en la guía sobre alta disponibilidad.
Errores frecuentes al administrar Proxmox
| Error | Qué provoca | Qué hacer |
|---|---|---|
| Confundir instantánea con copia | Se pierde el disco y se pierden las dos | Copias fuera del nodo, con retención |
| Clúster de dos nodos sin QDevice | Si cae uno, el otro queda en solo lectura | Añadir un tercer votante |
| Corosync por la misma red que los datos | Una copia satura el enlace y el clúster se parte | Red dedicada o segundo enlace |
Tipo de CPU host en clúster mixto | La migración en vivo falla | Tipo común para todos los nodos |
| Globo activado en la base de datos | Rendimiento errático sin causa aparente | Desactivarlo y fijar la memoria |
| ZFS sobre controladora RAID | No puede reparar la corrupción que detecta | Controladora en modo HBA |
| Nadie mira el estado del nodo | Un disco degradado pasa semanas sin verse | Monitoreo con alertas |
El último es el más común de todos. Proxmox avisa por correo de una copia fallida o de un disco degradado, pero solo si alguien configuró el envío y alguien lee ese buzón. Sobre cómo montar esa vigilancia sin depender de la buena memoria de nadie, está la guía de monitoreo de servidores.
Preguntas frecuentes sobre Proxmox
¿Proxmox es gratis de verdad?
Sí. El producto completo, sin funciones recortadas, se descarga y se usa sin pagar nada. La suscripción es opcional y da acceso al repositorio empresarial y al soporte del fabricante. En producción se recomienda tenerla; no por las funciones, sino por la estabilidad de las actualizaciones.
¿Cuántos nodos admite un clúster?
No hay un límite declarado. El proyecto documenta instalaciones con más de cincuenta nodos en producción. El factor que manda no es el número, sino la calidad de la red que une a corosync.
¿Se puede empezar con un solo servidor?
Se puede, y es lo habitual. Un nodo único da consolidación, instantáneas y copias, que ya es la mayor parte del beneficio. Lo que no da es tolerancia a que ese servidor se apague. Añadir nodos después no obliga a reinstalar nada.
¿Qué pasa con las licencias de Windows dentro de Proxmox?
Son independientes del hipervisor. Cada Windows Server virtualizado necesita su licencia y sus CAL igual que en un servidor físico, y las reglas de asignación por núcleos del anfitrión siguen aplicando. Conviene revisarlo antes de consolidar, porque a veces el ahorro de hierro se come el costo de licenciamiento.
Qué llevarse de esta guía
Proxmox es un hipervisor completo sobre Debian, sin costo de licencia, con copias, clúster y alta disponibilidad incluidos. Se administra desde el navegador y desde una línea de órdenes corta y coherente. Lo que separa una instalación sólida de una frágil no es el software, sino tres decisiones: el almacenamiento compartido, la red de corosync y una reserva de capacidad que aguante la pérdida de un nodo.
La siguiente guía toma este mismo inventario y lo separa en VLAN, con las reglas de firewall que deciden qué máquina puede hablar con cuál.
