Referência de Operações do Proxmox VE (Versão 9.1.2)
Nós, convidados e serviços podem estar inativos, inacessíveis ou desaparecer durante uma operação. Nunca presuma que algo está ativo:
consulte novamente o estado real, tente novamente com um limite de tempo e degrade graciosamente. Para os padrões de autocura, consulte bitranox:coding-resilience.
1. Configuração do Cluster (Auto-Detecção)
| Verificação | Comando |
|---|---|
| Ambiente | pveversion --verbose (versões completas dos componentes: kernel, pve-manager, corosync, qemu-server) |
| Nós | pvecm nodes (contagem, nomes, IDs) / pvecm status (IPs, quorum, transporte, estados dos links) |
| Quorum | pvecm status -- verificar o campo "Quorate". Limiar: floor(total_nodes/2) + 1 |
| Acesso à API | pvesh (CLI local), pveproxy (HTTPS :8006), API REST. Utilize --output-format json para scripts |
| Armazenamento | pvesm status (armazenamentos ativos) / cat /etc/pve/storage.cfg (configuração completa) |
| Rede | pvesh get /nodes/{node}/network --output-format json / cat /etc/network/interfaces |
| Assinatura | pvesubscription get (verificar status) / pvesubscription set <key> (aplicar chave) |
2. Protocolos de Segurança
| Regra | Detalhes |
|---|---|
| Sem operações destrutivas em massa | Comandos que afetam >1 nó (reinicializar, desligar, parar VMs em massa) exigem confirmação explícita do usuário. |
| Verificação de quorum | Antes de reinicializar/manutenção do nó: pvecm status. Se (current - 1) < floor(total/2) + 1 -- abortar. Em clusters de 2 nós, verificar o QDevice. |
| Backup primeiro | Antes de alterações de configuração de VM ou atualizações, verificar se o backup existe: pvesm list {storage} --content backup |
| Sem exclusão forçada | Nunca use --purge ou --force sem verificar o ID do recurso: qm config {vmid} ou pct config {vmid} |
| Status de HA | Antes de alterações em recursos HA: ha-manager status -- verificar se não há migrações/fencing em andamento. |
| Alterações de rede | Sempre teste primeiro em seco: ifreload -a -n (ifupdown2 não tem --test). Nunca use ifdown em uma bridge que transporta tráfego de convidados. Aplicação remota e armadilhas DHCP/bond/WLAN: references/host-networking.md. |
| Configuração do Corosync | Copie primeiro, edite a cópia, faça backup da atual e depois mova. Sempre incremente o config_version. |
| Operações de armazenamento | Antes de remover armazenamento: pvesm list {storage} para verificar se nenhuma VM/CT o referencia. |
| Flag de proteção | qm set {vmid} --protection 1 / pct set {vmid} --protection 1 para evitar exclusão acidental. |
| Varreduras de propriedades ZFS | O PVE armazena o tamanho de disco configurado de um convidado COMO o refquota do dataset. Uma varredura que limpa refquota/refreservation em todos os datasets remove silenciosamente o limite de disco de cada convidado, enquanto o pct config ainda relata o tamanho antigo, permitindo que um contêiner encha o pool. Excluir nomes de folha que começam com subvol- ou vm-. |
3. Protocolo de Revisão de Ação
Obrigatório. Realize esta revisão antes de cada ação executada diretamente em um nó Proxmox, VM ou contêiner (comandos, alterações de configuração, operações de serviço).
Exceção: Operações somente leitura - ler logs, consultar status, coletar informações sem alterar nada - são consideradas seguras e podem ser realizadas imediatamente sem esta revisão.
Execute esta verificação no
opus. Este julgamento steelman / red-team controla uma alteração na infraestrutura AO VIVO - um modelo mais fraco subestima o risco de interrupção, perda de dados e quorum. Faça a revisão noopus: delegue-a a um subagenteopusfixo com esforçomedium(revisão de despacho, veja bitranox:process-agents-subagent-driven-development "Despachos de revisão"), ou (se você mantê-la inline) ofereça alterar-modelo-ou-continuar ANTES de executar. Nunca execute esta verificação em um nível inferior desconhecido. Consultebitranox:process-agents-subagent-driven-development("O modelo da sessão é fixo" / "Níveis concretos").
3.1 Prompt Steelman
Considere a ação ou configuração planejada para ser executada no servidor Proxmox em sua forma ideal e mais bem-sucedida. Imagine que esta ação representa a solução mais segura, eficiente e perfeitamente integrada. Articule como esta ação cumpre perfeitamente os objetivos da administração do sistema, aumenta a estabilidade e atende totalmente às necessidades do usuário.
3.2 Prompt Red-Team
Revise a ação Proxmox planejada como se você fosse um administrador experiente ou analista de segurança que busca descobrir riscos potenciais. Identifique possíveis pontos fracos na configuração, considere riscos de interrupção, perda de dados ou efeitos colaterais não intencionais. Teste a robustez do plano sob cenários de pior caso para garantir que ele permaneça seguro e confiável mesmo sob pressão.
3.3 Decisão
Ao final da revisão red-team, avalie se os riscos ou pontos fracos identificados são graves o suficiente para interromper a ação planejada. Se a ação parecer segura, lógica e robusta, ela pode ser executada imediatamente. Se permanecerem incertezas significativas, o usuário deve ser explicitamente solicitado a confirmar. Conclua com uma decisão clara: ou "Executar ação" ou "Perguntar ao usuário para confirmação".
4. Estilo de Código e Resposta
- Respostas: Curtas, precisas, focadas em CLI (
pvesh,pvecm,pvesm,qm,pct,ha-manager,vzdump,pvesr,pvenode,pveceph,pveum,pveam). - Solução de problemas: Sempre consulte os logs primeiro:
journalctl -u pvedaemon -n 50,pvenode task list --errors 1,/var/log/pveproxy/access.log. - Preferência por JSON: Utilize
--output-format jsonoujson-pretty. Utilize--noborder --noheaderpara análise em scripts. - Plano de reversão: Toda alteração deve incluir reversão. Faça backup dos arquivos de configuração primeiro. Certifique-se de que os backups existem antes de alterações de armazenamento/VM.
5. Tabela Rápida de Tamanho do Cluster
| Tamanho | Comportamento |
|---|---|
| Nó único | Sem operações de cluster. Sem HA. Foco em armazenamento local + backups externos. |
| 2 nós | QDevice fortemente recomendado. Sem ele: perda de 1 nó = perda de quorum. pvecm expected 1 para emergência. |
| 3+ nós | HA completo. Tolerar floor((N-1)/2) falhas (3 nós: 1, 5 nós: 2). |
Detectar contagem de nós: pvecm nodes | grep -c '^\s*[0-9]'
6. Referência Rápida de Solução de Problemas
| Problema | Diagnóstico |
|---|---|
| Cluster sem quorum | pvecm status > "Quorate: No". Verificar conectividade, systemctl status corosync. Emergência: pvecm expected 1. |
| Nó não consegue entrar | Verificar UDP 5405-5412, sincronização de tempo, SSH (TCP 22). Tentar: pvecm add {IP} --fingerprint {SHA256}. |
| VM não inicia | Verificar bloqueio: |
...
[truncado para tradução]