Hay una fase bastante cutre en casi todo homelab con Proxmox. La de decirte a ti mismo que levantar una VM nueva son cinco minutos y luego echar media hora repitiendo siempre lo mismo. Crear la máquina, montar ISO o importar imagen, tocar red, meter clave SSH, actualizar paquetes, instalar cuatro utilidades, corregir alguna tontería del hostname y cruzar los dedos para no haber dejado un usuario raro o una configuración vieja de otra prueba. No es un drama, pero tampoco es serio.
Yo estuve así más tiempo del que me gustaría admitir. No porque no supiera que cloud-init existía, sino porque me daba la impresión de que era una de esas piezas pensadas para nube pública y que en casa iba a añadir complejidad antes que ahorrar tiempo. Error mío. En Proxmox, cuando empiezas a clonar VMs con cierta frecuencia, cloud-init es de las mejoras que más se notan y más rápido amortizas.
Mi conclusión después de usarlo es muy simple. Si levantas Linux en Proxmox más de dos veces al mes, ya vas tarde. No hace falta montar un sistema barroco, ni aprender media enciclopedia de OpenStack, ni volverte loco con YAML infinito. Hace falta una plantilla limpia, un par de buenas decisiones y dejar de repetir trabajo manual como si fuera una tradición familiar.
qué hace cloud-init y por qué en Proxmox encaja tan bien#
Cloud-init es el sistema que usan muchísimas imágenes de Ubuntu, Debian y otras distribuciones para configurarse en el primer arranque. Proxmox aprovecha eso bastante bien. Tú preparas una VM base o importas una cloud image, la conviertes en plantilla, y luego Proxmox le inyecta datos de primer arranque como el usuario, la clave SSH, la red, el hostname o incluso configuración personalizada.
La parte buena es que esa configuración no vive cocida dentro de cada clon. Va pegada al despliegue. Eso cambia mucho la historia. La VM nace con una identidad concreta en lugar de heredar cicatrices del experimento anterior.
Proxmox además lo pone bastante fácil. La propia documentación oficial recomienda convertir la imagen preparada en template y usar clones enlazados cuando tenga sentido. Y ahí está el truco. No solo despliegas más rápido. También reduces errores tontos, que en homelab suelen ser la clase de error que te roba una tarde entera por no haber querido ordenar diez minutos antes.
por qué me cansé del método manual#
En mi caso el punto de inflexión llegó al empezar a levantar más VMs pequeñas para pruebas, servicios web, automatizaciones y algún invento que no quería mezclar con otros entornos. Al principio iba tirando con una VM Debian bastante limpia que clonaba a mano. Funcionaba, sí. También acumulaba costumbres bastante feas.
Unas veces la máquina arrancaba con un hostname heredado. Otras había restos de claves viejas. Otras el netplan no quedaba fino. Y casi siempre acababa entrando por consola para rematar cosas que se suponía que ya deberían venir listas. No era un problema técnico grave. Era simplemente una forma mediocre de trabajar.
Cloud-init no me arregló la vida, tampoco nos vengamos arriba, pero sí me quitó bastante fricción absurda. Y en homelab esa fricción cuenta mucho. No porque levantar una VM nueva sea difícil, sino porque repetir veinte veces lo mismo termina desgastando. Cuanto menos tiempo dedico a la fontanería repetitiva, más tiempo me queda para probar lo que realmente quería probar.
mi enfoque hoy#
Yo intento mantener una plantilla Linux razonablemente genérica y no contaminarla con demasiadas decisiones específicas. Quiero que sirva para varias cosas. Una VM para Docker. Una VM para un servicio pequeño. Una caja temporal para pruebas. Un nodo auxiliar. Si conviertes la plantilla en una especie de imagen sagrada con media pila de utilidades que solo necesitas tú los domingos, al final vuelves a crear otra fuente de problemas.
Lo que sí dejo resuelto desde el inicio es lo básico.
- Usuario inicial claro
- Acceso por SSH con clave pública
- Actualización de paquetes en primer arranque cuando tiene sentido
- Red simple
- Plantilla convertida y lista para clonar
Con eso ya me ahorro muchísimo trabajo.
Esta captura está sacada de una plantilla real de mi entorno, saneada para no regalar detalles internos. La gracia no es el nombre del bridge ni el identificador concreto. La gracia es ver lo poco que necesitas para que Proxmox haga el trabajo pesado por ti.
plantilla buena frente a plantilla inflada#
Aquí tengo una opinión bastante fuerte. La mayoría de plantillas caseras están demasiado cargadas o demasiado vacías. Y las dos cosas son malas.
Una plantilla demasiado vacía hace que cloud-init apenas te ahorre nada. Sigues entrando a mano para instalar media base. Una plantilla demasiado cargada acaba heredando configuraciones que luego no recuerdas por qué existen. Ahí es cuando una VM supuestamente nueva ya arranca oliendo a trastero.
Yo prefiero una plantilla sobria. Sistema limpio, agente de invitado si lo voy a usar, cloud-init bien instalado o una cloud image bien preparada, y poco más. Si una aplicación necesita cosas especiales, que nazcan en su propio proceso de despliegue. No dentro de la plantilla madre, que bastante trabajo tiene con no convertirse en una leyenda urbana.
el detalle que más cambia la experiencia#
Para mí la parte más importante no es ni siquiera la plantilla. Es usar clave SSH desde el primer segundo y olvidarme de contraseñas manuales salvo casos muy concretos. La documentación de Proxmox va en esa línea y me parece sensato. Si puedes evitar depender de una contraseña provisional y entrar directamente con tu clave, mejor.
No porque seas una gran empresa, sino porque es más limpio. Despliegas, arranca, entras por SSH, verificas que todo está donde toca y sigues con tu vida. Mucho más agradable que andar copiando passwords temporales en una consola web a las tantas.
Esta otra captura también sale de una plantilla real y resume bastante bien la idea. Usuario, hostname, clave pública y actualización inicial. Nada heroico. Justo lo necesario.
lo que de verdad me ahorra tiempo#
Hay gente que ve cloud-init como una pijada de automatización. Yo lo veo más como una forma de no hacer chapuzas repetidas.
Cuando clono desde plantilla con cloud-init ya sé varias cosas de antemano.
- La máquina nace con el usuario correcto
- La clave SSH está puesta
- La red arranca como espero
- El hostname no hereda basura
- El despliegue es repetible
Eso último vale mucho. Repetible no significa perfecto. Significa que, si algo sale mal, al menos sabes que el proceso fue el mismo. Y eso en troubleshooting ayuda bastante. El caos improvisado tiene una costumbre muy fea, que es fallar de forma distinta cada vez.
dónde se nota más en un homelab pequeño#
Aquí hay un punto importante. En entornos enormes esto es obvio. En casa, en cambio, a veces uno piensa que no merece la pena porque total solo son unas pocas VMs. Yo creo justo lo contrario. En homelab pequeño la automatización buena luce más, porque el tiempo que te ahorra sale directamente de tus noches y tus fines de semana.
A mí se me nota especialmente en tres escenarios.
pruebas rápidas#
Quiero probar un servicio, una nueva base Debian o una integración rara. Antes montaba la VM y ya había gastado energía mental antes de empezar la prueba real. Ahora clono, ajusto recursos, arranco y en pocos minutos estoy en la parte interesante.
separar cosas que no quiero mezclar#
Hay servicios que no quiero meter en el mismo host por limpieza o por seguridad. Con una plantilla buena, crear una VM aparte deja de dar pereza. Y eso hace que termine aislando mejor algunas cargas.
rehacer sin miedo#
Este es quizá el mayor cambio. Cuando desplegar es barato, borrar una VM mediocre deja de doler. Y eso te vuelve mejor administrador. Rehaces más. Limpias antes. Arrastras menos basura histórica. Si crear una máquina nueva es un rollo, acabas justificando demasiadas decisiones malas con el argumento miserable de “ya que está montada”.
errores que ya he cometido para que tú no los repitas#
He metido la pata con cloud-init unas cuantas veces y hay tres o cuatro lecciones que tengo bastante clavadas.
no conviertas cualquier VM vieja en plantilla por puro optimismo#
Se puede, sí. También puedes vivir con un cajón donde conviven cables, destornilladores y pilas muertas, pero no es buena práctica. Si la VM arrastra pruebas viejas, paquetes que ya no tocan o configuraciones raras, ese barro viaja contigo a cada clon.
no metas demasiada personalización en la base#
La tentación es fuerte. “Ya que estoy, le dejo Docker, fail2ban, mosh, zsh, aliases y cuatro scripts”. Luego usas esa plantilla para otra cosa y te preguntas por qué demonios la VM trae medio ajuar de otra vida. Mejor poco y limpio.
no te fíes del primer arranque sin comprobarlo#
Cloud-init suele ir bien, pero no es magia. Yo reviso el primer login, el hostname, la IP y el estado general. Un vistazo rápido te evita descubrir horas después que la red no quedó fina o que el usuario no se aplicó como esperabas.
no dependas de una sola imagen sin revisar cuándo se actualizó#
Esto también importa. Si dejas una plantilla dormir meses, acabas arrancando sistemas que nacen viejos. No pasa nada por actualizar la base periódicamente. Mejor dedicarle un rato de vez en cuando que desplegar máquinas nuevas con olor a 2024.
cuándo usar cloud image y cuándo prefiero cocinar mi propia base#
Las cloud images oficiales de Ubuntu o Debian son muy cómodas y Proxmox las soporta bien. Para muchas cosas me parecen una opción estupenda. Arrancas rápido y no necesitas instalar la distro desde cero solo para llegar al mismo punto.
Aun así, entiendo perfectamente la recomendación de Proxmox de preparar tu propia imagen cuando quieras saber exactamente qué lleva dentro. Yo me muevo entre ambos mundos según el caso.
Si quiero velocidad y un Linux bastante estándar, tiro de cloud image. Si voy a usar una base más controlada, con ciertos paquetes o ajustes que sé que repetiré mucho, prefiero cocinar la plantilla yo y dejarla convertida en template.
La clave aquí es no obsesionarse con la pureza. Lo importante es que el resultado sea limpio, predecible y mantenible. No ganar un premio imaginario a la elegancia.
cloud-init no sustituye al resto de tu criterio#
Esto también conviene dejarlo claro. Cloud-init no decide por ti cuánto disco asignar, qué cargas merecen su propia VM o cuándo te estás pasando creando máquinas para resolver problemas que quizá iban mejor en un contenedor. Solo automatiza el arranque inicial. La arquitectura sigue siendo tu responsabilidad.
Yo, por ejemplo, sigo usando contenedores para muchas cosas pequeñas y VMs para lo que quiero aislar más o tocar con más calma. No porque una opción sea moralmente superior, sino porque mezclar todo en la misma cesta suele acabar regular. Si estás en ese punto de duda, te recomiendo echar un ojo a Docker Compose vs Kubernetes: cuándo usar cada uno y también a Proxmox cluster de 3 nodos en mini PCs: lo que haría distinto después de montarlo en casa. No resuelven cloud-init, pero sí ponen contexto a la decisión de qué merece vivir dónde.
cómo encaja esto con el resto del homelab#
En mi caso cloud-init no vive aislado. Tiene sentido porque el resto del laboratorio ya está pensado para que desplegar no sea un castigo. Hay backups decentes, red razonablemente ordenada, plantillas con sentido y cierta disciplina para no dejar que cada invento se convierta en una reliquia sagrada que nadie se atreve a tocar.
De hecho, cuanto más ordenado tienes el homelab, más luce cloud-init. Porque deja de ser una curiosidad y se convierte en una pieza natural del flujo. Clonas, ajustas, arrancas, validas y sigues. Sin ceremonia. Sin abrir siete pestañas para recordar qué olvidaste la última vez.
dónde creo que merece la pena empezar#
Si no lo estás usando todavía, yo haría esto y nada más.
- Preparar una sola plantilla Ubuntu o Debian limpia
- Dejar resuelto usuario y clave SSH
- Probar DHCP primero, sin inventos extra
- Clonar dos o tres VMs de prueba
- Confirmar que el primer arranque hace justo lo que esperas
Con eso ya te llevas el 80 por ciento de la mejora. Después, si te apetece, puedes entrar en configuración personalizada, snippets, netplan más fino o user-data específico por caso. Pero no hace falta empezar por la parte barroca.
mi veredicto#
Cloud-init en Proxmox merece muchísimo la pena. Lo digo sin reservas. No porque sea una herramienta espectacular de enseñar en una captura bonita, sino porque elimina una clase de trabajo repetitivo que no aporta nada. Y cuando una herramienta hace eso sin pedirte un peaje absurdo, yo no necesito mucha más argumentación.
Hay tecnologías que impresionan más. Esta simplemente te hace perder menos tiempo. Y a cierta altura del homelab, eso vale oro.
Si sigues clonando VMs a mano y rehaciendo el mismo arranque una y otra vez, mi recomendación es clara. Deja de sufrir por costumbre. Móntate una plantilla decente, mete cloud-init en el flujo y recupera tus noches para cosas más entretenidas que volver a escribir el mismo hostname.