Solucionar problemas de erros de replicação de VMs do Azure para o Azure

Este artigo descreve como solucionar erros comuns no Azure Site Recovery durante a replicação e a recuperação de VMs (máquinas virtuais) do Azure de uma região para outra. Para obter mais informações sobre configurações com suporte, consulte a matriz de suporte para replicar máquinas virtuais do Azure.

Problemas de cota de recursos do Azure (código de erro 150097)

Veja se sua assinatura está habilitada para criar VMs do Azure na região de destino que você planeja usar como a região de recuperação de desastre (DR). Sua assinatura precisa de cota suficiente para criar VMs dos tamanhos necessários. Por padrão, o Site Recovery escolhe um tamanho de VM de destino que seja igual ao tamanho da VM de origem. Se o tamanho correspondente não estiver disponível, o Site Recovery escolherá automaticamente o tamanho mais próximo disponível.

Se não houver um tamanho que dê suporte à configuração da VM de origem, a seguinte mensagem será exibida:

Replication couldn't be enabled for the virtual machine <VmName>.

Possíveis causas

• Sua ID de assinatura não está habilitada para criar máquinas virtuais no local de região de destino.
• Sua ID de assinatura não está habilitada ou não tem uma cota suficiente para criar tamanhos específicos de VM no local de região de destino.
• Nenhum tamanho de VM de destino adequado é encontrado para corresponder à contagem de NIC (placa de interface de rede) da VM de origem (2), para a ID da assinatura no local da região de destino.

Corrigir o problema

Entre em contato com o suporte à cobrança do Azure para habilitar sua assinatura para criar VMs nos tamanhos necessários no local de destino. Em seguida, tente novamente a operação que falhou.

Se o local de destino tiver uma restrição de capacidade, desabilite a replicação para esse local. Em seguida, habilite a replicação para um local diferente em que sua assinatura tem uma cota suficiente para criar VMs dos tamanhos necessários.

Certificados de raiz confiável (código de erro 151066)

Se nem todos os certificados raiz confiáveis mais recentes estiverem presentes na VM, o trabalho para habilitar a replicação para Site Recovery poderá falhar. A autenticação e a autorização de chamadas de serviço do Site Recovery da VM falham sem esses certificados.

Se o trabalho habilitar replicação falhar, a seguinte mensagem será exibida:

Site Recovery configuration failed.

Causa possível

Os certificados raiz confiáveis necessários para autorização e autenticação não estão presentes na máquina virtual.

Corrigir o problema

Windows

Para uma VM que executa o sistema operacional Windows, instale as atualizações mais recentes do Windows para que todos os certificados raiz confiáveis estejam presentes na VM. Siga o típico gerenciamento de atualização do Windows ou o certificado de processo de gerenciamento de atualização na sua organização para conseguir os certificados de raiz mais recentes e a lista de certificados revogados atualizada nas VMs.

• Se você estiver em um ambiente desconectado, siga o processo de atualização padrão do Windows em sua organização para obter os certificados.
• Se os certificados necessários não estiverem presentes na VM, as chamadas para o serviço de recuperação de Site falharão por razões de segurança.

Para verificar se o problema foi resolvido, vá para login.microsoftonline.com de um navegador em sua VM.

Para obter mais informações, consulte Configurar raízes confiáveis e certificados não permitidos.

Linux

Diga as diretrizes fornecidas pelo distribuidor da versão do sistema operacional Linux para obter os certificados raiz confiáveis mais recentes e a última lista de certificados revogados na VM.

Como o SUSE Linux usa links simbólicos, ou simlinks, para manter uma lista de certificados, siga estes passos:

1. Entre como um usuário raiz. O símbolo de hash (#) é o prompt de comando padrão.

2. Execute este comando para alterar o diretório:

   cd /etc/ssl/certs

3. Verifique se o certificado de autoridade de certificação raiz da Symantec está presente:

   ls VeriSign_Class_3_Public_Primary_Certification_Authority_G5.pem

   • Se o certificado da autoridade de certificação raiz da Symantec não for encontrado, execute o comando a seguir para baixar o arquivo. Verifique se há algum erro e siga as ações recomendadas para falhas de rede.

     wget https://docs.broadcom.com/docs-and-downloads/content/dam/symantec/docs/other-resources/verisign-class-3-public-primary-certification-authority-g5-en.pem -O VeriSign_Class_3_Public_Primary_Certification_Authority_G5.pem

4. Verifique se o certificado de autoridade de certificação raiz da Baltimore está presente:

   ls Baltimore_CyberTrust_Root.pem

   • Se o certificado de autoridade de certificação raiz da Baltimore não for encontrado, execute este comando para baixar o certificado:

     wget https://www.digicert.com/CACerts/BaltimoreCyberTrustRoot.crt.pem -O Baltimore_CyberTrust_Root.pem

5. Verifique se o certificado DigiCert_Global_Root_CA está presente:

   ls DigiCert_Global_Root_CA.pem

   • Se o DigiCert_Global_Root_CA não for encontrado, execute os comandos a seguir para baixar o certificado:

     wget http://www.digicert.com/CACerts/DigiCertGlobalRootCA.crt
     
     openssl x509 -in DigiCertGlobalRootCA.crt -inform der -outform pem -out DigiCert_Global_Root_CA.pem
     

6. Para atualizar os hashes de entidade de certificado para os certificados baixados recentemente, execute o script rehash:

   c_rehash

7. Para verificar se os hashes da entidade como simlinks foram criados para os certificados, execute estes comandos:

   ls -l | grep Baltimore
   

   lrwxrwxrwx 1 root root   29 Jan  8 09:48 3ad48a91.0 -> Baltimore_CyberTrust_Root.pem
   
   -rw-r--r-- 1 root root 1303 Jun  5  2014 Baltimore_CyberTrust_Root.pem
   

   ls -l | grep VeriSign_Class_3_Public_Primary_Certification_Authority_G5
   

   -rw-r--r-- 1 root root 1774 Jun  5  2014 VeriSign_Class_3_Public_Primary_Certification_Authority_G5.pem
   
   lrwxrwxrwx 1 root root   62 Jan  8 09:48 facacbc6.0 -> VeriSign_Class_3_Public_Primary_Certification_Authority_G5.pem
   

   ls -l | grep DigiCert_Global_Root
   

   lrwxrwxrwx 1 root root   27 Jan  8 09:48 399e7759.0 -> DigiCert_Global_Root_CA.pem
   
   -rw-r--r-- 1 root root 1380 Jun  5  2014 DigiCert_Global_Root_CA.pem
   

8. Crie uma cópia do arquivo VeriSign_Class_3_Public_Primary_Certification_Authority_G5.pem com o nome de arquivo b204d74a.0:

   cp VeriSign_Class_3_Public_Primary_Certification_Authority_G5.pem b204d74a.0

9. Crie uma cópia do arquivo Baltimore_CyberTrust_Root.pem com o nome de arquivo 653b494a.0:

   cp Baltimore_CyberTrust_Root.pem 653b494a.0

10. Crie uma cópia do arquivo DigiCert_Global_Root_CA.pem com o nome de arquivo 3513523f.0:

    cp DigiCert_Global_Root_CA.pem 3513523f.0

11. Verifique se os arquivos estão presentes:

    ls -l 653b494a.0 b204d74a.0 3513523f.0
    

    -rw-r--r-- 1 root root 1774 Jan  8 09:52 3513523f.0
    
    -rw-r--r-- 1 root root 1303 Jan  8 09:52 653b494a.0
    
    -rw-r--r-- 1 root root 1774 Jan  8 09:52 b204d74a.0
    

Intervalos de IP ou URLs de saída (código de erro 151037 ou 151072)

Para replicação do Site Recovery funcionar, a conectividade de saída para URLs específicas é necessária a partir da VM. Se a VM estiver atrás de um firewall ou usa regras de grupo de segurança de rede (NSG) para controlar a conectividade de saída, você poderá enfrentar um desses problemas. Enquanto continuamos a dar suporte ao acesso de saída por meio de URLs, não há mais suporte para o uso de uma lista de permissões de intervalos de IP.

Possíveis causas

• Não é possível estabelecer uma conexão com pontos de extremidade do Site Recovery devido a uma falha de resolução de DNS (Sistema de Nomes de Domínio).
• Esse problema é mais comum durante a nova proteção, quando você faz failover da máquina virtual, mas o servidor DNS não está acessível na região de DR (recuperação de desastre).

Corrigir o problema

Se você estiver usando o DNS personalizado, veja que o servidor DNS está acessível na região de recuperação de desastres.

Para verificar se a VM usa uma configuração de DNS personalizada:

1. Abra Máquinas virtuais e selecione a VM.
2. Navegue até as Configurações de VMs e selecione Rede.
3. Em Rede virtual/sub-rede, selecione o link para abrir a página de recursos da rede virtual.
4. Vá para Configurações e selecione Servidores DNS.

Tente acessar o servidor DNS da máquina virtual. Se o servidor DNS não estiver acessível, torne-o acessível fazendo failover do servidor DNS ou criando a linha de site entre a rede de DR e o DNS.

Problema 2: falha na configuração do Azure Site Recovery (151196)

Causa possível

Não é possível estabelecer a conexão para pontos de extremidade de IP4 de identidade e autenticação do Microsoft 365.

Corrigir o problema

O Azure Site Recovery precisa de acesso aos intervalos de IP do Microsoft 365 para autenticação. Se estiver usando as regras do Grupo de segurança de rede (NSG) do Azure / proxy de firewall para controlar a conectividade de rede de saída na VM, certifique-se de usar a regra NSG baseada na marca de serviço do Microsoft Entra para permitir o acesso ao Microsoft Entra ID. Não há mais suporte para regras de NSG baseadas em endereço IP.

Problema 3: falha na configuração do Site Recovery (151197)

Causa possível

Não é possível estabelecer conexão com pontos de extremidade de serviço do Azure Site Recovery.

Corrigir o problema

Se você estiver usando regras de NSG (grupo de segurança de rede) do Azure/proxy de firewall para controlar a conectividade de rede de saída na VM, certifique-se de usar marcas de serviço. Não há mais suporte para usar uma lista de permissões de endereços IP via NSGs para Azure Site Recovery.

Problema 4: a replicação falha quando o tráfego de rede usa o servidor proxy local (151072)

Causa possível

As configurações de proxy personalizadas são inválidas, e o agente do serviço Mobilidade não detectou automaticamente as configurações de proxy do Internet Explorer.

Corrigir o problema

1. O agente do serviço Mobilidade detecta as configurações de proxy do Internet Explorer no Windows e /etc/environment no Linux.

2. Se você preferir definir o proxy somente para o serviço Mobilidade do ASR, você poderá fornecer os detalhes do proxy em ProxyInfo.conf localizado em:

   • Linux: /usr/local/InMage/config/
   • Windows: C:\ProgramData\Microsoft Azure Site Recovery\Config

3. ProxyInfo.conf deve ter as configurações de proxy no seguinte formato INI.

   [proxy]
   Address=http://1.2.3.4
   Port=567
   

Mais informações

Para especificar as URLs necessárias ou os intervalos de IP necessários, siga as orientações em Sobre a rede na replicação do Azure para o Azure.

Disco não encontrado na VM (código de erro 150039)

Um novo disco anexado à máquina virtual deve ser inicializado. Se o disco não for encontrado, a seguinte mensagem será exibida:

Azure data disk <DiskName> <DiskURI> with logical unit number <LUN> <LUNValue> was not mapped to a corresponding disk being reported from within the VM that has the same LUN value.

Possíveis causas

• Um novo disco de dados foi anexado à VM, mas não foi inicializado.
• O disco de dados dentro da VM não está relatando corretamente o valor de LUN (número de unidade lógica) no qual o disco foi anexado à VM.

Corrigir o problema

Verifique se os discos de dados são inicializados e, em seguida, repita a operação.

• Windows: anexe e inicialize um novo disco.
• Linux: inicialize um novo disco de dados no Linux.

Se o problema persistir, contate o Suporte.

Vários discos disponíveis para proteção (código de erro 153039)

Possíveis causas

• Um ou mais discos foram adicionados recentemente à máquina virtual após a proteção.
• Um ou mais discos foram inicializados após a proteção da máquina virtual.

Corrigir o problema

Para tornar o status de replicação da VM íntegro novamente, você pode optar por proteger os discos ou ignorar o aviso.

Para proteger os discos

1. Vá para Itens replicados>Nome da VM>Discos.

2. Selecione o disco desprotegido e, em seguida, selecione Habilitar replicação:

   

Para ignorar o aviso

1. Vá para Itens replicados>Nome da VM.

2. Selecione o aviso na seção Visão geral e, em seguida, selecione OK.

   

A VM removida do cofre foi concluída com informações (código de erro 150225)

Quando o Site Recovery protege a máquina virtual, ele cria links na máquina virtual de origem. Quando você remove a proteção ou desabilita a replicação, o Site Recovery remove esses links como parte do trabalho de limpeza. Se a máquina virtual tiver um bloqueio de recurso, o trabalho de limpeza será concluído com as informações. As informações indicam que a máquina virtual foi removida do cofre dos serviços de recuperação, mas que alguns dos links obsoletos não puderam ser limpos no computador de origem.

Você poderá ignorar esse aviso se você nunca pretender proteger essa máquina virtual novamente. Mas se você precisar proteger essa máquina virtual posteriormente, siga as etapas nesta seção para limpar os links.

Corrigir o problema

1. Remova o bloqueio da VM ou do grupo de recursos da VM. Por exemplo, na imagem a seguir, o bloqueio de recurso na VM chamada MoveDemo deve ser excluído:

   

2. Baixe o script para remover uma configuração obsoleta do Site Recovery.

3. Execute o script, Cleanup-stale-asr-config-Azure-VM.ps1. Forneça a ID da assinatura, o grupo de recursos da VMe o nome da VM como parâmetros.

4. Se você for solicitado a fornecer as credenciais do Azure, forneça-as. Em seguida, verifique se o script é executado sem falhas.

Replicação não habilitada na VM com recursos obsoletos (código de erro 150226)

Possíveis causas

A máquina virtual tem uma configuração obsoleta da proteção do Site Recovery anterior.

Uma configuração obsoleta poderá ocorrer em uma VM do Azure se você tiver habilitado a replicação para a VM do Azure usando Site Recovery e, em seguida:

• Você desabilitou a replicação, mas a VM de origem tinha um bloqueio de recurso.
• Você excluiu o cofre do Site Recovery sem desabilitar explicitamente a replicação na VM.
• Você excluiu o grupo de recursos que contém o cofre do Site Recovery sem desabilitar explicitamente a replicação na VM.

Corrigir o problema

1. Remova o bloqueio da VM ou do grupo de recursos da VM. Por exemplo, na imagem a seguir, o bloqueio de recurso na VM chamada MoveDemo deve ser excluído:

   

2. Baixe o script para remover uma configuração obsoleta do Site Recovery.

3. Execute o script, Cleanup-stale-asr-config-Azure-VM.ps1. Forneça a ID da assinatura, o grupo de recursos da VMe o nome da VM como parâmetros.

4. Se você for solicitado a fornecer as credenciais do Azure, forneça-as. Em seguida, verifique se o script é executado sem falhas.

Não é possível selecionar a VM ou o grupo de recursos em Habilitar trabalho de replicação

Problema 1: o grupo de recursos e a VM de origem estão em locais diferentes

Atualmente, Site Recovery requer que o grupo de recursos da região de origem e as máquinas virtuais estejam no mesmo local. Se não estiverem, você não poderá encontrar a máquina virtual ou o grupo de recursos ao tentar aplicar a proteção.

Como alternativa, você pode habilitar a replicação da VM em vez do cofre dos Serviços de Recuperação. Vá para VM de Origem>Propriedades>Recuperação de Desastre e habilite a replicação.

Problema 2: o grupo de recursos não faz parte da assinatura selecionada

Talvez não seja possível localizar o grupo de recursos no momento da proteção, se ele não fizer parte da assinatura selecionada. Veja se o grupo de recursos pertence à assinatura que está sendo usada.

Problema 3: configuração obsoleta

Talvez você não veja a VM que deseja habilitar para replicação se houver uma configuração de Site Recovery obsoleta na VM do Azure. Essa condição poderá ocorrer se você tiver habilitado a replicação para a VM do Azure usando o Site Recovery e, em seguida:

• Você excluiu o cofre do Site Recovery sem desabilitar explicitamente a replicação na VM.
• Você excluiu o grupo de recursos que contém o cofre do Site Recovery sem desabilitar explicitamente a replicação na VM.
• Você desabilitou a replicação, mas a VM de origem tinha um bloqueio de recurso.

Corrigir o problema

1. Remova o bloqueio, se houver, da VM ou do grupo de recursos da VM. Por exemplo, na imagem a seguir, o bloqueio de recurso na VM chamada MoveDemo deve ser excluído:

   

2. Baixe o script para remover uma configuração obsoleta do Site Recovery.

3. Execute o script, Cleanup-stale-asr-config-Azure-VM.ps1. Forneça a ID da assinatura, o grupo de recursos da VMe o nome da VM como parâmetros.

4. Se você for solicitado a fornecer as credenciais do Azure, forneça-as. Em seguida, verifique se o script é executado sem falhas.

Não é possível selecionar uma VM para proteção

Causa possível

A máquina virtual tem uma extensão instalada em um estado com falha ou sem resposta

Corrigir o problema

Vá para Máquinas virtuais>Configurações>Extensões e verifique se há extensões em um estado com falha. Desinstale qualquer extensão com falha e tente proteger a máquina virtual novamente.

O estado de provisionamento da VM não é válido (código de erro 150019)

Para habilitar a replicação na VM, o estado de provisionamento deve ser Com êxito. Execute as seguintes etapas para verificar o estado de provisionamento:

1. Selecione o Gerenciador de Recursos em Todos os Serviços no portal do Azure.
2. Expanda a lista Assinaturas e selecione sua assinatura.
3. Expanda a lista ResourceGroups e selecione o grupo de recursos da VM.
4. Expanda a lista Recursos e selecione sua VM.
5. Verifique o campo provisioningState na exibição de instância no lado direito.

Corrigir o problema

• Se provisioningState forCom falha, entre em contato com o suporte com detalhes para solucionar o problema.
• Se provisioningState for Atualizando, outra extensão poderá estar sendo implantada. Verifique se há operações em andamento na VM, aguarde até que elas sejam concluídas e repita o trabalho do Site Recovery com falha para habilitar a replicação.

Não é possível selecionar a VM de destino

Problema 1: a VM está anexada a uma rede que já está mapeada para uma rede de destino

Durante a configuração de recuperação de desastre, se a VM de origem fizer parte de uma rede virtual e outra VM da mesma rede virtual já estiver mapeada com uma rede no grupo de recursos de destino, a caixa de listagem suspensa da seleção de rede estará indisponível (aparece esmaecida) por padrão.

Problema 2: você protegeu anteriormente a VM e, em seguida, desabilitou a replicação

Desabilitar a replicação de uma VM não exclui o mapeamento de rede. O mapeamento deve ser excluído do cofre dos Serviços de Recuperação onde a VM foi protegida. Selecione o cofre dos Serviços de Recuperação e vá para Gerenciar>Infraestrutura do Site Recovery>Para máquinas virtuais do Azure>Mapeamento de Rede.

A rede de destino configurada durante a configuração da recuperação de desastre pode ser alterada após a configuração inicial e depois que a VM está protegida. Para Modificar o mapeamento de rede, selecione o nome da rede:

COM+ ou VSS (código de erro 151025)

Quando ocorre o erro de COM+ ou Serviço de Cópias de Sombra de Volume (VSS), a seguinte mensagem é exibida:

Site Recovery extension failed to install.

Possíveis causas

• O serviço Aplicativo do Sistema COM+ está desabilitado.
• O Serviço de Cópias de Sombra de Volume está desabilitado.

Corrigir o problema

Defina o Aplicativo do Sistema COM+ e o Serviço de Cópias de Sombra de Volume para o modo de inicialização manual ou automático.

1. Abra o console Serviços no Windows.

2. Verifique se o Aplicativo do Sistema COM+ e o Serviço de Cópias de Sombra de Volume não estão definidos como Desabilitado como seu Tipo de Inicialização.

   

Tamanho do disco gerenciado não suportado (código de erro 150172)

Quando esse erro ocorre, a mensagem a seguir é exibida:

Protection couldn't be enabled for the virtual machine as it has <DiskName> with size <DiskSize> that is lesser than the minimum supported size 1024 MB.

Causa possível

O disco é menor que o tamanho suportado de 1024 MB.

Corrigir o problema

Verifique se o tamanho do disco está dentro do intervalo de tamanhos válido. Em seguida, tente realizar a operação novamente.

Proteção não habilitada quando o GRUB usa o nome do dispositivo (código de erro 151126)

Possíveis causas

Os arquivos de configuração do Grand Unified Bootloader (GRUB) Linux ( /boot/grub/menu.lst, /boot/grub/grub.cfg, /boot/grub2/grub.cfg ou /etc/default/grub) podem especificar os nomes de dispositivo reais em vez de valores de identificador universalmente exclusivo (UUID) para os parâmetros root e resume. O Site Recovery requer UUIDs porque os nomes de dispositivo podem ser alterados. Após a reinicialização, uma VM pode não vir com o mesmo nome no failover, resultando em problemas.

Os exemplos a seguir são linhas de arquivos GRUB nos quais os nomes de dispositivo aparecem em vez dos UUIDs necessários:

• Arquivo /boot/grub2/grub.cfg:

  linux /boot/vmlinuz-3.12.49-11-default root=/dev/sda2 ${extra_cmdline} resume=/dev/sda1 splash=silent quiet showopts

• Arquivo: /boot/grub/menu.lst

  kernel /boot/vmlinuz-3.0.101-63-default root=/dev/sda2 resume=/dev/sda1 splash=silent crashkernel=256M-:128M showopts vga=0x314

Corrigir o problema

Substitua cada nome de dispositivo pelo UUID correspondente:

1. Localize o UUID do dispositivo executando o comando blkid <device name>. Por exemplo:

   blkid /dev/sda1
   /dev/sda1: UUID="6f614b44-433b-431b-9ca1-4dd2f6f74f6b" TYPE="swap"
   blkid /dev/sda2
   /dev/sda2: UUID="62927e85-f7ba-40bc-9993-cc1feeb191e4" TYPE="ext3"
   

2. Substitua o nome do dispositivo por seu UUID nos formatos root=UUID=<UUID> e resume=UUID=<UUID>. Por exemplo, após a substituição, a linha de /boot/grub/menu.lst ficaria parecida com a seguinte linha:

   kernel /boot/vmlinuz-3.0.101-63-default root=UUID=62927e85-f7ba-40bc-9993-cc1feeb191e4 resume=UUID=6f614b44-433b-431b-9ca1-4dd2f6f74f6b splash=silent crashkernel=256M-:128M showopts vga=0x314

3. Tente novamente a proteção.

Falha na proteção porque o dispositivo GRUB não existe (código de erro 151124)

Causa possível

Os arquivos de configuração do GRUB ( /boot/grub/menu.lst, /boot/grub/grub.cfg, /boot/grub2/grub.cfg ou /etc/default/grub) podem conter os parâmetros rd.lvm.lv ou rd_LVM_LV. Esses parâmetros identificam os dispositivos LVM (Gerenciador de volumes lógicos) que serão descobertos no momento da inicialização. Se esses dispositivos LVM não existirem, o próprio sistema protegido não será inicializado e ficará preso no processo de inicialização. O mesmo problema também será visto com a VM de failover. Veja alguns exemplos:

• Arquivo: /boot/grub2/grub.cfg em RHEL7:

  linux16 /vmlinuz-3.10.0-957.el7.x86_64 root=/dev/mapper/rhel_mup--rhel7u6-root ro crashkernel=128M\@64M rd.lvm.lv=rootvg/root rd.lvm.lv=rootvg/swap rhgb quiet LANG=en_US.UTF-8

• Arquivo: /etc/default/grub em RHEL7:

  GRUB_CMDLINE_LINUX="crashkernel=auto rd.lvm.lv=rootvg/root rd.lvm.lv=rootvg/swap rhgb quiet

• Arquivo: /boot/grub/menu.lst em RHEL6:

  kernel /vmlinuz-2.6.32-754.el6.x86_64 ro root=UUID=36dd8b45-e90d-40d6-81ac-ad0d0725d69e rd_NO_LUKS LANG=en_US.UTF-8 rd_NO_MD SYSFONT=latarcyrheb-sun16 crashkernel=auto rd_LVM_LV=rootvg/lv_root KEYBOARDTYPE=pc KEYTABLE=us rd_LVM_LV=rootvg/lv_swap rd_NO_DM rhgb quiet

Em cada exemplo, o GRUB precisa detectar dois dispositivos LVM com os nomes root e swap do grupo de volumes rootvg.

Corrigir o problema

Se o dispositivo LVM não existir, crie-o ou remova os parâmetros correspondentes dos arquivos de configuração do GRUB. Em seguida, tente novamente habilitar a proteção.

Atualização do serviço Mobilidade concluída com avisos (código de erro 151083)

O serviço Mobilidade do Site Recovery tem muitos componentes, um dos quais é chamado driver de filtro. O driver de filtro é carregado na memória do sistema somente durante a reinicialização do sistema. Sempre que uma atualização do serviço Mobilidade inclui alterações de driver de filtro, o computador é atualizado, mas você ainda vê um aviso de que algumas correções exigem uma reinicialização. O aviso é exibido porque as correções do driver de filtro só podem entrar em vigor quando o novo driver de filtro é carregado, o que ocorre apenas durante uma reinicialização.

Proteção não habilitada se o disco gerenciado de réplica existir

Esse erro ocorre quando o disco gerenciado de réplica já existe, sem as marcas esperadas, no grupo de recursos de destino.

Causa possível

Esse problema poderá ocorrer caso a máquina virtual tenha sido protegida anteriormente, e quando a replicação foi desabilitada e o disco de réplica não tenha sido removido.

Corrigir o problema

Exclua o disco de réplica identificado na mensagem de erro e repita o trabalho de proteção com falha.

Falha ao habilitar a proteção, pois o instalador não pode localizar o disco raiz (código de erro 151137)

Esse erro ocorre em computadores Linux em que o disco do sistema operacional é criptografado usando Azure Disk Encryption (ADE). Esse é um problema válido somente na versão 9.35 do Agente.

Possíveis causas

O instalador não pode localizar o disco raiz que hospeda o sistema de arquivos raiz.

Corrigir o problema

Execute as etapas a seguir para corrigir esse problema.

1. Localize os bits de agente no diretório /var/lib/waagent em computadores RHEL e CentOS usando o comando abaixo:
   

   # find /var/lib/ -name Micro\*.gz

   Saída esperada:

   /var/lib/waagent/Microsoft.Azure.RecoveryServices.SiteRecovery.LinuxRHEL7-1.0.0.9139/UnifiedAgent/Microsoft-ASR_UA_9.35.0.0_RHEL7-64_GA_30Jun2020_release.tar.gz

2. Crie um novo diretório e altere o diretório para esse novo diretório.

3. Extraia o arquivo do agente encontrado na primeira etapa aqui, usando o comando abaixo:

   tar -xf <Tar Ball File>

4. Abra o arquivo prereq_check_installer.js e exclua as linhas a seguir. Salve o arquivo após isso.

      {
         "CheckName": "SystemDiskAvailable",
         "CheckType": "MobilityService"
      },
   

5. Invoque o instalador usando o comando:
   

   ./install -d /usr/local/ASR -r MS -q -v Azure

6. Se o instalador for executado com sucesso, repita o trabalho de habilitar replicação.

Solucionar problemas e lidar com alterações de hora em servidores replicados

Esse erro ocorre quando a hora do computador de origem avança e, em seguida, volta em pouco tempo para corrigir a alteração. Talvez você não perceba a alteração, pois a hora é corrigida muito rapidamente.

Como corrigir: para resolver esse problema, aguarde até que a hora do sistema atinja a hora futura distorcida. Outra opção é desabilitar e habilitar a replicação mais uma vez, o que só é viável para a replicação direta (dados replicados da região primária para a secundária) e não se aplica à replicação reversa (dados replicados da região secundária para primária).

Próximas etapas

Replicar VMs do Azure para outra região do Azure.