Hay una tarea que todo el mundo hace de más al principio: instalar el sistema operativo desde la ISO cada vez que hace falta una máquina virtual nueva. Montar la ISO, esperar al instalador, particionar, crear el usuario, actualizar, instalar lo básico, configurar la red… media hora larga por VM, y al final tienes una máquina parecida a las demás, pero no idéntica. Multiplica eso por cincuenta VMs y tienes un problema doble: tiempo perdido y un parque de máquinas que divergen sutilmente entre sí, cada una con su pequeña particularidad que nadie recuerda haber configurado.
La solución lleva años resuelta y mucha gente no la usa: preparas el sistema base una sola vez, lo conviertes en plantilla, y a partir de ahí cada VM nueva se clona de esa plantilla en segundos, ya configurada. Este artículo explica cómo montar esa plantilla en Proxmox, cómo cloud-init le pone a cada clon su configuración propia sin que toques la consola, y la diferencia entre los dos tipos de clon que conviene conocer. Es el paso previo natural a llevar todo esto a código con Terraform.
El concepto es el de una imagen maestra o golden image: una VM que preparas con esmero una única vez, con todo lo que quieres que compartan tus máquinas, y que luego usas como molde. Lo que suele ir en ella:
Una vez preparada, se convierte en plantilla. En Proxmox esto es literalmente marcar la VM como template: deja de ser arrancable directamente y pasa a ser un molde de solo lectura del que se clonan las máquinas reales.
# Convertir una VM (ID 9000) en plantilla
qm template 9000El patrón más habitual y cómodo parte de las imágenes cloud que las distribuciones publican: Debian, Ubuntu, Rocky y demás ofrecen imágenes .qcow2 ya preparadas para cloud-init, pensadas justo para esto. Las importas, las ajustas a tu gusto, les añades el guest agent, y las conviertes en plantilla. A partir de ahí, aprovisionar es clonar.
Aquí está la magia que hace que el clonado sea útil de verdad. Si clonas una plantilla sin más, obtienes cincuenta máquinas idénticas… incluido el mismo hostname y sin IP asignada. Inservible. Lo que hace falta es que cada clon reciba su configuración: su nombre, su dirección, su usuario, sus claves. Eso es cloud-init.
cloud-init es el estándar de facto para inicializar máquinas en la nube, y Proxmox lo integra de fábrica. Funciona así: a la VM se le adjunta un pequeño disco cloud-init con los datos de configuración, y en el primer arranque el sistema los lee y se auto-configura antes de que puedas siquiera entrar. Lo que puede inyectar:
En Proxmox, tras clonar, defines estos valores en la pestaña Cloud-Init de la VM (o por CLI/API), arrancas, y la máquina se levanta ya configurada. Nunca entras al instalador ni a la consola para configurar la red o el usuario: todo llega en el arranque.
# Clonar la plantilla y configurar el clon vía cloud-init, por CLI
qm clone 9000 201 --name web-01
qm set 201 --ipconfig0 ip=10.20.0.201/24,gw=10.20.0.1
qm set 201 --sshkeys ~/.ssh/authorized_keys
qm set 201 --ciuser admin
qm start 201
# La VM 201 arranca ya con su IP, su hostname y tu clave SSH.Proxmox ofrece dos formas de clonar, y elegir bien ahorra mucho espacio (o evita un problema):
Clon completo (full clone). Copia entera e independiente de la plantilla. El clon no depende de nada: puedes borrar la plantilla y la VM sigue tan campante. La contrapartida es que ocupa el espacio completo desde el primer momento y tarda algo más en crearse (hay que copiar todo el disco).
Clon enlazado (linked clone). No copia el disco base: lo comparte con la plantilla y solo guarda las diferencias que va escribiendo cada clon. Ventajas enormes: se crea casi instantáneamente y ocupa muy poco al principio. La contrapartida: depende de la plantilla, que no se puede borrar mientras existan clones enlazados a ella.
| Clon completo | Clon enlazado | |
|---|---|---|
| Independiente de la plantilla | Sí | No (la necesita) |
| Espacio inicial | El disco entero | Mínimo (solo diferencias) |
| Velocidad de creación | Más lento | Casi instantáneo |
| Mejor para | VMs permanentes y críticas | Flotas efímeras, entornos de prueba, alta densidad |
La regla práctica: clon enlazado para máquinas efímeras o numerosas donde priorizas velocidad y densidad (entornos de test, VMs de usar y tirar, granjas idénticas); clon completo para máquinas permanentes que quieres totalmente independientes. Muchos entornos combinan: plantillas con clones enlazados para lo desechable, clones completos para producción estable.
Plantillas y cloud-init resuelven el «cómo nace una máquina bien configurada». El siguiente paso natural es automatizar el «quién las crea y con qué valores», y ahí entra la infraestructura como código. El patrón que escala:
Así se cierra el círculo: la plantilla garantiza que la base es idéntica, cloud-init garantiza que cada clon recibe su configuración propia, y el código garantiza que todo el proceso es reproducible y auditable. Se acabó el drift de máquinas que divergen y el «¿cómo se montó esta VM?».
¿Qué es una plantilla (template) en Proxmox?
Una VM preparada una vez con el sistema base y convertida en molde de solo lectura. No se arranca directamente; sirve para clonar máquinas nuevas a partir de ella en segundos. Lo habitual es partir de una imagen cloud de la distribución, ajustarla, añadirle el guest agent y cloud-init, y convertirla en plantilla con qm template.
¿Para qué sirve cloud-init? Para que cada VM clonada reciba su configuración propia en el primer arranque —hostname, IP, usuario, claves SSH, scripts iniciales— sin que entres a la consola. Sin cloud-init, clonar una plantilla te daría máquinas idénticas e inservibles (mismo nombre, sin red configurada). Con él, cada clon nace listo.
¿Clon completo o enlazado? Clon completo para VMs permanentes que quieres independientes de la plantilla (ocupa más, pero puedes borrar la plantilla). Clon enlazado para máquinas efímeras o numerosas: se crea casi al instante y ocupa mínimo, a cambio de depender de la plantilla, que no se puede borrar mientras tenga clones enlazados.
¿Puedo actualizar una plantilla y que se propague a los clones? No directamente: los clones ya creados no heredan cambios posteriores de la plantilla (un clon enlazado comparte el disco base congelado, no los cambios nuevos). La práctica correcta es mantener la plantilla al día para las máquinas futuras, y actualizar las existentes por sus propios medios (gestión de configuración, parches). La plantilla define el punto de partida, no el mantenimiento continuo.
¿Esto sustituye a la instalación desde ISO? Para el día a día, sí: una vez tienes la plantilla, no vuelves a instalar desde ISO salvo para preparar o renovar la propia plantilla. Aprovisionar deja de ser instalar y pasa a ser clonar más cloud-init, que es cuestión de segundos.
qm.¿Sigues instalando el sistema operativo a mano en cada VM y tu parque diverge sin control? Te ayudamos a montar tus plantillas cloud-init y el aprovisionamiento reproducible sobre Proxmox. Empieza por nuestra comparativa de cloud o hablemos de tu proyecto.
Cómo funciona Proxmox Backup Server por dentro y cómo se monta bien: troceado en chunks y deduplicación global, incrementales para siempre con el dirty bitmap de QEMU, verificación programada, retención con prune y recolección de basura, réplica offsite con sync jobs, S3 y cinta, y los tres caminos de restauración. Con el dimensionado del servidor, los fallos que vemos repetirse y en qué casos Veeam sigue teniendo sentido.
Proxmox Backup Server hace que los backups ocupen una fracción de lo esperado y se puedan guardar muchos más de lo que imaginas. Detrás hay tres piezas que conviene entender para confiar en tus copias: la deduplicación que ahorra el espacio, la verificación que detecta la corrupción silenciosa antes de que la necesites, y las políticas de retención que deciden cuánto historia guardas. Las explicamos una a una.
Asignar a tus VMs más CPU y RAM de la que el servidor tiene físicamente —overcommit— es lo que permite meter más máquinas en el mismo hardware. Con la CPU suele salir bien; con la memoria, hecho a la ligera, es la receta de un servidor que muere de golpe. Explicamos por qué la CPU se sobreasigna con tranquilidad y la RAM con mucho cuidado, y las herramientas (ballooning, KSM) para hacerlo con cabeza.