Indo para o VCF 9? Migre o vSphere Replication para o Protection and Recovery

Você tem o vSphere Replication no seu ambiente, standalone, sem o SRM, ainda está no VCF 5.x ou no VVF 8.0 U3 e precisa chegar ao VCF 9? Então o primeiro passo não é o vCenter nem os ESXi: é levar o vSphere Replication para o produto que o substituiu, agora chamado VCF Protection and Recovery.

A boa notícia é que o Protection and Recovery 9.1 já roda em vSphere 8.0 U3. Dá para migrar a replicação com o ambiente ainda em 8.x e deixar o upgrade do vSphere para depois. A má notícia é que não existe upgrade in-place, e o trabalho de verdade não está no upgrade em si, e sim na preparação das replicações.

Este post junta o que encontrei na documentação da Broadcom com um lab que montei de ponta a ponta, partindo de dois sites com vCenter e ESXi 8.0 U3 e VR 9.0.2.3, até chegar ao Protection and Recovery 9.1.1.0100 com a replicação funcionando.

SRM, VLSR, VLR, Protection and Recovery: qual produto é qual

#

A primeira dificuldade é o nome. Em três anos o produto mudou de nome três vezes, e a documentação e o portal de download misturam todos eles:

Ou seja, a partir da 9.0.3 não existe mais “o appliance do vSphere Replication”. Existe um appliance combinado, e o VR é um dos serviços dele.

As versões que importam aqui:

• vSphere Replication 9.0.2.3 (build 25068554, 28/11/2025): a última da linha legada e a origem suportada para convergir para a 9.1.
• Protection and Recovery 9.1.0 (build 25367487, 12/05/2026).
• Protection and Recovery 9.1.1.0 (build 25691510, 03/09/2026).
• Protection and Recovery 9.1.1.0100 (build 25753785): a que usei no lab.

A 9.0.3 foi retirada do portal por um bug de upgrade e substituída pela 9.0.4. Se você encontrar referências a ela, é por isso que ela não aparece para download.

Compatibilidade: não precisa atualizar o vSphere

#

O Protection and Recovery 9.1.x é compatível com vCenter 8.0 U3 e ESXi 8.0 U3 ou posteriores. A KB de convergência pede ESXi 8.0 U2d+ ou 8.0 U3b+. Se o seu ambiente já está em 8.0 U3 atualizado, não há nada a fazer na camada do vSphere.

Fica um appliance combinado por vCenter, com até nove add-ons.

O caminho de upgrade

#

Não dá para montar o ISO da 9.1 no appliance 9.0.2.x e clicar em upgrade. Se você tentar com qualquer ISO 9.0.4+, a VAMI devolve:

Failed to install update: Is a directory

O caminho suportado é este:

VR 8.7.x ──► 8.8.x ──► 9.0.2.3 ──► [deploy de appliance novo 9.1.x] ──► Converge Legacy Appliances

• Da 8.7 direto para a 9.0.x falha com vmlinuz-4.19.182-2.ph3 not found. A passagem pela 8.8 é obrigatória.
• Da 9.0.1 ou 9.0.2.x para a 9.0.2.3 é um upgrade in-place normal, via ISO na VAMI (porta 5480).
• Da 9.0.2.3 para a 9.1.x você faz o deploy de um appliance novo, com IP e FQDN novos, e roda o wizard Converge Legacy Appliances nele. O wizard importa a configuração e as replicações do appliance antigo.

Pré-requisitos

#

Todas as replicações em Enhanced Replication

#

Esse é o pré-requisito que mais pesa. Se sobrar qualquer replicação no modo legacy, em qualquer sentido (incoming ou outgoing), a convergência para com:

Failed to export service: 'hms'. Reason: 'Legacy replications present.'

Isso não é só uma linha na documentação: forcei esse cenário no lab, com uma replicação de teste em modo legacy, e o wizard barrou na hora.

Duas consequências de migrar para Enhanced Replication que vale saber antes:

• Criptografia de rede é obrigatória. O wizard não deixa avançar sem ela habilitada.
• O caminho dos dados muda. No modo enhanced o tráfego vai de ESXi para ESXi, e não mais pelo appliance VR de destino. Roteamento e firewall entre as vmkernels de replicação dos dois sites precisam estar liberados. O próprio wizard tem um Replication mapping tests para validar isso.

Os outros itens

#

1. SSH habilitado nos appliances legados (VRMS e, se houver, SRM).
2. DNS direto e reverso resolvendo os vCenters, os appliances legados e os appliances novos. Falha de resolução é a causa mais comum de erro no wizard.
3. vLCM saudável. O hbr-agent é instalado nos hosts pelo vLCM. Live Patch forçado nas políticas ou deltas pendentes na imagem do cluster fazem a instalação falhar.
4. Snapshots dos appliances legados e dos vCenters dos dois sites, como pede a KB 408127.

O lab

#

Tudo roda no VMware Workstation, com ESXi nested.

Passo a passo

#

1. O ponto de partida

#

Os dois sites com VR 9.0.2.3, pareados, e a ubuntu-DR replicando do Site A para o Site B já em Enhanced replication, que é o pré-requisito para convergir. A replicação usa:

• Target datastore: ClusterA-to-ClusterB
• Replication mapping: Cluster-A ↔ Cluster-B
• RPO de 5 min, compressão e criptografia habilitadas, DataSets replication habilitado

Antes de começar, confira no VRMS legado se a replicação está como deveria. A coluna Replication Server deve mostrar Enhanced replication, o status deve estar OK, e Network compression e Network encryption devem aparecer como Enabled. Esse é o estado que o wizard de convergência espera encontrar.

2. Deploy do appliance Protection and Recovery

#

O appliance novo convive com o VRMS legado até a convergência, então ele precisa de IP e FQDN próprios. Registre o DNS direto e reverso antes de começar, e faça o deploy pelo vCenter do site onde ele vai rodar.

No inventário, clique com o botão direito no cluster e escolha Deploy OVF Template….

Em Select an OVF template, marque Local file, clique em Upload files e selecione o OVA baixado do portal da Broadcom (no lab, Protection-and-recovery-9.1.1.0100.25753785.ova). Clique em Next.

Em Select a name and folder, dê um nome à VM (no lab, par01) e escolha o datacenter ou a pasta de destino. Clique em Next.

Em Select a compute resource, escolha o cluster ou o host onde o appliance vai rodar (no lab, esxi01.9tec.lab) e espere o Compatibility checks succeeded. Clique em Next.

Em Review details, confira o produto e a versão (Protection and recovery appliance, 9.1.1.0100) e repare no tamanho em disco: 4,3 GB em thin, mas 826 GB em thick. Guarde isso para a tela de storage. Clique em Next.

Em License agreements, marque I accept all license agreements e clique em Next.

Em Select storage, troque o Select virtual disk format para Thin Provision, para não reservar os 826 GB do formato thick. Escolha o datastore onde ficam as VMs de infraestrutura (no lab, storage_vmware), e não os datastores que recebem réplicas. Clique em Next.

Em Select networks, aponte a Network 1 do appliance para o port group de gerência, a mesma rede onde estão o vCenter e o VRMS legado (no lab, VM Network). O IP é estático e manual, e vai ser preenchido na próxima tela. Clique em Next.

Customize template é a tela que importa. Ela tem dois blocos. Em Application:

• Enable SSHD: marque. Ajuda muito no troubleshooting se algo der errado na convergência.
• Hostname: o FQDN do appliance (no lab, par01.9tec.lab), já registrado no DNS direto e reverso.
• Initial root password e Initial admin password: no mínimo oito caracteres, com minúsculas, maiúsculas, números e caracteres especiais, sem conter o nome do usuário.
• NTP Servers: o mesmo NTP do vCenter e dos ESXi (no lab, 192.168.99.20).

Em Networking Properties, preencha a rede de forma estática: ipv4, modo static, gateway, domínio, search path, DNS, o IP do appliance e o prefixo. No lab: gateway e DNS 192.168.99.1, domínio 9tec.lab, IP 192.168.99.61/24. Quando aparecer All properties have valid values no topo, clique em Next.

Em Ready to complete, revise o resumo. Os pontos que mais valem a conferência são o formato Thin provision no storage e as propriedades de rede. Clique em Finish e acompanhe o deploy em Recent Tasks.

Terminado o deploy, ligue a VM e acesse a interface de gerência do appliance em https://<fqdn>:5480 (no lab, https://par01.9tec.lab:5480), com o usuário admin e a senha definida no Customize template. O Summary mostra o produto, a versão e os dois caminhos possíveis: Configure Appliance, para uma instalação do zero, e Converge Legacy Appliances, que é o que interessa aqui.

Antes de clicar em qualquer um deles, vá em Certificates e confira se o CN do Appliance Certificate bate com o FQDN do appliance (no lab, CN=par01.9tec.lab). Um CN diferente do FQDN causa erro mais adiante, no registro com o vCenter e no pareamento. Isso costuma acontecer quando o campo Hostname do Customize template fica em branco e o reverse lookup falha. Se não bater, corrija antes de seguir.

3. Converge Legacy Appliances

#

Antes de abrir o wizard, garanta que o SSH está habilitado no VRMS legado que vai ser convergido (no lab, vrms01.9tec.lab). É pré-requisito: o wizard precisa acessar o appliance antigo para exportar a configuração. Na interface de gerência do VRMS (https://vrms01.9tec.lab:5480), vá em Access e confira se SSH login aparece como Enabled. Se estiver desabilitado, clique em Enable.

De volta ao Summary da interface de gerência do appliance novo (https://par01.9tec.lab:5480), clique em Converge Legacy Appliances.

O wizard tem três etapas: vCenter Connection, vCenter Server e Source Appliances.

Em vCenter Connection, informe o vCenter onde o VRMS legado está registrado (no lab, vcsa01.9tec.lab, porta 443) e uma conta de administrador do SSO ([email protected]). Clique em Next.

Como o appliance novo ainda não confia no certificado do vCenter, aparece um Security Alert com o thumbprint do vcsa01.9tec.lab. Confira se é o host certo e clique em Connect.

Em vCenter Server, o wizard lista os serviços de proteção registrados nesse vCenter que podem ser convergidos. No lab aparece só o vSphere Replication em vrms01.9tec.lab:8043, versão 9.0.2.18711 (a 9.0.2.3), já selecionado. O que importa é a coluna Convergence supported mostrar Yes. Se aparecer No, a versão de origem não é suportada e você precisa atualizar o VR para a 9.0.2.3 antes. Clique em Next.

Em Source Appliances, informe as credenciais do VRMS legado (no lab, o usuário admin do vrms01.9tec.lab). É aqui que o SSH conferido no começo deste passo faz diferença: o wizard usa esse acesso para exportar a configuração do appliance antigo, e com o SSH desabilitado no vrms01 a convergência falha. Clique em Finish.

Antes de concluir, aparece mais um Security Alert, agora com o thumbprint do certificado do vrms01.9tec.lab. Confira o host e clique em Connect para a convergência começar.

A convergência leva alguns minutos, mais ou menos conforme a quantidade de replicações existentes. Durante o processo, o wizard mostra o andamento, começando pela exportação dos dados do serviço no appliance legado.

Ao final, aparece no canto inferior direito da tela a mensagem SUCCESS — Appliances converged.

4. Configure Appliance

#

Depois da convergência, a interface de gerência do appliance novo mostra um banner vermelho no topo: “To complete the convergence, run the Configuration wizard and confirm your current configuration settings.” Clique em Configure Appliance no próprio banner. É esse wizard que integra o appliance novo com o vCenter.

Vale saber que, antes mesmo desse Configure, o VRMS legado já foi desligado pela convergência. No inventário do vCenter, o vrms01 aparece como VM desligada, ao lado do par01 ligado. Não ligue o appliance antigo de novo: a partir daqui, quem responde pela replicação é o appliance novo.

O wizard Configure protection and recovery tem quatro etapas: vCenter Connection, vCenter Server, Name and extension e Ready to complete.

Em vCenter Connection, o hostname do vCenter já vem preenchido e travado com o que foi usado na convergência (no lab, vcsa01.9tec.lab). Informe só o usuário e a senha de administrador do SSO e clique em Next.

O Security Alert com o thumbprint do vcsa01.9tec.lab aparece de novo. Clique em Connect.

Em vCenter Server, o wizard só confirma o vCenter selecionado (vcsa01.9tec.lab). Clique em Next.

Ao avançar, o mesmo Security Alert do vcsa01.9tec.lab aparece mais uma vez, com o mesmo thumbprint. Clique em Connect de novo.

Em Name and extension, preencha:

• Site name: um nome único para o site de proteção, que aparece no Protection and Recovery e no pareamento (no lab, Cluster-A).
• Administrator email: o e-mail que recebe as notificações do sistema.
• Local host: o endereço que o appliance vai usar. Selecione o FQDN do appliance novo (par01.9tec.lab).
• Protection and recovery Extension ID: vem fixo como com.vmware.vcDr.

Clique em Next.

Em Ready to complete, revise o resumo (vCenter, site name, extension ID, e-mail e local host) e clique em Finish. Com isso o appliance novo se registra no vCenter e a convergência está concluída neste site.

Durante a configuração, o appliance mostra o andamento, começando pela parada dos serviços.

Ao final, aparece a mensagem SUCCESS — Appliance configured.

5. Repetindo no Site B

#

Antes de repetir o processo no Site B, vale olhar como está a replicação. Neste momento o ambiente está misto: o Site A (vcsa01) já roda o Protection and Recovery configurado, e o Site B (vcsa02) ainda está com o VRMS legado. Mesmo assim, a replicação continua funcionando.

No vCenter do Site A, o plugin já aparece como Protection and Recovery, com o par vcsa01.9tec.lab ↔ vcsa02.9tec.lab e a replicação da ubuntu-DR em Outgoing.

Nos detalhes, a replicação segue com status OK, Enhanced replication e sincronizando dentro do RPO (no lab, lag de 3 segundos). A convergência de um site não interrompe a replicação, então dá para fazer um site de cada vez, com calma.

O Summary do site pair mostra bem esse estado misto. Do lado do Site A, o servidor já é o par01.9tec.lab:443, com o site name Cluster-A definido no Configure Appliance. Do lado do Site B, continua o vrms02.9tec.lab:8043, ainda na 9.0.2. E os dois aparecem com Remote VR connection Connected: o appliance novo conversa normalmente com o VRMS legado do outro site.

Agora repita o processo no Site B: deploy do par02, checagem do certificado, SSH habilitado no vrms02, convergência e Configure Appliance. O site pair entre os dois vCenters não precisa ser recriado, porque a convergência o mantém. Mas, no lab, ele precisou de um reconnect no final, como mostra o próximo passo.

Comecei pelo Site A, o protegido, e só depois fui para o Site B, o de recuperação. É a ordem que a documentação recomenda.

6. Reconectando o site pair

#

Com o Site B convergido e configurado, ao abrir o Protection and Recovery pelo vcsa01 apareceu um banner vermelho: “VR Management Server at par02.9tec.lab is unreachable.” O par mostrava Outgoing 0, como se a replicação tivesse sumido.

Do lado do vcsa02, por outro lado, estava tudo certo: a replicação aparecia em Incoming 1, e o Summary mostrava par02 e par01 com Remote VR connection Connected.

Ou seja, o Site A ainda tinha guardado o caminho antigo do Site B, do tempo do vrms02. A correção é reconectar o par a partir do Site A. No vcsa01, clique em View details no site pair.

No Summary, o lado do vcsa02 aparece sem servidor e com Remote VR connection Unknown. Clique em Reconnect.

Em Reconnect Pair, marque o serviço vSphere Replication e informe o vCenter do outro site (vcsa02.9tec.lab, porta 443) com as credenciais de administrador do SSO. O aviso no topo diz que operações em andamento (Recover, Test, Cleanup, Reprotect) serão interrompidas, então faça isso fora de qualquer teste de DR. Clique em Reconnect.

Aceite o certificado do vcsa02.9tec.lab no Security Alert clicando em Connect.

Pronto: o Summary passa a mostrar Cluster-A com o par01 e Cluster-B com o par02, os dois na 9.1.1.0 e com Remote VR connection Connected.

E a replicação da ubuntu-DR segue OK em Enhanced replication, agora com o destino aparecendo como Cluster-B, o site name do Site B.

Resumo

#

Sair do vSphere Replication 9.0.2.3 para o Protection and Recovery 9.1 não exige tocar no vCenter nem nos ESXi. O trabalho de verdade está antes: deixar todas as replicações em Enhanced Replication, com criptografia de rede, e garantir DNS, SSH e snapshots. A convergência em si é um wizard de poucos minutos por site. Faça um site de cada vez, começando pelo protegido, e no final confira o site pair nos dois vCenters, porque o reconnect pode ser necessário.

Passou por algum erro diferente na sua convergência? Conta nos comentários que eu incluo no FAQ.

O que levar para produção

#

• O trabalho principal é migrar para Enhanced Replication. A convergência é um wizard de poucos minutos. Faça a migração em lotes, ainda na 9.0.2.3, acompanhando o RPO de cada lote.
• Criptografia obrigatória custa CPU, nos hosts de origem e de destino, somada à compressão. Meça o impacto antes de migrar as VMs grandes.
• Esteja pronto para um reconfigure em massa depois de cada convergência. Se aparecer o “Unable to move replication group” (veja o FAQ), as VMs ficam em RPO violation até o reconfigure rodar. Com centenas de VMs, automatize via REST API ou PowerCLI.
• Customizações no appliance legado não migram (overrides de systemd, ajustes manuais, como o do hms.service que mostrei em VRMS Connection refused). Documente antes.
• Permissões customizadas que referenciam roles do VR se perdem e precisam ser recriadas.
• O management pack do VCF Operations (vROps) move as métricas para um novo resource group. Ajuste dashboards e alertas.
• Não apague os appliances legados até terminar a validação. A convergência já os desliga; deixe-os assim, sem ligar de novo.

Checklist pós-upgrade

#

• Conferir o site pair nos dois vCenters e fazer o reconnect onde ele aparecer como unreachable, como no passo 6 (evita também o Failed to retrieve capabilities for site)
• NTP: a sincronização pode parar depois de convergir para a 9.1.1.0; reconfigure o horário
• Reconfigure das replicações em erro
• Recriar as permissões customizadas
• Test recovery (vindo de 9.0.4/9.0.5 existe o problema conhecido “group has independent instances”: faça o cleanup, rode systemctl restart hms no site de recuperação e repita)
• Validar o monitoramento no VCF Operations
• Confirmar que os appliances legados estão desligados (e mantê-los, sem apagar, até validar)

Perguntas frequentes

#

E se sobrar alguma replicação em modo legacy?

A convergência para. Para ver isso na prática, criei de propósito uma replicação de teste em modo legacy e, com o par02 no ar, tentei convergir: o wizard barrou com Legacy replications present, o erro da captura lá nos pré-requisitos. Num ambiente real, é o que acontece quando alguma VM fica para trás na migração para Enhanced.

Para achar as replicações que ainda estão em legacy, abra o Site Recovery, vá em Replications e olhe Outgoing e Incoming. Na visão do site de destino (Incoming), uma replicação legacy mostra na coluna Replication Server o VR server do próprio appliance (no lab, 127.0.0.1). O sinal mais claro, porém, é Network encryption como Disabled: no modo enhanced a criptografia é obrigatória, então qualquer replicação sem ela ainda está em legacy.

A saída é converter a replicação que sobrou para Enhanced, ou simplesmente removê-la, se ela não fizer mais sentido. A conversão é um Reconfigure da própria replicação, sem recriar nada:

Marque a replicação na lista e clique em Reconfigure.

Em Replication mode, troque para Enhanced replication e clique em Next. O wizard passa a ter as etapas de datastore de destino, testes de mapeamento e configurações da replicação.

Em Target datastore, o wizard já traz o datastore da replicação atual (no lab, ClusterA-to-ClusterB). Mantenha o mesmo destino e clique em Next.

Em Replication mapping tests, o wizard testa a conectividade entre os clusters de origem e destino. É aqui que aparece a mudança de caminho: no modo enhanced, os dados vão direto de ESXi para ESXi, sem passar pelo appliance VR de destino. Se o teste falhar, revise o roteamento e o firewall entre as vmkernels de replicação dos dois sites. Com All connectivity tests passed (no lab, cluster-A ↔ Cluster-B com conexão Good), clique em Next.

Em Replication settings, ajuste o RPO e as demais opções como na replicação original (no lab, RPO de 5 minutos, compressão e DataSets replication habilitados). O ponto obrigatório é Enable network encryption for VR data: o próprio wizard avisa que Enhanced vSphere Replication requires network encryption e não avança sem ela. Lembre que criptografia e compressão custam CPU nos hosts de origem e destino. Clique em Next.

Em Ready to complete, revise o resumo e confirme principalmente Network encryption: Enabled e o datastore de destino. Clique em Finish.

Depois da sincronização, a replicação muda de cara nos dois lados. No site de origem (Outgoing), a coluna Replication Server passa a mostrar Enhanced replication.

No site de destino (Incoming), ela deixa de apontar para o VR server do appliance e passa a mostrar o IP de gerência do ESXi que recebe a replicação (no lab, 192.168.99.32, o esxi02). É a prova de que os dados agora vão de ESXi para ESXi.

Antes de tentar convergir de novo, confira os dois sentidos (incoming e outgoing): nenhuma replicação pode continuar com Network encryption desabilitada ou apontando para o VR server do appliance.

E se a replicação ficar em RPO violation depois da convergência?

Neste lab, a replicação continuou OK. Numa execução anterior do mesmo processo, porém, a replicação apareceu em erro depois de convergir:

Error (RPO Violation) — Unable to move replication group to a new vSphere Replication Server.

A causa é o IP novo do appliance: as replicações ainda apontam para o servidor antigo. É um problema conhecido desde a 9.0.3 e dado como corrigido na 9.1.1.0, mas eu o reproduzi na 9.1.1.0100.

A correção é um Reconfigure sem alterar nada: abra o wizard, avance até o fim e conclua. Depois disso o status volta para OK. Com muitas VMs, vale automatizar esse reconfigure via REST API ou PowerCLI.

No lab, logo depois do reconfigure a replicação voltou a sincronizar: status OK, lag de 11 segundos e a última sincronização de 424 KB em 1 segundo.

E a licença, para quem usa só o vSphere Replication?

Quem usa só o VR costuma estranhar: o appliance combinado sempre inclui os componentes de SRM e registra o plugin Site Recovery no vCenter. Junto aparece uma licença de avaliação do Live Site Recovery.

Essa avaliação vale só para as funções de SRM: protection groups, recovery plans, planned migration e orquestração de DR. Quando ela expira, a replicação standalone continua funcionando, coberta pela licença do vSphere ou do VCF. Se você não usa SRM, pode remover o registro da solução Live Site Recovery do vCenter sem impacto no VR (KB 445654).

Referências

#

• Protection and Recovery 9.1.1.0 Release Notes
• Protection and Recovery 9.1 Release Notes
• KB 408127 – Steps to Converge to VMware Live Recovery Appliance 9.0.4 (or newer) and Common Issues
• KB 414400 – How to upgrade (converge) from VLSR to VMware Live Recovery Appliance
• KB 445654 – Licensing Behavior for Standalone vSphere Replication after Converged Appliance
• KB 441696 – Download VMware Protection and Recovery / Live Recovery
• KB 380968 – Build numbers and versions of vSphere Replication Appliance
• KB 414278 – vSphere Replication 9.0.3 not downloadable
• Blog VMware – Protecting VCF 9: Upgrade to Enhanced vSphere Replication