La instalación deja un nodo operativo, pero todavía no define cómo se administrará, dónde vivirán las VMs, qué red usarán ni cómo se separará la operación de los datos. EP013 cubre ese tramo: convertir un Proxmox recién instalado en una plataforma preparada para virtualizar con orden.
1. Qué significa “configuración inicial”
Configurar inicialmente Proxmox VE significa establecer una base coherente para el resto de la plataforma: proteger el acceso, revisar la identidad del nodo, confirmar la red, actualizar paquetes, entender los storages disponibles y verificar que el sistema está listo para recibir una primera VM.
No es todavía un diseño completo de producción. Es una línea base. Si esa línea base está mal, los problemas aparecerán después como pérdida de conectividad, discos llenos, imágenes que no se pueden crear o respaldos mezclados con la operación.
2. Primer acceso y cambio de contraseña
Desde otro equipo se abre el panel web usando la dirección HTTPS mostrada por la consola del nodo. El primer objetivo es comprobar que el acceso funciona y cambiar la contraseña inicial por una credencial robusta, única y protegida.
- Confirmar que la URL corresponde al nodo correcto.
- Iniciar sesión con la cuenta configurada en EP012.
- Revisar la hora y el nombre del nodo.
- Cambiar la contraseña desde la sección de permisos o usuarios.
- Registrar quién administra el nodo y dónde se custodia la credencial.
En producción, el acceso debe limitarse a redes y personas autorizadas. La interfaz web facilita la operación, pero no sustituye controles de acceso, MFA cuando corresponda, segmentación y auditoría.
3. Configuración de red: vmbr0 y la identidad del nodo
La instalación suele crear un bridge llamado vmbr0 conectado a la primera interfaz física. El bridge actúa como un switch virtual: las VMs pueden conectarse a él y aparecer en la red como equipos independientes. Esta relación está descrita en la guía oficial de administración de Proxmox.
Antes de cambiar la red, documenta IP, máscara, gateway, DNS, VLAN y nombre del equipo. Un error de red puede cortar el acceso al panel y obligar a recuperar el nodo desde consola.
Qué validar
- El hostname es único y coherente con DNS.
- La IP pertenece al segmento correcto.
- El gateway permite salir a las redes necesarias.
- El DNS resuelve nombres internos y externos según la política.
- La interfaz física y vmbr0 muestran estado activo.
4. Actualizar el sistema con control
Un nodo recién instalado debe revisarse y actualizarse antes de alojar cargas. La infografía muestra la actualización desde Shell con apt update y apt upgrade -y; la documentación vigente puede indicar el procedimiento exacto según la versión y el repositorio.
No conviene ejecutar comandos a ciegas en un nodo de producción. Primero se confirma la suscripción o repositorio configurado, se revisan avisos, se toma una ventana de mantenimiento y se documenta el resultado. Después de actualizar, se valida si hace falta reiniciar y se comprueba que el panel y la red siguen operativos.
5. Qué es un storage en Proxmox VE
Un storage es una definición lógica que indica dónde y qué puede guardar Proxmox. La misma plataforma puede trabajar con almacenamiento local o compartido. La guía oficial enumera, entre otros, Directory, LVM, ZFS, NFS, CIFS/SMB, iSCSI y Ceph.
| Tipo | Uso habitual | Decisión principal |
|---|---|---|
| Directory | ISOs, plantillas, backups o discos en un sistema de archivos | Controlar ruta, permisos y espacio. |
| LVM / LVM-thin | Discos de máquinas virtuales | Conocer capacidad y crecimiento del thin pool. |
| NFS / SMB | Recursos compartidos de red | Validar latencia, permisos y disponibilidad. |
| iSCSI | Bloques remotos para escenarios específicos | Diseñar red y multipath si aplica. |
| ZFS / Ceph | Funciones avanzadas locales o distribuidas | Dimensionar memoria, discos y operación. |
La tabla orienta; no sustituye el diseño. Un storage para ISOs no tiene el mismo propósito que uno para discos de VMs o backups.
6. Crear el primer almacenamiento
La infografía muestra la ruta Datacenter > Storage > Add. El procedimiento conceptual es:
- Definir el propósito: discos, ISO, plantillas, contenedores o backup.
- Confirmar el dispositivo o ruta que se utilizará.
- Elegir el tipo de storage compatible.
- Asignar un identificador claro y único.
- Seleccionar el contenido permitido.
- Guardar y comprobar el estado “Active”.
El error más común es crear un storage sin saber qué guardará. El nombre “local” puede ser correcto técnicamente, pero no explica por sí solo si contiene ISOs, discos, backups o varias clases de contenido.
7. Ejemplo empresarial
Una empresa tiene un nodo independiente con dos espacios: un almacenamiento local para el sistema y un segundo recurso destinado a máquinas virtuales. El administrador define un storage para ISOs y plantillas, otro para discos de VMs y reserva un recurso separado para backups.
Antes de crear la primera VM, verifica que el storage de discos tenga capacidad suficiente, que el storage de ISOs permita subir la imagen necesaria y que el destino de backup no sea el mismo disco que se quiere proteger. Así evita que una falla del almacenamiento local destruya simultáneamente operación y recuperación.
8. Escenario práctico
Diseña el storage inicial de un laboratorio con estas necesidades: una VM Windows, un contenedor Linux, una ISO de instalación y copias semanales.
- Indica qué contenido debe aceptar cada storage.
- Explica qué ocurriría si guardas las copias en el mismo disco que las VMs.
- Define tres pruebas para comprobar que el almacenamiento funciona.
- Especifica qué dato registrarías para poder ampliar capacidad después.
9. Verificación final: “listo para virtualizar”
El nodo no está listo solo porque el storage aparezca en pantalla. Debes comprobar:
- Acceso web y credenciales actualizadas.
- Hostname, hora y DNS correctos.
- Red activa y vmbr0 operativo.
- Paquetes actualizados según la política.
- Storage en estado Active.
- Capacidad visible y suficiente.
- Permisos de contenido coherentes.
- Plan de backup definido antes de crear cargas críticas.
Con estas evidencias, EP014 podrá concentrarse en crear la primera máquina virtual sin repetir la preparación del nodo.
10. Buenas prácticas y errores frecuentes
Buenas prácticas
- Usar nombres descriptivos para storages.
- Separar operación, ISOs y backups cuando sea posible.
- Documentar capacidad total y disponible.
- Probar lectura, escritura y creación de un recurso pequeño.
- Revisar alertas y estado después de actualizar.
Errores frecuentes
- Cambiar la IP sin consola o plan de recuperación.
- Guardar backups en el mismo disco que las VMs.
- Activar contenidos que el storage no puede soportar.
- Ignorar permisos de NFS, SMB o iSCSI.
- Confundir storage “activo” con storage respaldado.
Preguntas frecuentes
¿Puedo usar el mismo storage para todo?
Es posible en un laboratorio pequeño, pero no siempre es conveniente. Separar propósitos ayuda a controlar capacidad, rendimiento, permisos y recuperación.
¿Qué diferencia hay entre local y local-lvm?
Depende del diseño creado por el instalador. “local” suele representar un directorio para contenidos como ISO y plantillas, mientras que “local-lvm” suele representar un pool de bloques para discos de VMs. Debes verificar la configuración real del nodo.
¿Un storage NFS reemplaza un backup?
No. NFS es una forma de almacenamiento compartido; el backup es una copia gestionada con política, retención y pruebas de restauración.
¿Qué hago si el storage aparece inactivo?
Revisa ruta, permisos, montaje, red, DNS, credenciales y logs. No crees VMs sobre un storage cuyo estado todavía no esté explicado.
Conclusión
EP013 convierte una instalación básica en una plataforma organizada. Proteger el acceso, estabilizar la red, actualizar con control y definir el primer almacenamiento son pasos distintos, pero forman una sola línea base operativa. Cuando esa base está verificada, el nodo queda preparado para crear la primera máquina virtual.