Ошибки, которые часто возникают при переносе из классической модели в Azure Resource Manager

  • Статья

Область применения: ✔️ Виртуальные машины Linux ✔️ Виртуальные машины Windows

Важно!

Сегодня примерно на 90 % виртуальных машин IaaS используется служба Azure Resource Manager. По состоянию на 28 февраля 2020 г. классические виртуальные машины устарели и будут полностью прекращены 6 сентября 2023 г. Узнайте больше об этом устаревании и о том, как оно влияет на вас.

В этой статье перечислены самые распространенные ошибки при переносе ресурсов IaaS из классической модели развертывания Azure в стек Azure Resource Manager, а также способы их устранения.

Список ошибок

Строка ошибки Исправление
Внутренняя ошибка сервера В некоторых случаях это временная ошибка, которая исчезает после повторной попытки. Если она не исчезает, обратитесь в службу поддержки Azure, так как в этом случае требуется исследование журналов платформы.

ПРИМЕЧАНИЕ. Как только инцидент отслеживается группой поддержки, не пытайтесь выполнить самостоятельное устранение рисков, так как это может привести к непредвиденным последствиям для вашей среды.
Миграция не поддерживается для развертывания {deployment-name} в размещенной службе {hosted-service-name}, так как это развертывание PaaS (веб-роль или рабочая роль). Это происходит, если развертывание содержит веб-роль или рабочую роль. Так как миграция поддерживается только для Виртуальные машины, удалите веб-или рабочую роль из развертывания и повторите попытку миграции.
Не удалось выполнить развертывание шаблона {template-name}. CorrelationId={guid} В серверной части службы миграции мы используем шаблоны Azure Resource Manager для создания ресурсов в стеке Azure Resource Manager. Так как шаблоны являются идемпотентными, обычно можно безопасно повторить операцию миграции для устранения этой ошибки. Если эта ошибка продолжает сохраняться, обратитесь к поддержка Azure и присвойте ему Идентификатор корреляции.

ПРИМЕЧАНИЕ. Как только инцидент отслеживается группой поддержки, не пытайтесь выполнить самостоятельное устранение рисков, так как это может привести к непредвиденным последствиям для вашей среды.
Виртуальная сеть {virtual-network-name} не существует. Это может произойти, если вы создали виртуальную сеть на новом портале Azure. Настоящее имя виртуальной сети соответствует шаблону "группа * <имя виртуальной сети>".
Виртуальная машина {vm-name} в размещенной службе {hosted-service-name} содержит расширение {extension-name}, которое не поддерживается в Azure Resource Manager. Рекомендуется удалить его из виртуальной машины перед продолжением миграции. ПРИМЕЧАНИЕ. Сообщение об ошибке находится в процессе обновления, передвигаясь вперед, необходимо удалить расширение, прежде чем расширения XML миграции , такие как BGInfo 1.*, не поддерживаются в Azure Resource Manager. Это означает, что их невозможно перенести.
Виртуальная машина {vm-name} в размещенной службе {hosted-service-name} содержит расширение VMSnapshot или VMSnapshotLinux, которое сейчас не поддерживается для миграции. Удалите его с виртуальной машины и добавьте снова с помощью Azure Resource Manager после завершения миграции. В этом сценарии виртуальная машина настроена для службы архивации Azure. Так как в настоящее время это неподдерживаемый сценарий, выполните обходное решение по адресу https://aka.ms/vmbackupmigration
Виртуальная машина {vm-name} в размещенной службе {hosted-service-name} содержит расширение {extension-name}, о состоянии которого она не сообщает. Поэтому виртуальную машину нельзя перенести. Убедитесь, что о состоянии расширения сообщается, или удалите расширение с виртуальной машины и повторите миграцию.

Виртуальная машина {vm-name} в размещенной службе {hosted-service-name} содержит расширение {extension-name}, сообщающее о состоянии обработчика: {handler-status}. Поэтому виртуальную машину нельзя перенести. Убедитесь, что сообщаемое состояние обработчика — {handler-status}, или удалите расширение с виртуальной машины и повторите миграцию.

Агент виртуальной машины {vm-name} в размещенной службе {hosted-service-name} сообщает, что общее состояние агента — Not Ready. Таким образом виртуальную машину невозможно перенести, если она содержит расширение, которое можно перенести. Убедитесь, что агент виртуальной машины сообщает о том, что общее состояние агента — Ready. См. https://aka.ms/classiciaasmigrationfaqs.		 Гостевому агенту Azure и расширениям виртуальных машин требуется исходящий доступ к Интернету для учетной записи хранения виртуальной машины, чтобы заполнить данные о состоянии. Распространенные причины сбоя состояния:
  • Группа безопасности сети, которая блокирует исходящий доступ к Интернету
  • Если виртуальная сеть имеет локальные DNS-серверы и dns-подключение теряется

    Если сообщение о неподдерживаемом состоянии не исчезнет, можно удалить расширения, чтобы пропустить эту проверку и перейти к миграции.
    		•
    Миграция недоступна для развертывания {deployment-name} в размещенной службе {hosted-service-name}, так как она затрагивает несколько наборов доступности. В настоящее время можно перенести только размещенные службы с одной и менее группами доступности. Чтобы обойти эту проблему, перенесите дополнительные группы доступности и виртуальные машины в этих группах доступности в другую размещенную службу.
    Миграция не поддерживается для развертывания {deployment-name} в размещенной службе {hosted-service-name}, так как она содержит виртуальные машины, которые не входят в группу доступности, но содержатся в размещенной службе. В этом сценарии нужно переместить все виртуальные машины в одну группу доступности или удалить их из группы доступности в размещенной службе.
    Учетная запись хранения, размещенная служба или виртуальная сеть {virtual-network-name} переносится и поэтому ее невозможно изменить. Эта ошибка возникает, после завершения операции подготовки к миграции для ресурса и инициации операции изменения ресурса. Так как плоскость управления блокируется после операции подготовки, любые изменения ресурса также блокируются. Чтобы разблокировать плоскость управления, можно запустить операцию фиксации миграции, чтобы завершить ее, или прерывания, чтобы сделать откат операции подготовки.
    Миграция запрещена для размещенной службы {размещенных service-name}, так как она содержит виртуальную машину {vm-name} в состоянии RoleStateUnknown. Миграцию можно выполнить, только если виртуальная машина находится в одном из следующих состояний: Running, Stopped, Stopped Deallocated. Виртуальная машина может находиться в процессе изменения состояния. Это обычно происходит при выполнении операций обновления для размещенной службы, таких как перезагрузка, установка расширения и т. д. Мы рекомендуем перед переносом завершить операцию обновления для размещенной службы.
    Развертывание {deployment-name} в размещенной службе {hosted-service-name} содержит виртуальную машину {vm-name} с диском данных {data-disk-name}, у которого физический размер большого двоичного объекта {size-of-the-vhd-blob-backing-the-data-disk} в байтах не соответствует логическому размеру диска данных виртуальной машины {size-of-the-data-disk-specified-in-the-vm-api}. Миграция будет выполнена без указания размера диска данных для виртуальной машины Azure Resource Manager. Эта ошибка возникает, если размер большого двоичного объекта VHD изменяется без обновления размера в модели API виртуальной машины. Подробное описание шагов по устранению этой ошибки приводится ниже.
    При проверке диска данных {имя диска данных} возникло исключение хранилища: ссылка на носитель {универсальный код ресурса (URI) диска данных} виртуальной машины {имя виртуальной машины} в облачной службе {имя облачной службы}. Убедитесь, что ссылка на носитель VHD доступна для этой виртуальной машины. Эта ошибка может произойти, если диски виртуальной машины были удалены или больше недоступны. Убедитесь, что диски виртуальной машины существуют.
    Виртуальная машина {vm-name} в HostedService {cloud-service-name} содержит диск с MediaLink {vhd-uri} с именем BLOB-объекта {vhd-blob-name}, которое не поддерживается в Azure Resource Manager. Эта ошибка возникает, когда имя большого двоичного объекта содержит символ "/", который в настоящее время не поддерживается поставщиком вычислительных ресурсов.
    Миграция запрещена для развертывания {deployment-name} в размещенной службе {cloud-service-name}, так как она не входит в область для региона. См. сведения о https://aka.ms/regionalscope перемещении этого развертывания в региональные область. В 2014 г. было объявлено, что сетевые ресурсы в Azure будут перемещены из области работ для кластера на региональный уровень. Дополнительные сведения см. в статье https://aka.ms/regionalscope. Эта ошибка возникает при миграции развертывания без выполнения обновления, которое автоматически перемещает такое развертывание в область для региона. Лучшим решением будет добавить для виртуальной машины конечную точку или диск данных, а затем повторить миграцию.
    Дополнительные сведения см. в статьях Как настроить конечные точки в классической виртуальной машине в Azure и Как присоединить диск данных к виртуальной машине, созданной по классической модели развертывания.
    Миграция не поддерживается для виртуальной сети {vnet-name}, так как она включает в себя развертывания PaaS без шлюза. Эта ошибка возникает при наличии развертываний PaaS без шлюза, например шлюза приложений или служб управления API, которые подключены к виртуальной сети.
    Операции управления на виртуальной машине запрещены, так как выполняется миграция Эта ошибка возникает из-за того, что виртуальная машина находится в состоянии подготовки и, следовательно, заблокирована для любой операции обновления или удаления. Вызов прерывания с помощью PS/CLI на виртуальной машине для отката миграции и разблокировки виртуальной машины для операций обновления и удаления. Вызов Commit также снимет блокировку виртуальной машина, но зафиксирует миграцию в ARM.

    Подробные инструкции по устранению

    Виртуальная машина с диском данных, у которого физический размер большого двоичного объекта в байтах не соответствует логическому размеру диска данных виртуальной машины.

    Это может произойти, когда нарушается синхронизация логического размера диска данных с фактическим размером большого двоичного объекта VHD. Это можно легко проверить с помощью следующих команд:

    Проверка наличия проблемы

    # 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

    Устранение проблемы

    # 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

    Перемещение виртуальной машины в другую подписку после миграции

    Возможно, после завершения миграции вы решите переместить виртуальную машину в другую подписку. Тем не менее, если на виртуальной машине имеется секрет или ключ, который ссылается на ресурс Key Vault, то переместить ее в настоящее время не удастся. Ниже приведены инструкции, позволяющие обойти эту проблему.

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

    Следующие шаги