Referencia de Operaciones de Proxmox VE (Versión 9.1.2)
Los nodos, invitados y servicios pueden estar caídos, ser inalcanzables o desaparecer durante una operación. Nunca asuma que uno está activo: vuelva a consultar el estado real, reintente con un tiempo de espera y degrade de forma elegante. Para los patrones de autocuración, consulte bitranox:coding-resilience.
1. Configuración del Clúster (Detección Automática)
| Comprobación | Comando |
|---|---|
| Entorno | pveversion --verbose (versiones completas de componentes: kernel, pve-manager, corosync, qemu-server) |
| Nodos | pvecm nodes (recuento, nombres, IDs) / pvecm status (IPs, quorum, transporte, estados de enlace) |
| Quórum | pvecm status -- comprobar el campo "Quorate". Umbral: floor(total_nodes/2) + 1 |
| Acceso API | pvesh (CLI local), pveproxy (HTTPS :8006), API REST. Use --output-format json para scripts |
| Almacenamiento | pvesm status (almacenamientos activos) / cat /etc/pve/storage.cfg (configuración completa) |
| Red | pvesh get /nodes/{node}/network --output-format json / cat /etc/network/interfaces |
| Suscripción | pvesubscription get (comprobar estado) / pvesubscription set <key> (aplicar clave) |
2. Protocolos de Seguridad
| Regla | Detalles |
|---|---|
| Sin operaciones masivas destructivas | Los comandos que afectan a más de 1 nodo (reinicio, apagado, parada masiva de VMs) requieren confirmación explícita del usuario. |
| Comprobación de quórum | Antes del reinicio/mantenimiento del nodo: pvecm status. Si (current - 1) < floor(total/2) + 1 -- abortar. En clústeres de 2 nodos, comprobar QDevice. |
| Copia de seguridad primero | Antes de cambios en la configuración de VMs o actualizaciones, verificar que exista una copia de seguridad: pvesm list {storage} --content backup |
| Sin eliminación forzada | Nunca usar --purge o --force sin verificar el ID del recurso: qm config {vmid} o pct config {vmid} |
| Estado de HA | Antes de cambios en recursos HA: ha-manager status -- verificar que no haya migraciones/vallas en curso. |
| Cambios de red | Siempre hacer una prueba en vacío primero: ifreload -a -n (ifupdown2 no tiene --test). Nunca usar ifdown en un puente que transporte tráfico de invitados. Aplicación remota y trampas de DHCP/bond/WLAN: references/host-networking.md. |
| Configuración de Corosync | Copiar primero, editar la copia, hacer copia de seguridad de la actual, luego mover. Siempre incrementar config_version. |
| Operaciones de almacenamiento | Antes de eliminar almacenamiento: pvesm list {storage} para verificar que ninguna VM/CT haga referencia a él. |
| Indicador de protección | qm set {vmid} --protection 1 / pct set {vmid} --protection 1 para evitar eliminaciones accidentales. |
| Barridos de propiedades ZFS | PVE almacena el tamaño de disco configurado de un invitado COMO el refquota del conjunto de datos. Un barrido que limpia refquota/refreservation en todos los conjuntos de datos elimina silenciosamente el límite de disco de cada invitado mientras que pct config aún informa el tamaño anterior, por lo que un contenedor puede llenar el pool. Excluir nombres de hojas que comiencen con subvol- o vm-. |
3. Protocolo de Revisión de Acciones
Obligatorio. Realice esta revisión antes de cada acción ejecutada directamente en un nodo, VM o contenedor de Proxmox (comandos, cambios de configuración, operaciones de servicio).
Excepción: Las operaciones de solo lectura (leer registros, consultar estado, recopilar información sin realizar cambios) se consideran seguras y se pueden realizar inmediatamente sin esta revisión.
Ejecute esta compuerta en
opus. Este juicio de fortaleza / equipo rojo controla un cambio en la infraestructura EN VIVO: un modelo más débil infravalora el riesgo de interrupción, pérdida de datos y quórum. Realice la revisión enopus: delegue a un subagenteopusfijado con esfuerzomedium(revisión de despachos, consulte bitranox:process-agents-subagent-driven-development "Despachos de revisión"), o (si lo mantiene en línea) ofrezca cambiar de modelo o continuar ANTES de ejecutar. Nunca ejecute esta compuerta en un nivel inferior desconocido. Consultebitranox:process-agents-subagent-driven-development("El modelo de sesión es fijo" / "Niveles concretos").
3.1 Indicación de Fortaleza
Considere la acción o configuración planificada que se ejecutará en el servidor Proxmox en su forma ideal y más exitosa. Imagine que esta acción representa la solución más segura, eficiente y óptimamente integrada. Articule cómo esta acción cumple perfectamente los objetivos de la administración del sistema, aumenta la estabilidad y satisface plenamente las necesidades del usuario.
3.2 Indicación de Equipo Rojo
Revise la acción planificada de Proxmox como si fuera un administrador experimentado o un analista de seguridad que busca descubrir riesgos potenciales. Identifique posibles debilidades en la configuración, considere riesgos de interrupción, pérdida de datos o efectos secundarios no deseados. Pruebe la robustez del plan bajo escenarios del peor caso para asegurarse de que siga siendo seguro y confiable incluso bajo presión.
3.3 Decisión
Al final de la revisión del equipo rojo, evalúe si los riesgos o debilidades identificados son lo suficientemente graves como para detener la acción planificada. Si la acción parece segura, lógica y robusta, se puede ejecutar inmediatamente. Si quedan incertidumbres significativas, se debe pedir confirmación explícita al usuario. Concluya con una decisión clara: "Ejecutar acción" o "Preguntar al usuario para confirmación".
4. Estilo de Código y Respuesta
- Respuestas: Cortas, precisas, centradas en CLI (
pvesh,pvecm,pvesm,qm,pct,ha-manager,vzdump,pvesr,pvenode,pveceph,pveum,pveam). - Solución de problemas: Siempre consulte primero los registros:
journalctl -u pvedaemon -n 50,pvenode task list --errors 1,/var/log/pveproxy/access.log. - Preferencia JSON: Use
--output-format jsonojson-pretty. Use--noborder --noheaderpara análisis mediante scripts. - Plan de reversión: Cada cambio debe incluir una reversión. Primero haga una copia de seguridad de los archivos de configuración. Asegúrese de que existan copias de seguridad antes de cambios en almacenamiento/VMs.
5. Tabla Rápida de Tamaño de Clúster
| Tamaño | Comportamiento |
|---|---|
| Nodo único | Sin operaciones de clúster. Sin HA. Enfoque en almacenamiento local + copias de seguridad externas. |
| 2 nodos | QDevice muy recomendado. Sin él: pérdida de 1 nodo = pérdida de quórum. pvecm expected 1 para emergencia. |
| 3+ nodos | HA completo. Tolera floor((N-1)/2) fallos (3 nodos: 1, 5 nodos: 2). |
Detectar recuento de nodos: pvecm nodes | grep -c '^\s*[0-9]'
6. Referencia Rápida de Solución de Problemas
| Problema | Diagnóstico |
|---|---|
| El clúster no tiene quórum | pvecm status > "Quorate: No". Comprobar conectividad, systemctl status corosync. Emergencia: pvecm expected 1. |
| El nodo no se une | Verificar UDP 5405-5412, sincronización de hora, SSH (TCP 22). Probar: pvecm add {IP} --fingerprint {SHA256}. |
| La VM no arranca | Comprobar bloqueo: ... |
[truncado para traducción]