tf_provider/docs/40_analysis/vm_creation_failure_analysis.md

Анализ сбоя создания VM (f12vmbad.har)

Операция: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

Статус операции

• isSuccessful: false
• isInProgress: false
• Время выполнения: 15:08:01 → 15:11:42 (≈3 минуты 40 секунд)
• Причина: Зависание на этапе "Добавление правил FW"

---

Хронология выполнения (Stages)

✅ Этап 1: Подготовка среды

• Статус: Успешно
• Длительность: 13 секунд
• Действия:
  • Определение ресурсной платформы: OK
  • Подготовка операции: OK
  • Определение переменных для работы с VM: OK

✅ Этап 2: Работа с сервисом (Cloud Director)

• Статус: Успешно
• Длительность: 192.8 секунды (~3 минуты)
• Действия:
  • Подготовка конфигурационных файлов: OK
  • Авторизация в Cloud Director: OK
  • Установка сервиса: OK ✓
    • VM ff12web01 успешно создана в Cloud Director

❌ Этап 3: Работа с сервисом (Firewall Rules)

• Статус: FAILED ❌
• Длительность: 15.5 секунд (зависание)
• Действие: "Добавление правил FW [PROCESS]"
• Проблема:
  • Процесс начался в 15:11:35.807
  • dtFinish: null (не завершился)
  • Сообщение осталось в статусе [PROCESS]

✅ Этап 4: Настройка vIP

• Статус: Успешно
• Длительность: 0.7 секунды
• Действия: Выделение VIP-адресов: OK

✅ Этап 5: Настройка DNS

• Статус: Успешно
• Длительность: 1 секунда
• Действия: Подготовка DNS записей: OK

---

Корневая причина сбоя

🔥 Систематический сбой на этапе Firewall

Факты:

1. VM успешно создана в Cloud Director (VCD).
2. VIP-адреса выделены корректно.
3. DNS-записи настроены.
4. Firewall Rules НЕ применены → операция застопорилась и упала по таймауту.
5. Процесс завис именно на вызове "Добавление правил FW [PROCESS]" без финализации.

Возможные причины

1. Проблемы с доступом к NSX Manager/Edge Gateway

• При применении правил FW оркестратор обращается к NSX-T API.
• Возможен таймаут из-за сетевой недоступности или перегрузки NSX Manager.
• Отсутствие errorLog в ответе говорит о том, что запрос "завис", а не упал с явной ошибкой.

2. Конфликт конфигурации Firewall

• VM ff12web01 создана в vApp xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.
• Если в этом vApp или Edge Gateway уже существуют противоречивые правила, новые правила могут не применяться.
• Возможна попытка создания дублирующих NAT/FW правил.

3. Недостаточность прав или квот

• Пустое значение accessIpList: "" могло быть интерпретировано бэкендом как запрос на открытие доступа со всех адресов (0.0.0.0/0).
• Если в организации есть политики безопасности, запрещающие такие правила, запрос может быть заблокирован без явной ошибки.

4. Анализ переданных параметров

Все основные параметры корректны:

• vappUid: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx ✓
• vmName: ff12web01 ✓
• CPU: 1 ✓
• RAM: 1 GB ✓
• osImage: Ubuntu_22-20G ✓
• userPublicKey: Валидный SSH-ключ ssh-ed25519 AAAAC3Nz... ✓
• userName: myuser ✓
• accessPortList: ["22"] (SSH) ✓
• needEnableExternalIp: true ✓

Потенциально проблемные значения:

1. Пустые строки в опциональных полях:

   • svcOperationCfsParamId 411 (вероятно vmDisk): "" — лучше передавать null или число.
   • svcOperationCfsParamId 413 (вероятно accessIpList): "" — ожидается JSON-массив типа ["0.0.0.0/0"].
   • svcOperationCfsParamId 415 (вероятно cloudInit): "" — опционально.

2. Значение "no-needed" (ID 412):

   • Неясное назначение параметра. Возможно, это placeholder для неиспользуемого поля.

Вывод: Основные параметры валидны. Пустые строки в опциональных полях технически допустимы, но могут некорректно обрабатываться бэкендом.

---

Рекомендации

Немедленные действия для отладки

1. Проверить логи NSX Manager:

   • Посмотреть, поступал ли запрос на создание FW правил в момент 15:11:35.807.
   • Если запрос отсутствует → проблема на стороне оркестратора (не дошел до NSX).
   • Если запрос есть, но с ошибкой → причина в конфигурации или правах.

2. Проверить текущее состояние Edge Gateway:

   • Посмотреть список правил FW для vApp xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.
   • Убедиться, что нет конфликтующих правил для VM ff12web01.

3. Проверить доступность NSX Manager:

   • Убедиться, что NSX API отвечает на запросы.
   • Проверить сетевую связность между Jenkins (оркестратор) и NSX Manager.

4. Повторить создание с улучшенными параметрами:

   • Передавать accessIpList как JSON-массив: ["0.0.0.0/0"] вместо пустой строки.
   • Для vmDisk указать либо null, либо конкретное значение (например, "10" для 10 GB).

Для Terraform Provider

1. Добавить проверку статуса стадий:

   • Если stage.dtFinish == null и duration > 30s → считать операцию зависшей.
   • Отдавать понятное сообщение: "VM создана, но Firewall не настроен".

2. Повторная попытка при Firewall Timeout:

   • Если сбой на этапе "Добавление правил FW", попробовать retry с экспоненциальной задержкой.
   • Добавить опцию skip_firewall_on_timeout для продолжения деплоя без FW.

3. Валидация параметров перед отправкой:

   • Не передавать пустые строки для списков (accessIpList, cloudInit).
   • Для числовых полей использовать либо валидное значение, либо null.
   • Проверять формат JSON-массивов перед сериализацией.

4. Расширенное логирование:

   • Записывать в лог полный JSON всех отправленных параметров.
   • Логировать промежуточные статусы стадий для отладки таймаутов.

---

Заключение

VM физически создана в Cloud Director, но из-за таймаута на этапе применения Firewall Rules ресурс считается неуспешно развернутым (isSuccessful: false).

Основные подозреваемые:

1. Недоступность NSX Manager или перегрузка API.
2. Конфликт правил FW в целевом Edge Gateway.
3. Пустые значения в параметрах (accessIpList: "", vmDisk: ""), которые могли некорректно обработаться бэкендом.

Для точной диагностики необходимо проверить логи Jenkins (оркестратор) и NSX Manager на момент 15:11:35 → 15:11:42.