Migração de VMware vSphere para HPE VM Essentials com Veeam: o guia completo

Como migrar workloads do VMware vSphere para o HPE VM Essentials (HVM) preservando proteção de dados, continuidade operacional e uma estratégia clara de rollback — usando o Veeam Backup & Replication como motor de movimentação.

O contexto: por que essa conversa virou prioridade em 2026

Desde a aquisição da VMware pela Broadcom, o cenário de virtualização corporativa mudou de patamar. Reajustes em renovações, descontinuação da licença perpétua, depreciação do vVols no VCF 9 e mudanças no modelo de licenciamento empurraram boa parte do mercado a uma pergunta inevitável: vale continuar pagando esse custo, ou existe uma alternativa madura?

A resposta que vem ganhando tração — especialmente entre organizações que já operam ecossistema HPE — é o HPE Morpheus VM Essentials (VME) combinado com o HVM, hypervisor baseado em KVM da HPE. E o que tornou esse caminho realmente viável foi o lançamento, em 2026, da integração nativa do Veeam com o VME, somado a um guia oficial de migração publicado pela própria Veeam.

Neste artigo, traduzimos esse guia para o contexto brasileiro: o que muda, o que prestar atenção, e como executar uma migração com risco controlado.

O que é o HPE VM Essentials e o hypervisor HVM

O HPE Morpheus VM Essentials não é apenas um hypervisor — é uma plataforma de gerenciamento de virtualização construída para administrar o HVM (HPE Virtualization Manager), o hypervisor KVM da HPE. Combina licenciamento previsível, recursos essenciais e suporte enterprise.

Características que importam para quem está avaliando:

• Licenciamento por socket de CPU, independentemente do número de cores, sem cobranças incrementais por feature.
• Recursos enterprise como live migration, hooks para proteção de dados e gerenciamento de segredos.
• Gerenciamento centralizado de clusters VME (KVM) e clusters VMware vSphere (ESXi) a partir de um único console — útil durante a fase de coexistência.
• Compatível com HPE Private Cloud, SimpliVity, Alletra dHCI ou deployment standalone.

O mecanismo de migração: como o Veeam atua

O ponto-chave para entender o desenho da migração: o Veeam não usa replicação contínua entre vSphere e HVM. A migração é feita via full VM recovery a partir de backups VMware, restaurados no cluster HVM através do Plug-in for Morpheus VM Essentials.

Na prática: os discos das VMs são convertidos para QCOW2 no host HVM de destino. Para que o sistema operacional consiga comunicar-se com o novo hypervisor, é necessário injetar e instalar VirtIO drivers e guest tools antes do restore — esse é o detalhe técnico que costuma surpreender quem não leu o guia.

Arquitetura da migração

A arquitetura exige quatro elementos principais funcionando em conjunto:

• Veeam Backup & Replication endurecido com o Plug-in HPE VME instalado.
• VMware Proxies no lado de origem para comprimir e transportar dados do storage de produção para o repositório de backup. Recomenda-se múltiplos proxies para balancear carga.
• Workers HVM no lado de destino — VMs efêmeras que ligam apenas durante backup e restore. Devem ser dimensionados para otimizar o tráfego de restore e reduzir downtime.
• Backup repository intermediário (swing space) com armazenamento rápido.

Aviso importante do guia oficial: evite usar storage com deduplicação como swing space de migração. Os tempos de restore ficam significativamente mais longos. Para a migração em si, prefira armazenamento rápido (NVMe, SSD ou similar). Depois da migração, o repositório definitivo pode — e geralmente deve — ser deduplicador como o HPE StoreOnce.

Sizing dos componentes

O guia oficial recomenda:

• VMware Backup Proxies: mínimo de 2 vCPUs + 1 vCPU para cada 2 tarefas concorrentes adicionais; mínimo de 2 GB RAM + 1 GB por tarefa concorrente. Lembre-se: 1 tarefa de proxy = 1 disco de VM.
• HVM Workers: default de 4 tarefas concorrentes com 6 vCPUs e 6 GB RAM; +1 vCPU e +1 GB RAM para cada tarefa concorrente adicional. Aqui, 1 tarefa de worker = 1 VM inteira.
• VBR Server: dimensione com o Veeam Calculator, considerando número de workloads, jobs e tarefas simultâneas pós-migração.

Fase 1: Discovery e classificação de workloads

O guia da Veeam propõe uma matriz de classificação por tier e nível de risco que ajuda muito na negociação de janelas com áreas de negócio:

Tier	Baixo Risco	Médio Risco	Alto Risco
Dev	Ambientes descartáveis	Servidores compartilhados (build)	Infraestrutura crítica de desenvolvimento
QA	Sistemas de teste	Ambientes de regressão	Pré-produção de aplicações críticas
Prod	Aplicações não-críticas	Aplicações de negócio internas	Sistemas com exposição a clientes

Recomendação prática: comece sempre por workloads de baixo risco. Eles vão revelar o tempo real de downtime, comportamento de drivers e ajustes finos antes de você tocar em qualquer sistema crítico.

Fase 2: Preparação — vSphere tags e batches

Uma técnica elegante do guia: usar vSphere tags para agrupar VMs em batches de migração. Crie tags no vCenter (Batch_A, Batch_B, Batch_C…), atribua às VMs conforme a classificação, e configure os jobs de backup do Veeam usando essas tags como critério. Isso facilita imensamente o controle das ondas de migração.

Antes de tocar em qualquer VM, prepare a infraestrutura:

• Instale e endureça o Veeam Backup & Replication seguindo o Veeam Security Blueprints.
• Se o VBR é virtual, considere instalá-lo já no cluster HVM — assim você evita migrar o próprio servidor de backup no meio do processo.
• Instale o HPE Morpheus VM Essentials Plug-In (arquivo .BNDL) no Host Management console, baixando-o em my.veeam.com → Additional Downloads → Virtualization Plug-Ins.
• Configure repositórios de backup separados: um para o swing space da migração e outro definitivo para proteção pós-migração.

Fase 3: Preparação das VMs — VirtIO drivers

Este é o passo mais técnico e onde mais migrações falham por desatenção. Tanto Windows quanto Linux precisam dos VirtIO drivers antes do backup pré-migração.

Sequência recomendada para cada batch:

1. Rodar full backup + 1 incremental (cria seu ponto de rollback antes das mudanças).
2. Desinstalar agentes de backup existentes e componentes VSS de terceiros.
3. Injetar e instalar VirtIO drivers (procedimento específico para Windows e Linux abaixo).
4. Rodar incremental pós-preparação (ponto pronto para migração).

Sobre o VMware Tools: mantenha-o instalado até o último incremental pré-migração. Se preferir, desabilite-o no startup. Após a VM estar rodando no HVM, remova o VMware Tools e mantenha apenas o VirtIO Guest Tools.

Preparando uma VM Windows

1. Faça upload da ISO do VirtIO para Windows em um datastore acessível à VM.
2. Edite o hardware da VM no vCenter, mapeie o CD/DVD para a ISO e marque "Connected".
3. Inicie a VM em Windows Server Recovery Mode → Troubleshoot → Command Prompt.
4. Use diskpart e depois list volume para identificar as letras do drive de imagem e da ISO montada (no exemplo do guia, image em E: e ISO em D:).
5. Injete os drivers viostor e vioscsi com DISM. Para Windows Server 2025:

dism /image:E:\ /add-driver:D:\viostor\2k25\amd64\viostor.inf
dism /image:E:\ /add-driver:D:\vioscsi\2k25\amd64\vioscsi.inf

Atenção: o caminho 2k25 muda conforme a versão do Windows (2k22, 2k19 etc.). Navegue na ISO antes de rodar os comandos para confirmar.

6. Após a operação bem-sucedida, saia do prompt e continue o boot do Windows.
7. Já no Windows, execute o instalador virtio-win-gt-x64 da ISO montada para instalar todos os drivers.
8. Em seguida, execute virtio-win-guest-tools para finalizar a instalação dos guest tools.

Preparando uma VM Linux

O exemplo do guia usa Rocky 9 minimal, mas o conceito vale para a maioria das distros enterprise (RHEL, AlmaRocky, SUSE, Ubuntu Server com ajustes).

1. Verifique se os drivers já estão presentes:

lsinitrd | grep virtio

2. Se nada retornar, crie o arquivo de configuração do dracut:

touch /etc/dracut.conf.d/virtio.conf
sudo vi /etc/dracut.conf.d/virtio.conf

3. Insira o conteúdo:

add_drivers+=" virtio virtio_blk virtio_pci virtio_net virtio_ring virtio_scsi "

4. Regenere os initramfs para todos os kernels instalados:

dracut -f --regenerate-all --add-drivers "virtio_blk virtio_scsi virtio_net"

5. Valide novamente com lsinitrd | grep virtio. Você deve ver os módulos listados.

Fase 4: Executando a migração

Com as VMs preparadas e os backups intermediários feitos, a janela de migração propriamente dita segue uma sequência enxuta:

1. Shutdown limpo das VMs do batch. Para deployments VBR Windows, é possível automatizar com o script BR-PreJobVMShutdown pré-job.
2. Incremental final pré-migração. Captura as últimas alterações, garantindo consistência de aplicação e banco. Mantém o delta pequeno para acelerar o restore.
3. Restore em lote para o HVM.
4. Validação técnica e funcional.

Procedimento de restore no VBR

1. Na console do VBR, acesse Disk e expanda o job do batch alvo.
2. Selecione a primeira VM e, com Shift, clique na última para destacar todo o batch.
3. Clique em Restore Entire VM → HPE Morpheus VM Essentials.
4. No wizard:
   • Virtual Machines: em "Point...", confirme o restore point mais recente.
   • Restore Mode: selecione "Restore to a new location, or with different settings".
   • Cluster: escolha o cluster HVM de destino.
   • Storage: selecione o datastore alvo.
   • Network: escolha a rede correspondente no HVM.
   • Opcionalmente, marque "power on after restore" e finalize.

Fase 5: Validação pós-migração

Esta fase é frequentemente subestimada, e é onde diferenciamos uma migração "funcionou" de uma migração "bem-sucedida". O guia oficial separa a validação por times:

• Sysadmins e equipe de redes: estado de power e OS, conectividade e mapeamento de storage, autenticação de workloads, conectividade de aplicação e banco, consistência de rede. Após a validação, o VMware Tools deve ser desinstalado.
• Application owners e stakeholders: autenticação de usuários, funcionalidade da aplicação, integridade dos dados. Obter o "sign-off" formal evita que problemas só apareçam quando os usuários estiverem usando o sistema.

Fase 6: Proteção contínua pós-migração

Migração bem-sucedida é marcada por proteção efetiva no destino. Após a validação, crie novos jobs permanentes no VBR apontando para o cluster HVM, com políticas de retenção definitivas, mirando o repositório de produção (não o swing space da migração).

É o momento de redesenhar o repositório considerando crescimento de longo prazo, retenção regulatória e imutabilidade. Recomendamos:

• HPE StoreOnce Gen4+ ou Gen5 para deduplicação de alta performance integrada ao ecossistema HPE.
• Object First Ootbi para resiliência contra ransomware via imutabilidade nativa S3.
• DR para AWS ou Azure mantido como opção, preservando a regra 3-2-1-1-0.

Por que essa rota reduz risco em vez de aumentá-lo

• Rollback claro. Os backups originais do vSphere continuam disponíveis. Em qualquer ponto do projeto é possível restaurar de volta para o VMware — ou para outro hypervisor suportado, incluindo nuvem pública.
• Coexistência durante a transição. O console VME gerencia clusters KVM (HVM) e ESXi simultaneamente, permitindo operação híbrida pelo tempo necessário.
• Proteção contínua na mesma plataforma. Você não troca a stack de backup. Mesma console Veeam, mesmos workflows, mesmas políticas de imutabilidade.
• Independência de fornecedor preservada. VMs do HVM podem ser restauradas para outros hypervisors, e DR para AWS/Azure continua viável.

Considerações finais

A combinação HPE VM Essentials + Veeam se ajusta especialmente bem quando:

• A organização já tem investimento em hardware HPE (ProLiant, SimpliVity, Alletra, StoreOnce).
• O ambiente VMware está pesando demais no orçamento após as últimas renovações.
• O time de TI já domina o Veeam e quer preservar essa expertise.
• Existe necessidade de uma estratégia de saída controlada e auditável do VMware, com prazos definidos.
• Workloads são majoritariamente Windows Server, Linux empresarial e aplicações tradicionais.

Para ambientes com dependência pesada de features muito específicas do vSphere (NSX-T avançado, vSAN com configurações exóticas, regras complexas de DRS), a avaliação precisa ser mais detalhada — caso típico de POC antes da decisão.

Como a SafeLevel apoia esse projeto

Como parceira Veeam e HPE no Brasil, a SafeLevel atua nas três frentes que esse tipo de migração exige:

1. Assessment técnico e dimensionamento. Inventário do vSphere atual, classificação de workloads por tier, mapeamento de dependências, desenho do cluster VME de destino e sizing de proxies, workers e repositórios.
2. Implementação e migração assistida. Instalação do plug-in, configuração de workers, preparação de VMs (VirtIO drivers Windows e Linux), execução das ondas em janelas controladas, com plano de rollback documentado.
3. Operação contínua. Revisão das políticas de backup, ajuste do desenho de repositórios definitivos e suporte recorrente após o go-live.

Se sua organização está avaliando alternativas ao VMware ou já decidiu migrar e precisa de um parceiro que conheça as duas pontas — Veeam e HPE — fale com a gente. Conduzimos workshops técnicos sem compromisso para discutir cenário, viabilidade e desenho.

---

📚 Referências e leitura complementar

• Guia oficial em PDF: Migration from VMware vSphere to HPE HVM with Veeam — por Christina Leimeister, Veeam Solutions Architect (publicado em maio de 2026 na Veeam Community). O download do PDF está disponível diretamente no post.
• Documentação técnica: HPE Morpheus VM Essentials — Veeam Backup & Replication User Guide
• Download do plug-in: Veeam Data Platform — Virtualization Plug-Ins

Conteúdo baseado no guia oficial da Veeam citado acima, com adaptações e comentários técnicos para o contexto brasileiro.

SafeLevel — Infraestrutura híbrida, sem complexidade.