vCenter, vSphere e ESXi: quem faz o quê no ambiente VMware
Autor: Pedro Tebaldi PM do KeepGreenNa reunião de orçamento, o ambiente se chama vSphere. No chamado que o N1 abriu de madrugada, ele virou ESXi. Na conversa com o fornecedor de backup, alguém pede o acesso ao vCenter. Ainda assim, é o mesmo parque de servidores nos três casos.
A troca de nomes parece inofensiva até o momento em que ela entra numa decisão. Dimensionar licença, desenhar coleta de métricas, definir o que o plantão resolve sozinho às três da manhã. Cada escolha dessas depende de saber qual camada faz o quê. Por isso, confundir as três leva a comprar o que já se tem.
Este artigo separa a pilha por camada. Em seguida, inverte a pergunta habitual. Em vez de listar o que o vCenter faz, ele responde o que para de funcionar quando o vCenter cai. Essa é a informação que o operador precisa antes do incidente, não durante.
Três nomes, um ambiente: por que a confusão persiste
Dois fatores sustentam a mistura. O primeiro é comercial. A VMware batizou de vSphere o produto vendido. O operador, porém, convive todo dia com o binário instalado no servidor, que se chama ESXi. Ou seja, vendedor e administrador descrevem a mesma infraestrutura com vocabulários diferentes.
O segundo fator é a interface. O console web que o time abre para tudo se chama vSphere Client, inclusive quando ele está conectado a um único host sem gerência centralizada. Dessa forma, a tela reforça o nome da suíte e apaga a fronteira entre os componentes.
Some-se a isso o hábito de usar “VMware” como sinônimo do ambiente inteiro. A empresa produz dezenas de linhas. No entanto, o comparativo entre as plataformas que disputam o mercado de virtualização costuma tratar “VMware” como uma opção única. Na prática, existe uma pilha com camadas separáveis.
O custo dessa imprecisão aparece em três lugares recorrentes. Antes de tudo, na renovação, quando o time descobre que pagava por recurso que nunca ligou. Depois disso, no projeto de monitoramento, quando alguém aponta a ferramenta para o alvo errado. Por fim, no plantão, quando ninguém sabe dizer se a indisponibilidade atinge as máquinas virtuais ou apenas o painel.
ESXi, vSphere e vCenter: quem faz o quê
O ESXi é o hypervisor tipo 1 instalado direto no hardware do servidor, onde as máquinas virtuais realmente executam. O vSphere é a suíte que empacota esse hypervisor com os demais componentes. O vCenter Server é a aplicação que centraliza a gerência de vários hosts ESXi em um único ponto de controle.
A relação entre os três é de contenção, não de concorrência. Isto é, o vSphere contém o ESXi e o vCenter; comparar vSphere com vCenter é comparar a caixa com uma das peças dentro dela. A tabela abaixo separa as responsabilidades pelo critério que importa na operação.
| Dimensão | ESXi | vCenter Server | vSphere |
|---|---|---|---|
| O que é | Hypervisor tipo 1 | Aplicação de gerência | Suíte que reúne os dois |
| Onde roda | No metal, sem sistema operacional embaixo | Como appliance, dentro de uma VM do próprio parque | Não roda: é o nome do conjunto |
| Executa VM? | Sim, é quem executa | Não executa nenhuma | Por meio do ESXi |
| Gerência sem ele | Impossível: sem host não há ambiente | Host a host, pelo VMware Host Client | Termo comercial, não operacional |
| Escopo | Um servidor por vez | Todo o inventário de hosts | Depende da edição contratada |
| Interface | Host Client e DCUI |
vSphere Client e API |
Herda a do componente |
Repare na terceira linha, porque ela desfaz o mal-entendido mais caro. O vCenter não executa carga nenhuma. Ele orquestra, agenda, aplica política e guarda o inventário. Ao mesmo tempo, o trabalho de rodar máquina virtual continua inteiro nos hosts ESXi.
O que só passa a existir quando há vCenter
Sem vCenter, cada host é uma ilha. Ele executa suas VMs, aceita conexão pelo Host Client e sobrevive sozinho. Todavia, tudo que depende de enxergar mais de um host ao mesmo tempo deixa de ser possível.
O vMotion entra nessa lista. Ele costuma ser o argumento decisivo da compra. Migrar uma máquina virtual ligada de um host para outro, sem derrubar a sessão do usuário, exige um orquestrador que conheça os dois lados. Da mesma forma, o DRS redistribui carga entre hosts conforme a pressão de CPU e memória muda.
O HA também nasce aí. Configurar reinício automático de VM após queda de host pressupõe um cluster de virtualização declarado. Essa declaração vive no vCenter. Além disso, perfis, papéis e delegação por pasta só existem na camada central. Sem ela, o acesso volta a ser a credencial local de cada host.
A prova mais direta dessa fronteira está na edição gratuita do hypervisor.
Segundo as notas de versão publicadas pela Broadcom, ela não conecta à gerência centralizada e aceita no máximo 8 vCPUs por máquina virtual.
Ademais, essa edição não traz suporte do fabricante e sai declarada para uso fora de produção. Ou seja, o limite ali não é de capacidade bruta: é de orquestração.
O que continua de pé quando o vCenter cai
Esta é a pergunta que a documentação responde por partes, mas que quase nenhum artigo reúne. Em síntese, a resposta tranquiliza mais do que o esperado: as máquinas virtuais não param.
Os hosts ESXi seguem executando tudo que já estava ligado, porque o vCenter nunca esteve no caminho do dado. Assim, você continua acessando cada host pelo Host Client, ligando ou desligando VM e abrindo console. Inclusive, o Distributed Switch continua encaminhando tráfego com a configuração já gravada nos hosts.
O que trava é a camada de decisão. Nenhuma migração nova por vMotion parte do vSphere Client. Além disso, o DRS para de rebalancear. Alterações de cluster, de portgroup distribuído e de política de armazenamento também ficam bloqueadas.
Simultaneamente, os perfis de permissão saem do ar. O acesso regride para a credencial local de cada host, o que costuma pegar o plantão sem senha em mãos.
Existe ainda um efeito de segunda ordem. Backup, replicação, automação e coleta de terceiros normalmente autenticam pela API do vCenter. Quando ele cai, portanto, essas rotinas falham em silêncio, mesmo com o ambiente inteiro rodando.
Por isso o vCenter merece o mesmo rigor de monitoramento de servidores aplicado a qualquer sistema de produção. No final das contas, ele é um ponto único de gerência que ninguém vigia até faltar.
O vCenter como fonte de dados do monitoramento
Depois de entender a divisão de papéis, a pergunta operacional muda. Nesse sentido, a dúvida deixa de ser o que cada peça faz. Ela passa a ser de onde a ferramenta externa tira número confiável.
Por que a coleta aponta para a camada central
O vCenter mantém o inventário consolidado: hosts, clusters, datastores, VMs e a relação entre eles. Dessa forma, uma ferramenta que fala com ele enxerga o parque inteiro em uma credencial só, com a topologia já montada. Apontar a coleta host a host funciona, porém devolve ilhas sem contexto de cluster.
A boa prática de acesso é conhecida e vale repetir: crie um usuário com perfil somente-leitura para a coleta. O monitoramento precisa ler contadores e inventário, nunca ligar, migrar ou desligar carga. Em contrapartida, projetos de monitorar um parque VMware que começam com credencial administrativa acumulam risco sem ganho de dado.
O que medir no host, na VM e na camada de gerência
A leitura útil combina camadas. No host entram saturação de CPU, pressão de memória, latência de datastore e descarte em interface.
Na VM entram CPU ready, ballooning e swap. Esses três denunciam disputa por recurso antes de o usuário reclamar. Ainda assim, o conjunto de métricas que fazem sentido acompanhar em hosts e VMs muda conforme o parque cresce.
Vale destacar a própria camada de gerência. Três sinais antecipam a queda descrita na seção anterior. São eles: serviço do appliance no ar, uso de disco das partições de log e banco, resposta da API.
O que o empacotamento pós-Broadcom mudou nessa conta
Até 2023, vCenter, vSphere e complementos eram itens de catálogo separáveis. A Broadcom consolidou a oferta em pacotes. Como resultado, o vCenter deixou de ser uma linha de pedido independente: ele entra junto com a assinatura da plataforma.
Quem precisa dos detalhes contratuais encontra o desenho atualizado em o que mudou no licenciamento depois da Broadcom. Duas consequências práticas, no entanto, afetam quem opera o ambiente todo dia.
A primeira é de escala.
As notas da versão 8.0 da plataforma registram que as operações com imagens do Lifecycle Manager passaram a suportar 1.000 hosts, contra 280 antes.
Portanto, quem planejava mais de uma instância de gerência por limite técnico deve refazer a conta.
A segunda é onde conferir número antes de desenhar topologia.
Os limites testados por versão ficam no portal de limites de configuração mantido pelo fabricante, que a própria Broadcom aponta como referência suportada. Por outro lado, blog de fornecedor repete número velho com frequência.
Um detalhe operacional fecha a seção. A documentação oficial em português saiu do ar: os endereços antigos em docs.vmware.com/br/ respondem com redirecionamento para o portal técnico da Broadcom, hoje em inglês. Logo, quem mantém runbook com link antigo vai encontrar rota quebrada.
99,9% de uptime não acontece por acidente. É resultado de engenharia.
Estruturamos arquiteturas de monitoramento proativo que elevam sua disponibilidade de forma gradativa e mensurável, com SLA garantido em contrato.
Antes da próxima renovação
A separação entre as três camadas não é preciosismo de vocabulário. Ela define o que se compra, o que se monitora e o que o plantão resolve sozinho. Em resumo, o ESXi executa, o vCenter orquestra e o vSphere é o nome do conjunto que chega no contrato.
Três verificações valem uma hora de trabalho antes da próxima renovação. Antes de tudo, liste quais recursos do vCenter o ambiente usa de verdade. Recursos como vMotion, DRS e HA aparecem em toda proposta, mas nem todo parque os ativou.
Em seguida, confirme se a camada de gerência está sob monitoramento, com alerta de serviço e de disco. Por fim, releia os limites da sua versão na fonte do fabricante, nunca no material comercial.
O ambiente que sobrevive bem a uma queda de vCenter é aquele em que alguém mapeou essa fronteira antes do incidente. Se você quer esse mapa feito com dado de coleta, fale com um especialista da OpServices sobre o seu parque virtualizado.
Perguntas Frequentes
Qual a diferença entre ESX e ESXi?
VMvisor e ESXi são a mesma coisa?
Como adicionar um host ESXi ao vCenter?
vSphere Client, dentro de um datacenter ou cluster já criado, informando endereço, usuário root do host e senha. Antes disso, confirme resolução de nome nos dois sentidos, sincronismo de horário por NTP e liberação das portas de gerência entre o appliance e o host. Falha de DNS e diferença de relógio respondem pela maioria das recusas de inclusão. O erro devolvido raramente aponta a causa real.O ESXi ainda tem versão gratuita?
8 vCPUs por máquina virtual, não inclui suporte do fabricante e é declarada para uso fora de produção. Ela serve para laboratório e teste, nunca como base de um ambiente produtivo.
