Resolver erros ao efetuar a ativação pós-falha da VM VMware ou da máquina física do Azure

Pode receber um dos seguintes erros ao fazer a falha de uma máquina virtual para a Azure. Para resolver problemas, utilize os passos descritos para cada condição de erro.

A ativação pós-falha falhou com o ID de Erro 28031

Site Recovery não foi capaz de criar uma falha sobre a máquina virtual em Azure. Pode acontecer por causa de uma das seguintes razões:

  • Não existe quota suficiente para criar a máquina virtual: Pode verificar a quota disponível indo para Subscrição -> Utilização + quotas. Pode abrir um novo pedido de apoio para aumentar a quota.

  • Está a tentar falhar com máquinas virtuais de diferentes famílias de tamanhos diferentes no mesmo conjunto de disponibilidade. Certifique-se de que escolhe a mesma família para todas as máquinas virtuais no mesmo conjunto de disponibilidade. Mude o tamanho indo para as definições de Computo da máquina virtual e, em seguida, redaça o failover.

  • Existe uma política sobre a subscrição que impede a criação de uma máquina virtual. Mude a política para permitir a criação de uma máquina virtual e, em seguida, relemque o failover.

A ativação pós-falha falhou com o ID de Erro 28092

O Site Recovery não foi capaz de criar uma interface de rede para a ativação pós-falha da máquina virtual. Certifique-se de que tem quota suficiente disponível para criar interfaces de rede na subscrição. Pode verificar a quota disponível indo para Subscrição -> Utilização + quotas. Pode abrir um novo pedido de apoio para aumentar a quota. Se tiver quota suficiente, então este pode ser um problema intermitente, tente a operação novamente. Se a questão persistir mesmo após as retrações, então deixe um comentário no final deste documento.

A ativação pós-falha falhou com o ID de Erro 70038

Site Recovery não foi capaz de criar uma falha sobre a máquina virtual Clássica em Azure. Pode acontecer porque:

  • Um dos recursos, como uma rede virtual que é necessária para a criação da máquina virtual, não existe. Crie a rede virtual conforme fornecido nas definições de Rede da máquina virtual ou modifique a definição para uma rede virtual que já existe e, em seguida, relemque o failover.

Falha falhou com Error ID 170010

Site Recovery não foi capaz de criar uma falha sobre a máquina virtual em Azure. Pode acontecer porque uma atividade interna de hidratação falhou para a máquina virtual no local.

Para criar qualquer máquina em Azure, o ambiente Azure requer que alguns dos condutores estejam no estado de arranque e serviços como o DHCP para estar em estado de arranque automático. Assim, a atividade de hidratação, no momento do failover, converte o tipo de arranque de atapi, intelide, storflt, vmbus e storvsc drivers para arranque. Também converte o tipo de startup de alguns serviços como o DHCP para o arranque automático. Esta atividade pode falhar devido a questões específicas do ambiente.

Para alterar manualmente o tipo de arranque de controladores para Windows Guest OS, siga os passos abaixo:

  1. Descarregue o script sem hidratação e execute-o da seguinte forma. Este script verifica se o VM requer hidratação.

    .\Script-no-hydration.ps1

    Dá o seguinte resultado se for necessária hidratação:

    REGISTRY::HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\storvsc           start =  3 expected value =  0
    
    This system doesn't meet no-hydration requirement.
    

    Caso o VM cumpra o requisito de não hidratação, o script dará o resultado "Este sistema não cumpre os requisitos de não hidratação". Neste caso, todos os motoristas e serviços estão no estado conforme exigido pela Azure e a hidratação no VM não é necessária.

  2. Executar o script sem hidratação da seguinte forma se o VM não cumprir o requisito de não hidratação.

    .\Script-no-hydration.ps1 -set

    Isto converterá o tipo de arranque de condutores e dará o resultado como abaixo:

    REGISTRY::HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\storvsc           start =  3 expected value =  0
    
    Updating registry:  REGISTRY::HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\storvsc   start =  0
    
    This system is now no-hydration compatible.
    

Não é possível ligar ou fazer RDP/SSH na máquina virtual com ativação pós-falha porque o botão Ligar está desativado na máquina virtual

Para obter instruções detalhadas sobre resolução de problemas em questões de PDR, consulte a nossa documentação aqui.

Para obter instruções detalhadas sobre resolução de problemas sobre questões de SSH, consulte a nossa documentação aqui.

Se o botão Ligação da falha sobre VM em Azure estiver acinzentado e não estiver ligado ao Azure através de uma rota expressa ou de uma ligação VPN local-a-local, então,

  1. Vá à máquina>virtualNetworking, clique no nome da interface de rede necessária. Screenshot shows the Networking page for a virtual machine with the network interface name selected.
  2. Navegue para Configurações Ip e, em seguida, clique no campo nome da configuração IP necessária. Screenshot shows the I P configurations page for the network interface with the I P configuration name selected.
  3. Para ativar o endereço IP público, clique em Enable. Enable IP
  4. Clique em Configurar as definições necessárias>Criar novos. Create new
  5. Insira o nome do endereço público, escolha as opções predefinição para SKU e atribuição e, em seguida, clique em OK.
  6. Agora, para guardar as alterações es feitas, clique em Guardar.
  7. Feche os painéis e navegue para a secção de visão geral da máquina virtual para ligar/RDP.

Não é possível ligar/RDP/SSH - Botão de Ligação VM disponível

Se o botão Ligação no VM falhado em Azure estiver disponível (não acinzentado), verifique os diagnósticos da Bota na sua Máquina Virtual e verifique se existem erros listadosneste artigo.

  1. Se a máquina virtual não tiver começado, tente falhar até um ponto de recuperação mais antigo.

  2. Se a aplicação dentro da máquina virtual não estiver em cima, tente falhar num ponto de recuperação consistente da aplicação.

  3. Se a máquina virtual estiver unida ao domínio, certifique-se de que o controlador de domínio está a funcionar com precisão. Isto pode ser feito seguindo os passos abaixo:

    a. Criar uma nova máquina virtual na mesma rede.

    b. Certifique-se de que é capaz de se juntar ao mesmo domínio em que se espera que a máquina virtual falhou.

    c. Se o controlador de domínio não estiver a funcionar com precisão, tente iniciar sessão na máquina virtual falhada utilizando uma conta de administrador local.

  4. Se estiver a utilizar um servidor DNS personalizado, certifique-se de que está acessível. Isto pode ser feito seguindo os passos abaixo:

    a. Criar uma nova máquina virtual na mesma rede e

    b. Verifique se a máquina virtual é capaz de fazer a resolução de nomes usando o servidor DNS personalizado

Nota

Permitir qualquer definição que não seja o Boot Diagnostics exigiria que o Agente VM do Azure fosse instalado na máquina virtual antes da falha.

Incapaz de abrir consola em série após falha de uma máquina baseada na UEFI em Azure

Se conseguir ligar-se à máquina utilizando RDP mas não conseguir abrir a consola em série, siga os passos abaixo:

  • Se a máquina OS for Red Hat ou Oracle Linux 7.*/8.0, executar o seguinte comando no Azure VM falhado com permissões de raiz. Reinicie o VM após o comando.

    grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg
    
  • Se a máquina OS for CentOS 7.*, executar o seguinte comando no Azure VM de failover com permissões de raiz. Reinicie o VM após o comando.

    grub2-mkconfig -o /boot/efi/EFI/centos/grub.cfg
    

Mensagem de encerramento inesperada (ID do evento 6008)

Ao iniciar um Windows falha do post VM, se receber uma mensagem de paragem inesperada no VM recuperado, indica que um estado de paragem VM não foi capturado no ponto de recuperação utilizado para o failover. Isto acontece quando se recupera a um ponto em que o VM não tinha sido totalmente desligado.

Isto normalmente não é motivo de preocupação e pode geralmente ser ignorado por falhas não planeadas. Se o failover for planeado, certifique-se de que o VM é corretamente desligado antes do failover e fornece tempo suficiente para que os dados de replicação pendentes no local sejam enviados para Azure. Em seguida, utilize a opção Mais recente no ecrã Failover de modo a que quaisquer dados pendentes sobre o Azure sejam processados num ponto de recuperação, que é depois utilizado para a falha de VM.

Não é possível selecionar a Datastore

Este problema é indicado quando não consegue ver a datastore em Azure o portal ao tentar reprotegir a máquina virtual que sofreu uma falha. Isto porque o alvo Master não é reconhecido como uma máquina virtual sob vCenters adicionados ao Azure Site Recovery.

Para obter mais informações sobre a reprotecção de uma máquina virtual, consulte Reprotect e falhe as máquinas traseiras para um local no local após a falha em Azure.

Para resolver o problema:

Crie manualmente o alvo Master no vCenter que gere a sua máquina de origem. A datastore estará disponível após a próxima descoberta do vCenter e atualização de operações de tecido.

Nota

As operações de tecido de descoberta e refrescação podem demorar até 30 minutos para ser concluída.

O registo linux Master Target com CS falha com um erro TLS 35

O registo Azure Site Recovery Master Target com o servidor de configuração falha devido à ativação do Proxy autenticado no Alvo Principal.

Este erro é indicado pelas seguintes cordas no registo de instalação:

RegisterHostStaticInfo encountered exception config/talwrapper.cpp(107)[post] CurlWrapper Post failed : server : 10.38.229.221, port : 443, phpUrl : request_handler.php, secure : true, ignoreCurlPartialError : false with error: [at curlwrapperlib/curlwrapper.cpp:processCurlResponse:231]   failed to post request: (35) - SSL connect error. 

Para resolver o problema:

  1. No servidor de configuração VM, abra um pedido de comando e verifique as definições de procuração utilizando os seguintes comandos:

    gato /etc/eco ambiente $http_proxy eco $https_proxy

  2. Se a saída dos comandos anteriores mostrar que as definições http_proxy ou https_proxy são definidas, utilize um dos seguintes métodos para desbloquear as comunicações Master Target com o servidor de configuração:

    • Descarregue a ferramenta PsExec.

    • Utilize a ferramenta para aceder ao contexto do utilizador do Sistema e determinar se o endereço de procuração está configurado.

    • Se o proxy estiver configurado, abra o IE num contexto de utilizador do sistema utilizando a ferramenta PsExec.

      psexec -s -i "%programfiles%\Internet Explorer\iexplore.exe"

    • Para garantir que o servidor alvo principal pode comunicar com o servidor de configuração:

      • Modifique as definições de procuração no Internet Explorer para contornar o endereço IP do servidor Master Target através do proxy.
        Ou
      • Desative o representante no servidor Target Principal.

Passos seguintes

Se precisar de mais ajuda, em seguida, publique a sua consulta na página de perguntas do Microsoft QA& para Site Recovery ou deixe um comentário no final deste documento. Temos uma comunidade ativa que deve ser capaz de ajudá-lo.