Fouten die zich vaak voordoen tijdens de migratie van klassiek naar Azure Resource Manager

Van toepassing op: ✔️ Virtuele Linux-machines ✔️ van Windows

Belangrijk

Tegenwoordig gebruiken ongeveer 90% van de IaaS-VM's Azure Resource Manager. Vanaf 28 februari 2020 zijn klassieke VM's afgeschaft en worden deze volledig buiten gebruik gesteld op 6 september 2023. Meer informatie over deze afschaffing en hoe dit van invloed is op u.

In dit artikel behandelen we de meest voorkomende fouten en oplossingen tijdens de migratie van IaaS-resources van het klassieke Azure-implementatiemodel naar de Azure Resource Manager-stack.

Lijst met fouten

Fouttekenreeks Oplossing
Interne serverfout In sommige gevallen is dit een tijdelijke fout die bij een nieuwe poging is verdwenen. Als deze fout zich blijft voordoen, neem dan contact op met de ondersteuning van Azure. De platformlogboeken moeten namelijk worden onderzocht.

OPMERKING: Zodra het incident is bijgehouden door het ondersteuningsteam, probeert u geen zelfbeperking uit te voeren, omdat dit onbedoelde gevolgen kan hebben voor uw omgeving.
Migratie wordt niet ondersteund voor implementatie {deployment-name} in HostedService {hosted-service-name} omdat het een PaaS-implementatie (Web/Worker) is. Dit gebeurt wanneer een implementatie een web-/werkrol bevat. Omdat migratie alleen wordt ondersteund voor virtuele machines, verwijdert u de web-/werkrol uit de implementatie en probeert u de migratie opnieuw.
Sjabloonimplementatie {sjabloonnaam} is mislukt. CorrelationId = {guid} In de back-end van de migratieservice gebruiken we Azure Resource Manager-sjablonen om resources te maken in de Azure Resource Manager-stack. Aangezien sjablonen idempotent zijn, kunt u de migratiebewerking meestal veilig opnieuw proberen om deze fout te verhelpen. Als deze fout zich blijft voordoen, neemt u contact op met ondersteuning voor Azure en geeft u deze de CorrelationId.

OPMERKING: Zodra het incident is bijgehouden door het ondersteuningsteam, probeert u geen zelfbeperking uit te voeren, omdat dit onbedoelde gevolgen kan hebben voor uw omgeving.
Het virtuele netwerk {virtual-network-name} bestaat niet. Dit kan gebeuren als u het virtuele netwerk hebt gemaakt in de nieuwe Azure portal. De werkelijke naam van het virtuele netwerk volgt het patroon 'Groep * <VNET-naam>'
VM {vm-name} in HostedService {hosted-service-name} bevat extensie {extension-name} die niet wordt ondersteund in Azure Resource Manager. Het is raadzaam deze te verwijderen van de VIRTUELE machine voordat u doorgaat met de migratie. OPMERKING: Foutbericht wordt verwerkt om bijgewerkt te worden. Het is vereist om de extensie te verwijderen voordat de XML-extensies voor migratie zoals BGInfo 1.* niet worden ondersteund in Azure Resource Manager. Daarom kunnen deze extensies niet worden gemigreerd.
VM {vm-naam} in HostedService {naam-gehoste-service} bevat de extensie VMSnapshot/VMSnapshotLinux. Deze wordt momenteel niet ondersteund voor migratie. Verwijder deze uit de virtuele machine en voeg de extensie opnieuw toe met Azure Resource Manager nadat de migratie is voltooid Dit is het scenario waarin de virtuele machine is geconfigureerd voor Azure Backup. Aangezien dit momenteel een niet-ondersteund scenario is, volgt u de tijdelijke oplossing op https://aka.ms/vmbackupmigration
VM {vm-name} in HostedService {hosted-service-name} bevat extensie {extension-name} waarvan de status niet wordt gerapporteerd van de VIRTUELE machine. Daarom kan deze VM niet worden gemigreerd. Zorg ervoor dat de status van de extensie wordt gerapporteerd of verwijder de extensie uit de virtuele machine en voer de migratie nogmaals uit.

VM {vm-naam} in HostedService {naam-gehoste-service} bevat de extensie {naam-extensie}. Deze rapporteert de volgende handlerstatus: {handlerstatus}. De VIRTUELE machine kan daarom niet worden gemigreerd. Zorg ervoor dat de status van de extensiehandler die wordt gerapporteerd {handlerstatus} is of verwijder de extensie uit de virtuele machine en voer de migratie nogmaals uit.

VM-agent voor de virtuele machine {vm-naam} in HostedService {naam-gehoste-service} rapporteert de algehele agentstatus Niet gereed. Daarom kan de virtuele machine niet worden gemigreerd, als deze een extensie heeft die kan worden gemigreerd. Zorg ervoor dat de VM-agent de algehele agentstatus Gereed rapporteert. https://aka.ms/classiciaasmigrationfaqsRaadpleeg .
De Azure-gastagent en VM-extensies hebben uitgaande internettoegang nodig tot het VM-opslagaccount om hun status te vullen. Veelvoorkomende oorzaken van statusfouten zijn
  • een netwerkbeveiligingsgroep die uitgaande toegang tot internet blokkeert
  • Als het VNET on-premises DNS-servers heeft en de DNS-connectiviteit is verbroken

    Als de melding dat een extensie niet wordt ondersteund nog steeds wordt weergegeven, kunt u de extensies verwijderen om deze controle over te slaan en verder te gaan met de migratie.
  • Migratie wordt niet ondersteund voor implementatie {deployment-name} in HostedService {hosted-service-name} omdat deze meerdere beschikbaarheidssets heeft. Op dit moment kunnen alleen gehoste services die maximaal één beschikbaarheidsset hebben worden gemigreerd. Als u dit probleem wilt omzeilen, verplaatst u de extra beschikbaarheidssets en virtuele machines in die beschikbaarheidssets naar een andere gehoste service.
    Migratie wordt niet ondersteund voor implementatie {deployment-name} in HostedService {hosted-service-name omdat deze VM's bevat die geen deel uitmaken van de beschikbaarheidsset, ook al bevat de HostedService er een. De tijdelijke oplossing voor dit scenario is om alle virtuele machines te verplaatsen naar een enkele beschikbaarheidsset. U kunt ook alle virtuele machines verwijderen uit de beschikbaarheidsset in de gehoste service.
    Opslagaccount/HostedService/virtueel netwerk {naam-virtueel-netwerk} wordt gemigreerd en kan daarom niet worden gewijzigd Deze fout treedt op wanneer de migratiebewerking 'Voorbereiden' is voltooid op de resource en een bewerking die een wijziging aanbrengt in de resource wordt geactiveerd. Vanwege de vergrendeling op het beheervlak na de bewerking 'Voorbereiden' worden eventuele wijzigingen in de resource geblokkeerd. Als u het beheervlak wilt ontgrendelen, kunt u de migratiebewerking 'Doorvoeren' uitvoeren om de migratie te voltooien. U kunt ook de migratiebewerking 'Afbreken' uitvoeren om de bewerking 'Voorbereiden' terug te draaien.
    Migratie is niet toegestaan voor HostedService {hosted-service-name} omdat deze VM {vm-name} in state heeft: RoleStateUnknown. Migratie is alleen toegestaan wanneer de VM zich in een van de volgende statussen bevindt: Wordt uitgevoerd, Gestopt, Gestopt (toewijzing opgeheven). De VM kan worden uitgevoerd via een statusovergang, wat meestal gebeurt tijdens een updatebewerking op de HostedService, zoals opnieuw opstarten, extensie-installatie, enzovoort. Het wordt aanbevolen om de updatebewerking te voltooien op de HostedService voordat u de migratie probeert uit te voeren.
    Implementatie {deployment-name} in HostedService {hosted-service-name} bevat een VM {vm-name} met gegevensschijf {data-disk-name} waarvan de fysieke blobgrootte {grootte-van-de-vhd-blob-backing-the-data-disk} bytes niet overeenkomt met de logische grootte van de logische VM-gegevensschijf {grootte-van-de-data-disk-specified-in-the-vm-api} bytes. De migratie wordt voortgezet zonder dat er een grootte wordt opgeven voor de gegevensschijf voor de Azure Resource Manager-VM. Deze fout treedt op als u de grootte van de VHD-blob hebt gewijzigd zonder de grootte in het API-model van de VM te wijzigen. Gedetailleerde stappen worden hieronder beschreven.
    Er is een opslaguitzondering opgetreden tijdens het valideren van de gegevensschijf {naam-gegevensschijf} met de medialink {Uri-gegevensschijf} voor de virtuele machine {VM-naam} in de cloudservice {naam-cloudservice}. Zorg ervoor dat de VHD-mediakoppeling toegankelijk is voor deze virtuele machine Deze fout kan optreden als de schijven van de virtuele machine zijn verwijderd of niet meer toegankelijk zijn. Zorg ervoor dat de schijven voor de virtuele machine bestaan.
    VM {vm-name} in HostedService {cloud-service-name} bevat schijf met MediaLink {vhd-uri} met blobnaam {vhd-blob-name} die niet wordt ondersteund in Azure Resource Manager. Deze fout treedt op wanneer de naam van de blob een '/' bevat die momenteel niet wordt ondersteund in de compute-resourceprovider.
    Migratie is niet toegestaan voor implementatie {deployment-name} in HostedService {cloud-service-name} omdat deze zich niet in het regionale bereik bevindt. Raadpleeg voor https://aka.ms/regionalscope het verplaatsen van deze implementatie naar regionaal bereik. In 2014 heeft Azure aangekondigd dat netwerkresources worden verplaatst van een clusterbereik naar een regionaal bereik. Zie https://aka.ms/regionalscope voor meer informatie. Deze fout treedt op wanneer de implementatie die wordt gemigreerd geen updatebewerking heeft gehad, waarmee de implementatie automatisch naar een regionaal bereik wordt verplaatst. Het beste is om een eindpunt toe te voegen aan een virtuele machine of een gegevensschijf aan de virtuele machine en vervolgens de migratie opnieuw uit te voeren.
    Zie Eindpunten instellen op een klassieke virtuele machine in Azure of een gegevensschijf koppelen aan een virtuele machine die is gemaakt met het klassieke implementatiemodel
    Migratie wordt niet ondersteund voor Virtual Network {vnet-name} omdat deze niet-gateway PaaS-implementaties heeft. Deze fout treedt op wanneer u niet-gateway PaaS-implementaties hebt, zoals Application Gateway- of API Management-services die zijn verbonden met het virtuele netwerk.
    Beheerbewerkingen op vm zijn niet toegestaan omdat de migratie wordt uitgevoerd Deze fout treedt op omdat de VM de status Voorbereiden heeft en daarom is vergrendeld voor elke update-/verwijderbewerking. Roep Afgebroken aan met ps/CLI op de virtuele machine om de migratie terug te draaien en de VM te ontgrendelen voor update-/verwijderbewerkingen. Door doorvoeren aan te roepen wordt ook de virtuele machine ontgrendeld, maar wordt de migratie naar ARM doorgevoerd.

    Gedetailleerde oplossingen

    Virtuele machine met gegevensschijf waarvan de fysieke blobgrootte in bytes niet overeenkomt met de logische grootte van de VM-gegevensschijf in bytes.

    Dit gebeurt wanneer de logische grootte van de gegevensschijf asynchroon kan lopen met de werkelijke grootte van de VHD-blob. Dit u kunt eenvoudig controleren met de volgende opdrachten:

    Het probleem verifiëren

    # 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
    

    Het probleem oplossen

    # 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      
    

    Een virtuele machine verplaatsen naar een ander abonnement nadat de migratie is voltooid

    Nadat u het migratieproces hebt voltooit, wilt u de virtuele machine mogelijk verplaatsen naar een ander abonnement. De verplaatsing wordt momenteel echter niet ondersteund als u een geheim/certificaat hebt op de virtuele machine die verwijst naar een Key Vault-resource. Met de onderstaande instructies kunt u het probleem omzeilen.

    PowerShell

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

    Azure-CLI

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

    Volgende stappen