Поделиться через

Troubleshooting Azure Windows VM extension failures

  • Статья

Общие сведения о шаблонах диспетчера ресурсов Azure

Шаблон Azure Resource Manager позволяет декларативно задать инфраструктуру IaaS Azure на языке JSON, установив зависимости между ресурсами.

Дополнительные сведения см. в статье о разработке шаблонов для использования расширений.

В этой статье вы узнаете, как устранять некоторые распространенные сбои в расширении виртуальной машины.

Просмотр состояния расширения

Шаблоны Azure Resource Manager можно выполнять из Azure PowerShell. После выполнения шаблона состояние расширения можно узнать в обозревателе ресурсов Azure или с помощью программ командной строки.

Приведем пример:

Azure PowerShell:

Get-AzVM -ResourceGroupName $RGName -Name $vmName -Status

Пример выходных данных:

Extensions:  {
  "ExtensionType": "Microsoft.Compute.CustomScriptExtension",
  "Name": "myCustomScriptExtension",
  "SubStatuses": [
    {
      "Code": "ComponentStatus/StdOut/succeeded",
      "DisplayStatus": "Provisioning succeeded",
      "Level": "Info",
      "Message": "    Directory: C:\\temp\\n\\n\\nMode                LastWriteTime     Length Name
          \\n----                -------------     ------ ----                              \\n-a---          9/1/2015   2:03 AM         11
          test.txt                          \\n\\n",
                  "Time": null
      },
    {
      "Code": "ComponentStatus/StdErr/succeeded",
      "DisplayStatus": "Provisioning succeeded",
      "Level": "Info",
      "Message": "",
      "Time": null
    }
  ]
}

Устранение неполадок расширений

Убедитесь в том, что агент виртуальной машины запущен и готов к работе

Агент виртуальной машины необходим для управления расширениями, их установки и выполнения. Если агент виртуальной машины не работает или не сообщает о состоянии готовности на платформу Azure, расширения будут работать неправильно.

Сведения об устранении неполадок агента виртуальной машины см. на следующих страницах:

Ознакомьтесь с руководством по устранению неполадок для конкретного расширения

Для некоторых расширений имеются специальные страницы с описанием способов устранения их неполадок. Список этих расширений и страниц можно найти в статье Устранение неполадок расширений.

Просмотр состояния расширения

Как указывалось выше, состояние расширения можно узнать, выполнив командлет PowerShell:

Get-AzVM -ResourceGroupName $RGName -Name $vmName -Status

или команду CLI:

az vm extension show -g <RG Name> --vm-name <VM Name>  --name <Extension Name>

либо перейдя на портале Azure к колонке виртуальной машины и выбрав "Параметры" > "Расширения". Затем можно щелкнуть расширение и проверить его состояние и сообщение.

Повторное выполнение расширения на виртуальной машине

При выполнении сценариев на виртуальной машине с помощью расширения пользовательских сценариев может возникать ошибка, указывающая на то, что виртуальная машина создана успешно, но сценарий не выполнен. В этом случае рекомендуется удалить соответствующее расширение и выполнить шаблон еще раз. Примечание. В будущем эта функция будет усовершенствована, что позволит устранить необходимость в удалении расширения.

Удаление расширения с помощью Azure PowerShell

Remove-AzVMExtension -ResourceGroupName $RGName -VMName $vmName -Name "myCustomScriptExtension"

После удаления расширения шаблон можно выполнить повторно, чтобы запустить скрипты на виртуальной машине.

Активация нового состояния GoalState для виртуальной машины

Возможно, вы заметили, что расширение не было выполнено или его не удается выполнить из-за отсутствующего генератора сертификатов CRP Windows Azure (этот сертификат используется для защиты защищенных параметров расширения при транспортировке). Этот сертификат будет автоматически создан повторно путем перезапуска гостевого агента Windows в виртуальной машине:

  • Откройте диспетчер задач.
  • Перейдите на вкладку "Подробности".
  • Найдите процесс WindowsAzureGuestAgent.exe.
  • Щелкните его правой кнопкой мыши и выберите "Завершить задачу". Процесс будет автоматически перезапущен.

Вы также можете активировать новое состояние GoalState для виртуальной машины, выполнив операцию Reapply. Reapply — это представленный в 2020 году API для повторного применения состояния виртуальной машины. Рекомендуем сделать это в то время, когда допускается непродолжительный простой виртуальной машины. Операция Reapply не приводит к перезагрузке виртуальной машины сама по себе, и в подавляющем большинстве раз виртуальная машина перезагружена не будет. Но есть очень небольшая вероятность, что, когда Reapply активирует новое целевое состояние, будет применено другое ожидающее обновление модели виртуальной машины, которое может потребовать перезагрузки.

Портал Azure:

Выберите виртуальную машину на портале, и в области слева в разделе Поддержка и устранение неполадок выберите Повторное развертывание и применение, а затем нажмите кнопку Применить повторно.

Azure PowerShell (замените RG Name и VM Name именами группы ресурсов и виртуальной машины соответственно):

Set-AzVM -ResourceGroupName <RG Name> -Name <VM Name> -Reapply

Azure CLI (замените RG Name и VM Name именами группы ресурсов и виртуальной машины соответственно):

az vm reapply -g <RG Name> -n <VM Name>

Если операция Reapply не сработала, попробуйте добавить новый пустой диск данных в виртуальную машину с помощью портала управления Azure, а затем удалить его, когда сертификат будет добавлен обратно.

Просмотр журналов расширений в виртуальной машине

Если предыдущие шаги не помогли и расширение по-прежнему находится в состоянии сбоя, далее необходимо просмотреть его журналы в виртуальной машине.

В виртуальной машине Windows журналы расширений обычно находятся в следующей папке:

C:\WindowsAzure\Logs\Plugins

Параметры и файлы состояний расширений находятся в следующей папке:

C:\Packages\Plugins

В виртуальной машине Linux журналы расширений обычно находятся в следующей папке:

/var/log/azure/

Параметры и файлы состояний расширений находятся в следующей папке:

/var/lib/waagent/

Каждое расширение имеет свои особенности, но обычно они подчиняются одним и тем же принципам.

Пакеты и двоичные файлы расширений скачиваются на виртуальную машину (например, /var/lib/waagent/custom-script/download/1 для Linux или C:\Packages\Plugins\Microsoft.Compute.CustomScriptExtension\1.10.12\Downloads\0 для Windows).

Их конфигурация и параметры передаются с платформы Azure в обработчик расширений с помощью агента виртуальной машины (например, /var/lib/waagent/Microsoft.Azure.Extensions.CustomScript-2.1.3/config для Linux или C:\Packages\Plugins\Microsoft.Compute.CustomScriptExtension\1.10.12\RuntimeSettings для Windows).

Обработчики расширений на виртуальной машине записывают данные в файл состояния (например, /var/lib/waagent/Microsoft.Azure.Extensions.CustomScript-2.1.3/status/1.status для Linux или C:\Packages\Plugins\Microsoft.Compute.CustomScriptExtension\1.10.12\Status для Windows), который затем передается на платформу Azure. Это состояние соответствует сообщаемому через PowerShell, CLI или колонку расширений виртуальной машины на портале Azure.

Они также записывают подробные журналы выполнения (например, /var/log/azure/custom-script/handler.log для Linux или C:\WindowsAzure\Logs\Plugins\Microsoft.Compute.CustomScriptExtension\1.10.12\CustomScriptHandler.log для Windows).

Если виртуальная машина создается на основе существующей виртуальной машины

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

Известные проблемы

PowerShell не распознается как внутренняя или внешняя команда

Вы заметите следующие записи об ошибках в выходных данных расширения RunCommand:

RunCommandExtension failed with "'powershell' isn't recognized as an internal or external command,"

Анализ

Расширения выполняются под учетной записью локальной системы, поэтому вполне возможно, что powershell.exe работает нормально при подключении к виртуальной машине по протоколу RDP, но завершается сбоем при запуске с помощью RunCommand.

Решение

  • Убедитесь, что PowerShell правильно указан в переменной среды PATH:
    • Откройте панель управления
    • Система и безопасность
    • Системные
    • Вкладка "Дополнительно" — переменные среды >
  • В разделе "Системные переменные" щелкните "Изменить" и убедитесь, что PowerShell находится в переменной среды PATH (обычно: "C:\Windows\System32\WindowsPowerShell\v1.0")
  • Перезагрузите виртуальную машину или перезапустите службу WindowsAzureGuestAgent, а затем повторите выполнение команды.

Команда не распознается как внутренняя или внешняя команда

В файле C:\WindowsAzure\Logs\Plugins<ExtensionName><Version>\CommandExecution.log вы увидите следующее:

Execution Error: '<command>' isn't recognized as an internal or external command, operable program or batch file.

Анализ

Расширения выполняются под учетной записью локальной системы, поэтому вполне возможно, что powershell.exe работает нормально при подключении к виртуальной машине по протоколу RDP, но завершается сбоем при запуске с помощью RunCommand.

Решение

  • Откройте командную строку на виртуальной машине и выполните команду для воспроизведения ошибки. Агент виртуальной машины использует cmd.exe администратора, и при каждом запуске cmd может быть выполнена определенная предварительно настроенная команда.
  • Кроме того, скорее всего, переменная PATH настроена неправильно, но это будет зависеть от проблемной команды.

VmAccessAgent завершается сбоем и отображается сообщение о невозможности обновления параметров подключения к удаленному рабочему столу для учетной записи администратора. Ошибка: System.Runtime.InteropServices.COMException (0x800706D9): в сопоставителе конечных точек больше нет конечных точек.

В состоянии расширения отображается следующее:

Type Microsoft.Compute.VMAccessAgent
Version 2.4.8
Status Provisioning failed
Status level Error
Status message Cannot update Remote Desktop Connection settings for Administrator account. Error: System.Runtime.InteropServices.COMException (0x800706D9): There are no more endpoints available from the endpoint mapper. (Exception from HRESULT: 0x800706D9) at NetFwTypeLib.INetFwRules.GetEnumerator() at 
Microsoft.WindowsAzure.GuestAgent.Plugins.JsonExtensions.VMAccess.RemoteDesktopManager.EnableRemoteDesktopFirewallRules() 
at Microsoft.WindowsAzure.GuestAgent.Plugins.JsonExtensions.VMAccess.RemoteDesktopManager.EnableRemoteDesktop() at

Анализ

Эта ошибка может возникать, если не запущена служба брандмауэра Windows.

Решение

Проверьте, включена и запущена ли служба брандмауэра Windows. Если это не так, включите и запустите ее, а затем повторите попытку, чтобы запустить VMAccessAgent.

Удаленный сертификат недопустим согласно процедуре проверки.

В журнале WaAppAgent.log отображается следующее

System.Net.WebException: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel. ---> System.Security.
Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure.

Анализ

Вероятно, на виртуальной машине отсутствует корневой сертификат Baltimore CyberTrust в разделе "Доверенные корневые центры сертификации".

Решение

Откройте консоль сертификатов с помощью certmgr.msc и проверьте наличие сертификата.

Еще одна возможная проблема заключается в том, что цепочка сертификатов нарушена сторонним средством проверки SSL, например ZScaler. В этом средстве следует настроить обход проверки SSL.