Migração open source de VMs: VMware e OpenStack para RHOSO 18.0 ou OpenStack da comunidade. Mantenha suas VMs no ar.
Faça a virada em minutos.

O Seamless Migrate é um plano de controle open source, sob a Apache License 2.0, que migra máquinas virtuais (VMs) do Red Hat OpenStack Platform 17.1, do OpenStack da comunidade (incluindo o Kolla-Ansible) e do VMware vSphere para o Red Hat OpenStack Services on OpenShift (RHOSO) 18.0 ou uma nuvem OpenStack da comunidade, de 2023.1 Antelope a 2026.2 Hibiscus. Ele planeja ondas, estima o tempo de inatividade de cada VM, copia os discos enquanto as VMs continuam em execução, condiciona cada virada a uma aprovação e a uma janela de mudança, verifica cada VM no destino e faz o rollback automaticamente quando uma verificação falha.

Adicione o vCenter (vSphere 7.0U3 ou 8.x) como origem e o RHOSO 18.0 ou uma nuvem OpenStack da comunidade como destino; depois, planeje as ondas e valide-as. VMs com Changed Block Tracking (CBT) usam a migração warm: passagens de CBT copiam os discos enquanto a VM está em execução e, na virada, só o delta final é copiado antes de uma conversão in-place com virt-v2v. VMs sem CBT usam a migração a frio: uma cópia completa e, depois, a conversão. Os dados passam pelo vmware-migration-kit do os-migrate e por um host de conversão com VDDK na nuvem de destino.

Sim. O procedimento de adoção da Red Hat converte uma implantação 17.1 in-place. Quando isso não atende, seja por hardware novo, por um novo backend de armazenamento, por um redesenho de rede como ML2/OVS para ML2/OVN ou por várias nuvens a consolidar, o Seamless Migrate migra as cargas de trabalho lado a lado: recria redes, grupos de segurança, flavors, imagens, pares de chaves, projetos e usuários no RHOSO e, então, migra cada VM com cópia a frio, migração warm ou transferência do armazenamento.

Sim. Além do RHOSO 18.0, toda série de versões do OpenStack da comunidade, de 2023.1 Antelope a 2026.2 Hibiscus, é um destino, tenha sido implantada com Kolla-Ansible, OpenStack-Ansible ou outra ferramenta: registre-a com a predefinição OpenStack Community ou Kolla-Ansible, e as mesmas estratégias de cópia a frio, migração warm e transferência do armazenamento são executadas nela. A verificação de provedores informa a série de versões, o nível de suporte e o perfil de política de cada destino, e a validação prévia bloqueia um plano quando falta uma capacidade, antes de mover qualquer coisa. Hoje, o RHOSO 18.0 é a plataforma de destino; a validação da versão em laboratório ainda está pendente; a validação em laboratório de cada série da comunidade mantida pelo upstream ainda não foi feita e vem antes de uma versão final.

Depende da estratégia e da VM. Para um volume de 200 GiB com 120 GiB em uso, 2 MiB/s de escrita no convidado e um link de 125 MiB/s, o modelo de planejamento estima 20 min 53 s para uma cópia a frio, 11 min 20 s para uma migração warm e 4 min 20 s para uma transferência do armazenamento. Na migração warm, o tempo de inatividade depende do delta final e de uma varredura do disco, não da cópia completa.

Uma migração a frio desliga a VM e copia os dados em uso, então o tempo de inatividade cresce com o disco. Uma migração warm copia os discos em passagens de snapshot enquanto a VM continua em execução, e a VM só é desligada para o delta final. Uma transferência do armazenamento (storage handover) não copia dado algum: quando as duas nuvens compartilham um cluster Ceph ou uma SVM NetApp ONTAP, o Cinder faz o unmanage de cada volume na origem e o manage no destino, então o tempo de inatividade é de poucos minutos, qualquer que seja o tamanho.

Sim, como Technology Preview validada em simulação. VMs com uma vGPU NVIDIA, por time-slicing ou baseada em MIG, ou com uma GPU inteira em passthrough migram assim que o plano associa cada GPU a um flavor com GPU do destino; uma VM com GPU sem associação continua bloqueada. A validação compara as GPUs do plano com a capacidade livre do destino no Placement, e o portão da virada a lê de novo antes de parar a origem: sem espaço, a migração espera e a origem continua em execução. Uma VM do VMware com GPU em passthrough só se move a frio, desligada. Os testes de laboratório em hosts com GPU ainda não foram feitos.

IPs fixos e endereços MAC são mantidos por padrão. Como Technology Preview validada em simulação, um plano também pode manter o endereço de cada IP flutuante, movido depois que a origem para e devolvido em um rollback, e trocar um registro DNS no Designate ou em um servidor RFC 2136 quando um endereço muda. A verificação espera até que cada endereço movido responda e conta essa espera no tempo de inatividade; o Seamless não fala BGP por conta própria. Hooks registrados por um administrador, playbooks Ansible ou webhooks HTTPS, cobrem o resto, e a validação prévia aponta o que continua com a equipe de operações, como stacks do Heat, grupos de autoescalonamento e pools do Octavia.

Sim, até você finalizar. Um rollback remove a instância no destino, mantém os volumes dela e inicia novamente a VM de origem, e uma verificação com falha o dispara automaticamente. Nada apaga dados da origem antes da finalização, e a finalização exige um aprovador e o nome da VM digitado por completo.

A partir do OpenStack, convidados KVM vão para KVM, então tudo o que inicializa na origem inicializa no destino: RHEL 5 a 10, CentOS, Rocky, AlmaLinux, Oracle Linux, Ubuntu, Debian, SLES, openSUSE, Windows Server 2003 a 2025 e Windows 7 a 11. A partir do VMware, o virt-v2v converte o convidado: RHEL 7 a 10 e Windows Server 2016 a 2025 têm suporte da Red Hat; os demais convidados funcionam após uma cópia de teste ou precisam ter os drivers virtio instalados antes.

É uma imagem de container mais o PostgreSQL 16. Implante no OpenShift 4.16 ou posterior, ao lado do RHOSO, no Kubernetes 1.28 ou posterior (EKS, AKS, GKE, RKE2, k3s, kubeadm) ou em um único host: o Docker Engine do próprio servidor Linux, 20.10 ou posterior, com Compose v2.20 (Ubuntu, Debian, RHEL, Rocky Linux, AlmaLinux, Fedora; sem Colima, sem Node.js), um Mac com Colima ou o Podman 4.7 ou posterior. Um só script de operações, o seamless-ctl.sh, sobe, derruba, reinicia e escala uma implantação da mesma forma em todas as plataformas, e drena os planos em execução antes de uma parada planejada. Uma demo com nuvens simuladas roda em um notebook e não precisa de credenciais de nuvem.

Sim. É open source sob a Apache License 2.0, e o código-fonte está no GitHub.

Não. É um projeto open source independente, não afiliado, patrocinado ou endossado pela Red Hat, pela OpenInfra Foundation ou pela Broadcom, e não é coberto por nenhuma subscrição da Red Hat. Ele se baseia na coleção Ansible upstream os-migrate, que continua responsável por mover os dados.

O os-migrate exporta e importa recursos de tenants e copia cargas de trabalho a frio, com a VM desligada durante toda a cópia. O Seamless Migrate se baseia nele e acrescenta um caminho warm para origens OpenStack, transferência do armazenamento, orquestração warm para VMware e um plano de controle com planos, ondas, estimativas de tempo de inatividade, aprovações, verificação, rollback, um dashboard, uma REST API e uma CLI.