Made4it

Alternativas ao VMware em 2026: conheça o Huawei FusionCompute

Quem trabalha com virtualização já entendeu que o VMware virou uma discussão diferente depois da Broadcom. A pauta saiu do “qual recurso eu preciso?” e foi para “quanto isso vai custar na próxima renovação?”. Em muitos clientes, essa conversa abriu espaço para o Proxmox. Faz sentido. Mas existe uma terceira opção que quase nunca aparece nas primeiras reuniões: o Huawei FusionCompute.

A plataforma não é nova nem experimental. Está na versão 8.10, tem documentação técnica extensa e casos de uso em telcos, bancos e órgãos governamentais ao redor do mundo.

No Brasil, ele ainda aparece pouco nas conversas sobre substituição do VMware. E talvez esteja na hora de olhar para ele com mais calma.

O que é o FusionCompute?

O FusionCompute é a camada de virtualização da Huawei para data center. Ele roda sobre servidores físicos, entrega VMs, gerencia CPU, memória, rede e storage, e faz parte da solução DCS da Huawei.

A arquitetura gira em torno de dois componentes:

CNA (Computing Node Agent): roda em cada servidor físico, implementa o hypervisor UVP e gerencia as VMs localmente.

VRM (Virtual Resource Manager): O VRM é o cerebro central e concentra a gestão do cluster. Ele controla agendamento de recursos, ciclo de vida das VMs, alocação de IP e VLAN, e entrega a interface web de administração. Roda em modo ativo/standby com failover automático em 1 a 2 minutos se o nó ativo cair.

O hypervisor UVP tem base em KVM, assim como o Proxmox, mas opera em arquitetura bare-metal sem OS host intermediário, parecido com o ESXi.

Tabela comparativa das três plataformas

 A tabela abaixo ajuda a separar o que é diferença real de arquitetura e o que é apenas diferença de empacotamento comercial.

FuncionalidadeVMware ESXi / vSphere 8Proxmox VE 9.2Huawei FusionCompute 8.10
Tipo de hypervisorBare-metal (ESXi)Type-1 (KVM + QEMU)Bare-metal (UVP/KVM)
Hosts por clusteraté 96Sem limite explícito*até 128
VMs por clusteraté 8.000Sem limite explícitoaté 8.000
LicenciamentoAssinatura obrigatória; mín. 72 cores/CPUOpen-source (suporte pago opcional)Licença comercial Huawei
VM HA✅ automático, independente do nó de gestão
Live Migration✅ vMotion
Storage Live Migration✅ Storage vMotion
Balanceamento de carga automático✅ DRS (incluso no bundle)✅ Dynamic Load Balancer (desde PVE 9.2)✅ DRS + DPM integrados
Economia de energia automática (DPM)✅ desliga hosts ociosos automaticamente
Memory Overcommit inteligente✅ (ballooning)✅ (ballooning + sharing + swapping; x86 e Arm)
Thin Provisioning
Virtual Switch distribuído✅ vDS (no bundle pago)✅ OVS/SDN✅ DVS nativo
SR-IOVLimitado
GPU Passthrough
GPU Virtualization✅ (NVIDIA vGPU)✅ (NVIDIA vGPU, desde 2025)✅ (Intel vGPU integrado)
Containers / K8s nativo❌ (Tanzu, separado e pago)✅ (LXC; sem K8s nativo)✅ K8s integrado
Multi-tenant completo✅ (com add-ons)✅ (VPC, ECS, ELB, NAT, etc.)
DR orquestrado✅ SRM (pago)✅ UltraVR integrado
Backup agentless com CBT✅ (via terceiros)✅ Proxmox Backup Server✅ eBackup nativo
Suporte a Arm
Black Box de diagnóstico

A documentação oficial do Proxmox não define um limite de nós por cluster. O teto prático depende de hardware de rede e latência; há relatos de clusters com mais de 50 nós em produção com hardware enterprise.

O que chama atenção no FusionCompute

Escala de cluster

O FusionCompute suporta 128 hosts e 8.000 VMs por cluster lógico, com até 4.096 hosts e 80.000 VMs gerenciadas por instância. O VMware chega a 96 hosts por cluster no vSphere 8. O Proxmox não tem um teto documentado, mas a estabilidade em clusters muito grandes depende bastante de como a rede de gerenciamento foi projetada.

Para data centers corporativos grandes, o suporte a 128 hosts por cluster com escala total de 80.000 VMs é um grande diferencial.

DRS e DPM: agendamento que poupa energia

O DRS do FusionCompute monitora a carga dos hosts em tempo real e migra VMs automaticamente para equilibrar o uso de CPU e memória no cluster, sem intervenção manual. Isso equivale ao que o VMware oferece no bundle do vSphere e ao que o Proxmox passou a oferecer com o Dynamic Load Balancer do PVE 9.2.

O diferencial do FusionCompute aqui é o DPM (Dynamic Power Management): quando a carga do cluster cai, o sistema consolida as VMs em menos hosts e desliga automaticamente os servidores ociosos. Quando a demanda sobe, os hosts são religados. Para ambientes com carga variável ao longo do dia ou da semana, isso representa economia real de energia sem precisar de automação externa.

Memory Overcommitment com três camadas

O FusionCompute combina ballooning, memory sharing (páginas idênticas entre VMs são consolidadas em uma cópia física) e swapping para permitir que um servidor ofereça mais memória virtual do que a física disponível. O Proxmox usa ballooning, mas não implementa memory sharing entre VMs de forma nativa. O resultado prático é uma densidade maior de VMs por host no FusionCompute, especialmente quando as cargas têm perfil de uso de memória parecido.

Esse recurso funciona tanto em x86 quanto em Arm, o que é um diferencial em ambientes com servidores Kunpeng ou similares.

QoS de recursos por VM com três dimensões

Enquanto o Proxmox tem controles básicos de CPU shares e limites, o FusionCompute permite configurar três parâmetros independentes por VM:

Quota: a proporção de CPU que a VM recebe durante disputa de recursos entre VMs no mesmo host.

Reservation: o mínimo garantido de CPU que a VM sempre receberá, mesmo sob alta contenda.

Limit: o teto absoluto de CPU que a VM pode consumir, mesmo com o host ocioso.

O mesmo modelo se aplica a memória, rede e IOPS de storage. Isso importa quando o mesmo cluster mistura produção, homologação e carga menos previsível. Sem política de recurso bem definida, uma VM barulhenta pode virar problema para outra área.

Isolamento de VMs em cinco camadas

O hypervisor UVP implementa isolamento entre VMs em cinco dimensões: recursos físicos, agendamento de vCPU (via VMCS), memória (com três níveis de endereçamento que impedem VMs de acessar a memória umas das outras), rede interna (com VRF e filtragem de pacotes) e I/O de disco.

Além disso, cada host tem um Black Box embarcado que registra informações críticas do kernel em memória não volátil quando ocorre uma exceção. Em qualquer falha de sistema, os dados de diagnóstico ficam preservados para análise pós-mortem, o que simplifica bastante o troubleshooting em ambientes de produção.

Multi-tenancy como parte da arquitetura

O Proxmox não foi desenhado para multi-tenancy. VMs de clientes diferentes podem coexistir no mesmo cluster, mas o isolamento de rede e storage entre eles é responsabilidade de quem configura, não da plataforma.

O FusionCompute, integrado ao stack DCS completo via eDME, oferece multi-tenancy nativo com VPC por tenant, ECS com isolamento completo, ELB, NAT, firewall virtual e políticas de storage separadas. Para quem precisa entregar recursos de TI como serviço para diferentes áreas de negócio ou clientes, essa diferença é arquitetural.

Backup e DR dentro do stack Huawei

No Proxmox, o Proxmox Backup Server resolve bem o backup, mas DR orquestrado entre sites exige soluções de terceiros. No VMware, o Site Recovery Manager cobre isso, mas é um produto pago adicional.

No stack DCS, o UltraVR oferece DR orquestrado com suporte a topologias de dois, três e mais data centers, com RPO zero em cenários de active-active e failover automatizado. O eBackup faz backup incremental permanente das VMs com CBT (Changed Block Tracking), sem precisar de agente instalado dentro de cada VM.

Para quem faz sentido?

O FusionCompute não entra bem em qualquer conversa. Para ambiente pequeno, com poucos hosts e time que quer custo baixo de licença, o Proxmox continua muito forte.

O jogo muda quando aparecem dezenas de hosts, SLA formal, DR entre sites, separação por áreas ou clientes, e necessidade de operar tudo com menos peças soltas. Nesse tipo de ambiente, o FusionCompute começa a fazer mais sentido.

Ele também fica mais natural quando o cliente já usa hardware Huawei, especialmente servidores, storage OceanStor ou switches CE. A integração não resolve tudo, mas reduz atrito operacional.

Arm também pode entrar nessa conta. Com o avanço de chips Arm em data centers, o suporte nativo do FusionCompute a processadores Arm, com paridade de funcionalidades em relação a x86, pode pesar em ambientes que já olham para servidores Kunpeng ou arquiteturas similares.

A migração do VMware precisa ser tratada com cuidado. Migrar para Proxmox pode ser a decisão certa em muitos casos, mas quando o requisito é manter funcionalidades enterprise como DRS, DR orquestrado, QoS por VM e multi-tenancy, o FusionCompute entrega isso sem exigir a montagem de um stack grande de ferramentas externas.

Contexto de mercado

A pesquisa da Gartner de 2024 mostrou que 74% dos líderes de TI estavam ativamente avaliando alternativas ao VMware. O vSphere 7 chegou ao fim de suporte em outubro de 2025, o que acelerou migrações de quem ainda estava postergando a decisão. E os clientes que aceitaram acordos de bridge de 1 ano em 2024 estão agora chegando às renovações com precificação VCF completa.

A saída do VMware deixou de ser uma conversa teórica. Em muitos ambientes, ela virou projeto, orçamento e risco. É nesse espaço que o FusionCompute precisa ser avaliado: não como curiosidade da Huawei, mas como uma opção enterprise para quem não quer trocar um problema comercial por um problema operacional.

Próximos passos

Se a discussão sobre VMware já chegou no orçamento, talvez valha colocar o FusionCompute na análise. A Made4it pode ajudar nessa leitura técnica: arquitetura, comparação com Proxmox e VMware, riscos de migração, operação e desenho de DR.

Chame a gente para avaliar se ele faz sentido no seu ambiente antes de decidir o caminho da migração.

 

Fontes: FusionCompute Product Documentation v8.10.0 (Huawei, maio/2026) · DCS Product Documentation v2.2.0 (Huawei, fevereiro/2026) · Proxmox VE 9.2 Release Notes (maio/2026) · Broadcom VMware Configuration Maximums vSphere 8.0

A Made4it surge para suprir as necessidades do mercado, que vem exigindo cada vez mais soluções personalizadas.