Migração · VMware
Migre máquinas virtuais VMware para o Apache CloudStack
O Apache CloudStack pode importar máquinas virtuais do VMware vCenter e, a partir da versão 4.19, convertê-las para KVM. Executar isso com segurança exige inventário, zona de destino, testes prévios e um plano de cutover por máquina. Nos 30 dias úteis do NexCMP Source, um engenheiro especialista realiza esse trabalho com você sem custos adicionais.
Incluído no NexCMP Source ($499 pagamento único), não no NexCMP Free. VMware, WHMCS, HostBill, Blesta, Paymenter, StackBill, Virtualizor e Apache CloudStack são marcas registradas de seus respectivos proprietários. O NexCMP é independente e não é afiliado nem endossado por eles.
O problema: sair do VMware sem perder o controle
Mudar para o Apache CloudStack significa que cada máquina virtual muda de plataforma: seus discos, placas de rede, drivers e, muitas vezes, seus endereços. Se feito às pressas, é aí que as máquinas falham na inicialização, clientes perdem acesso ou licenças deixam de funcionar.
O CloudStack fornece as ferramentas de importação, mas não decide por você quais máquinas vão primeiro, como cada rede é mapeada, o que acontece com os guests Windows ou por quanto tempo cada máquina ficará offline. Essas decisões e os testes relacionados a elas são a migração em si.
Se você vende máquinas virtuais para clientes, a migração tem uma segunda parte: as máquinas precisam terminar vinculadas aos clientes, planos e preços corretos no seu sistema de faturamento. O NexCMP é essa camada de faturamento e portal do cliente sobre o CloudStack, e o mesmo engenheiro cuida de ambas as partes.
O que o próprio CloudStack suporta
Há duas rotas documentadas a partir do VMware. A escolha ideal depende se os hosts VMware permanecerão na sua nuvem.
A. Converter para KVM com virt-v2v
- O que o CloudStack documenta
- A partir da versão 4.19, o administrador pode selecionar uma VM VMware em um datacenter vCenter existente ou externo e importá-la para um cluster KVM, em Tools, Import-Export Instances. A VM é exportada, convertida com virt-v2v e seus discos são importados como QCOW2. A documentação mais recente adiciona um fluxo baseado em VDDK junto ao baseado em OVF; a versão 4.22 adicionou a conversão direta para um pool de armazenamento e a versão 4.22.1 a seleção do sistema operacional guest com base no sistema operacional guest de origem.
- Limites indicados na documentação
- O virt-v2v não é instalado pelo agente do CloudStack e deve ser instalado em cada host KVM, caso contrário a conversão falha. O sucesso não é garantido e depende do sistema operacional guest e dos sistemas de arquivos, por isso a documentação recomenda testar antes do uso em produção. A VM importada recebe o tipo padrão de sistema operacional guest CentOS 4.5 (32-bit) na 4.19 e deve ser editada posteriormente.
Source: Apache CloudStack — Importação de VMs VMware para KVM · acessado 2026-10-19
B. Importar no local (unmanaged instances)
- O que o CloudStack documenta
- Para clusters vSphere cujos hosts já fazem parte do CloudStack, o listUnmanagedInstances lista as VMs e o importUnmanagedInstance as coloca sob o gerenciamento do CloudStack. A listagem de unmanaged instances do VMware começou na 4.14, a desassociação (unmanaging) na 4.15 e a importação pela UI na 4.16.
- Limites indicados na documentação
- A rede de destino já deve existir no CloudStack, e o armazenamento deve ser adicionado como armazenamento primário. Os discos de dados devem ser mapeados para disk offerings, e tipos mistos de controladora de disco ou de NIC causam erro. Uma VM em execução só pode ser importada se a VLAN da rede e a compute offering coincidirem; caso contrário, ela deve ser parada primeiro.
Source: Apache CloudStack — Sobre Import Export Instances · acessado 2026-10-19
A rota A se aplica quando o destino é o KVM. A própria documentação do NexCMP indica o KVM como o hipervisor testado, portanto planejamos a rota A, a menos que seu projeto mantenha hosts VMware sob o CloudStack. Verifique a versão do CloudStack que você executa: as páginas acima descrevem comportamentos diferentes entre a 4.19 e a versão mais recente.
O que é migrado e o que exige atenção
Discos
- O que acontece
- Convertidos para QCOW2 e importados no pool de armazenamento primário de destino (rota A), ou mapeados para disk offerings do CloudStack (rota B).
- Atenção
- Na rota B, o disco não é redimensionado se sua disk offering for maior. O armazenamento temporário durante a conversão da rota A é o armazenamento secundário por padrão; o armazenamento primário só pode ser usado para isso se for NFS.
Source: Apache CloudStack — Importação de VMs VMware para KVM · acessado 2026-10-19
Redes
- O que acontece
- As redes devem existir no CloudStack antes da importação. Um script de descoberta lista as redes do vCenter que têm pelo menos uma VM conectada, para que as redes correspondentes possam ser criadas.
- Atenção
- O virt-v2v não pode reconfigurar as definições de rede de um guest nem alterar seu endereço MAC. Se a sub-rede de destino for diferente, o guest precisará de ajustes após a conversão.
Source: libguestfs — manual do virt-v2v · acessado 2026-10-19
Guests Linux
- O que acontece
- Uma VM Linux em execução pode ser importada pela rota A: o CloudStack a clona antes da exportação, de modo que ela é convertida em um estado crash-consistent.
- Atenção
- A documentação do CloudStack recomenda desligar as VMs Linux primeiro. O virt-v2v não instala novos kernels ou drivers e avisa caso falte suporte a virtio; portanto, o guest deve atender às versões mínimas antes da conversão.
Source: libguestfs — manual do virt-v2v · acessado 2026-10-19
Guests Windows
- O que acontece
- Devem ser desligados corretamente antes da importação pela rota A. Os drivers virtio são extraídos do pacote virtio-win e instalados na primeira inicialização; o Windows pode reiniciar quatro ou mais vezes após o primeiro boot.
- Atenção
- A Inicialização Rápida ou hibernação impede a conversão, e um disco de sistema em Disco Dinâmico não é suportado. A importação do Windows requer drivers virtio no host de conversão.
Source: libguestfs — manual do virt-v2v · acessado 2026-10-19
VMware Tools
- O que acontece
- O virt-v2v tenta remover o VMware Tools.
- Atenção
- O manual informa que a remoção não funciona de forma confiável no Windows, onde o Tools pode precisar ser removido por outro método.
Source: libguestfs — manual do virt-v2v · acessado 2026-10-19
Tipo de SO do guest
- O que acontece
- A VM importada recebe um tipo de SO guest padrão.
- Atenção
- Na versão 4.19, é CentOS 4.5 (32-bit) e precisa ser alterado manualmente; a versão 4.22.1 pode mapeá-lo a partir do SO guest de origem, caso existam mapeamentos.
Source: Apache CloudStack — Importação de VMs VMware para KVM · acessado 2026-10-19
Faturamento e clientes
- O que acontece
- Planos, preços e contas de clientes são configurados no NexCMP, e cada máquina migrada é vinculada ao cliente correto.
- Atenção
- Definido na semana 1 para a sua versão do CloudStack. Esse é um trabalho do NexCMP, não um recurso do CloudStack.
O plano, semana a semana
Padrão, ajustado ao seu caso. Os 30 dias úteis de trabalho contínuo equivalem a cerca de seis semanas corridas.
Semana 1 — Inventário e decisões
Com acesso somente leitura ao vCenter, listamos todas as VMs: SO guest, discos, placas de rede, VLANs, snapshots, status de energia e dependências mútuas. Escolhemos a rota A ou B, definimos as ondas de migração e identificamos as máquinas que exigem atenção especial, como guests Windows, discos grandes e qualquer item com licença fixa.
Semana 2 — Preparação do ambiente de destino
A zona do CloudStack é verificada ou criada: hosts KVM, storage e redes correspondentes aos do VMware. Instalamos o virt-v2v nos hosts KVM (e o nbdkit em hosts Ubuntu), preparamos os drivers virtio para Windows e liberamos os caminhos de rede entre os hosts de conversão e o vCenter e o ESXi. Se você revende as máquinas, o NexCMP é instalado e conectado ao CloudStack na mesma semana.
Semana 3 — Piloto
Algumas máquinas não críticas, uma para cada tipo de guest que você possui, passam pelo procedimento real. Verificamos se inicializam, se têm rede e os drivers corretos, definimos o tipo de SO guest e medimos o tempo de indisponibilidade de cada máquina. O resultado define as janelas para as ondas de migração.
Semanas 4 e 5 — Ondas de migração
As máquinas são migradas em grupos nos horários combinados. Cada grupo é validado antes do início do próximo, e as máquinas originais do VMware permanecem desligadas, mas preservadas para permitir rollback. Se você revende as máquinas, clientes, planos e preços são configurados no NexCMP em paralelo, e o faturamento opera em paralelo antes da virada definitiva.
Semana 6 — Cutover final e entrega
As últimas máquinas são migradas, a data de faturamento é alterada caso você as revenda e os apontamentos de DNS são realizados. Documentamos todo o procedimento realizado, revisamos o hardening e os backups, e permanecemos à disposição para a migração até o fim dos 30 dias úteis.
Apenas uma visão geral. O plano definitivo é definido na semana 1, e o único compromisso de prazo da proposta são os 30 dias úteis.
Riscos e como os reduzimos
Nenhuma migração é isenta de riscos e não prometemos zero downtime. Veja o que pode dar errado e o que fazemos a respeito.
Downtime por máquina
Máquinas Windows não podem ser convertidas em execução, e uma máquina Linux em execução é convertida em estado crash-consistent. O CloudStack não especifica o tempo necessário para a conversão. Nós medimos isso no piloto e depois alinhamos uma janela de parada para cada grupo de máquinas.
Uma conversão não é bem-sucedida
O CloudStack declara que o sucesso não é garantido e depende do guest. Testamos cada tipo de guest no piloto antes de qualquer onda, e a máquina original permanece intocada até que a nova seja validada.
Drivers e VMware Tools
Máquinas Windows recebem drivers virtio durante a conversão, máquinas Linux precisam de suporte a virtio previamente e o VMware Tools pode exigir remoção manual. Esses pontos são validados por guest durante o piloto.
Endereços IP, endereços MAC e DNS
Os guests mantêm seus endereços MAC e suas próprias configurações de rede, portanto uma sub-rede de destino diferente exigirá ajustes internos no guest. Mapeamos todos os endereços na semana 1, reduzimos os TTLs de DNS antes do cutover e avisamos seus clientes com antecedência.
Licenças de software do guest
O Windows e softwares comerciais dentro de uma máquina podem estar licenciados para a plataforma antiga. Nós os listamos no inventário para que você possa confirmar os termos com cada fornecedor antes da migração.
Conversões interrompidas
O CloudStack indica que reiniciar os management servers durante uma migração a interrompe e a importação precisa ser reiniciada. Agendamos as ondas fora das manutenções e evitamos reinicializações enquanto uma estiver em andamento.
Transição do faturamento e rollback
Se você comercializa as máquinas, a data de transição do faturamento é definida com você e ambos os sistemas operam em paralelo primeiro. As máquinas originais no VMware são mantidas até você concordar que a migração foi concluída, o que garante a cada grupo uma opção de retorno.
Quem faz o quê
Acesso somente leitura ao vCenter e uma lista das máquinas que você considera críticas
- O especialista faz
- Inventaria todas as VMs e planeja as ondas
Acesso ao ambiente CloudStack e aos hosts KVM, ou ao hardware para montá-los
- O especialista faz
- Prepara a zona, as redes e os hosts de conversão
Os pacotes VDDK e virtio necessários para a rota escolhida, caso os fornecedores exijam que você mesmo faça o download
- O especialista faz
- Instala e testa esses pacotes nos hosts de conversão
Janelas de parada combinadas e comunicados aos seus clientes
- O especialista faz
- Executa o piloto e as ondas, e verifica cada máquina depois
Suas decisões de precificação, caso você comercialize as máquinas
- O especialista faz
- Configura planos, clientes e faturamento no NexCMP e executa o período em paralelo
O que você recebe nos 30 dias úteis
A migração faz parte do upgrade para o NexCMP Source: pagamento único de $499 que inclui o código-fonte completo (servidor em Rust, portal e admin em Vue, agente de nó em Go, CLI, scripts de build), o direito de modificar e compilar sua própria versão sem limites, 12 meses de novas releases do código-fonte, todos os apps e 30 dias úteis de trabalho contínuo com um engenheiro especialista.
Nesses 30 dias úteis, o especialista migra o seu ambiente do VMware para o Apache CloudStack sem custos adicionais. Em vez disso, ou também, esse mesmo período pode ser usado para migrar a partir do WHMCS ou de outro sistema, ou para uma configuração completa de A a Z e build dos seus apps. A contagem começa quando você inicia os trabalhos com o especialista e é exibida na sua página de licença. O suporte para a migração dura os mesmos 30 dias.
O NexCMP Free não inclui isso. O plano Free é gratuito por um ano com todos os módulos e sem suporte técnico, apenas correções de bugs no código-fonte, e renova por $99 ao ano.
VMware para CloudStack — perguntas frequentes
Quanto custa?
Isso está incluído no NexCMP Free?
Quais versões do CloudStack e do VMware são suportadas?
Minhas máquinas virtuais terão downtime?
Todas as VMs podem ser convertidas?
Preciso manter o VMware depois?
O que eu preciso fornecer?
Fontes e notas
As declarações técnicas provêm da documentação oficial do Apache CloudStack e do manual do virt-v2v. A documentação muda entre versões, portanto verifique a versão em execução. A declaração sobre a 4.19 vem da documentação da 4.19, que inicia a página VMware-to-KVM com 'As of CS 4.19'. VMware, WHMCS, HostBill, Blesta, Paymenter, StackBill, Virtualizor e Apache CloudStack são marcas registradas de seus respectivos proprietários. O NexCMP é independente e não possui afiliação nem endosso por parte deles.
Deixe o VMware com um engenheiro ao seu lado
Faça o upgrade para o NexCMP Source por $499 e inicie seus 30 dias úteis, ou consulte [email protected] sobre o seu ambiente primeiro.
Última atualização: