# Анализ сбоя создания 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`.