Errores montando un homelab: autopsia de mi primer setup
Monté mi primer homelab con más entusiasmo que planificación. Esto es lo que rompí, lo que aprendí y el orden en el que debería haberlo hecho.
Compraste el hardware antes de entender el software
Si tienes un mini-PC o un NUC encima de la mesa y llevas dos días peleándote con la instalación, o con por qué Proxmox no ve tu red, o con por qué la VM que creaste ayer ya no arranca, estás exactamente donde estaba yo. No es que seas torpe. Es que nadie te contó en qué orden van las cosas, y el orden importa muchísimo.
La trampa del homelab de principiante es que parece un problema de hardware cuando casi siempre es un problema de conceptos. Yo gasté dinero en un switch antes de entender qué era una VLAN. Monté tres VMs antes de saber cuánta RAM necesitaba cada una. Abrí puertos en el router antes de haber leído nada sobre seguridad. Cada error me costó horas, a veces días, y en algún caso tuve que reinstalar desde cero.
Este post es la autopsia de esos errores: qué rompí, por qué, y qué habría cambiado si lo supiera desde el principio. No te prometo que tu homelab vaya a funcionar mañana, pero sí que cuando termines de leer vas a saber exactamente dónde estás metiendo la pata.
Por qué importa
RAM siempre escasa
Cada VM ligera necesita entre 512 MB y 2 GB. Con 8 GB en total, tres VMs y el host ya vas justo.
Factura ignorada
Un servidor 24/7 puede sumar 40-85 € anuales solo en electricidad. Mide el consumo real antes de dejarlo encendido.
Switch equivocado
Un switch no gestionado no puede crear VLANs. Tu tráfico de lab y el doméstico van mezclados en el mismo cable.
Backups al final
Proxmox Backup Server necesita almacenamiento separado del host. Si falla el disco principal, pierdes VMs y copias a la vez.
El problema de la RAM: “con 8 GB llego de sobra”
El primer error fue subestimar cuánta RAM consume cada VM. Tenía un mini PC con 8 GB y pensé que montando Proxmox podía levantar cuatro o cinco máquinas virtuales sin problema. Spoiler: no.
Proxmox en sí consume poco, pero cada VM ligera —una Ubuntu Server sin escritorio, por ejemplo— se lleva entre 512 MB y 2 GB solo para arrancar. Cuando intenté levantar Nextcloud, Pi-hole, un servidor de pruebas y un contenedor de monitorización al mismo tiempo, el sistema empezó a usar swap y todo se volvió lento hasta hacerse inutilizable.
La primera vez que vi el resultado de free -h al 94%, apagué dos VMs y empecé a replantearme todo el proyecto.
La solución fue ampliar la RAM —en ese equipo se podía llegar a 16 GB— y, sobre todo, aprender a distinguir entre contenedores LXC y VMs completas. Los contenedores comparten el kernel del host y consumen mucho menos. No siempre son la opción adecuada, pero para muchos servicios de homelab van perfectos.
Lo que haría diferente
- Calcular el consumo estimado de RAM antes de elegir el hardware.
- Priorizar LXC para servicios que no necesiten kernel propio.
- Empezar con dos o tres servicios, no con diez a la vez.
Todo en un disco, sin backups: la receta perfecta para perder trabajo
Segundo error clásico: instalar Proxmox, crear un montón de VMs con configuraciones a mano y no hacer ni una sola copia de seguridad. Todo en el mismo disco del sistema.
Un día ese disco empezó a dar errores SMART. Había pasado suficiente tiempo como para que yo ya no recordara exactamente cómo había configurado cada servicio. Perdí unas cuatro horas de trabajo de configuración que no había documentado en ningún sitio.
Proxmox tiene integración con Proxmox Backup Server (PBS) para hacer backups de VMs, pero PBS necesita almacenamiento separado: no puedes hacer backup en el mismo disco donde viven las VMs. Eso requiere al menos un disco adicional o almacenamiento en red, algo que en mi setup inicial no tenía.
Lo que aprendí
- Un segundo disco viejo de 500 GB para PBS es suficiente para empezar.
- Documentar al menos los pasos clave de configuración de cada servicio nuevo.
- Los snapshots de Proxmox no son backups: si el disco muere, el snapshot muere con él.
La red sin planificar: IPs estáticas a mano y sin VLANs
Tercer error: no pensar en la red desde el principio. Empecé asignando IPs estáticas a mano en cada VM, sin llevar ningún registro. A las dos semanas tenía conflictos de IP y no sabía qué máquina tenía qué dirección.
El siguiente problema fue que el tráfico del homelab iba por la misma red que el resto de dispositivos de casa. Un servidor de pruebas con configuraciones experimentales en la misma subred que el portátil de trabajo no es una idea especialmente buena.
La solución correcta pasa por un switch gestionado con soporte de VLANs para separar el tráfico del lab del resto de la red doméstica. Con un switch no gestionado, esto sencillamente no es posible.
No hace falta montarlo todo desde el día uno, pero reservar un rango de IPs para el homelab y documentarlo en algún sitio evita muchos dolores de cabeza. Yo tardé demasiado en hacer esto.
Cambios que hice después
- Un servidor DHCP propio con reservas fijas por MAC (dnsmasq en un contenedor LXC).
- Un switch gestionado de segunda mano para tener VLANs entre el lab y el resto de la red.
- Una hoja de cálculo simple con el inventario de IPs y hostnames.
El consumo eléctrico: lo que no calculé hasta que llegó la factura
Un servidor encendido 24/7 consume electricidad. Esto suena obvio, pero hasta que no tienes un vatímetro conectado al enchufe no te das cuenta de lo que suma a fin de mes.
Un mini PC eficiente puede rondar los 15-25 W en carga baja. Una torre de oficina reciclada puede irse fácilmente a 60-90 W. Con el precio medio del kWh en España rondando los 0,13-0,17 € según OMIE/REE en 2024, un servidor de 80 W encendido siempre son unos 85-90 € al año solo en electricidad. No es una fortuna, pero tampoco es gratis.
En mi caso tenía una torre con una tarjeta gráfica discreta que no usaba para nada en el servidor. La quité, el consumo bajó casi 30 W y el equipo empezó a hacer menos ruido de paso.
Pequeñas optimizaciones que ayudan
- Medir el consumo real con un enchufe inteligente o vatímetro antes de dejar el servidor 24/7.
- Quitar hardware que no uses: tarjetas gráficas discretas, unidades extra que no sirven.
- Valorar si merece la pena pagar ese consumo o apagar el servidor cuando no lo estés usando.
El hardware de servidor barato con sorpresa incluida: los discos SAS
Buscando discos de gran capacidad de segunda mano, me encontré con discos SAS a precios muy bajos. Son discos de servidor, robustos, con el kilometraje registrado. Pensé que era una ganga.
El problema es que los discos SAS no se conectan directamente a una placa base de consumo normal. Necesitan una controladora SAS, que puede costar más que los propios discos. Algunos modelos de controladoras también requieren drivers específicos que en Linux pueden ser un quebradero de cabeza adicional.
Al final opté por discos SATA de segunda mano de uso ofimático, con muchas menos horas y mucho más compatibles. Menos glamour, más funcionalidad práctica. A veces la opción aburrida es la correcta.
Querer aprenderlo todo el primer fin de semana
El error más difícil de confesar: quise montarlo todo a la vez. Proxmox, VLANs, Nextcloud, servidor de medios, monitorización con Grafana, VPN de acceso remoto… en un solo fin de semana. Resultado: nada funcionaba del todo bien, todo estaba a medias y no entendía bien por qué fallaba cada cosa.
Proxmox tiene una curva de aprendizaje real. La interfaz web es intuitiva para operaciones básicas, pero en cuanto tocas la red, el almacenamiento o la configuración avanzada de VMs, las cosas se complican. No es algo que se domine en dos días, y no pasa nada por ir despacio.
Lo que funcionó para mí fue montar un servicio, dejarlo estable y documentado, y solo entonces pasar al siguiente. Aburrido pero efectivo.
También aprendí que el acceso remoto seguro vale la pena configurarlo pronto. Abrir puertos directamente en el router doméstico es arriesgado y poco flexible. Tailscale tarda unos quince minutos en configurar y funciona de forma consistente; WireGuard da más control pero requiere más tiempo de configuración inicial. Cualquiera de las dos es mejor que exponer servicios directamente a internet desde casa.
El orden que recomendaría hoy
- Instalar Proxmox y entender la interfaz básica: VMs, LXC, red, almacenamiento.
- Montar un único servicio sencillo y dejarlo estable.
- Configurar backups antes de complicar más el setup.
- Añadir acceso remoto seguro (Tailscale o WireGuard).
- Planificar la red y las VLANs cuando el resto ya funcione.
Preguntas frecuentes
Q: ¿Cuánta RAM necesito realmente para empezar?
A: Depende de cuántas VMs quieras correr en paralelo. Cada VM ligera consume entre 512 MB y 2 GB mínimos, así que con 8 GB puedes arrancar 3-4 contenedores cómodamente, pero te quedarás corto en cuanto añadas una VM con escritorio. La RAM es el cuello de botella más común y el primer error que cometí ignorando.
Q: ¿Qué pasa si uso un disco SAS que tenía por casa?
A: Los discos SAS no se conectan directamente a placas base de consumo; necesitas una controladora HBA adicional. Sin ella, el disco simplemente no aparece. Es uno de esos errores que cuestan tiempo y dinero si no lo sabes de antemano.
Q: ¿Vale cualquier router doméstico para arranque PXE?
A: La mayoría de routers domésticos no soportan PXE de fábrica. Para arranque por red necesitas configurar opciones DHCP específicas (opción 66/67) que muy pocos routers de operadora permiten tocar. La solución habitual es montar un servidor DHCP propio, como dnsmasq en un contenedor LXC.
Q: ¿Cuánto me va a costar en luz tener el server encendido?
A: Depende del hardware y de tu tarifa, pero un servidor encendido 24/7 puede consumir entre 50 y 100 W. Con el precio medio del kWh en España (0,13-0,17 € según OMIE/REE en 2024), estás hablando de entre 40 y 85 € anuales. Con hardware de oficina reciclado y perfil de bajo consumo, puedes quedarte en la franja baja.
Q: ¿Por qué no puedo crear VMs dentro de otras VMs?
A: La virtualización anidada requiere que el procesador tenga VT-x y VT-d habilitados en BIOS, y no todos los procesadores de consumo los soportan igual. Los Intel Haswell, por ejemplo, tienen VT-x casi siempre, pero VT-d varía según el modelo exacto; hay que verificarlo en la ARK de Intel antes de asumir que va a funcionar.
Deja una respuesta