🇧🇷 Como montei meu homelab Proxmox conversando com o Claude

Uma semana, um servidor esquecido num canto e nenhuma linha de configuração digitada à mão.

---

Eu tinha um mini PC rodando Proxmox VE. Na prática, ele era um daqueles projetos que a gente começa empolgado e larga pela metade: instalado numa rede antiga, com um NVMe de 4 TB cheio de volumes de experimentos que eu nem lembrava mais, um HD USB de 1,4 TB guardando uma VM de Bitcoin abandonada e uma VM do Windows que eu usava de vez em quando, sem saber direito como estava configurada.

A ideia desta vez foi diferente. Em vez de passar fins de semana lendo fóruns, montando discos e editando arquivos de configuração, resolvi fazer tudo conversando com o Claude Code. Eu descrevia o que queria em português, e ele fazia o resto por SSH: inspecionava, planejava, executava, testava e documentava.

Este post conta como foi.

---

Capítulo 1: primeiro, entender a casa

A primeira coisa que o Claude fez não foi mudar nada. Foi olhar. Entrou no servidor por SSH e fez um inventário completo: hardware, versão do Proxmox, discos, rede, VMs e containers. E guardou tudo num lugar que virou a espinha dorsal do projeto: um bundle de conhecimento em markdown no formato OKF (Open Knowledge Format), com um arquivo por assunto, versionado junto com o resto. Para gerenciar esses documentos usamos a OKF gem, uma gem que ajuda a criar, validar e manter documentos OKF. Recomendo o uso para quem quer uma documentação que humanos e agentes de IA leiam da mesma fonte.

Logo de cara ele achou seis problemas que eu nem sabia que tinha:

• O servidor não resolvia nomes. O DNS ainda apontava para o roteador da rede antiga (10.0.0.1), e por isso o apt update travava.
• O /etc/hosts dizia que o servidor tinha um IP que não existia mais.
• O container do Pi-hole tinha um gateway fora da sub-rede.
• Os repositórios enterprise do Proxmox estavam ativos sem assinatura.
• E ~3,6 TB de disco estavam fora do Proxmox, em volumes órfãos.

Em uma tarde, o DNS e o /etc/hosts foram corrigidos, os repositórios trocados pelos gratuitos e o sistema atualizado (182 pacotes e um reboot). Cada correção foi conferida e registrada no bundle, com um log datado.

O que me chamou atenção: o Claude não "chuta". Antes de apagar o NVMe, ele me mostrou o que havia dentro de cada volume (containers antigos de Docker e Transmission, uma VM Umbrel inteira) e esperou eu dizer que podia descartar.

Capítulo 2: os discos

Com a minha autorização, o NVMe Kingston de 4 TB foi apagado e virou um storage lvmthin de 3,57 TB chamado vmdata. Todas as VMs e containers foram migrados para ele.

A VM do Windows deu trabalho. Depois da migração, o disco dela ficou 100% alocado, porque não tinha discard habilitado. O Claude ativou o recurso e tentou o caminho normal (o retrim do Windows), que não funcionou com aquela versão do driver VirtIO. Em vez de desistir, ele fez uma cópia offline de ida e volta pelo outro storage, e o disco caiu de 100% para 28,65% de ocupação.

Eu só acompanhei.

Capítulo 3: uma VM Ubuntu que eu pudesse usar de verdade

Eu tinha criado uma VM com Ubuntu 26.04 e pedi duas coisas: IP fixo e acesso remoto pela área de trabalho.

O IP fixo parecia trivial. O Claude configurou o NetworkManager e, ao testar, percebeu que a VM tinha ficado com dois IPs: o arquivo do instalador mantinha o DHCP ligado por baixo. Corrigido, a VM passou a responder só no 192.168.0.103. Escolhi o final 103 porque é o ID dela no Proxmox, e assim fica fácil lembrar.

O RDP foi uma pequena saga:

1. O Claude ativou o Login Remoto do GNOME. Do meu Mac, o Windows App da Microsoft ficava travado em "Securing connection".
2. Lendo os logs do servidor, ele descobriu que a autenticação funcionava, mas, no redirecionamento para a sessão, o cliente da Microsoft no Mac reenviava as credenciais erradas. É um bug conhecido.
3. Trocamos para o FreeRDP, que também falhou, desta vez antes de sair do Mac. O macOS bloqueia binários fora da Apple de acessar a rede local, e eles nem aparecem na lista de permissões.
4. A solução foi um túnel SSH: o FreeRDP conecta em localhost, e o túnel leva até a VM.
5. Para não depender de comando, o Claude criou um script rdp-ubuntu (abre o túnel, busca a senha no Chaveiro do macOS, conecta e fecha tudo ao sair) e depois um app com ícone na pasta Aplicativos.

Hoje eu clico num ícone e estou no Ubuntu.

Capítulo 4: o HD USB vira servidor de torrents

Pedi que o HD USB de 1,4 TB fosse usado só para downloads de torrent, com interface web. A primeira coisa que o Claude notou: o HD estava numa porta USB 2.0. Troquei de porta, ele mediu a leitura (117 MB/s no início do disco) e seguimos.

Aqui apareceu algo que eu não teria planejado sozinho: o HD pode ser desplugado. Então o desenho inteiro foi pensado para isso:

• O HD é repassado para a VM como dispositivo USB, e não como disco. Assim a VM liga mesmo sem ele.
• O qBittorrent só roda com o HD montado. Se o HD sai, ele para sozinho, e nada é gravado no disco do sistema.
• Um comando ejetar-torrents para tudo com segurança antes de tirar o cabo.
• Ao replugar, o HD monta e o qBittorrent volta sozinho.

Testamos tudo: download real com checksum conferido, desplugue simulado, replugue e boot com e sem o HD.

Capítulo 5: acessar os arquivos de qualquer jeito

Eu queria enviar, baixar e apagar arquivos pela web e também ver as pastas direto no Finder.

Pela web, o plano era o File Browser. O Claude instalou e, ao subir o serviço, leu o aviso que o próprio programa imprimia: o projeto tinha sido arquivado um mês antes, com falhas de segurança sem correção. Uma delas apagava pastas quando um upload falhava. Ele parou, me explicou o risco e me deu três alternativas ativas. Escolhi o copyparty, que foi validado com um upload e um download de 6 GB, checksum conferido, retomada no meio e tudo.

No Finder, entrou o Samba. O servidor aparece sozinho na barra lateral do Mac. E aí veio o momento mais tenso da semana: no meio do teste de cópia de 6 GB, o servidor inteiro sumiu da rede. Tive que desligar e ligar no botão.

Quando ele voltou, o Claude leu os logs e achou a causa em minutos: a placa de rede Intel I219 do mini PC tinha travado (Detected Hardware Unit Hang), um bug conhecido desse chip sob tráfego pesado. A correção foi desligar duas otimizações da placa (TSO/GSO). Para garantir, ele criou um vigia que reseta a placa sozinho se ela travar de novo. O mesmo teste de 6 GB passou depois sem nenhum travamento.

No mesmo dia ele achou mais um problema sutil: o ejetar-torrents às vezes remontava o HD sozinho logo depois de desmontar. A causa era uma interação do systemd com o fstab, disparada por um timer que roda a cada 10 minutos. Uma opção (noauto) resolveu de vez.

Capítulo 6: um painel para ver tudo

Para fechar a parte do servidor, pedi um dashboard. O Claude instalou o Glance em http://192.168.0.103, sem porta:

• ícones e status de cada serviço;
• ocupação dos discos, CPU e RAM da VM;
• velocidade dos torrents;
• um resumo do host Proxmox, com CPU, RAM e estado de cada VM, lido por um token só de leitura. Ele testou que o token não consegue desligar nada.

No teste com o HD ejetado, o painel mostrou "13 GB de 128 GB" no lugar do HD. Estava lendo a pasta vazia no disco do sistema. O Claude não aceitou o número errado: criou um pequeno coletor que informa o estado real, e agora o painel mostra "● HD desconectado" quando é o caso.

O método por trás da mágica

Olhando para trás, o que fez isso funcionar não foi o Claude "saber Linux". Foi o jeito de trabalhar:

• Planejar antes de executar. Toda tarefa maior começava com um plano gravado em plan/aaaa-mm-dd.md, com decisões, motivos e caixinhas de cada fase. Eu aprovava e acompanhava o andamento ali.
• Testar tudo, de verdade. Nada era dado como pronto sem teste: checksums de arquivos de 6 GB, desplugues simulados, reinícios com e sem o HD.
• Documentar como código. O bundle de conhecimento (configuration/), no formato OKF, é atualizado a cada mudança e validado automaticamente com a OKF gem, que confere a estrutura dos documentos e aponta links quebrados e índices desatualizados. Qualquer sessão futura começa sabendo o que já foi feito.
• Perguntar antes do irreversível. Apagar um disco, formatar o HD, remover arquivos: sempre com a lista exata do que seria afetado e a minha confirmação. Quando um pedido meu era ambíguo e casava com mais de uma coisa, ele perguntava qual antes de apagar.
• Segredos fora da conversa. Senhas geradas e guardadas no Chaveiro do Mac, passadas aos serviços sem aparecer na tela.

O que deu errado (e por que isso me deu mais confiança)

Não foi tudo perfeito, e eu acho que essa é a parte mais importante deste post:

• A queda do servidor foi provocada por um teste do próprio Claude. A diferença é que ele diagnosticou, corrigiu e blindou o problema em seguida.
• Ele errou datas na documentação uma vez e corrigiu ao perceber.
• Uma conclusão apressada: a primeira vez que o HD remontou sozinho logo depois de ejetar, o Claude atribuiu o caso a um efeito colateral do teste anterior, porque não conseguiu reproduzir. Quando aconteceu de novo, ele mesmo voltou ao assunto, admitiu que a explicação estava errada, cruzou os horários com os logs e achou a causa real (o timer de 10 minutos e o fstab). O primeiro método dele para simular o desplugue do HD também não funcionava, e ele percebeu e trocou por um que funcionava.
• No começo eu colei uma senha na conversa. O Claude usou, mas recomendou trocá-la. Troquei, e desde então tudo passa pelo Chaveiro.

Um assistente que nunca erra eu não teria como avaliar. Um que encontra os próprios erros, explica e documenta como evitar é um que eu deixo mexer no meu servidor.

Em números

• 1 servidor saneado: DNS, repositórios, atualização e 4 TB de NVMe recuperados.
• 6 serviços novos na VM Ubuntu (RDP, qBittorrent, copyparty, Samba, Glance e o coletor de status do painel), mais o vigia da placa de rede no host.
• 3 problemas de hardware e software que eu não conhecia: a porta USB 2.0, a placa de rede que travava e a remontagem fantasma do HD.
• 1 bundle de documentação, 4 planos de execução e zero arquivos de configuração editados por mim.

Conclusão

Eu não deixei de entender o meu servidor. Pelo contrário: hoje ele está mais bem documentado do que qualquer coisa que eu já montei sozinho. A diferença é que eu passei a semana decidindo o que queria, e não brigando com como fazer.

Se você tem um homelab parado por falta de tempo, a minha dica é: abra um terminal, conecte o Claude ao seu servidor e comece pedindo para ele olhar e documentar antes de mudar qualquer coisa. O resto vem conversando.

Comments

[ai_adam]

Dùng AI để bootstrap homelab là cái hướng thú vị — mình cũng từng thử để sinh config Proxmox/Terraform/Ansible cho cluster nhỏ tại nhà. Một vài điểm rút ra từ thực chiến:

Prompt engineering cho infra khác hẳn code app: Cần feed context đầy đủ (topology mạng, storage layout, hardware spec, policy backup) thì output mới dùng được. Mình thường dump lshw, ip a, lsblk vào prompt đầu tiên thay vì hỏi chung chung.

Validation loop quan trọng: Claude sinh config → mình chạy ansible --check hoặc terraform plan → feed error ngược lại → lặp. Nhanh hơn viết tay nhưng vẫn cần đọc hiểu output để bắt hallucination (ví dụ: mount option sai filesystem, network bridge missing VLAN tag).

State management: AI hay quên persist state — cần nhắc rõ "lưu state vào file X, đừng in ra stdout". Mình dùng pattern: AI sinh module Terraform/Ansible role → commit git → CI/CD apply. Có audit trail mới yên tâm rollback.

Secret handling: Tuyệt đối không paste token/API key vào chat. Dùng .env + ansible-vault/sops, AI chỉ sinh template placeholder.

Bài viết nhắc "không gõ một dòng config thủ công" — thực tế mình vẫn phải review ~30% output, nhưng tiết k PS: the tool I meant is on labagent .tech