Share via


Fel som ofta inträffar under migrering från klassisk till Azure Resource Manager

Gäller för: ✔️ Virtuella Linux-datorer ✔️, virtuella Windows-datorer

Viktigt!

Idag använder cirka 90 % av de virtuella IaaS-datorerna Azure Resource Manager. Från och med den 28 februari 2020 har klassiska virtuella datorer blivit inaktuella och kommer att dras tillbaka helt den 6 september 2023. Läs mer om den här utfasningen och hur den påverkar dig.

I den här artikeln visas vanliga fel och åtgärder under migrering av IaaS-resurser från Azures klassiska distributionsmodell till Azure Resource Manager-stacken.

Lista över fel

Felsträng Åtgärd
Internt serverfel I vissa fall är det här ett tillfälligt fel som försvinner vid ett nytt försök. Om felet kvarstår kan du kontakta Azure-supporten så att plattformsloggarna kan undersökas.

Obs! När incidenten spåras av supportteamet ska du inte försöka med någon självreducering eftersom det kan få oavsiktliga konsekvenser för din miljö.
Migrering stöds inte för distribution {deployment-name} i HostedService {hosted-service-name} eftersom det är en PaaS-distribution (Web/Worker). Det här inträffar när en distribution innehåller en web/worker-roll. Eftersom migrering endast stöds för virtuella datorer tar du bort webb-/arbetsrollen från distributionen och försöker migrera igen.
Det gick inte att distribuera mallen {template-name}. CorrelationId={guid} I serverdelen av migreringstjänsten använder vi Azure Resource Manager-mallar för att skapa resurser i Azure Resource Manager-stacken. Eftersom mallar är idempotenta kan du vanligtvis lugnt göra ett nytt migreringsförsök för att komma förbi felet. Om det här felet kvarstår kontaktar du Azure-supporten och ger dem CorrelationId.

Obs! När incidenten spåras av supportteamet ska du inte försöka med någon självreducering eftersom det kan få oavsiktliga konsekvenser för din miljö.
Det virtuella nätverket {virtual-network-name} finns inte. Det här kan inträffa om du har skapat det virtuella nätverket på nya Azure Portal. Det faktiska namnet på det virtuella nätverket följer mönstret "Grupp * <VNET-namn>"
Den virtuella datorn {vm-name} i HostedService {hosted-service-name} innehåller tillägget {extension-name} som inte stöds i Azure Resource Manager. Vi rekommenderar att du avinstallerar den från den virtuella datorn innan du fortsätter med migreringen. Obs! Felmeddelandet håller på att uppdateras. Framöver krävs det att tillägget avinstalleras innan XML-tillägg för migrering, till exempel BGInfo 1.* inte stöds i Azure Resource Manager. Därför kan dessa tillägg inte migreras.
Den virtuella datorn {vm-name} i HostedService {hosted-service-name} innehåller tillägget VMSnapshot/VMSnapshotLinux, som för närvarande inte stöds för migrering. Avinstallera det från den virtuella datorn och lägg tillbaka det via Azure Resource Manager när migreringen är klar I det här fallet är den virtuella datorn konfigurerad för Azure Backup. Eftersom detta för närvarande är ett scenario som inte stöds följer du lösningen på https://aka.ms/vmbackupmigration
Den virtuella datorn {vm-name} i HostedService {hosted-service-name} innehåller tillägget {extension-name} vars status inte rapporteras från den virtuella datorn. Därför kan den här virtuella datorn inte migreras. Se till att tilläggets status rapporteras eller avinstallera tillägget från den virtuella datorn och försök att migrera igen.

Den virtuella datorn {vm-name} i HostedService {hosted-service-name} innehåller tillägget {extension-name} som rapporterar hanterarstatus: {handler-status}. Därför kan den virtuella datorn inte migreras. Se till att tilläggets hanterarstatus som rapporteras är {handler-status} eller avinstallera det från den virtuella datorn och försök att migrera igen.

Den virtuella datoragenten för den virtuella datorn {vm-name} i HostedService {hosted-service-name} rapporterar övergripande agentstatus Inte redo. Den virtuella datorn kan därför inte migreras, om den har ett migreringsbart tillägg. Se till att den virtuella datoragenten rapporterar övergripande agentstatus Redo. https://aka.ms/classiciaasmigrationfaqsSe .
Azure-gästagenten och virtuella datortillägg måste ha utgående Internetåtkomst till den virtuella datorns lagringskonto för att kunna ange status. Vanliga orsaker till statusfel är
  • en nätverkssäkerhetsgrupp som blockerar utgående åtkomst till Internet
  • Om det virtuella nätverket har lokala DNS-servrar och DNS-anslutningen går förlorad

    Om en status som inte stöds fortsätter att visas kan du avinstallera tilläggen om du vill hoppa över kontrollen och gå vidare med migreringen.
  • Migrering stöds inte för distribution {deployment-name} i HostedService {hosted-service-name} eftersom den har flera tillgänglighetsuppsättningar. För närvarande går det bara att migrera värdbaserade tjänster med högst 1 tillgänglighetsuppsättning. Du kan undvika det här problemet genom att flytta de ytterligare tillgänglighetsuppsättningarna och virtuella datorer i dessa tillgänglighetsuppsättningar till en annan värdbaserad tjänst.
    Migrering stöds inte för distributionen {deployment-name} i HostedService {hosted-service-name eftersom den har virtuella datorer som inte ingår i tillgänglighetsuppsättningen trots att HostedService innehåller en. Lösningen i det här fallet är att flytta alla virtuella datorer till en enda tillgänglighetsuppsättning eller ta bort alla virtuella datorer från tillgänglighetsuppsättningen i den värdbaserade tjänsten.
    Kontot för lagring/HostedService/virtuellt nätverk {virtual-network-name} håller på att migreras och kan därför inte ändras Det här felet inträffar när migreringsåtgärden ”Förbered” har slutförts på resursen och en åtgärd som skulle ändra resursen aktiveras. Eftersom hanteringsplanet låses efter förberedelseåtgärden blockeras alla ändringar av resursen. Du kan låsa upp hanteringsplanet, köra en incheckningsåtgärd för att slutföra migreringen eller köra migreringsåtgärden Avbryt för att återställa förberedelseåtgärden.
    Migrering tillåts inte för HostedService {hosted-service-name} eftersom den har den virtuella datorn {vm-name} i tillstånd: RoleStateUnknown. Migrering tillåts bara när den virtuella datorn har följande status: körs, stoppad, stoppad frigjord. Den virtuella datorn kan genomgå en tillståndsövergång, vilket vanligtvis sker under en uppdateringsåtgärd på HostedService, till exempel en omstart, tilläggsinstallation osv. Vi rekommenderar att uppdateringsåtgärden slutförs på HostedService innan du provar migreringen.
    Distributionen {deployment-name} i HostedService {hosted-service-name} innehåller en virtuell dator {vm-name} med Data Disk {data-disk-name} vars fysiska blobstorlek {size-of-the-vhd-blob-backing-the-data-disk} bytes inte matchar den virtuella datorns datadisk logiska storlek {size-of-the-data-disk-specified-in-the-vm-api} bytes. Migreringen fortsätter utan att du anger en storlek för datadisken för den virtuella Azure Resource Manager-datorn. Felet kan inträffa om du har ändrat storlek på den virtuella hårddisk-blobben utan att uppdatera storleken på den virtuella dator API-modellen. Utförliga anvisningar för migrering hittar du nedan.
    Ett Storage-undantag uppstod under verifiering av datadisken {data disk name} med medielänken {data disk Uri} för den virtuella datorn {VM name} i molntjänsten {Cloud Service name}. Kontrollera att VHD-medielänken är tillgänglig för den här virtuella datorn Det här kan inträffa om den virtuella datorns diskar har tagits bort eller inte kan nås längre. Kontrollera att diskarna för den virtuella datorn finns.
    Den virtuella datorn {vm-name} i HostedService {cloud-service-name} innehåller Disk med MediaLink {vhd-uri} som har blobnamnet {vhd-blob-name} som inte stöds i Azure Resource Manager. Det här felet uppstår när namnet på blobben har ett "/" i den som för närvarande inte stöds i Compute Resource Provider.
    Migrering tillåts inte för distributionen {deployment-name} i HostedService {cloud-service-name} eftersom den inte finns i det regionala omfånget. Se för att https://aka.ms/regionalscope flytta den här distributionen till ett regionalt omfång. Azure meddelade 2014 att nätverksresurser skulle flyttas från klusternivå till regionalnivå. Mer https://aka.ms/regionalscope information finns i. Felet kan uppstå när den distribution som migreras inte har uppdaterats så att den automatiskt flyttas till ett regionalt omfång. Det bästa sättet är att antingen lägga till en slutpunkt till en virtuell dator eller en datadisk till den virtuella datorn och sedan försöka migrera igen.
    Se Konfigurera slutpunkter på en klassisk virtuell dator i Azure eller Koppla en datadisk till en virtuell dator som skapats med den klassiska distributionsmodellen
    Migrering stöds inte för det virtuella nätverket {vnet-name} eftersom det har paaS-distributioner som inte är gatewayer. Det här felet uppstår när du har paaS-distributioner som inte är gatewayer, till exempel Application Gateway eller API Management-tjänster som är anslutna till det virtuella nätverket.
    Hanteringsåtgärder på virtuella datorer tillåts inte eftersom migreringen pågår Det här felet beror på att den virtuella datorn är i tillståndet Förbered och därför låst för alla åtgärder för uppdatering/borttagning. Anropa Avbryt med PS/CLI på den virtuella datorn för att återställa migreringen och låsa upp den virtuella datorn för uppdaterings-/borttagningsåtgärder. Att anropa incheckningen låser också upp den virtuella datorn men genomför migreringen till ARM.

    Detaljerade åtgärder

    En virtuell dator med en datadisk vars fysiska blobbstorlek i byte inte stämmer med datadiskens logiska storlek i byte.

    Det här kan hända när datadiskens logiska storlek inte är synkroniserad med den faktiska blobbstorleken på den virtuella hårddisken. Det går lätt att kontrollera med följande kommandon:

    Kontrollera problemet

    # 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
    

    Åtgärda problemet

    # 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      
    

    Flytta en virtuell dator till en annan prenumeration efter slutförd migrering

    Efter en migrering vill du kanske flytta den virtuella datorn till en annan prenumeration. Men om det finns en hemlighet eller ett certifikat på den virtuella datorn som hänvisar till en Key Vault-resurs, finns det för närvarande inte stöd för en sådan flytt. Med anvisningarna nedan kan du kringgå problemet.

    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=[]
    

    Nästa steg