Partilhar via


Erros que ocorrem frequentemente durante a migração da implementação Clássica para o Azure Resource Manager

Aplica-se a: ✔️ VMs Linux VMs ✔️ Windows

Importante

Atualmente, cerca de 90% das VMs IaaS estão usando o Azure Resource Manager. A partir de 28 de fevereiro de 2020, as VMs clássicas foram preteridas e serão totalmente desativadas em 6 de setembro de 2023. Saiba mais sobre essa depreciação e como ela afeta você.

Este artigo cataloga os erros e mitigações mais comuns durante a migração de recursos de IaaS do modelo de implementação clássica do Azure para a pilha do Azure Resource Manager.

Lista de erros

Cadeia do erro Mitigação
Erro de servidor interno Em alguns casos, este é um erro transitório que desaparece com uma nova tentativa. Se persistir, contacte o suporte do Azure, pois requer que sejam investigados os registos da plataforma.

NOTA: Depois que o incidente for rastreado pela equipe de suporte, não tente nenhuma automitigação, pois isso pode ter consequências não intencionais em seu ambiente.
A migração não é suportada para Deployment {deployment-name} em HostedService {hosted-service-name} porque é uma implantação PaaS (Web/Worker). Isto acontece quando uma implementação contém uma função da Web/trabalho. Como a migração só é suportada para Máquinas Virtuais, remova a função Web/trabalhador da implantação e tente migrar novamente.
Falha na implementação de modelo {template-name}. CorrelationId={guid} No back-end do serviço de migração, utilizamos modelos do Azure Resource Manager para criar recursos na pilha do Azure Resource Manager. Uma vez que os modelos são idempotent, pode, normalmente, repetir a operação de migração em segurança para ultrapassar este erro. Se esse erro continuar a persistir, entre em contato com o suporte do Azure e forneça a CorrelationId.

NOTA: Depois que o incidente for rastreado pela equipe de suporte, não tente nenhuma automitigação, pois isso pode ter consequências não intencionais em seu ambiente.
A rede virtual {virtual-network-name} não existe. Isto pode acontecer se tiver criado a Rede Virtual no novo portal do Azure. O nome real da Rede Virtual segue o padrão "Grupo * <Nome> VNET"
VM {vm-name} em HostedService {hosted-service-name} contém a Extensão {extension-name} que não é suportada no Azure Resource Manager. É recomendável desinstalá-lo da VM antes de continuar com a migração. NOTA: A mensagem de erro está em processo de atualização, avançando é necessário desinstalar a extensão antes que as extensões XML de migração , como BGInfo 1.*, não sejam suportadas no Azure Resource Manager. Portanto, essas extensões não podem ser migradas.
A VM {vm-name} em HostedService {hosted-service-name} contém a Extensão VMSnapshot/VMSnapshotLinux, que não é suportada, atualmente, para Migração. Desinstale-a da VM e adicione-a novamente com o Azure Resource Manager após a Conclusão da Migração. Este é o cenário em que a máquina virtual está configurada para o Azure Backup. Como esse é atualmente um cenário sem suporte, siga a solução alternativa em https://aka.ms/vmbackupmigration
VM {vm-name} em HostedService {hosted-service-name} contém Extension {extension-name} cujo Status não está sendo relatado da VM. Portanto, essa VM não pode ser migrada. Verifique se o estado da Extensão é reportado ou desinstale-a da VM e repita a migração.

A VM {vm-name} em HostedService {hosted-service-name} contém a Extensão {extension-name}, que reporta o Estado do Processador: {handler-status}. Portanto, a VM não pode ser migrada. Verifique se o estado do processador da Extensão reportado é {handler-status} ou desinstale-a da VM e repita a migração.

O Agente da VM para a VM {vm-name} em HostedService {hosted-service-name} está a reportar o estado do agente geral como Não Pronto. Por conseguinte, a VM pode não ser migrada, se tiver uma extensão que pode ser migrada. Confirme que o estado do agente geral que o Agente da VM está a reportar é Pronto. Consulte https://aka.ms/classiciaasmigrationfaqs.
O agente convidado do Azure e as Extensões da VM precisam de acesso de saída à Internet para a conta de armazenamento do Azure para preencher o respetivo estado. As causas comuns de falha de status incluem
  • um Grupo de Segurança de Rede que bloqueia o acesso de saída à Internet
  • Se a VNET tiver servidores DNS locais e a conectividade DNS for perdida

    Se continuar a ver um estado não suportado, pode desinstalar as extensões para ignorar esta verificação e avançar com a migração.
  • A migração não é suportada para Deployment {deployment-name} em HostedService {hosted-service-name} porque tem vários Conjuntos de Disponibilidades. Atualmente, só podem ser migrados serviços alojados que tenham um ou menos Conjuntos de Disponibilidade. Para contornar esse problema, mova os conjuntos de disponibilidade adicionais e máquinas virtuais nesses conjuntos de disponibilidade, para um serviço hospedado diferente.
    A migração não é suportada para Deployment {deployment-name} em HostedService {hosted-service-name porque tem VMs que não fazem parte do Conjunto de Disponibilidade, mesmo que o HostedService contenha uma. A solução para este cenário é mover todas as máquinas virtuais para um único Conjunto de Disponibilidade ou removê-las todas do Conjunto de Disponibilidade no serviço alojado.
    O Serviço Alojado/a Conta de armazenamento/a Rede Virtual {virtual-network-name} está no processo de migração, pelo que não pode ser alterado. Este erro acontece quando a operação de migração “Preparar” é concluída no recurso e uma operação que faria uma alteração ao mesmo é acionada. Devido ao bloqueio no plano de gestão após a operação “Preparar”, todas as alterações ao recurso são bloqueadas. Para desbloquear o plano de gestão, pode executar a operação de migração “Consolidar”, para concluir a migração, ou “Abortar” a mesma, para reverter a operação “Preparar”.
    A migração não é permitida para HostedService {hosted-service-name} porque tem VM {vm-name} em State: RoleStateUnknown. A migração só é permitida se a VM estiver num dos estados seguintes - Em Execução, Parada, Parada (Desalocada). A VM pode estar passando por uma transição de estado, o que geralmente acontece durante uma operação de atualização no HostedService, como uma reinicialização, instalação de extensão, etc. É recomendável que a operação de atualização seja concluída no HostedService antes de tentar a migração.
    Deployment {deployment-name} em HostedService {hosted-service-name} contém uma VM {vm-name} com Data Disk {data-disk-name} cujo tamanho de blob físico {size-of-the-vhd-blob-backing-the-data-disk} bytes não corresponde ao tamanho lógico do VM Data Disk {size-of-the-data-disk-specified-in-the-vm-api} bytes. A migração prossegue sem especificar um tamanho para o disco de dados da VM do Azure Resource Manager. Este erro acontece se tiver redimensionado o blob do VHD sem atualizar o tamanho no modelo da API da VM. Os passos de mitigação detalhados estão descritos abaixo.
    Ocorreu uma exceção de armazenamento ao validar o disco de dados {data disk name} com a ligação de multimédia {data disk Uri} para a VM {VM name} no Serviço Cloud {Cloud Service name}. Verifique se o link de mídia VHD está acessível para essa máquina virtual Este erro pode acontecer se os discos da VM tiverem sido eliminados ou já não estiverem acessíveis. Verifique se os discos da VM existem.
    VM {vm-name} em HostedService {cloud-service-name} contém Disco com MediaLink {vhd-uri} que tem blob name {vhd-blob-name} que não é suportado no Azure Resource Manager. Este erro ocorre quando o nome do blob tem um "/" que não é suportado no Compute Resource Provider atualmente.
    A migração não é permitida para Deployment {deployment-name} em HostedService {cloud-service-name}, pois não está no escopo regional. Consulte para https://aka.ms/regionalscope mover essa implantação para o escopo regional. Em 2014, o Azure anunciou que os recursos de rede vão passar de um âmbito de nível de cluster para o âmbito regional. Consulte https://aka.ms/regionalscope para obter mais detalhes. Este erro ocorre se a implementação que está a ser migrada não tiver tido uma operação de atualização, o que a move automaticamente para um âmbito regional. A melhor solução é adicionar um ponto de extremidade a uma VM ou um disco de dados à VM e, em seguida, tentar migrar novamente.
    Consulte Como configurar pontos de extremidade em uma máquina virtual clássica no Azure ou Anexar um disco de dados a uma máquina virtual criada com o modelo de implantação clássico
    A migração não é suportada para a Rede Virtual {vnet-name} porque tem implantações PaaS que não são de gateway. Este erro ocorre quando você tem implantações de PaaS que não são de gateway, como o Application Gateway ou serviços de gerenciamento de API que estão conectados à rede virtual.
    As operações de gerenciamento na VM não são permitidas porque a migração está em andamento Este erro ocorre porque a VM está no estado Preparar e, portanto, bloqueada para qualquer operação de atualização/exclusão. Chame Abortar usando PS/CLI na VM para reverter a migração e desbloquear a VM para operações de atualização/exclusão. Chamar a confirmação também desbloqueará a VM, mas confirmará a migração para o ARM.

    Mitigações detalhadas

    VM com Disco de Dados cujos bytes de tamanho físico do blob não correspondem aos bytes do tamanho lógico do Disco de Dados da VM.

    Isto acontece se o tamanho lógico do Disco de Dados ficar dessincronizado com o tamanho real do blob do VHG. Pode utilizar os comandos seguintes para verificar este problema:

    Verificar o problema

    # Store the VM details in the VM object
    $vm = Get-AzureVM -ServiceName $servicename -Name $vmname
    
    # Display the data disk properties
    # NOTE the data disk LogicalDiskSizeInGB below which is 11GB. Also note the MediaLink Uri of the VHD blob as we'll use this in the next step
    $vm.VM.DataVirtualHardDisks
    
    
    HostCaching         : None
    DiskLabel           : 
    DiskName            : coreosvm-coreosvm-0-201611230636240687
    Lun                 : 0
    LogicalDiskSizeInGB : 11
    MediaLink           : https://contosostorage.blob.core.windows.net/vhds/coreosvm-dd1.vhd
    SourceMediaLink     : 
    IOType              : Standard
    ExtensionData       : 
    
    # Now get the properties of the blob backing the data disk above
    # NOTE the size of the blob is about 15 GB which is different from LogicalDiskSizeInGB above
    $blob = Get-AzStorageblob -Blob "coreosvm-dd1.vhd" -Container vhds 
    
    $blob
    
    ICloudBlob        : Microsoft.WindowsAzure.Storage.Blob.CloudPageBlob
    BlobType          : PageBlob
    Length            : 16106127872
    ContentType       : application/octet-stream
    LastModified      : 11/23/2016 7:16:22 AM +00:00
    SnapshotTime      : 
    ContinuationToken : 
    Context           : Microsoft.WindowsAzure.Commands.Common.Storage.AzureStorageContext
    Name              : coreosvm-dd1.vhd
    

    Mitigar o problema

    # Convert the blob size in bytes to GB into a variable which we'll use later
    $newSize = [int]($blob.Length / 1GB)
    
    # See the calculated size in GB
    $newSize
    
    15
    
    # Store the disk name of the data disk as we'll use this to identify the disk to be updated
    $diskName = $vm.VM.DataVirtualHardDisks[0].DiskName
    
    # Identify the LUN of the data disk to remove
    $lunToRemove = $vm.VM.DataVirtualHardDisks[0].Lun
    
    # Now remove the data disk from the VM so that the disk isn't leased by the VM and it's size can be updated
    Remove-AzureDataDisk -LUN $lunToRemove -VM $vm | Update-AzureVm -Name $vmname -ServiceName $servicename
    
    OperationDescription OperationId                          OperationStatus
    -------------------- -----------                          ---------------
    Update-AzureVM       213xx1-b44b-1v6n-23gg-591f2a13cd16   Succeeded  
    
    # Verify we have the right disk that's going to be updated
    Get-AzureDisk -DiskName $diskName
    
    AffinityGroup        : 
    AttachedTo           : 
    IsCorrupted          : False
    Label                : 
    Location             : East US
    DiskSizeInGB         : 11
    MediaLink            : https://contosostorage.blob.core.windows.net/vhds/coreosvm-dd1.vhd
    DiskName             : coreosvm-coreosvm-0-201611230636240687
    SourceImageName      : 
    OS                   : 
    IOType               : Standard
    OperationDescription : Get-AzureDisk
    OperationId          : 0c56a2b7-a325-123b-7043-74c27d5a61fd
    OperationStatus      : Succeeded
    
    # Now update the disk to the new size
    Update-AzureDisk -DiskName $diskName -ResizedSizeInGB $newSize -Label $diskName
    
    OperationDescription OperationId                          OperationStatus
    -------------------- -----------                          ---------------
    Update-AzureDisk     cv134b65-1b6n-8908-abuo-ce9e395ac3e7 Succeeded 
    
    # Now verify that the "DiskSizeInGB" property of the disk matches the size of the blob 
    Get-AzureDisk -DiskName $diskName
    
    
    AffinityGroup        : 
    AttachedTo           : 
    IsCorrupted          : False
    Label                : coreosvm-coreosvm-0-201611230636240687
    Location             : East US
    DiskSizeInGB         : 15
    MediaLink            : https://contosostorage.blob.core.windows.net/vhds/coreosvm-dd1.vhd
    DiskName             : coreosvm-coreosvm-0-201611230636240687
    SourceImageName      : 
    OS                   : 
    IOType               : Standard
    OperationDescription : Get-AzureDisk
    OperationId          : 1v53bde5-cv56-5621-9078-16b9c8a0bad2
    OperationStatus      : Succeeded
    
    # Now we'll add the disk back to the VM as a data disk. First we need to get an updated VM object
    $vm = Get-AzureVM -ServiceName $servicename -Name $vmname
    
    Add-AzureDataDisk -Import -DiskName $diskName -LUN 0 -VM $vm -HostCaching ReadWrite | Update-AzureVm -Name $vmname -ServiceName $servicename
    
    OperationDescription OperationId                          OperationStatus
    -------------------- -----------                          ---------------
    Update-AzureVM       b0ad3d4c-4v68-45vb-xxc1-134fd010d0f8 Succeeded      
    

    Mover uma VM para outra subscrição depois de concluir a migração

    Depois de concluir o processo de migração, poderá querer mover a VM para outra subscrição. No entanto, se tiver um segredo/certificado na VM que faça referência a um recurso do Key Vault, a mudança não é atualmente suportada. As instruções abaixo permitirão que você contorne o problema.

    PowerShell

    $vm = Get-AzVM -ResourceGroupName "MyRG" -Name "MyVM"
    Remove-AzVMSecret -VM $vm
    Update-AzVM -ResourceGroupName "MyRG" -VM $vm
    

    CLI do Azure

    az vm update -g "myrg" -n "myvm" --set osProfile.Secrets=[]
    

    Próximos passos