[{"content":"","date":"24 de setembro de 2026","externalUrl":null,"permalink":"/pt/tags/amprs/","section":"Tags","summary":"","title":"Amprs","type":"tags"},{"content":"","date":"24 de setembro de 2026","externalUrl":null,"permalink":"/pt/categories/architecture/","section":"Categories","summary":"","title":"Architecture","type":"categories"},{"content":"","date":"24 de setembro de 2026","externalUrl":null,"permalink":"/pt/tags/architecture/","section":"Tags","summary":"","title":"Architecture","type":"tags"},{"content":"","date":"24 de setembro de 2026","externalUrl":null,"permalink":"/pt/categories/","section":"Categories","summary":"","title":"Categories","type":"categories"},{"content":"","date":"24 de setembro de 2026","externalUrl":null,"permalink":"/pt/tags/design/","section":"Tags","summary":"","title":"Design","type":"tags"},{"content":"","date":"24 de setembro de 2026","externalUrl":null,"permalink":"/pt/tags/design-decisions/","section":"Tags","summary":"","title":"Design-Decisions","type":"tags"},{"content":"","date":"24 de setembro de 2026","externalUrl":null,"permalink":"/pt/","section":"Do homelab à nuvem híbrida","summary":"","title":"Do homelab à nuvem híbrida","type":"page"},{"content":"","date":"24 de setembro de 2026","externalUrl":null,"permalink":"/pt/tags/infrastructure/","section":"Tags","summary":"","title":"Infrastructure","type":"tags"},{"content":"","date":"24 de setembro de 2026","externalUrl":null,"permalink":"/pt/posts/","section":"Posts","summary":"","title":"Posts","type":"posts"},{"content":"","date":"24 de setembro de 2026","externalUrl":null,"permalink":"/pt/tags/racr/","section":"Tags","summary":"","title":"Racr","type":"tags"},{"content":"Em resumo: RACR (Requirements, Assumptions, Constraints, Risks — Requisitos, Premissas, Restrições e Riscos) registra o que o design precisa entregar e sobre o que ele se apoia. AMPRS (Availability, Manageability, Performance, Recoverability, Security) avalia como cada decisão afeta as cinco qualidades de infraestrutura. Use o RACR para enquadrar o problema, o AMPRS para julgar a resposta e rastreie cada decisão até os dois.\nEnquanto me preparo para a certificação de VCF Architect, esbarrei em um tópico que vai muito além da prova. RACR e AMPRS são coisas que eu já aplico no dia a dia, muitas vezes sem dar nome, toda vez que avalio um design ou uma proposta. Estudar isso de forma estruturada me fez parar para refletir, e este post é o resultado dessa reflexão.\nA maioria dos designs de infraestrutura não falha porque alguém escolheu o produto errado. Falha porque ninguém anotou por que uma escolha foi feita, o que se assumiu como verdade e quanto ela custaria em outro lugar. Seis meses depois alguém pergunta \u0026ldquo;por que esse cluster é estendido?\u0026rdquo; e a única resposta é \u0026ldquo;pareceu uma boa ideia\u0026rdquo;.\nRACR e AMPRS são as duas lentes que uso para evitar isso. Elas vêm do mundo da metodologia de design VMware/VCDX, mas funcionam para qualquer coisa: um cluster vSphere, uma plataforma Kubernetes, uma estratégia de backup ou avaliar se uma proposta de fornecedor faz sentido.\nO que é RACR? # RACR é um método de enquadramento de design que classifica cada informação recebida em Requisitos, Premissas, Restrições e Riscos antes de qualquer solução ser escolhida.\nCada categoria tem um significado preciso, e misturá-las é o erro mais comum:\nItem Definição Exemplo Requisito (Requirement) Algo que o design precisa entregar. Funcional (o que faz) ou não funcional (quão bem faz). \u0026ldquo;VMs Tier-1 devem tolerar a perda de um host sem impacto no serviço.\u0026rdquo; Premissa (Assumption) Algo que se acredita ser verdade, mas não foi verificado. Toda premissa precisa de um dono e de uma validação. \u0026ldquo;O link WAN do cliente tem pelo menos 1 Gbps disponível para replicação.\u0026rdquo; Restrição (Constraint) Algo que limita as escolhas e não pode ser alterado pelo arquiteto. \u0026ldquo;Deve reutilizar o storage Fibre Channel existente até 2028.\u0026rdquo; Risco (Risk) Algo que pode acontecer e prejudicar os objetivos do design, com uma mitigação. \u0026ldquo;Um único storage é ponto único de falha para todos os clusters.\u0026rdquo; Regra prática: se dá para negociar, é requisito; se não dá, é restrição; se você não verificou, é premissa; se pode dar errado, é risco.\nO que é AMPRS? # AMPRS é um modelo de avaliação que mede cada decisão de design contra cinco qualidades de infraestrutura: Disponibilidade, Gerenciabilidade, Performance, Recuperabilidade e Segurança.\nAvailability (Disponibilidade) — O serviço continua de pé quando componentes falham? (HA, redundância, domínios de falha) Manageability (Gerenciabilidade) — O time consegue operar no dia 2? (automação, monitoramento, ciclo de vida, conhecimento) Performance — Atende às metas de throughput, latência e capacidade sob carga real? Recoverability (Recuperabilidade) — Quando algo quebra de verdade, quão rápido e quão completo voltamos? (RPO/RTO, backup, DR) Security (Segurança) — Protege confidencialidade e integridade? (segmentação, identidade, hardening, compliance) A ideia central: nenhuma decisão é neutra. Quase toda escolha melhora uma qualidade e cobra de outra. O AMPRS obriga você a dizer isso em voz alta.\nPor que esses frameworks importam # Sem estrutura, revisões de design viram debates entre preferências. Com RACR e AMPRS:\nDecisões ficam rastreáveis. Cada decisão cita o requisito que atende e a restrição que respeita. Premissas escondidas aparecem cedo. Uma premissa não validada é um risco esperando para acontecer, e o RACR a coloca na mesa. Trade-offs ficam explícitos. \u0026ldquo;Ganhamos Performance, perdemos Gerenciabilidade, e compensamos assim\u0026rdquo; é defensável. \u0026ldquo;É mais rápido\u0026rdquo; não é. Revisões ficam mais rápidas. Um revisor (ou uma banca VCDX) segue a lógica em vez de ter que fazer engenharia reversa dela. Como RACR e AMPRS funcionam juntos # Pense em um pipeline: o RACR define o espaço do problema, as decisões de design vivem dentro dele e o AMPRS avalia o impacto de cada decisão.\nPasso 1: o RACR enquadra o problema # Antes de desenhar qualquer diagrama, colete as informações dos stakeholders e classifique. Numere cada item (R01, A01, C01, RK01) para poder referenciá-lo depois.\nPasso 2: decisões são tomadas contra o RACR # Toda decisão deve responder: qual requisito isso atende e qual restrição a molda? Se uma decisão não se liga a nenhum requisito, questione por que ela existe.\nPasso 3: o AMPRS mede o impacto # Para cada decisão, marque o efeito em cada qualidade: positivo (+), negativo (−) ou neutro (0). Impactos negativos precisam ser aceitos com justificativa ou mitigados.\nPasso 4: o ciclo se fecha # Impactos negativos no AMPRS costumam gerar novos riscos, que voltam para o registro RACR. O design está \u0026ldquo;pronto\u0026rdquo; quando todo risco tem mitigação ou aceite explícito.\nExemplo prático: cluster estendido ou não? # Digamos que a entrada seja: \u0026ldquo;o negócio quer zero perda de dados se um datacenter cair\u0026rdquo;. Classificando com RACR:\nR01: RPO = 0 para workloads Tier-1. R02: RTO ≤ 15 minutos. C01: Dois sites, a 40 km de distância, com fibra apagada existente. A01: Latência de ida e volta entre os sites abaixo de 5 ms (a validar com teste de rede). RK01: Cenário de split-brain se o witness ficar inacessível. Duas opções, avaliadas com AMPRS:\nQualidade Opção A: vSAN stretched cluster Opção B: replicação assíncrona + SRM Disponibilidade + Restart automático no site sobrevivente 0 Exige orquestração de failover Gerenciabilidade − Witness host, regras de afinidade por site, upgrades mais complexos + Clusters mais simples, runbooks no SRM Performance − Escritas síncronas adicionam latência entre sites + Apenas latência de escrita local Recuperabilidade + RPO = 0, RTO em minutos − RPO \u0026gt; 0 (não atende R01) Segurança 0 Mesmo domínio de confiança entre sites 0 Igual A Opção B não atende R01, então está fora, apesar da vantagem de gerenciabilidade. A Opção A é escolhida, mas seus impactos negativos viram novas entradas: um risco de latência de escrita (mitigado validando A01) e um risco de gerenciabilidade (mitigado documentando a operação do witness). Esse é o método inteiro em uma tabela.\nErros comuns # Escrever soluções como requisitos. \u0026ldquo;Deve usar vSAN\u0026rdquo; não é requisito. É uma restrição (se realmente imposta) ou uma decisão que você ainda não justificou. Deixar premissas sem validação. Uma premissa sem dono e sem data de validação é só um risco que você escondeu. Tratar restrições como opcionais. Se orçamento ou hardware são fixos, é restrição. Projetar como se não fossem desperdiça o tempo de todo mundo. Marcar só os pontos positivos no AMPRS. Uma decisão só com \u0026ldquo;+\u0026rdquo; normalmente significa que a análise não foi honesta. Riscos sem mitigação. Listar o risco é metade do trabalho. Declare a mitigação ou o aceite explícito, e quem aceitou. Ignorar a Gerenciabilidade. É a qualidade que mais dói no dia 2 e a mais esquecida no dia 0. FAQ # O que significa RACR em design de infraestrutura? Requirements, Assumptions, Constraints e Risks: Requisitos, Premissas, Restrições e Riscos. É um método para classificar as entradas do design antes de escolher a solução, permitindo rastrear cada decisão até a necessidade do negócio e seus limites.\nO que significa AMPRS? Availability, Manageability, Performance, Recoverability e Security: Disponibilidade, Gerenciabilidade, Performance, Recuperabilidade e Segurança. São as cinco qualidades de design usadas para avaliar o impacto positivo e negativo de cada decisão, popularizadas pela metodologia VMware VCDX.\nQual a diferença entre restrição e premissa? Restrição é uma limitação conhecida e fixa que o arquiteto não pode mudar, como um hardware existente. Premissa é algo que se acredita verdadeiro, mas ainda não foi verificado, como a banda disponível. Premissas exigem validação; restrições exigem respeito.\nRACR e AMPRS servem só para designs VMware? Não. Surgiram na metodologia de design da VMware, mas se aplicam a qualquer infraestrutura: plataformas Kubernetes, landing zones em nuvem, redes, estratégias de backup ou avaliação de propostas de fornecedores. São ferramentas de raciocínio agnósticas de fornecedor.\nComo documentar decisões de design usando AMPRS? Para cada decisão, registre a justificativa, os requisitos e restrições relacionados e o impacto em cada qualidade como positivo, negativo ou neutro. Todo impacto negativo deve apontar para uma mitigação ou para uma entrada no registro de riscos.\nConclusão # O RACR diz o que você está resolvendo e sobre o que está apoiado. O AMPRS diz quanto cada resposta custa. Nenhum dos dois é complicado, e é justamente esse o ponto: o valor não está nas siglas, está na disciplina de escrever as coisas antes de discutir sobre elas. Na próxima revisão de design, inclusive a sua, faça duas perguntas para cada decisão: qual requisito motivou isso? e quanto custou em AMPRS? Se não houver resposta, você encontrou seu próximo trabalho.\nReferências # The Nutanix Design Guide (First Edition) Conceptual Design: RCARs \u0026amp; AMPRS, VCDX Style — Stephan McTighe Journey to VMware Cloud Foundation 9.0 Architect Certification: A Complete Preparation Guide — cnuggets ","date":"24 de setembro de 2026","externalUrl":null,"permalink":"/pt/posts/racr-amprs/","section":"Posts","summary":"","title":"RACR e AMPRS: duas lentes para decisões de design de infraestrutura","type":"posts"},{"content":"","date":"24 de setembro de 2026","externalUrl":null,"permalink":"/pt/tags/risk/","section":"Tags","summary":"","title":"Risk","type":"tags"},{"content":"","date":"24 de setembro de 2026","externalUrl":null,"permalink":"/pt/tags/","section":"Tags","summary":"","title":"Tags","type":"tags"},{"content":"","date":"24 de setembro de 2026","externalUrl":null,"permalink":"/pt/tags/vcdx/","section":"Tags","summary":"","title":"Vcdx","type":"tags"},{"content":"","date":"24 de setembro de 2026","externalUrl":null,"permalink":"/pt/tags/virtualization/","section":"Tags","summary":"","title":"Virtualization","type":"tags"},{"content":"","date":"24 de setembro de 2026","externalUrl":null,"permalink":"/pt/categories/vmware/","section":"Categories","summary":"","title":"VMware","type":"categories"},{"content":"","date":"20 de abril de 2026","externalUrl":null,"permalink":"/pt/categories/troubleshooting/","section":"Categories","summary":"","title":"Troubleshooting","type":"categories"},{"content":"","date":"20 de abril de 2026","externalUrl":null,"permalink":"/pt/tags/troubleshooting/","section":"Tags","summary":"","title":"Troubleshooting","type":"tags"},{"content":"","date":"20 de abril de 2026","externalUrl":null,"permalink":"/pt/tags/vlsr/","section":"Tags","summary":"","title":"Vlsr","type":"tags"},{"content":"","date":"20 de abril de 2026","externalUrl":null,"permalink":"/pt/tags/vmware/","section":"Tags","summary":"","title":"Vmware","type":"tags"},{"content":"","date":"20 de abril de 2026","externalUrl":null,"permalink":"/pt/tags/vrms/","section":"Tags","summary":"","title":"Vrms","type":"tags"},{"content":"Se você gerencia o vSphere Replication pela API e está enfrentando erros intermitentes de Connection refused na porta 8043, provavelmente é isso que está acontecendo. O erro se parece com isto:\nUnable to retrieve pairs from extension server at https://vrms-appliance.example.local:8043. Unable to connect to vSphere Replication Management Server at https://vrms-appliance.example.local:8043. Reason: https://vrms-appliance.example.local:8043 invocation failed with \u0026#34;java.net.ConnectException: Connection refused\u0026#34;, ErrorCode=2.99.2, OpID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx O hms.service (o processo Java do vSphere Replication Management Server) escuta na porta 8043. Quando ele não está lá, as chamadas de API falham. O processo não estava ausente por causa de um problema de rede — ele estava reiniciando.\nSeguindo o contador de reinícios # O primeiro número útil veio do systemctl show:\nroot@vrms-appliance [ ~ ]# systemctl show hms.service --property=NRestarts NRestarts=13 13 reinícios desde o último reboot do VRMS, 13 dias antes — aproximadamente uma queda por dia. O hbrsrv.service (o motor de replicação) esteve rodando continuamente durante esses mesmos 13 dias, então o appliance em si estava estável. O hms era quem estava ciclando.\nO journal mostrava o mecanismo:\nApr 14 11:16:28 vrms-appliance systemd[1]: hms.service: Watchdog timeout (limit 5min)! Apr 14 11:16:28 vrms-appliance systemd[1]: hms.service: Killing process 1725075 (java) with signal SIGABRT. Apr 14 11:16:29 vrms-appliance systemd-coredump[2582430]: Process 1725075 (java) of user 980 dumped core. Apr 14 11:16:29 vrms-appliance systemd[1]: hms.service: Main process exited, code=dumped, status=6/ABRT Apr 14 11:16:29 vrms-appliance systemd[1]: hms.service: Failed with result \u0026#39;watchdog\u0026#39;. Apr 14 11:16:34 vrms-appliance systemd[1]: hms.service: Scheduled restart job, restart counter is at 13. O watchdog do systemd mata o processo se ele deixa de responder às verificações de saúde dentro do intervalo configurado (5 minutos aqui) e o reinicia. O hms estava perdendo essa janela de forma consistente.\nToo many open files # O log de auditoria do kernel apontava para o processo java:\nApr 14 11:16:28 vrms-appliance kernel: audit: type=1701 audit(1776176188.958:11942): auid=4294967295 uid=980 gid=980 ses=4294967295 subj=unconfined pid=1725075 comm=\u0026#34;java\u0026#34; exe=\u0026#34;/usr/java/jre-vmware/bin/java\u0026#34; sig=6 res=1 E o hms-stderr.log tinha o erro de fato, se repetindo em um intervalo de cerca de 2 segundos por vários minutos antes da queda:\nApr 14, 2026 11:16:08 AM org.apache.tomcat.util.net.Acceptor run SEVERE: Socket accept failed java.io.IOException: Too many open files at java.base/sun.nio.ch.Net.accept(Native Method) at java.base/sun.nio.ch.ServerSocketChannelImpl.implAccept(Unknown Source) at java.base/sun.nio.ch.ServerSocketChannelImpl.accept(Unknown Source) at org.apache.tomcat.util.net.NioEndpoint.serverSocketAccept(NioEndpoint.java:449) at org.apache.tomcat.util.net.Acceptor.run(Acceptor.java:129) A thread acceptor do Tomcat tentava aceitar novas conexões e batia no limite de file descriptors. Quando não dá para aceitar conexões, o processo também não consegue responder à verificação de saúde do watchdog do systemd — então o systemd o mata.\nCerca de 2,5 horas depois do último reinício, o processo já estava com 14.472 file descriptors abertos, contra um limite de 20.000:\nroot@vrms-appliance [ ~ ]# cat /proc/2582480/limits | grep -i \u0026#34;open files\u0026#34; Max open files 20000 20000 files root@vrms-appliance [ ~ ]# ls /proc/2582480/fd | wc -l 14472 72% do limite consumidos em menos de três horas. Nesse ritmo, o processo bate no teto bem antes do fim do dia.\nChegando ao schedule-health-checks # Um engenheiro da Broadcom sugeriu olhar o schedule-health-checks no hms-configuration.xml:\nroot@vrms-appliance [ ~ ]# cat /opt/vmware/hms/conf/hms-configuration.xml | grep \u0026#34;\u0026lt;schedule-health-checks\u0026gt;\u0026#34; \u0026lt;schedule-health-checks\u0026gt;true\u0026lt;/schedule-health-checks\u0026gt; O schedule-health-checks diz ao hms para consultar periodicamente a saúde da replicação em todas as VMs protegidas. Cada ciclo abre conexões que nunca são fechadas corretamente — então os file descriptors se acumulam até o processo ficar sem eles e cair.\nComo verificar se você é afetado # Execute estes comandos no seu appliance VRMS via SSH.\n1. Verifique se o hms.service vem reiniciando:\nsystemctl show hms.service --property=NRestarts Qualquer valor acima de 0 significa que o serviço caiu e foi reiniciado desde o último reboot do appliance. Compare com o uptime:\nuptime Se o appliance está no ar há semanas, mas o NRestarts está na casa das dezenas, alguma coisa está ciclando o hms regularmente.\n2. Confirme que os reinícios são causados por timeout do watchdog:\njournalctl -u hms.service --no-pager | grep -i \u0026#34;watchdog\\|Failed with result\u0026#34; Você está procurando linhas como estas:\nhms.service: Watchdog timeout (limit 5min)! hms.service: Failed with result \u0026#39;watchdog\u0026#39;. Se você vir essas linhas, o processo está travando — e não caindo por um motivo não relacionado.\n3. Verifique o uso atual de file descriptors:\nObtenha o PID do processo hms em execução:\nsystemctl show hms.service --property=MainPID A saída vai se parecer com:\nMainPID=2582480 Use esse número nos dois próximos comandos — substituindo 2582480 pelo valor que você obteve:\ncat /proc/2582480/limits | grep -i \u0026#34;open files\u0026#34; ls /proc/2582480/fd | wc -l O primeiro comando mostra o limite configurado (Max open files). O segundo mostra quantos file descriptors o processo tem abertos no momento. Se a contagem do segundo comando já é uma fração grande do limite — e o serviço reiniciou recentemente — o vazamento está ativo.\n4. Confirme que o parâmetro está habilitado:\ncat /opt/vmware/hms/conf/hms-configuration.xml | grep \u0026#34;\u0026lt;schedule-health-checks\u0026gt;\u0026#34; Se ele retornar \u0026lt;schedule-health-checks\u0026gt;true\u0026lt;/schedule-health-checks\u0026gt;, você está sofrendo com este problema.\nCorreção # Passos:\nFaça um snapshot do appliance primeiro.\nEntre no appliance por SSH e pare o hms.service:\nsystemctl stop hms.service Edite o arquivo de configuração:\nvi /opt/vmware/hms/conf/hms-configuration.xml Altere:\n\u0026lt;schedule-health-checks\u0026gt;true\u0026lt;/schedule-health-checks\u0026gt; Para:\n\u0026lt;schedule-health-checks\u0026gt;false\u0026lt;/schedule-health-checks\u0026gt; Aguarde aproximadamente dois minutos para que os sockets abertos expirem e sejam fechados.\nInicie o serviço:\nsystemctl start hms.service Confirme que o NRestarts agora é 0:\nsystemctl show hms.service --property=NRestarts Você também pode verificar há quanto tempo o hms está no ar sem problemas:\nsystemctl status hms.service | grep Active Depois da correção # No dia seguinte, o NRestarts voltou a 0 e permaneceu assim.\nroot@vrms-appliance [ ~ ]# systemctl show hms.service --property=NRestarts NRestarts=0 O engenheiro da Broadcom neste caso foi genuinamente prestativo — ele nos apontou o parâmetro schedule-health-checks e, depois de confirmarmos a correção, dedicou tempo para documentá-lo oficialmente. Esse tipo de acompanhamento merece ser destacado.\nA Broadcom publicou a KB 437468 sobre este problema. A KB confirma a causa raiz: as conexões de verificação de saúde dos mapeamentos de Enhanced Replication nunca são fechadas corretamente, então os file descriptors se acumulam até o processo cair. Versões afetadas e corrigidas:\nvSphere Replication Live Site Recovery Afetadas 9.x com hosts ESXi em larga escala usando Enhanced Replication 9.0.3, 9.0.4 Corrigidas 9.0.2.3 9.0.5 Atualizar para a versão corrigida elimina totalmente a necessidade do workaround do schedule-health-checks.\n","date":"20 de abril de 2026","externalUrl":null,"permalink":"/pt/posts/vrms-hms-connection-refused/","section":"Posts","summary":"","title":"VRMS Connection refused: caçando um vazamento de file descriptors no hms.service","type":"posts"},{"content":"","date":"20 de abril de 2026","externalUrl":null,"permalink":"/pt/tags/vsphere/","section":"Tags","summary":"","title":"Vsphere","type":"tags"},{"content":"","date":"20 de abril de 2026","externalUrl":null,"permalink":"/pt/tags/vsphere-replication/","section":"Tags","summary":"","title":"Vsphere-Replication","type":"tags"},{"content":"","date":"2 de abril de 2026","externalUrl":null,"permalink":"/pt/tags/benchmark/","section":"Tags","summary":"","title":"Benchmark","type":"tags"},{"content":"","date":"2 de abril de 2026","externalUrl":null,"permalink":"/pt/tags/fio/","section":"Tags","summary":"","title":"Fio","type":"tags"},{"content":"","date":"2 de abril de 2026","externalUrl":null,"permalink":"/pt/tags/lsi/","section":"Tags","summary":"","title":"Lsi","type":"tags"},{"content":"","date":"2 de abril de 2026","externalUrl":null,"permalink":"/pt/tags/performance/","section":"Tags","summary":"","title":"Performance","type":"tags"},{"content":"","date":"2 de abril de 2026","externalUrl":null,"permalink":"/pt/tags/pvscsi/","section":"Tags","summary":"","title":"Pvscsi","type":"tags"},{"content":"A documentação da VMware diz para usar o PVSCSI em cargas de trabalho intensivas em storage. A internet concorda. E não está errado — mas depois de rodar a mesma carga do fio em cinco VMs simultâneas com os dois controladores, o tipo de controlador se mostrou a variável menos interessante. O SIOC fazia todo o trabalho pesado.\nEste é um complemento do post sobre o fio_benchmark. Mesmo script, mesmos discos virtuais de 200 GiB, cinco VMs acessando o storage simultaneamente em quatro configurações: LSI sem SIOC, LSI com SIOC, PVSCSI sem SIOC e PVSCSI com SIOC.\nO ambiente de teste # Cinco VMs (gus_fio_1 até gus_fio_5), todas no mesmo cluster vSphere, todas rodando o fio_benchmark simultaneamente contra um disco virtual dedicado de 200 GiB. Cada teste rodou por 300 segundos por perfil. O alvo era /dev/sdb — um disco dedicado, sem SO nem dados.\nConfiguração das VMs: Ubuntu Server 24.04, 2 vCPU, 4 GB de RAM. Idêntica nas cinco VMs em cada rodada de teste.\nCada VM executou o seguinte comando simultaneamente:\nsudo ./fio_benchmark.sh -t /dev/sdb -r 300 -s -m -r 300 define 300 segundos por perfil de teste, -s executa a varredura de iodepth e -m executa a varredura de mix R/W.\nQuatro configurações:\nLSI Logic SAS (LSI) — o controlador padrão que o vSphere atribui quando você avança pelo assistente de criação de VM VMware Paravirtual (PVSCSI) — o controlador SCSI paravirtual da VMware, feito sob medida Cada um repetido com o SIOC (Storage I/O Control) desabilitado e habilitado AVISO — o fio_benchmark escreve diretamente no dispositivo de bloco que você especificar. Executá-lo contra qualquer disco que contenha dados vai destruir esses dados imediatamente. Apenas discos de teste. Sem SIOC: a loteria do storage # Com cinco VMs rodando simultaneamente e o SIOC desligado, o que você tem é uma corrida. Quem submete I/O primeiro fica com a fila — e os resultados refletem exatamente isso.\nLeitura sequencial de 128K — LSI, SIOC desligado # VM Largura de banda Latência (méd.) gus_fio_1 401 MiB/s 9,95 ms gus_fio_2 1.148 MiB/s 3,47 ms gus_fio_3 203 MiB/s 19,63 ms gus_fio_4 326 MiB/s 12,22 ms gus_fio_5 204 MiB/s 19,60 ms O gus_fio_2 puxou 1.148 MiB/s enquanto o gus_fio_3 e o gus_fio_5 ficaram presos em ~204 MiB/s. Cinco VMs idênticas, mesma carga, mesmo datastore — e uma delas recebeu 5,6× mais banda do que outra. Não é diferença de configuração. É só timing de fila.\nA dispersão de latência confirma: o gus_fio_2 com 3,47 ms de média, o gus_fio_3 com 19,63 ms. A VM \u0026ldquo;vencedora\u0026rdquo; completava o I/O 5,7× mais rápido porque estava com a fila.\nO PVSCSI tem o mesmo problema:\nLeitura sequencial de 128K — PVSCSI, SIOC desligado # VM Largura de banda Latência (méd.) gus_fio_1 191 MiB/s 20,85 ms gus_fio_2 382 MiB/s 10,44 ms gus_fio_3 648 MiB/s 6,15 ms gus_fio_4 382 MiB/s 10,45 ms gus_fio_5 191 MiB/s 20,85 ms Outro vencedor, mesma dinâmica. O gus_fio_3 pegou 648 MiB/s enquanto o gus_fio_1 e o gus_fio_5 ficaram em 191 MiB/s — uma diferença de 3,4×. O controlador mudou; a injustiça não.\nÉ isso que acontece quando várias VMs compartilham storage sem nenhum mecanismo de fairness. Não é previsível, não é proporcional, e muda a cada vez que você roda o benchmark.\nA varredura de iodepth revela outra camada # A varredura de iodepth (randread de 4K, um único job, indo da profundidade 1 a 128) mostra algo interessante sobre como as diferentes VMs se comportam sob contenção.\nVarredura de iodepth do gus_fio_4 — LSI, SIOC desligado:\niodepth IOPS Latência média 16 32.470 0,49 ms 32 40.120 0,80 ms 64 40.319 1,59 ms 128 40.735 3,14 ms O gus_fio_4 conseguiu continuar escalando bem além do iodepth 32 e manteve mais de 40K IOPS até a profundidade 128. Enquanto isso:\nVarredura de iodepth do gus_fio_2 — LSI, SIOC desligado:\niodepth IOPS Latência média 16 22.399 0,71 ms 32 30.885 1,03 ms 64 19.845 3,22 ms 128 19.274 6,64 ms O gus_fio_2 atingiu o pico na profundidade 32 (30.885 IOPS) e depois despencou na profundidade 64 — caindo para 19.845 IOPS. É a fila de storage saturando: quando o gus_fio_2 empurrou I/Os concorrentes demais, eles se acumularam e a latência subiu o suficiente para reduzir a vazão efetiva. A fila de comandos bateu no teto, e adicionar mais profundidade piorou as coisas.\nEste é o diagnóstico mais útil que a varredura oferece. Se a sua curva de IOPS atinge um pico e depois cai conforme você aumenta a profundidade, você encontrou o ponto em que o seu storage (ou a fila do hypervisor) está saturado.\nO que o SIOC realmente faz # O SIOC (Storage I/O Control) adiciona uma camada de gerenciamento de congestionamento no nível do datastore. Quando detecta que a latência está subindo acima de um limite (configurável, com padrão de 30ms para datastores de HDD), ele começa a limitar as VMs que estão emitindo quantidades desproporcionalmente grandes de I/O.\nLeitura sequencial de 128K — LSI, SIOC ligado # VM Largura de banda Latência (méd.) gus_fio_1 406 MiB/s 9,82 ms gus_fio_2 401 MiB/s 9,95 ms gus_fio_3 292 MiB/s 13,67 ms gus_fio_4 331 MiB/s 12,07 ms gus_fio_5 293 MiB/s 13,64 ms Os 1.148 MiB/s do gus_fio_2 viraram 401 MiB/s — uma redução de 65%. O gus_fio_3, que estava estrangulado em 203 MiB/s, subiu para 292 MiB/s. A faixa se comprimiu de 203–1.148 MiB/s para 292–406 MiB/s.\nO SIOC não aumentou a vazão agregada total — o datastore tem a mesma capacidade física de qualquer forma. O que ele fez foi impedir que uma VM levasse 5× a sua parte justa.\nO gus_fio_3 e o gus_fio_5 ainda ficam atrás do gus_fio_1 e do gus_fio_2 mesmo com o SIOC habilitado. Isso é consistente em todas as rodadas e sugere que eles estão em um disco físico ou extent VMFS diferente dentro do mesmo datastore — um problema de posicionamento que o SIOC não consegue resolver.\nO PVSCSI com SIOC mostra o mesmo padrão:\nLeitura sequencial de 128K — PVSCSI, SIOC ligado # VM Largura de banda Latência (méd.) gus_fio_1 285 MiB/s 14,00 ms gus_fio_2 568 MiB/s 7,02 ms gus_fio_3 576 MiB/s 6,93 ms gus_fio_4 569 MiB/s 7,01 ms gus_fio_5 285 MiB/s 14,02 ms O SIOC comprimiu a variação do PVSCSI de uma dispersão de 3,4× (191–648 MiB/s) para 2× (285–576 MiB/s). O gus_fio_1 e o gus_fio_5 continuam consistentemente com metade da banda das outras três — as mesmas duas VMs que ficaram atrás com o LSI. O controlador mudou; o posicionamento não.\nA varredura de mix R/W — a fairness do SIOC fica mais visível aqui # A varredura de mix R/W (randrw de 4K, 8 jobs, iodepth 8, variando o % de escrita de 0% a 100%) mostra como o IOPS degrada conforme a pressão de escrita aumenta. A curva de penalidade de escrita diz muito sobre a saúde do storage.\nLSI, SIOC desligado — varredura de mix R/W do gus_fio_4:\n% de escrita IOPS Latência média 0% (leitura pura) 40.585 1,56 ms 50% 33.997 1,92 ms 100% (escrita pura) 29.838 2,13 ms Degradação limpa e gradual. O gus_fio_4 foi a VM com sorte nesta rodada.\nLSI, SIOC desligado — varredura de mix R/W do gus_fio_3:\n% de escrita IOPS Latência média 0% 19.189 3,32 ms 50% 16.043 4,05 ms 100% 14.888 4,29 ms O gus_fio_3 começou em 19K IOPS onde o gus_fio_4 começou em 40K. Mesmo datastore, mesmo instante. Sem o SIOC, a diferença entre a VM \u0026ldquo;vencedora\u0026rdquo; e a \u0026ldquo;perdedora\u0026rdquo; na leitura pura é de mais de 2× — e essa diferença persiste ao longo de toda a curva de penalidade de escrita.\nPVSCSI vs LSI: o que os números realmente dizem # O controlador SCSI paravirtual elimina o overhead da emulação de hardware. Em vez de o hypervisor fingir ser uma placa LSI Logic SAS, o PVSCSI usa um ring buffer compartilhado com o qual o driver do guest conversa diretamente. Menos trocas de contexto, agrupamento de I/O mais eficiente, teoricamente melhor vazão.\nNa prática, com estas VMs e este datastore, a diferença dependeu da carga de trabalho.\nVazão e latência (apenas gus_fio_1, SIOC desligado) # Teste Controlador IOPS Largura de banda Latência média Leitura aleatória 4K LSI 19.238 75,2 MiB/s 6,63 ms Leitura aleatória 4K PVSCSI 20.193 78,9 MiB/s 6,32 ms Escrita aleatória 4K LSI 17.357 67,8 MiB/s 3,67 ms Escrita aleatória 4K PVSCSI 15.451 60,4 MiB/s 4,13 ms Escrita aleatória LSI 5.146 321,6 MiB/s 12,37 ms Escrita aleatória PVSCSI 1.653 103,3 MiB/s 38,69 ms Escrita seq. LSI 8.960 280,0 MiB/s 1,76 ms Escrita seq. PVSCSI 5.450 170,3 MiB/s 2,92 ms As leituras aleatórias são praticamente um empate. O quadro das escritas é mais difícil de ler com clareza: as escritas aleatórias de 4K são parecidas, mas a escrita aleatória de bloco maior (bs de 64K, 8 jobs) mostra o PVSCSI com 3× menos IOPS e 3× mais latência do que o LSI. As escritas sequenciais seguem na mesma direção — o PVSCSI com cerca de 40% menos banda.\nEsses testes rodaram simultaneamente nas cinco VMs, então os resultados não são apenas uma comparação de controladores — são uma comparação de controladores sob contenção compartilhada. O comportamento de agrupamento de I/O do ring buffer do PVSCSI pode mudar a dinâmica de contenção quando várias VMs acessam o mesmo datastore ao mesmo tempo.\nOverhead de CPU: onde o PVSCSI realmente entrega # O quadro de vazão acima é misto. O quadro de CPU não é.\nTeste Controlador CPU (usr / sys) IOPS/CPU% Leitura seq. LSI 0,68% / 2,09% 8.563 Leitura seq. PVSCSI 0,48% / 1,51% 9.851 Escrita seq. LSI 2,85% / 2,10% 1.807 Escrita seq. PVSCSI 1,01% / 1,00% 2.701 Leitura aleatória 4K LSI 0,26% / 0,77% 18.640 Leitura aleatória 4K PVSCSI 0,20% / 0,63% 24.260 Escrita aleatória 4K LSI 0,75% / 1,40% 8.104 Escrita aleatória 4K PVSCSI 0,44% / 1,01% 10.666 O PVSCSI consistentemente gasta menos CPU por IOPS em todos os testes:\nEscrita sequencial: o LSI usa 4,95% de CPU total para 8.960 IOPS. O PVSCSI usa 2,01% de CPU total para 5.450 IOPS. A regressão de banda é real, mas a redução de 59% na CPU também. Leitura aleatória de 4K: o PVSCSI é 30% mais eficiente (24.260 vs 18.640 IOPS/CPU%). Aqui o PVSCSI também ganha em vazão, então é uma vitória limpa. Escrita aleatória de 4K: 31% melhor eficiência no PVSCSI, e vazão quase equivalente. Essa é a promessa original do driver paravirtual: eliminar o overhead da emulação e obter mais I/O por ciclo de CPU. Os números de CPU confirmam que funciona. Se o custo em vazão nas escritas de bloco grande importa depende da sua carga de trabalho.\nAs principais conclusões # O SIOC importa mais do que o tipo de controlador. Sem o SIOC, uma única VM em um cluster de cinco VMs puxou 5,6× mais banda do que as vizinhas. Com o SIOC, a variação se comprimiu para cerca de 1,4×. Se você roda várias VMs intensivas em storage em um datastore compartilhado e o SIOC está desabilitado, você tem um problema de fairness independentemente do controlador que estiver usando.\nA vantagem real do PVSCSI é a eficiência de CPU, não a vazão bruta. As diferenças de vazão entre os controladores dependem da carga de trabalho e nem sempre favorecem o PVSCSI. O que é consistente: o PVSCSI gasta de 30 a 60% menos CPU por IOPS em todos os testes. Em um host rodando muitas VMs pesadas em storage, esse overhead se acumula. Se você tem limitação de CPU, o PVSCSI importa mesmo quando os números de IOPS parecem semelhantes.\nA varredura de iodepth é diagnóstica, não só informativa. O comportamento de saturação da fila (o IOPS atinge o pico e depois cai conforme a profundidade aumenta) mostra onde está o teto do seu storage. O gus_fio_2 atingiu o pico na profundidade 32 e degradou a partir dali — esse é o ponto em que aumentar a profundidade da fila prejudica em vez de ajudar.\nA recomendação prática: habilite o SIOC em todo datastore compartilhado — o argumento da fairness é inequívoco, seja qual for o controlador. Para a escolha do controlador, o PVSCSI é o padrão certo: o ganho de eficiência de CPU é consistente em todas as cargas, e para a maioria das cargas mistas ou com predominância de leitura os números de vazão são equivalentes ou melhores. O único caso que vale a pena fazer benchmark antes de se comprometer é o de escritas em massa de bloco grande (backups, ETL, ingestão de vídeo) — a regressão ali foi significativa o bastante para que, se essa for a sua carga principal, você deva verificar no seu storage específico antes de assumir que o PVSCSI é a escolha certa.\nO posicionamento da VM dentro de um datastore tem efeitos reais. O gus_fio_3 e o gus_fio_5 tiveram desempenho consistentemente inferior ao do gus_fio_1 e do gus_fio_2 em todas as configurações, inclusive com o SIOC. Se VMs no mesmo datastore estão recebendo desempenhos sistematicamente diferentes, suspeite do extent do disco ou do layout dos spindles antes de culpar o controlador ou o guest.\nTodos os testes usaram o fio_benchmark — o script de benchmark apresentado no post anterior. Tempo de execução de 300 segundos por teste, libaio, I/O direto, sem cache de sistema de arquivos.\nOs resultados brutos das cinco VMs nas quatro configurações estão disponíveis para download, caso você queira verificar os números ou fazer a sua própria análise: results_fio.txt.\n","date":"2 de abril de 2026","externalUrl":null,"permalink":"/pt/posts/pvscsi-vs-lsi-sioc/","section":"Posts","summary":"","title":"PVSCSI vs LSI no vSphere: a escolha do controlador realmente importa?","type":"posts"},{"content":"","date":"2 de abril de 2026","externalUrl":null,"permalink":"/pt/tags/sioc/","section":"Tags","summary":"","title":"Sioc","type":"tags"},{"content":"","date":"2 de abril de 2026","externalUrl":null,"permalink":"/pt/categories/storage/","section":"Categories","summary":"","title":"Storage","type":"categories"},{"content":"","date":"2 de abril de 2026","externalUrl":null,"permalink":"/pt/tags/storage/","section":"Tags","summary":"","title":"Storage","type":"tags"},{"content":"Toda sessão de troubleshooting de storage começa do mesmo jeito: você entra por SSH em uma máquina, abre as suas anotações (ou o histórico do navegador) e reconstrói o mesmo punhado de comandos fio que já rodou cem vezes. Leitura sequencial, escrita sequencial, leitura aleatória de 4K, R/W misto — cada um com tamanhos de bloco, profundidades de fila e quantidades de jobs ligeiramente diferentes, conforme o que você está caçando.\nEssa estrutura repetitiva é exatamente o que o fio_benchmark elimina.\nAVISO — ESTE SCRIPT ESCREVE DIRETAMENTE NO DISPOSITIVO DE BLOCO QUE VOCÊ ESPECIFICAR.\nApontá-lo para qualquer disco que contenha dados — o disco do seu SO, um volume montado, um datastore em uso — vai corromper ou destruir esses dados, imediatamente e sem nenhuma confirmação. Não há como desfazer.\nAntes de executar, confirme o seu alvo com lsblk ou fdisk -l. Se /dev/sda é o seu disco de sistema, /dev/sdb é o datastore das suas VMs, ou você não tem 100% de certeza do que há no dispositivo, não execute este script contra ele. Use um disco de teste dedicado e em branco ou um arquivo de teste em um sistema de arquivos descartável (-t /mnt/testdir/testfile).\nO que é (e o que não é) # fio_benchmark é um wrapper em Bash em torno do fio. Ele não substitui o fio — nem tenta. O fio já é a ferramenta certa. O que ele faz é reunir os perfis de teste que a maioria dos sysadmins e profissionais de storage executa separadamente em uma única execução repetível, com parâmetros consistentes e saída estruturada que você realmente consegue comparar entre sistemas.\nO público-alvo é simples: se você é sysadmin ou engenheiro de storage e precisa caracterizar rapidamente um dispositivo — seja um NVMe novo em um servidor bare-metal, uma LUN de SAN ou um disco de VM que você suspeita estar sendo limitado — isso leva você até lá sem montar a matriz de testes do zero toda vez.\nOs 9 perfis que ele executa # Todos os testes usam --direct=1, --ioengine=libaio e --group_reporting. Os testes aleatórios também desativam padrões repetidos (--randrepeat=0 --norandommap) para evitar artefatos de aquecimento de cache.\n# Teste Padrão Tamanho de bloco Jobs iodepth Tamanho 1 seqread Leitura sequencial 8k 8 4 1G 2 seqwrite Escrita sequencial 32k 4 4 2G 3 seq128kread Leitura sequencial (BW máx.) 128k 8 4 2G 4 seq128kwrite Escrita sequencial (BW máx.) 128k 4 4 2G 5 randread Leitura aleatória 8k 16 8 1G 6 randwrite Escrita aleatória 64k 8 8 512m 7 rand4kread Leitura aleatória 4K 4k 16 8 1G 8 rand4kwrite Escrita aleatória 4K 4k 8 8 1G 9 randrw R/W aleatório (90% leitura) 16k 8 8 1G Para cada teste, ele coleta IOPS, largura de banda (MiB/s), latência média, desvio padrão da latência, percentis p50/p99/p99.9 e utilização de CPU. Também calcula uma razão de eficiência de IOPS por percentual de CPU — útil quando você compara um resultado bare-metal com uma VM rodando no mesmo hardware e quer quantificar o overhead do hypervisor.\nInstalação # Requisitos: Bash 4.4+, fio 3.0+, awk POSIX. Sem jq.\ngit clone https://github.com/9llo/fio_benchmark.git chmod +x fio_benchmark/fio_benchmark.sh Executando # A invocação mais simples contra um dispositivo de bloco (requer root):\nsudo ./fio_benchmark.sh -t /dev/sdb Se você quiser fazer antes um dry-run, para verificar a configuração sem tocar no disco:\n./fio_benchmark.sh -t /dev/sdb -n Sem argumentos, você cai no modo interativo, que pergunta o alvo e o tempo de execução.\nO formato de saída é texto simples por padrão. Para automação ou acompanhamento de longo prazo, use JSON ou CSV — as mensagens de progresso e de status sempre vão para o stderr, então a saída estruturada no stdout fica limpa para redirecionamento:\nsudo ./fio_benchmark.sh -t /dev/sdb -o json \u0026gt; results.json sudo ./fio_benchmark.sh -t /dev/sdb -o csv \u0026gt; results.csv O tempo de execução por teste é de 600 segundos por padrão. Para uma passada mais rápida durante a triagem inicial, você pode reduzi-lo:\nsudo ./fio_benchmark.sh -t /dev/sdb -r 60 As duas varreduras que realmente encontram gargalos # Os perfis padrão dão uma linha de base. As varreduras é que diagnosticam por que um dispositivo se comporta como se comporta.\nVarredura de iodepth (-s) # Executa randread com bs=4k, numjobs=1 e percorre os valores de iodepth 1, 2, 4, 8, 16, 32, 64, 128.\nsudo ./fio_benchmark.sh -t /dev/sdb -s A curva de IOPS mostra onde o paralelismo interno do dispositivo satura. Um NVMe de consumo normalmente estabiliza por volta de iodepth 8–16. Um SSD empresarial ou uma LUN de SAN com uma fila de comandos profunda pode continuar subindo bem além de 32. Se você vê o IOPS estabilizar cedo e depois degradar, isso costuma ser um problema de firmware ou de gerenciamento de fila que vale a pena investigar.\nVarredura de mix R/W (-m) # Executa randrw com bs=4k, numjobs=8, iodepth=8, variando o percentual de escrita de 0% a 100% em passos de 10%.\nsudo ./fio_benchmark.sh -t /dev/sdb -m Isso mapeia a curva de penalidade de escrita. Em um NVMe saudável, o IOPS deve degradar de forma razoavelmente gradual conforme o % de escrita aumenta. Em um SSD muito superprovisionado perto da capacidade, ou em um datastore thin-provisioned sendo supercomprometido, a curva despenca quando as escritas começam a disparar garbage collection e amplificação de escrita. Se você roda um banco de dados e se pergunta por que o desempenho despenca sob cargas pesadas em escrita, esta varredura vai mostrar.\nExemplo de saída (texto) # Device: /dev/sdb | Samsung SSD 870 QVO | SSD | 1000GB | 512B blocks | mq-deadline ┌──────────────────┬──────────┬──────────┬────────────┬────────────┬────────────┬────────────┬────────────┬───────┬───────┬──────────────┐ │ Test │ IOPS │ BW MB/s │ Lat avg │ Lat std │ p50 │ p99 │ p99.9 │ CPU u │ CPU s │ IOPS/CPU% │ ├──────────────────┼──────────┼──────────┼────────────┼────────────┼────────────┼────────────┼────────────┼───────┼───────┼──────────────┤ │ seqread │ 52341 │ 409.7 │ 0.61 ms │ 0.12 ms │ 0.58 ms │ 0.94 ms │ 1.24 ms │ 3.1% │ 2.1% │ 10018.7 │ │ seqwrite │ 14832 │ 462.9 │ 1.08 ms │ 0.31 ms │ 0.99 ms │ 1.97 ms │ 3.51 ms │ 2.2% │ 1.8% │ 3707.8 │ ... Quando usar # Qualificar hardware de storage novo antes de ele entrar em produção Comparar o desempenho do disco de uma VM com o de bare-metal para medir o overhead de virtualização Verificar se uma reclamação de \u0026ldquo;storage lento\u0026rdquo; de uma equipe de aplicação é real ou uma pista falsa Montar uma linha de base antes e depois de uma atualização de firmware ou de uma mudança na configuração de storage Investigar um SSD que parece mais lento do que o esperado após meses de uso (desgaste e amplificação de escrita) Ele não vai dizer por que algo está lento por conta própria — isso ainda exige interpretação. Mas ter a matriz de testes completa, com parâmetros consistentes, em menos de uma hora, é um ponto de partida melhor do que montá-la à mão toda vez.\nUma palavra sobre como isso foi construído # Transparência total: boa parte da iteração neste script foi feita com o Claude Code como par de programação.\nO conhecimento de domínio — quais testes importam, quais tamanhos de bloco usar para cada perfil de carga, por que a varredura de iodepth é mais útil do que rodar uma única profundidade de fila, como fazer o parse da saída JSON do fio sem trazer o jq como dependência — tudo isso veio de anos de troubleshooting real de storage. O Claude não sabia que randrepeat=0 importa para evitar artefatos de aquecimento de cache, nem que uma razão de eficiência de IOPS por CPU é útil especificamente em ambientes de VM. Esse contexto precisou ser fornecido.\nO que ele acelerou: o boilerplate em Bash que ninguém gosta de escrever. O parser de argumentos, os traps de limpeza, o wrapper de timeout em volta de cada chamada ao fio, a passada de awk que extrai os campos de percentil do JSON sem dependência. Coisas tediosas e propensas a erro para acertar, mas nada intelectualmente interessante depois que você sabe o que elas precisam fazer.\nO resumo honesto: ele transformou uma tarefa que seria um fim de semana inteiro de hacking intermitente em uma noite focada. O raciocínio não foi terceirizado — foi destravado.\nA IA não vai substituir sysadmins nem engenheiros de storage. Ela não faz ideia de como é a topologia da sua SAN, por que a sua latência dispara às 3h da manhã, ou o que \u0026ldquo;estava tudo bem antes da atualização de firmware\u0026rdquo; realmente significa no contexto. Mas se você consegue descrever com precisão o que quer, ela é uma colaboradora notavelmente boa para as partes do trabalho que são apenas execução. Quem descobrir como usá-la bem não vai ser substituído — vai render mais.\nO repositório está em github.com/9llo/fio_benchmark. Issues e PRs estão abertos.\n","date":"20 de março de 2026","externalUrl":null,"permalink":"/pt/posts/fio_benchmark/","section":"Posts","summary":"","title":"fio_benchmark: um wrapper para parar de escrever os mesmos comandos fio toda vez","type":"posts"},{"content":"","date":"20 de março de 2026","externalUrl":null,"permalink":"/pt/tags/linux/","section":"Tags","summary":"","title":"Linux","type":"tags"},{"content":"","date":"20 de março de 2026","externalUrl":null,"permalink":"/pt/tags/sysadmin/","section":"Tags","summary":"","title":"Sysadmin","type":"tags"},{"content":"","date":"6 de março de 2026","externalUrl":null,"permalink":"/pt/categories/ai/","section":"Categories","summary":"","title":"AI","type":"categories"},{"content":"","date":"6 de março de 2026","externalUrl":null,"permalink":"/pt/tags/amd/","section":"Tags","summary":"","title":"Amd","type":"tags"},{"content":"","date":"6 de março de 2026","externalUrl":null,"permalink":"/pt/tags/docker/","section":"Tags","summary":"","title":"Docker","type":"tags"},{"content":"","date":"6 de março de 2026","externalUrl":null,"permalink":"/pt/tags/gpu-passthrough/","section":"Tags","summary":"","title":"Gpu-Passthrough","type":"tags"},{"content":"","date":"6 de março de 2026","externalUrl":null,"permalink":"/pt/categories/homelab/","section":"Categories","summary":"","title":"Homelab","type":"categories"},{"content":"","date":"6 de março de 2026","externalUrl":null,"permalink":"/pt/tags/llm/","section":"Tags","summary":"","title":"Llm","type":"tags"},{"content":"","date":"6 de março de 2026","externalUrl":null,"permalink":"/pt/tags/lxc/","section":"Tags","summary":"","title":"Lxc","type":"tags"},{"content":"","date":"6 de março de 2026","externalUrl":null,"permalink":"/pt/tags/ollama/","section":"Tags","summary":"","title":"Ollama","type":"tags"},{"content":"","date":"6 de março de 2026","externalUrl":null,"permalink":"/pt/tags/open-webui/","section":"Tags","summary":"","title":"Open-Webui","type":"tags"},{"content":"Rodar Large Language Models (LLMs) locais em CPU é lento. Se o seu servidor de homelab tem uma APU AMD Ryzen, você pode usar essa GPU integrada para acelerar a inferência.\nRodar tudo dentro de um container LXC leve do Proxmox, em vez de uma VM completa, economiza recursos. No entanto, as permissões de containers sem privilégios e as peculiaridades dos drivers da AMD costumam quebrar a configuração.\nMeu hardware:\nCPU: AMD Ryzen 5 4600G com Radeon Graphics (1 Socket) Memória: 128GB SO: Proxmox Virtual Environment 9.1.6 Isto é para testes, aprendizado e self-hosting de modelos leves em hardware de homelab, e não para montar uma estação de trabalho de IA gigante.\nVeja como repassar a sua APU AMD a um container LXC, instalar o Docker e implantar uma stack de IA com aceleração por hardware usando Ollama e Open WebUI.\nFase 1: Preparar o host Proxmox # Todos os comandos desta fase devem ser executados no shell do host Proxmox (root@pve1).\n1. Instalar o firmware da AMD (o repositório non-free) # O Proxmox (baseado em Debian) não inclui por padrão o firmware gráfico da AMD necessário. Precisamos habilitar os repositórios de firmware non-free para instalar o pacote.\nnano /etc/apt/sources.list Garanta que as linhas do seu repositório principal do Debian incluam non-free e non-free-firmware. Deve ficar mais ou menos assim:\ndeb http://deb.debian.org/debian trixie main contrib non-free non-free-firmware deb http://security.debian.org/debian-security trixie-security main contrib non-free non-free-firmware deb http://deb.debian.org/debian trixie-updates main contrib non-free non-free-firmware (Nota: se você está em uma versão mais antiga do Proxmox, substitua trixie por bookworm).\nAtualize os pacotes e instale o firmware:\napt update apt install -y firmware-amd-graphics 2. Configurar o GRUB para IOMMU # Primeiro, habilite o IOMMU para que o host possa acessar diretamente o hardware da GPU.\nnano /etc/default/grub Modifique a linha GRUB_CMDLINE_LINUX_DEFAULT para ficar exatamente assim (remova qualquer flag video=efifb:off ou nomodeset, se existir):\nGRUB_CMDLINE_LINUX_DEFAULT=\u0026#34;quiet amd_iommu=on iommu=pt\u0026#34; Atualize o GRUB para aplicar:\nupdate-grub 3. Desativar o \u0026ldquo;sequestro\u0026rdquo; do VFIO # Se você já configurou passthrough de VM antes, pode ter colocado os drivers da GPU na blacklist. Precisamos que o host os use para o LXC.\nnano /etc/modprobe.d/vfio.conf Comente (adicione # no início) todas as linhas, para que fique assim:\n# options vfio-pci ids=1002:1636... # softdep amdgpu pre: vfio-pci # softdep snd_hda_intel pre: vfio-pci 4. Forçar o carregamento do módulo amdgpu # Garanta que o host carregue os drivers da AMD no boot.\nnano /etc/modules Adicione estas linhas no final:\nvfio vfio_iommu_type1 vfio_pci vfio_virqfd amdgpu 5. Verificar blacklists ocultas da AMD # Antes de reiniciar, garanta que o Proxmox não esteja bloqueando ativamente o driver. Execute a seguinte verificação:\ngrep -ir \u0026#34;amdgpu\u0026#34; /etc/modprobe.d/ Se você vir um arquivo como blacklist-amdgpu.conf, será preciso renomeá-lo, ou o driver nunca vai carregar, independentemente da sua configuração em /etc/modules:\nmv /etc/modprobe.d/blacklist-amdgpu.conf /etc/modprobe.d/blacklist-amdgpu.conf.bak 6. Aplicar as alterações e reiniciar # Regenere as imagens de boot e reinicie o seu servidor Proxmox.\nupdate-initramfs -u -k all reboot 7. Verificar se os drivers carregaram # Quando o host voltar, verifique os arquivos de dispositivo da GPU:\nls -l /dev/dri Você deve ver card0 e renderD128.\nFase 2: Corrigir as permissões do container (a correção com Udev) # Por padrão, containers LXC sem privilégios mapeiam o usuário root para um usuário \u0026ldquo;nobody\u0026rdquo; de número alto no host. Se você repassar a GPU agora, o container terá o acesso negado. Corrigimos isso com uma regra Udev no host.\nExecute isto no host Proxmox:\n# Create the rule to make the GPU globally readable/writable echo \u0026#39;KERNEL==\u0026#34;renderD128\u0026#34;, MODE=\u0026#34;0666\u0026#34;\u0026#39; \u0026gt; /etc/udev/rules.d/99-render.rules echo \u0026#39;KERNEL==\u0026#34;card0\u0026#34;, MODE=\u0026#34;0666\u0026#34;\u0026#39; \u0026gt;\u0026gt; /etc/udev/rules.d/99-render.rules # Apply the rule immediately udevadm control --reload-rules \u0026amp;\u0026amp; udevadm trigger Verifique se as permissões mudaram (procure por crw-rw-rw-):\nls -l /dev/dri/renderD128 Fase 3: Criar e configurar o container LXC # 1. Provisionar o container # Crie um novo container LXC sem privilégios usando a CLI do Proxmox. Para a stack de IA, o Ubuntu 24.04 é o template recomendado. Primeiro, atualize o cache de templates e baixe a imagem:\npveam update pveam download local ubuntu-24.04-standard_24.04-2_amd64.tar.zst Crie o container (usamos o ID 100 como exemplo), atribuindo 4 núcleos de CPU, 4GB de RAM e 30GB de armazenamento:\npct create 100 local:vztmpl/ubuntu-24.04-standard_24.04-2_amd64.tar.zst \\ --unprivileged 1 \\ --hostname local-ai \\ --cores 6 \\ --memory 49152 \\ --swap 0 \\ --rootfs local-lvm:30 \\ --net0 name=eth0,bridge=vmbr0,ip=10.1.99.16/16,gw=10.1.0.1,tag=99 Não inicie o container ainda.\n2. Obter os IDs de grupo do host (opcional) # Como a regra Udev da Fase 2 torna a GPU gravável por qualquer usuário (0666), alinhar os IDs de grupo não é estritamente necessário para o container iniciar. Mesmo assim, mantê-los alinhados continua sendo uma boa prática estrutural. Encontre os IDs dos grupos render e video no seu host:\ngetent group render | cut -d: -f3 # Example: 104 getent group video | cut -d: -f3 # Example: 44 3. Habilitar o nesting do LXC # Na interface web do Proxmox, selecione o seu container -\u0026gt; Options -\u0026gt; Features. Marque a caixa Nesting. Isso é obrigatório para rodar Docker dentro do LXC.\n4. Editar a configuração do LXC # Encontre o ID do seu container (por exemplo, 100). Edite o arquivo de configuração dele no host:\nnano /etc/pve/lxc/100.conf Acrescente as linhas a seguir para repassar o hardware (atualize os GIDs se os seus forem diferentes de 104 e 44):\n# GPU Passthrough lxc.cgroup2.devices.allow: c 226:0 rwm lxc.cgroup2.devices.allow: c 226:128 rwm lxc.mount.entry: /dev/dri/card0 dev/dri/card0 none bind,optional,create=file lxc.mount.entry: /dev/dri/renderD128 dev/dri/renderD128 none bind,optional,create=file Inicie (ou reinicie) o seu container LXC.\nFase 4: Implantando o Ollama e o Open WebUI com Docker Compose # Rodar containers avulsos exige vários comandos e deixa a rede frágil. Em vez disso, definimos a stack de IA com o Docker Compose.\nEntre no console do seu container LXC (pct enter 100 ou SSH).\n1. Instalar o Docker # Primeiro, pegue o script oficial para instalar o Docker (que inclui o plugin do Compose) no seu container Ubuntu novo:\napt update \u0026amp;\u0026amp; apt upgrade -y curl -fsSL https://get.docker.com | sh 2. Definir a configuração da stack # Crie um novo diretório para os serviços de IA e escreva o arquivo docker-compose.yml:\nmkdir -p ~/ai-stack \u0026amp;\u0026amp; cd ~/ai-stack nano docker-compose.yml Cole o YAML a seguir no arquivo:\nservices: # ------------------------------------- # 1. Reverse Proxy (Traefik) # ------------------------------------- traefik: image: traefik:v3.0 container_name: traefik restart: unless-stopped command: - \u0026#34;--api.insecure=true\u0026#34; # Enables the Traefik dashboard on port 8080 (optional) - \u0026#34;--providers.docker=true\u0026#34; - \u0026#34;--providers.docker.exposedbydefault=false\u0026#34; # Security: deny mapping unless explicitly labeled # Define both HTTP (80) and HTTPS (443) entrypoints - \u0026#34;--entrypoints.web.address=:80\u0026#34; - \u0026#34;--entrypoints.websecure.address=:443\u0026#34; # Automatically redirect all HTTP traffic to HTTPS (websecure) - \u0026#34;--entrypoints.web.http.redirections.entrypoint.to=websecure\u0026#34; - \u0026#34;--entrypoints.web.http.redirections.entrypoint.scheme=https\u0026#34; ports: - \u0026#34;80:80\u0026#34; # Standard HTTP entrypoint - \u0026#34;443:443\u0026#34; # Secure HTTPS entrypoint - \u0026#34;8080:8080\u0026#34; # Traefik Dashboard volumes: - \u0026#34;/var/run/docker.sock:/var/run/docker.sock:ro\u0026#34; # Secure read-only access to Docker events networks: - proxy-net logging: driver: \u0026#34;json-file\u0026#34; options: max-size: \u0026#34;10m\u0026#34; max-file: \u0026#34;3\u0026#34; # ------------------------------------- # 2. LLM Backend (Ollama) # ------------------------------------- ollama: image: ollama/ollama:latest container_name: ollama restart: unless-stopped user: \u0026#34;root\u0026#34; # Force hardware permissions privileged: true # Bypass Docker AppArmor blocking IO controls to /dev/dri networks: - ai-net devices: - /dev/dri:/dev/dri volumes: - ollama_data:/root/.ollama environment: - OLLAMA_HOST=0.0.0.0 - OLLAMA_VULKAN=1 healthcheck: test: [\u0026#34;CMD\u0026#34;, \u0026#34;ollama\u0026#34;, \u0026#34;list\u0026#34;] interval: 10s timeout: 5s retries: 5 start_period: 15s deploy: resources: limits: memory: 48G logging: driver: \u0026#34;json-file\u0026#34; options: max-size: \u0026#34;20m\u0026#34; max-file: \u0026#34;3\u0026#34; # ------------------------------------- # 3. Frontend UI (Open-WebUI) # ------------------------------------- open-webui: image: ghcr.io/open-webui/open-webui:main container_name: open-webui restart: unless-stopped networks: - ai-net # Internal network to reach Ollama - proxy-net # Edge network facing Traefik volumes: - open_webui_data:/app/backend/data environment: - OLLAMA_BASE_URL=http://ollama:11434 depends_on: ollama: condition: service_healthy # Will not try to start before Ollama\u0026#39;s API responds # Principle of Least Privilege cap_drop: - ALL deploy: resources: limits: memory: 2G logging: driver: \u0026#34;json-file\u0026#34; options: max-size: \u0026#34;10m\u0026#34; max-file: \u0026#34;3\u0026#34; labels: - \u0026#34;traefik.enable=true\u0026#34; # Tell Traefik exactly which network to use to reach this container! - \u0026#34;traefik.docker.network=ai-stack_proxy-net\u0026#34; # Catch-all rule: Allows ANY IP or domain to reach Open-WebUI - \u0026#34;traefik.http.routers.openwebui.rule=PathPrefix(`/`)\u0026#34; # Route traffic through HTTPS and generate a self-signed certificate - \u0026#34;traefik.http.routers.openwebui.entrypoints=websecure\u0026#34; - \u0026#34;traefik.http.routers.openwebui.tls=true\u0026#34; - \u0026#34;traefik.http.services.openwebui.loadbalancer.server.port=8080\u0026#34; # Traefik Security Middleware - \u0026#34;traefik.http.middlewares.secure-headers.headers.browserXssFilter=true\u0026#34; - \u0026#34;traefik.http.middlewares.secure-headers.headers.contentTypeNosniff=true\u0026#34; - \u0026#34;traefik.http.middlewares.secure-headers.headers.forceSTSHeader=true\u0026#34; - \u0026#34;traefik.http.routers.openwebui.middlewares=secure-headers\u0026#34; # ------------------------------------- # Networks \u0026amp; Volumes # ------------------------------------- networks: ai-net: driver: bridge # Secure internal layer proxy-net: driver: bridge # External ingress layer volumes: ollama_data: open_webui_data: Por que essa arquitetura importa # Rodar comandos docker run puros funciona para uma demo rápida, mas não se sustenta em um servidor de homelab permanente. Veja por que estruturamos o docker-compose.yml desta forma:\nAPI do LLM isolada (air-gapped): O Ollama está vinculado exclusivamente à bridge interna ai-net. Não há nenhuma porta exposta no host. A única forma de falar com o modelo é pelo container do Open WebUI, por meio da rede isolada. Ingress dinâmico com Traefik: Em vez de vincular portas do host de forma estática, o Traefik age como um reverse proxy inteligente. Ele roteia o tráfego de entrada nas portas 80/443 diretamente para o Open WebUI usando labels do Docker, força o redirecionamento automático para HTTPS e injeta cabeçalhos de segurança rígidos (browserXssFilter, contentTypeNosniff). A armadilha do \u0026ldquo;Memory Backoff\u0026rdquo;: Como a APU compartilha a RAM do sistema, o driver Vulkan impõe um limite estrito às alocações únicas de memória. Se você tenta carregar um modelo grande demais, a GPU falha na alocação inicial e \u0026ldquo;recua\u0026rdquo; (backs off), jogando essas camadas para a CPU. Se você vê 0% de uso da GPU durante a inferência, é por isso. Ao aumentar o limite de memória do LXC e do Ollama (no nosso caso, para 48GB), damos a folga necessária para o buffer do Vulkan. A tag latest vs rocm: Muitos usuários de AMD puxam por precaução a tag de imagem rocm. Não faça isso com APUs. Em uma APU Ryzen, a abstração do ROCm muitas vezes falha ao inicializar a GPU integrada e recua silenciosamente para a execução na CPU. Para a aceleração Vulkan em APU, a imagem latest simplesmente funciona. Princípio do menor privilégio: Removemos todas as capabilities de root do Linux desnecessárias do container do Open WebUI (cap_drop: ALL). Se surgir uma vulnerabilidade no frontend, o raio de impacto fica contido. Resolvendo o crash do erro 500: Normalmente, o Open WebUI inicia mais rápido do que o Ollama consegue inicializar os drivers da GPU AMD. Quando a interface tenta conectar e falha, ela gera um crash permanente 500: Internal Error. Corrigimos isso construindo um health check nativo com CMD ollama list que sonda a API. O Traefik e o WebUI esperam estruturalmente que o Ollama fique healthy antes de tentar a conexão. 3. Implantar a stack # Suba o ambiente inteiro em segundo plano:\ndocker compose up -d 4. Verificar a aceleração por hardware # Verifique se o Ollama detecta a placa gráfica da AMD antes de baixar qualquer modelo de vários gigabytes.\ndocker logs ollama | grep \u0026#34;AMD\u0026#34; Saída esperada: ggml_vulkan: Found AMD Radeon Graphics\nBônus: como monitorar o uso da GPU (radeontop) # Se você executa inferências pela CLI, pode monitorar as métricas da APU em tempo real com o radeontop, uma alternativa da AMD ao nvidia-smi.\nComo você configurou o container para acessar /dev/dri, dá para executá-lo diretamente de dentro do ambiente LXC.\nPrimeiro, instale o utilitário:\napt install -y radeontop Em seguida, basta executá-lo para ver a atividade de renderização, as alocações de VRAM e as frequências de clock dos shaders:\nradeontop Quando você gera uma resposta no Open WebUI, a utilização do Graphics pipe sobe brevemente a 100% enquanto a GPU processa os tokens.\nO resultado final # Quando estiver rodando, você tem um ambiente de IA local e privado. A aceleração por hardware torna rápidas tarefas como resumir artigos inteiros.\nAcessando o Open WebUI # Você pode acessar a interface web navegando até https://10.1.99.16 (ou o IP que você atribuiu ao seu container LXC) no navegador. Como o Traefik cuida do roteamento, ele responde automaticamente na porta 443 com um certificado autoassinado.\nAqui está o Open WebUI resumindo um link usando a APU:\n","date":"6 de março de 2026","externalUrl":null,"permalink":"/pt/posts/amd_apu_to_lxc/","section":"Posts","summary":"","title":"Passthrough de APU AMD para um LXC do Proxmox para IA local","type":"posts"},{"content":"","date":"6 de março de 2026","externalUrl":null,"permalink":"/pt/categories/proxmox/","section":"Categories","summary":"","title":"Proxmox","type":"categories"},{"content":"","date":"6 de março de 2026","externalUrl":null,"permalink":"/pt/tags/proxmox/","section":"Tags","summary":"","title":"Proxmox","type":"tags"},{"content":"","date":"6 de março de 2026","externalUrl":null,"permalink":"/pt/tags/ryzen/","section":"Tags","summary":"","title":"Ryzen","type":"tags"},{"content":"","date":"18 de agosto de 2025","externalUrl":null,"permalink":"/pt/tags/sddc/","section":"Tags","summary":"","title":"Sddc","type":"tags"},{"content":"","date":"18 de agosto de 2025","externalUrl":null,"permalink":"/pt/categories/sddc/","section":"Categories","summary":"","title":"SDDC","type":"categories"},{"content":" Tarefas com falha no SDDC # Recentemente enfrentei um caso estranho com a VMware: do nada, começaram a aparecer tarefas com falha no meu SDDC. De início achei que fosse algo relacionado a senha expirada, mas não, dessa vez não.\nOs logs não mentem # Pessoas mentem, mas os logs não. Depois de alguns dias trabalhando com o suporte da VMware sem encontrar nenhuma pista do que estava acontecendo, vi por acaso algo no healthcheck do SOS que chamou minha atenção: ele reclamava que o SDDC tinha problemas para se conectar ao meu host pela API (porta 443).\nComo executar um health check no SDDC\n/opt/vmware/sddc-support/sos --health-check --domain-name ALL --skip-cert-check | 21 | ESXi : testhost1.9tec.local | Ping status | GREEN | | | | API Connectivity status | RED | | 21 | ESXI : testhost1.9tec.local | svc-vcf-testhost1 | Jul 20, 2025 | Never | Never | GREEN | | | | root | - | - | - | Failed to get details | | 21 | ESXi : testhost1.9tec.local | NTP Status | YELLOW | | | | ESX Time | YELLOW | Poxa, isso me lembrou de uma situação que encontrei não faz muito tempo, em que a minha replicação do vSphere estava fazendo o reverse proxy do ESXi esgotar as sessões (o limite é 128). Referência: ESXi hosts go unresponsive on the vCenter Server with maximum connection exceeded for the envoy proxy.\nBem, vamos olhar o envoy.log deste host em particular e ver o que está acontecendo\nless /var/log/envoy.log ## or less /var/log/envoy.log Procure pela palavra \u0026ldquo;exceed\u0026rdquo; e você verá se há evidências de que o máximo de conexões foi excedido\n2025-08-13T22:14:06.853Z In(166) envoy[2100238]: \u0026#34;2025-08-13T22:13:57.261Z warning envoy[2100869] [Originator@6876 sub=filter] [Tags: \u0026#34;ConnectionId\u0026#34;:\u0026#34;696461\u0026#34;] remote https connections exceed max allowed: 128\u0026#34; 2025-08-13T22:14:06.853Z In(166) envoy[2100238]: \u0026#34;2025-08-13T22:13:57.261Z warning envoy[2100869] [Originator@6876 sub=filter] [Tags: \u0026#34;ConnectionId\u0026#34;:\u0026#34;696461\u0026#34;] closing connection TCP\u0026lt;my_vcenter_IP:59956, my_esxi_IP:443\u0026gt;\u0026#34; 2025-08-13T22:14:06.853Z In(166) envoy[2100238]: \u0026#34;2025-08-13T22:13:57.261Z info envoy[2100869] [Originator@6876 sub=connection] [Tags: \u0026#34;ConnectionId\u0026#34;:\u0026#34;696461\u0026#34;] remote address:my_vcenter_IP:59956,TLS_error:|268435588:SSL routines:OPENSSL_internal:CLIENTHELLO_TLSEXT|268435646:SSL routines:OPENSSL_internal:PARSE_TLSEXT\u0026#34; O workaround # Como diz a KB mencionada acima, não existe correção, mas há um workaround que consiste em desabilitar o healthcheck da replicação do vSphere (é isso que está consumindo as sessões nos hosts ESXi, por causa das verificações sofisticadas da replicação avançada)\n1 - Abra uma sessão SSH no servidor VRMS nos dois sites.\n2 - Abra o arquivo /opt/vmware/hms/conf/hms-configuration.xml em um editor de texto\nvi /opt/vmware/hms/conf/hms-configuration.xml 3 - Defina schedule-health-checks como false\n4 - Reinicie o serviço HMS nos dois sites\nsystemctl restart hms 5 - Ao configurar a replicação avançada, pule o health check. Clicar no botão \u0026ldquo;Next\u0026rdquo; permite prosseguir com a configuração da replicação sem executar o health check.\n","date":"18 de agosto de 2025","externalUrl":null,"permalink":"/pt/posts/failed-tasks-in-sddc-5-2/","section":"Posts","summary":"","title":"Tarefas com falha no SDDC 5.2","type":"posts"},{"content":"","date":"28 de abril de 2025","externalUrl":null,"permalink":"/pt/categories/automation/","section":"Categories","summary":"","title":"Automation","type":"categories"},{"content":"","date":"28 de abril de 2025","externalUrl":null,"permalink":"/pt/categories/esxi/","section":"Categories","summary":"","title":"ESXi","type":"categories"},{"content":" Requisitos # Máquina Linux (estou usando o WSL rodando Ubuntu 24.04 neste exemplo) ISO do ESXi 8.0U3 (deve funcionar em versões mais antigas, mas alguns parâmetros podem ser diferentes) Objetivos principais # Subir um servidor HTTP temporário que você possa usar em campo para implantar ESXi em massa Criar uma ISO personalizada do ESXi, com o boot.cfg editado para ler o ks.cfg de um servidor HTTP Explicar a lógica por trás dos meus scripts A ISO personalizada # Editar o BOOT.CFG # Baixe a ISO mais recente do ESXi no portal da Broadcom aqui\nMonte essa ISO no seu sistema e copie o conteúdo dela para um diretório dentro da sua máquina Linux (no meu caso, /home/novello/ESXi8/)\nCom esses arquivos em um diretório, é hora de editar o arquivo BOOT.CFG, responsável por indicar onde está o arquivo kickstart\nvi /home/novello/ESXi8/EFI/BOOT/BOOT.CFG e\nvi /home/novello/ESXi8/BOOT.CFG Linhas editadas: timeout: Removi o tempo de espera da tela de abertura para pular a tela de \u0026ldquo;carregando\u0026rdquo;. kernelopt: Adicionei o caminho do arquivo ks.cfg hospedado no servidor web. bootstate=0 title=Loading ESXi installer timeout=0 # Here I removed the timeout to not show the \u0026#34;loading\u0026#34; screen prefix= kernel=/b.b00 kernelopt=runweasel ks=http://192.168.100.32:8000/ks.cfg # Here I added the ks.cfg file to the boot options, loaded from a web server modules=/jumpstrt.gz --- /useropts.gz --- /features.gz --- /k.b00 --- /uc_intel.b00 --- /uc_amd.b00 --- /uc_hygon.b00 --- /procfs.b00 --- /vmx.v00 --- /vim.v00 --- /tpm.v00 --- /sb.v00 --- /s.v00 --- /atlantic.v00 --- /bcm_mpi3.v00 --- /bnxtnet.v00 --- /bnxtroce.v00 --- /brcmfcoe.v00 --- /cndi_igc.v00 --- /dwi2c.v00 --- /elxiscsi.v00 --- /elxnet.v00 --- /i40en.v00 --- /iavmd.v00 --- /icen.v00 --- /igbn.v00 --- /intelgpi.v00 --- /ionic_cl.v00 --- /ionic_en.v00 --- /irdman.v00 --- /iser.v00 --- /ixgben.v00 --- /lpfc.v00 --- /lpnic.v00 --- /lsi_mr3.v00 --- /lsi_msgp.v00 --- /lsi_msgp.v01 --- /lsi_msgp.v02 --- /mtip32xx.v00 --- /ne1000.v00 --- /nenic.v00 --- /nfnic.v00 --- /nhpsa.v00 --- /nipmi.v00 --- /nmlx5_cc.v00 --- /nmlx5_co.v00 --- /nmlx5_rd.v00 --- /ntg3.v00 --- /nvme_pci.v00 --- /nvmerdma.v00 --- /nvmetcp.v00 --- /nvmxnet3.v00 --- /nvmxnet3.v01 --- /pvscsi.v00 --- /qcnic.v00 --- /qedentv.v00 --- /qedrntv.v00 --- /qfle3.v00 --- /qfle3f.v00 --- /qfle3i.v00 --- /qflge.v00 --- /rdmahl.v00 --- /rste.v00 --- /sfvmk.v00 --- /smartpqi.v00 --- /vmkata.v00 --- /vmksdhci.v00 --- /vmkusb.v00 --- /vmw_ahci.v00 --- /bmcal.v00 --- /clusters.v00 --- /crx.v00 --- /drivervm.v00 --- /elx_esx_.v00 --- /btldr.v00 --- /dvfilter.v00 --- /esx_ui.v00 --- /esxupdt.v00 --- /tpmesxup.v00 --- /weaselin.v00 --- /esxio_co.v00 --- /infravis.v00 --- /loadesx.v00 --- /lsuv2_hp.v00 --- /lsuv2_in.v00 --- /lsuv2_ls.v00 --- /lsuv2_nv.v00 --- /lsuv2_oe.v00 --- /lsuv2_oe.v01 --- /lsuv2_sm.v00 --- /native_m.v00 --- /qlnative.v00 --- /trx.v00 --- /vcls_pod.v00 --- /vdfs.v00 --- /vds_vsip.v00 --- /vmware_e.v00 --- /hbrsrv.v00 --- /vsan.v00 --- /vsanheal.v00 --- /vsanmgmt.v00 --- /tools.t00 --- /xorg.v00 --- /gc.v00 --- /imgdb.tgz --- /basemisc.tgz --- /resvibs.tgz --- /esxiodpt.tgz --- /imgpayld.tgz build=8.0.3-0.0.24022510 updated=0 Compilar os novos arquivos em uma nova ISO personalizada # É aqui que a mágica acontece: como compilamos todos aqueles arquivos extraídos em uma nova .ISO personalizada? Simples!\nParâmetros que você precisa alterar:\n-o: Caminho/nome do arquivo que você quer salvar. Neste exemplo, /home/novello/ESXi8U3_custom.iso O caminho onde a ISO foi extraída, no meu caso /home/novello/ESXi8 genisoimage -relaxed-filenames -J -R -o /home/novello/ESXi8U3_custom.iso -b ISOLINUX.BIN -c BOOT.CAT -no-emul-boot -boot-load-size 4 -boot-info-table -eltorito-alt-boot -e EFIBOOT.IMG -no-emul-boot /home/novello/ESXi8 ks.cfg (onde a mágica realmente acontece) # Ok, então no BOOT.CFG eu informei que, quando o host iniciar, ele deve ler um arquivo kickstart e usar a lógica dele para começar a configurar o ESXi. Objetivos principais do ks.cfg # Carregar a instalação do ESXi e aceitar o EULA Definir a senha do root Obter o IP inicial usando a vmnic0 e DHCP Habilitar o SSH e o shell Bash Executar um script Python que vai configurar o IP definitivo e o hostname no host vmaccepteula rootpw VMware123! install --firstdisk --overwritevmfs network --bootproto=dhcp --device=vmnic0 reboot %firstboot --interpreter=busybox # Wait for the network to start sleep 5 # Enable SSH and ESXi Shell vim-cmd hostsvc/enable_ssh vim-cmd hostsvc/start_ssh vim-cmd hostsvc/enable_esx_shell vim-cmd hostsvc/start_esx_shell # Suppress ESXi Shell warning esxcli system settings advanced set -o /UserVars/SuppressShellWarning -i 1 # Adjust the time zone cp /usr/share/zoneinfo/America/Sao_Paulo /etc/localtime # Download the host_config.py script and macs.csv file wget http://192.168.100.32:8000/host_config.py -O /tmp/host_config.py wget http://192.168.100.32:8000/macs.csv -O /tmp/macs.csv # Make the script executable # (Note: The script is already executable in the original code, but this is a good practice) chmod u+x /tmp/host_config.py # Run the host_config.py script /bin/python3 /tmp/host_config.py Objetivos principais do host_config.py # O Python lê o macs.csv Com base no endereço MAC da vmnic0, ele determina qual IP/máscara/gateway/VLAN/hostname será configurado no vmk0 (gerenciamento) import os import csv import subprocess CSVPATH = \u0026#34;/tmp/macs.csv\u0026#34; # Path to the CSV file # Get the MAC address of the host interfaces MAC = subprocess.check_output( \u0026#34;esxcli network ip interface list | grep \u0026#39;MAC Address\u0026#39; | awk \u0026#39;{print $3}\u0026#39;\u0026#34;, shell=True ) MACADDR = MAC.split() print(\u0026#34;MACs found:\u0026#34;) print(MACADDR) # Read the CSV file and find the matching MAC address with open(CSVPATH, \u0026#39;r\u0026#39;) as csvFile: csvReader = csv.reader(csvFile) next(csvReader) # Skip the header row for csvRow in csvReader: # csvRow format: hostname,mac,ip,netmask,gateway,vlan if MACADDR[0].decode(\u0026#39;utf-8\u0026#39;).lower() == csvRow[1].lower(): hostname = csvRow[0] ip = csvRow[2] netmask = csvRow[3] gateway = csvRow[4] vlan = csvRow[5] print(f\u0026#34;Configuring host {hostname} with IP {ip}\u0026#34;) os.system(f\u0026#34;esxcli system hostname set --fqdn={hostname}\u0026#34;) os.system(f\u0026#34;esxcli network ip interface ipv4 set --interface-name=vmk0 --ipv4={ip} --netmask={netmask} --type=static\u0026#34;) os.system(f\u0026#34;esxcfg-route {gateway}\u0026#34;) os.system(f\u0026#34;esxcfg-vswitch -p \u0026#39;Management Network\u0026#39; -v {vlan} vSwitch0\u0026#34;) Como é o macs.csv\nhostname,mac,ip,netmask,gateway,vlan esxi01,00:50:56:11:22:33,10.1.99.101,255.255.255.0,10.1.99.1,99 esxi02,00:50:56:44:55:66,10.1.99.102,255.255.255.0,10.1.99.1,99 Subir o servidor HTTP # Vou usar a mesma instância do WSL que usei para compilar a ISO como servidor HTTP Criei uma pasta separada que vai conter ks.cfg, macs.csv e host_config.py python3 -m http.server -d /home/novello/http No seu navegador, acesse http://\u0026lt;IP_da_instância_WSL\u0026gt;:8000; você deve ver algo parecido com E é só isso: estamos prontos para iniciar a instalação do ESXi, que deve configurar o básico para nós automaticamente.\nInstalado # Para fins de teste, criei uma VM no VMware Workstation e personalizei o endereço MAC para corresponder ao esxi02 do nosso macs.csv Referências # Documentação da VMware sobre o ks.cfg\nGuia de opções de boot da VMware\nWilliam Lam\n","date":"28 de abril de 2025","externalUrl":null,"permalink":"/pt/posts/ztp_esxi_installation/","section":"Posts","summary":"","title":"Instalação do ESXi com ZTP","type":"posts"},{"content":"","date":"28 de abril de 2025","externalUrl":null,"permalink":"/pt/tags/ks.cfg/","section":"Tags","summary":"","title":"Ks.cfg","type":"tags"},{"content":"","date":"23 de abril de 2025","externalUrl":null,"permalink":"/pt/categories/general/","section":"Categories","summary":"","title":"General","type":"categories"},{"content":"","date":"23 de abril de 2025","externalUrl":null,"permalink":"/pt/tags/general/","section":"Tags","summary":"","title":"General","type":"tags"},{"content":" Bem-vindo 🤖🛸 # Olá! Este é o meu primeiro post no blog — um projeto que estava parado no meu backlog há algum tempo. Finalmente arrumei tempo para tirá-lo do papel 🚀\nSe você está aqui, pode esperar posts sobre VMware, Proxmox, Linux, automação e muitos experimentos de homelab 🛠️\nSinta-se à vontade para deixar um comentário ou uma sugestão — adoraria saber o que você gostaria de ver a seguir!\n","date":"23 de abril de 2025","externalUrl":null,"permalink":"/pt/posts/awakening/","section":"Posts","summary":"","title":"Houve um despertar!","type":"posts"},{"content":"","externalUrl":null,"permalink":"/pt/authors/","section":"Authors","summary":"","title":"Authors","type":"authors"},{"content":"","externalUrl":null,"permalink":"/pt/series/","section":"Series","summary":"","title":"Series","type":"series"},{"content":"Olá! Sou Gustavo Novello, Especialista em Infraestrutura de Nuvem, com grande paixão por virtualização, Linux e tecnologias de código aberto. Tenho ampla experiência na gestão de ambientes VMware de grande escala.\nMinha trajetória profissional é construída sobre soluções de infraestrutura resilientes, escaláveis e seguras. Gosto de otimizar sistemas complexos e viabilizar operações de nuvem sem atritos, que sustentam a agilidade e a inovação do negócio.\nAlém da experiência técnica, tenho o compromisso de aprender continuamente e compartilhar conhecimento com a comunidade de tecnologia. Seja por colaboração, mentoria ou contribuição para projetos de código aberto, acredito no poder do crescimento coletivo.\nFique à vontade para se conectar comigo no LinkedIn para explorar possíveis colaborações ou conversar sobre as novidades em infraestrutura de nuvem e virtualização.\n","externalUrl":null,"permalink":"/pt/about/","section":"Do homelab à nuvem híbrida","summary":"","title":"Sobre","type":"page"}]