Migrando do VMware: 7 alternativas open source que eu colocaria em produção sem hesitar

Na sala fria do datacenter, com o rack já reduzido para caber no orçamento do trimestre, eu fiz a conta que todo time de infraestrutura acaba fazendo quando o VMware pesa demais no CAPEX e no contrato de suporte: manter a pilha proprietária ou desenhar a saída com alternativas open source para virtualização e cloud. A resposta, para ambientes Linux e DevOps, quase nunca é sentimental. É operacional. E a melhor rota depende do tipo de workload, do nível de automação que você precisa e de quanto controle quer devolver para o seu próprio stack.

Eu já vi migração sair limpa usando KVM com libvirt e Proxmox, e já vi cluster travado por decisão apressada de mover tudo para uma plataforma “mais moderna” sem validar storage, rede e estratégia de snapshots. Então vou ser direto: migrando do VMware, você não troca um hypervisor por outro; você troca um ecossistema inteiro. Se quiser reduzir risco, precisa tratar compute, rede, storage, backup, observabilidade e automação como um único problema.

1. Proxmox VE: a saída mais pragmática para quem quer sair do VMware sem reinventar o datacenter

Se eu tivesse de escolher uma plataforma para a maioria dos ambientes que saem de VMware em Linux e DevOps, Proxmox VE estaria no topo. Não por marketing. Por pragmatismo operacional. Ele entrega KVM para VM e LXC para containers, interface web decente, cluster nativo, réplica, storage plugins, API e uma curva de aprendizado curta para quem já administra Debian, ZFS, Ceph ou NFS.

A principal vantagem aqui é que a plataforma não te obriga a montar tudo na mão. Você sobe nós, cria cluster, integra storage e já começa a importar workload. Para times pequenos ou médios, isso elimina o custo invisível de operar peças soltas. E para quem vive de automação, a API do Proxmox permite encaixar o ambiente em Ansible, Terraform e pipelines de CI.

Base de instalação e cluster

apt update
apt install -y wget gnupg
wget https://enterprise.proxmox.com/debian/proxmox-release-bookworm.gpg -O /usr/share/keyrings/proxmox-release-bookworm.gpg
echo "deb [signed-by=/usr/share/keyrings/proxmox-release-bookworm.gpg] http://download.proxmox.com/debian/pve bookworm pve-no-subscription" 
 > /etc/apt/sources.list.d/pve-install-repo.list
apt update
apt install -y proxmox-ve postfix open-iscsi chrony
pvecm create lab-cluster

Se você vai usar cluster de verdade, não economize na rede. Eu considero 10 GbE o ponto de partida honesto para ambientes com storage compartilhado ou réplica de VM. Em cluster com Ceph, 25 GbE faz diferença real na janela de rebuild e no comportamento sob carga. Misturar tráfego de gerenciamento, replicação e storage em 1 GbE é pedir para sofrer depois.

Quando Proxmox vence

• Ambiente pequeno ou médio que precisa sair rápido de VMware.
• Equipe que quer interface web sem abrir mão de shell e API.
• Uso intenso de ZFS, backup incremental e réplica entre nós.
• Necessidade de automatizar VMs com Ansible ou Terraform.

O ponto fraco é o mesmo que dá força: ele é opinativo. Se seu desenho exige integração com storage enterprise muito específico ou governança pesada em escala de provedor, você vai sentir limites mais cedo. Mas para migrar do VMware com cabeça de DevOps, Proxmox VE é uma aposta muito sólida.

2. KVM + libvirt: a rota mais limpa para quem quer controle total no Linux

Se o seu time já opera Linux de forma madura, KVM com libvirt é a alternativa mais honesta. Não tem camada extra de abstração tentando esconder o que o kernel já faz bem. Você usa o hipervisor nativo do Linux, gerencia por libvirt, automatiza com virsh, virt-install, Ansible e, se quiser subir o nível, integra com OpenStack ou com orquestradores próprios.

Essa opção ganha quando a prioridade é previsibilidade. O comportamento do stack fica mais transparente. Você sabe exatamente onde a CPU é alocada, como a memória é ballooned, como a rede está conectada e como o storage está exposto ao guest. Isso reduz dependência de appliance e torna troubleshooting muito mais rápido para quem já trabalha com perf, fio, tcpdump e systemd.

Provisionamento por linha de comando

virt-install 
 --name app01 
 --memory 4096 
 --vcpus 2 
 --disk path=/var/lib/libvirt/images/app01.qcow2,size=40,bus=virtio 
 --os-variant ubuntu24.04 
 --network bridge=br0,model=virtio 
 --graphics none 
 --console pty,target_type=serial 
 --location http://mirror.cedia.org.ec/ubuntu/dists/noble/main/installer-amd64/

O segredo do KVM não está no comando de instalação. Está na engenharia ao redor: bridge correta, tuning de CPU, storage coerente e um padrão de rede que não vire colcha de retalhos. Se você usa virtio-blk ou virtio-scsi depende do perfil do workload. Para banco, eu normalmente prefiro virtio-scsi com cache e discard ajustados com cuidado. Para VMs leves, virtio-blk já resolve.

Snippet de rede com bridge no Linux

# /etc/netplan/01-br0.yaml
network:
 version: 2
 ethernets:
 enp3s0:
 dhcp4: no
 bridges:
 br0:
 interfaces: [enp3s0]
 addresses: [192.168.10.20/24]
 gateway4: 192.168.10.1
 nameservers:
 addresses: [1.1.1.1, 8.8.8.8]
 parameters:
 stp: false
 forward-delay: 0

Onde KVM brilha mesmo é em automação. Você consegue carregar esse desenho inteiro em Git, versionar o template, a rede e o storage. Essa disciplina vale ouro quando a migração sai do “vamos mover 20 VMs” para “vamos recriar 200 workloads com naming, tags e políticas consistentes”.

3. OpenStack: a opção certa quando o problema já é cloud privada, não apenas virtualização

OpenStack não é para todo mundo. E eu prefiro dizer isso logo para evitar desastre. Se o objetivo é apenas substituir VMware por VMs, OpenStack pode virar uma máquina de complexidade. Mas se o ambiente exige multi-tenancy, self-service, network overlays, catálogo de imagens, quotas, projeto por time e automação forte, aí a conversa muda.

Na prática, OpenStack é o caminho para quem quer construir uma cloud privada com governança e APIs robustas. Ele encaixa muito bem em organizações que já vivem de infra as code e precisam separar domínio de rede, compute, identidade e armazenamento. O preço da flexibilidade é a operação. Não existe almoço grátis. O stack pede maturidade em Linux, mensagens, banco, identity provider, storage backend e observabilidade.

O que eu consideraria obrigatório

• Identidade centralizada com Keystone integrada a um IdP corporativo.
• Storage bem definido: Ceph, NFS ou backend enterprise compatível.
• Rede desenhada com Neutron e estratégia clara de VXLAN ou VLAN.
• Pipeline para imagens com Glance e hardening antes do deploy.

Para subir serviços em OpenStack, o desenho de implantação precisa ser repetível. Se você está escrevendo comando manual em produção, o ambiente ainda está cru. O mínimo aceitável é automatizar via Ansible e manter inventário limpo. Um exemplo simplificado de playbook para validar pacote base:

- hosts: controllers
 become: true
 tasks:
 - name: Instalar dependências base
 apt:
 name:
 - python3-openstackclient
 - mariadb-client
 - rabbitmq-server
 state: present
 update_cache: yes

Se seu time não tem apetite para manter isso, eu não forçaria OpenStack só porque a palavra “cloud” soa bem no slide. Mas quando o requisito é cloud privada de verdade, com automação e isolamento, ele ainda é uma das alternativas open source para virtualização e cloud mais completas do mercado.

4. oVirt: a migração mais próxima da experiência clássica de virtualização enterprise

oVirt ficou em um lugar interessante: menos “plataforma para construir tudo” do que OpenStack, e mais orientado à virtualização tradicional. Quem vem de VMware costuma se sentir menos perdido aqui. Há cluster, storage domains, templates, snapshots, live migration e uma camada de gerenciamento centralizada. É uma alternativa que conversa bem com times que querem continuar operando VMs com disciplina de datacenter clássico.

Eu gosto do oVirt quando o ambiente precisa de uma transição com menos fricção conceitual. Você não precisa convencer o time inteiro a pensar em cloud nativa de um dia para o outro. E isso importa. A migração técnica já é difícil; a migração de mentalidade costuma ser pior.

Integração com storage e rede

OVirt costuma funcionar bem com storage compartilhado e redes claramente segmentadas. O desenho ideal é simples de explicar e chato de improvisar: management separado, storage separado, tráfego de VM separado. Quando você tenta “economizar VLAN”, o problema aparece nos horários ruins. Sempre aparece.

Para administradores Linux, o valor está em APIs e automação ao redor do ciclo de vida da VM. O ecossistema não tem a onipresença de VMware, mas entrega uma transição consistente para operações de VM em ambiente open source sem empurrar imediatamente tudo para Kubernetes ou para um mega-ambiente de cloud privada.

5. XCP-ng: bom equilíbrio para times que querem hypervisor dedicado com administração simples

XCP-ng entra bem quando a prioridade é hypervisor dedicado e gestão centralizada sem complicar demais. Ele é útil para workloads com necessidade de live migration, alta disponibilidade e organização em pool. O administrador não fica preso a uma experiência excessivamente manual, e a camada de gerenciamento ajuda a manter a operação sob controle.

Se eu comparo com KVM puro, XCP-ng entrega mais estrutura pronta. Se comparo com Proxmox, perde em algumas flexibilidades de stack Linux crua, mas ganha em uma abordagem mais “appliance-like”. Para determinadas equipes isso é exatamente o que funciona.

Onde ele se encaixa no plano de saída

• Ambientes que exigem operação estável com pouco atrito.
• Times que preferem abstração moderada sobre hiperconfiguração.
• Projetos que precisam de HA e manutenção simplificada.

Eu não usaria XCP-ng como base para uma cloud privada pesada com muitas integrações customizadas. Para isso, OpenStack ou KVM mais automatizado me parecem escolhas melhores. Mas como substituto de parte da experiência VMware em virtualização clássica, ele merece lugar alto na lista de alternativas open source para virtualização e cloud.

6. OpenNebula: o meio-termo que muita gente ignora

OpenNebula costuma ser subestimado porque não faz tanto barulho quanto OpenStack. Justamente por isso me interessa. Ele pode atender cloud privada, virtualização e ambientes com automação sem exigir o nível de complexidade de uma stack OpenStack completa. Em empresas que querem portal, multi-tenant, templates, redes virtuais e integração com KVM, ele aparece como solução equilibrada.

O valor de OpenNebula está na simplicidade relativa. Ele organiza o ciclo de vida da VM, entrega API e trabalha bem em cenários onde o time quer sair do VMware sem construir uma operação nova do zero. Se a equipe já tem maturidade com Linux e algum domínio de infraestrutura como código, a curva tende a ser administrável.

Exemplo de template de VM

NAME = "ubuntu-iaas"
CPU = "2"
VCPU = "2"
MEMORY = "4096"
DISK = [
 IMAGE_ID = "18",
 SIZE = "20480"
]
NIC = [ NETWORK = "prod-net" ]

Eu considero OpenNebula uma escolha útil quando a organização quer uma camada central para cloud privada, mas não quer operar a complexidade total de uma nuvem em escala de hyperscaler. É um meio-termo real, não um compromisso tímido.

7. EVE-NG ou GNS3: quando a migração esbarra em laboratório, validação e treinamento

Nem toda saída do VMware precisa mirar produção. Em vários times, o primeiro passo é reconstruir o ambiente de laboratório, proof of concept e treinamento. Aí EVE-NG e GNS3 entram com força. Não são substitutos diretos para datacenter corporativo, mas são excelentes para topologias de rede, testes com appliances virtuais e simulações de integração.

Eu coloco esses dois por último porque eles resolvem outro pedaço do problema. Ainda assim, são úteis demais para serem ignorados. Se você vai migrar a infraestrutura e precisa provar comportamento de rede antes de tocar em produção, um laboratório isolado em KVM com essas ferramentas economiza horas de retrabalho.

Uso tático no processo de migração

• Testar roteamento entre VLANs e overlays.
• Validar templates de firewall e ACL.
• Simular falha de links e retorno de serviços.

Isso é particularmente valioso quando há dependência de storage iSCSI, BGP, VRRP ou integração com appliances de segurança. Não dá para migrar isso “no escuro”.

Ordem prática para sair do VMware sem atropelar produção

Se eu tivesse de ordenar as alternativas open source para virtualização e cloud por aderência prática à migração de VMware, eu seguiria assim:

1. Proxmox VE para a maior parte dos datacenters que querem rapidez com controle.
2. KVM + libvirt para equipes Linux maduras que querem automação total.
3. oVirt para continuar com mentalidade enterprise clássica de VM.
4. OpenNebula para cloud privada equilibrada com menor complexidade.
5. OpenStack para cloud privada séria, multi-tenant e altamente automatizada.
6. XCP-ng para hypervisor dedicado com operação simples.
7. EVE-NG/GNS3 para laboratório e validação de topologia.

Como eu desenho a migração de forma automatizável

O erro clássico é migrar VM por VM sem reestabelecer padrão. Eu prefiro tratar a saída do VMware como uma iniciativa de infraestrutura como código. A ordem de trabalho muda bastante quando você pensa assim:

{
 "migration_phases": [
 "inventario",
 "classificacao_workload",
 "baseline_host",
 "rede_e_storage",
 "piloto",
 "batch_migration",
 "descomissionamento"
 ]
}

Inventário não é só lista de VMs. É dependência de rede, disco, RPO, RTO, sistema operacional, versão de kernel, suporte a virtio, uso de snapshots e janela de mudança. Sem isso, qualquer cronograma vira fantasia.

Checklist operacional que eu uso

• Confirmar compatibilidade de guest tools e drivers virtio.
• Mapear VLANs, bridges, MTU e políticas de firewall.
• Validar storage de destino com teste de IOPS e latência.
• Planejar corte com rollback que não dependa do hypervisor antigo.

O teste de storage não precisa ser sofisticado para ser útil. Um fio simples já mostra muita coisa:

fio --name=randrw --filename=/var/lib/libvirt/images/testfile 
 --size=2G --bs=4k --rw=randrw --iodepth=32 --numjobs=4 
 --direct=1 --runtime=60 --time_based

Se o resultado não se sustenta sob carga, a migração está sendo construída em cima de suposição. E suposição em infraestrutura cobra juros.

O detalhe que quase sempre decide o sucesso: storage e rede antes do hypervisor

Quando alguém me pergunta por que um projeto de saída do VMware travou, a resposta está quase sempre em storage ou rede. O hypervisor raramente é o problema central. É a orquestração dos recursos ao redor dele.

Em storage, eu gosto de separar claramente os cenários:

• ZFS local para simplicidade, snapshots e replicação ponto a ponto.
• Ceph para resiliência e elasticidade em cluster.
• NFS bem projetado para ambientes menores ou legados.
• iSCSI quando a arquitetura já depende disso e o time domina o backend.

Em rede, a regra é brutal: padronize naming, MTU e segmentação. Se a ponte do host, a VLAN da VM e o firewall não conversam com clareza, a migração vai virar uma sequência de exceções mal documentadas.

Uma rota realista para equipes Linux e DevOps

Se o seu contexto é Linux e DevOps, minha recomendação é começar por Proxmox ou KVM/libvirt, usando Ansible como camada de execução e Git como fonte de verdade. Depois, só depois, avaliar se o ambiente realmente pede OpenStack ou OpenNebula. Muita gente tenta pular direto para a opção mais ambiciosa e paga com complexidade sem necessidade.

O caminho mais seguro que eu já vi em produção costuma ter este desenho:

VMware
 → inventário e classificação
 → POC em Proxmox ou KVM
 → automatização de rede/storage
 → batch migration
 → remoção de dependências do legado
 → descomissionamento gradual

Esse fluxo respeita o que realmente quebra migração: dependências invisíveis. Uma VM de aplicação pode ser simples. O problema é o DNS preso em outra VLAN, a réplica de banco fora do padrão, a integração com backup sem agente compatível, a regra de firewall esquecida em um edge antigo. É aí que o projeto sangra tempo.

Quando a plataforma nova estiver estável, versionar templates e playbooks vira obrigação. Um exemplo mínimo em Ansible para criar host provisório:

- hosts: proxmox
 become: true
 tasks:
 - name: Criar diretório de imagens
 file:
 path: /vmdata/images
 state: directory
 mode: '0755'

 - name: Garantir serviço de virtualização ativo
 service:
 name: pvedaemon
 state: started
 enabled: yes

No fim, a melhor alternativa open source não é a que soa mais sofisticada em conversa de corredor. É a que encaixa no seu modo de operar, aceita automação sem gambiarra e reduz dependência de licenças, sem introduzir fragilidade nova. Para muita gente, isso vai ser Proxmox. Para outros, KVM puro. Em alguns casos, OpenStack fará sentido. O erro é tratar tudo como se fosse a mesma coisa.

Se a sua meta é tirar o peso do VMware sem perder governança, comece pelo inventário, construa um piloto em KVM ou Proxmox, valide rede e storage com fio e só então mova os lotes críticos. O stack certo aparece quando o primeiro corte de produção acontece sem pedido de rollback às 2 da manhã.

Rogerio Lima

Sou um profissional na área de Tecnologia da informação, especializado em monitoramento de ambientes, Sysadmin e na cultura DevOps. Possuo certificações de Segurança, AWS e Zabbix.