Solucionar erros ao fazer failover de VM VMWare ou de computador físico para o Azure

Artigo
09/10/2024

Você poderá receber um dos erros a seguir ao fazer failover de uma máquina virtual para o Azure. Para solucionar problemas, use as etapas descritas para cada condição de erro.

Falha no failover com a ID de Erro 28031

O Site Recovery não foi capaz de criar uma máquina virtual de failover no Azure. Isso pode ocorrer devido a um dos seguintes motivos:

Não há cota suficiente disponível para criar a máquina virtual: verifique a cota disponível acessando Assinatura -> Uso + cotas. Abra uma nova solicitação de suporte para aumentar a cota.
Você está tentando fazer failover em máquinas virtuais de famílias de tamanhos diferentes no mesmo conjunto de disponibilidade. Escolha a mesma família de tamanho para todas as máquinas virtuais no mesmo conjunto de disponibilidade. Altere o tamanho acessando as configurações de Computação da máquina virtual e, em seguida, repita o failover.
Há uma política na assinatura que impede a criação de uma máquina virtual. Altere a política para permitir a criação de uma máquina virtual e, em seguida, repita o failover.

Falha no failover com a ID de Erro 28092

O Site Recovery não pôde criar um adaptador de rede para a máquina virtual de failover. Verifique se você tem uma cota suficiente disponível para criar adaptadores de rede na assinatura. Verifique a cota disponível acessando Assinatura -> Uso + cotas. Abra uma nova solicitação de suporte para aumentar a cota. Se você tem uma cota suficiente, isso pode ser um problema intermitente. Repita a operação. Se o problema persistir mesmo após várias tentativas, deixe um comentário ao final deste documento.

Falha no failover com a ID de Erro 70038

O Site Recovery não foi capaz de criar uma máquina virtual clássica de failover no Azure. Isso pode ocorre 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 configurações de Rede da máquina virtual ou modifique a configuração para uma rede virtual que já existe e, em seguida, repita o failover.

Falha no failover com a ID de Erro 170010

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

Para exibir qualquer computador no Azure, o ambiente do Azure requer que alguns dos drivers em inicialização iniciem estado e serviços conforme o DHCP esteja no estado de inicialização automática. Assim, a atividade de hidratação, no momento do failover, converte o tipo de inicialização atapi, intelide, storflt, vmbus, and storvsc drivers para iniciar. Ele também converte o tipo de inicialização de alguns serviços, como o DHCP para iniciar automaticamente. Essa atividade pode falhar devido a problemas específicos do ambiente.

Para alterar manualmente o tipo de inicialização de drivers para o sistema operacional convidado do Windows, siga as etapas abaixo:

Baixar o script sem hidratação e executar conforme a seguir. Esse script verifica se a VM requer hidratação.

.\Script-no-hydration.ps1

Fornece o seguinte resultado se for necessária a hidratação:
```
REGISTRY::HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\storvsc           start =  3 expected value =  0

This system doesn't meet no-hydration requirement.
```
Caso a VM atenda ao requisito de sem-hidratação, o script fornecerá o resultado "Este sistema atende ao requisito de sem-hidratação". Nesse caso, todos os drivers e serviços estão no estado exigido pelo Azure e a hidratação na VM não é necessária.

Execute o script no-hydration-set da seguinte maneira se a VM não atender ao requisito de sem-hidratação.

.\Script-no-hydration.ps1 -set

Isso converte o tipo de inicialização dos drivers e fornecerá o resultado 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.

Falha de failover com um erro informando que a réplica dos endereços IP para o adaptador de rede da máquina virtual é inválido

A operação de failover de teste ou de failover pode falhar em um computador com o erro "Um ou mais endereços IP de réplica para o adaptador de rede da máquina virtual é inválido", se a limpeza adequada de uma operação de failover de teste anterior não tiver ocorrido. Devido a isso, o computador de teste ainda pode estar presente no ambiente do Azure e pode estar usando o mesmo endereço IP. Isso faz com que a configuração de destino da máquina virtual se torne crítica.

Para resolver esse problema, certifique-se de que uma limpeza completa do failover de teste tenha sido realizada para que a operação de failover ou failover de teste possa ser bem-sucedida.

Não é possível conectar/RDP/SSH para a máquina virtual com failover devido ao botão Conectar esmaecido na máquina virtual

Para obter instruções de solução de problemas detalhadas sobre problemas de RDP, consulte nossa documentação aqui.

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

Se o botão Conectar da VM de failover no Azure estiver esmaecido e você não estiver conectado ao Azure por meio de uma conexão VPN Site a Site ou do Express Route, então

Vá para Máquina Virtual>Rede e clique no nome da interface de rede necessária.
Navegue até Configurações de Ip e depois selecione o campo de nome da configuração de IP necessária.
Para habilitar o endereço IP público, selecione Habilitar.
Clique em Definir as configurações necessárias>Criar novo.
Insira o nome do endereço público, escolha as opções padrão para a SKU e atribuição, depois selecione OK.
Agora, para salvar as alterações feitas, selecione Salvar.
Feche os painéis e navegue até a seção Visão geral de máquina virtual para conectar-se/RDP.

Conectar/RDP/SSH está desabilitado - O botão VMConnect está disponível

Se o botão Conectar da VM com failover no Azure estiver disponível (não esmaecido), verifique o Diagnóstico de inicialização em sua máquina virtual e verifique se há erros conforme listado neste artigo.

Se a máquina virtual não tiver sido iniciada, tente fazer o failover para um ponto de recuperação mais antigo.
Se o aplicativo dentro da máquina virtual não responder, tente fazer o failover para um ponto de recuperação consistente com o aplicativo.
Se a máquina virtual estiver ingressada no domínio, verifique se esse controlador de domínio está funcionando corretamente. Isso pode ser feito seguindo as etapas fornecidas abaixo:

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

b. Certifique-se de que ele é capaz de se ingressar ao mesmo domínio no qual se espera que a máquina virtual de failover deve aparecer.

c. Se o controlador de domínio não estiver funcionando corretamente, tente fazer logon na máquina virtual com failover usando uma conta do administrador local.
Se você estiver usando um servidor DNS personalizado, então certifique-se de que ele está acessível. Isso pode ser feito seguindo as etapas fornecidas abaixo:

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

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

Observação

Habilitar qualquer configuração diferente do Diagnóstico de Inicialização exigiria um Agente de VM do Azure instalado na máquina virtual antes do failover

Não é possível abrir o console serial após o failover de um computador baseado em UEFI no Azure

Se você conseguir se conectar ao computador usando o RDP, mas não conseguir abrir o console serial, siga as etapas abaixo:

Se o sistema operacional do computador for Red Hat ou Oracle Linux 7.*/8.0, execute o comando a seguir na VM do Azure de failover com permissões de raiz. Reinicialize a VM após o comando.
```
grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg
```

Mensagem de desligamento inesperado (ID de evento 6008)

Ao inicializar uma VM do Windows após o failover, se você receber uma mensagem de desligamento inesperado na VM recuperada, isso indica que o estado de desligamento da VM não foi capturado no ponto de recuperação usado para o failover. Isso acontece quando você recupera para um ponto em que a VM não foi totalmente desligada.

Normalmente, isso não é motivo de preocupação e geralmente pode ser ignorado para failovers não planejados. Se o failover for planejado, verifique se a VM foi desligada corretamente antes do failover e forneça tempo suficiente para que os dados da replicação pendente localmente sejam enviados para o Azure. Em seguida, use a opção Mais recente na Tela de failover para que todos os dados pendentes no Azure sejam processados em um ponto de recuperação, que é usado para failover da VM.

Não é possível selecionar o armazenamento de dados

Esse problema é indicado quando você não consegue ver o armazenamento de dados no portal do Azure ao tentar proteger novamente a máquina virtual que passou por um failover. Isso ocorre porque o destino mestre não é reconhecido como uma máquina virtual nos vCenters adicionados ao Azure Site Recovery.

Para obter mais informações sobre como proteger novamente uma máquina virtual, confira Proteja novamente e execute o failback de computadores para um site local após o failover no Azure.

Como resolver o problema:

Crie manualmente o destino mestre no vCenter que gerencia o computador de origem. O armazenamento de dados estará disponível após as próximas operações de descoberta e atualização de malha do vCenter.

Observação

As operações de descoberta e atualização de malha podem levar até 30 minutos para serem concluídas.

O registro de destino mestre do Linux com o CS falha com um erro de TLS 35

O registro de destino mestre do Azure Site Recovery com o servidor de configuração falha devido ao proxy autenticado estar habilitado no destino mestre.

Esse erro é indicado pelas seguintes cadeias de caracteres no log 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.