Исчезающие в облаке сети

Хабр, привет!

В эфире —  команда из центра компетенций VMware. Недавно мы разбирали  интересное поведение в работе ПО у одного из наших заказчиков — облачного провайдера.

 Вы знали, что в vCloud Director с NSX‑V добавление новой внешней сети на шлюз может тихо отключить уже существующую? Система предательски завершит задачу без ошибок, а заказчик заметит пропажу только по упавшим ВМ. Мы воспроизвели это в тестовом контуре и проследили всю цепочку — от галочек в интерфейсе до delete-запроса в PostgreSQL.

Статья — для тех, кто сопровождает vCD с NSX‑V в продакшне. Если вы хоть раз правили внешние сети через UI, вы в группе риска. Покажем, как именно это происходит, и дадим два рабочих обхода — без танцев с БД и перехода на NSX‑T.

Сразу важная ремарка:  NSX-V уже много лет не поддерживается вендором, по нему нет документации на techdocs.broadcom.com и с получением дистрибутивов из официальных источников также наблюдаются проблемы. Но вот матрица взаимодействия продуктов Broadcom все еще успешно пишет о его совместимости с последними релизами Cloud Director, хоть он и указан как Legacy.

Как использовать NSX-V и зачем?

Итак, благодаря связке продуктов NSX-V с vCloud Director на стороне провайдера конечный пользователь может:

• Создавать свои внутренние виртуальные сети.

• Делать эти сети как изолированными, так и маршрутизируемыми.

• Настраивать маршрутизацию и дополнительные сервисы.

Дополнительный вариант маршрутизации — это использование существующих виртуальных сетей провайдера. В контексте vSphere это означает, что к Edge Service Gateway (ESG) клиента можно подключить любую порт-группу vSphere Distributed Switch (vDS) в качестве Uplink-интерфейса. Частные случаи такой настройки опустим. Самое главное — наличие кнопки в интерфейсе, которая позволяет это сделать.

Сегодня мы подробнее рассмотрим процесс добавления внешних сетей на ESG-клиентах. Именно в этой, казалось бы, простой процедуре мы обнаружили интересную особенность.

Вторая важная ремарка: при использовании NSX-T с vCD workflow, мастер настройки сетей и логика взаимодействия продуктов отличаются. Проблема, описанная ниже, затрагивает только инсталляции Cloud Director, интегрированные с NSX-V.

Работаем в нашем тестовом контуре:

• Создаем на vDS 15 новых порт-групп (почему 15, поясним чуть позже).

• В тестовом тенанте vCD создаем новый ESG.

• Добавим на новый ESG несколько внешних сетей (Ext-Net-01, 02, 15):

При редактировании пункта Network & Subnets наблюдаем, что сеть Ext-net-15 находится на второй странице в списке доступных сетей. До добавления 15 порт-групп vCD уже знал о нескольких сетях.

На одной странице может быть до 15 записей о внешних сетях. Соответственно, в нашем случае Ext-Net-15 находится на второй странице. Запомним это!

Теперь заглянем в БД vCD. Там нас будут интересовать две таблицы:

• Таблица logical_network содержит записи о всех внешних сетях и их соотношении с PG vDS (rnet_id).

• Таблица gateway_interface содержит информацию о всех сетях, подключенных к ESG. Мы специально отфильтровали по конкретному тестовому GW для простоты понимания.

На текущий момент на ESG добавлены сети 01, 02, и 15. Первая запись в таблице — это интерфейс для связи с DLR. Его мы не учитываем — он создается автоматически при определенных условиях.

Попробуем добавить сеть Ext-Net-03 и посмотрим, что произойдет. В логах vCD фиксируется событие сбора спецификации для обновления информации по этому GW:

2026-03-18 09:46:21,363 | DEBUG | pool-jetty-51 | NsxVEdge | Placement required for edge TEST-02. Existing portgroup ids [3f656fff-4f16-4fec-8cf3-81fafe386d96, <== Ext-Net-15051371ef-6a9a-4bfc-a486-ecd08d475369, <== Ext-Net-024d2e7c20-12bf-4e90-a9fc-ecaf1b88ccdc <== Ext-Net-01] do not contain all new portgroup ids [4d2e7c20-12bf-4e90-a9fc-ecaf1b88ccdc, <== Ext-Net-01051371ef-6a9a-4bfc-a486-ecd08d475369, <== Ext-Net-022088d79c-2ea5-496a-81ce-b96532961a1b <== Ext-Net-03] | requestId=0b4d3d9f-0ac1-4bd4-bf5c-a8e179ed2512,request= PUT https://<API_Public_URL>/api/admin/edgeGateway/116ac26a-5b67-41bf-b303-8d3feba8a9f7/action/updateProperties,requestTime=1773827181006,remoteAddress=<source_IP>:63748,userAgent=Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 ...,accept=application/*+json;version 38.0.0-alpha

Мы видим, что, несмотря на знание исходной конфигурации, vCD решил проигнорировать Ext-Net-15 в итоговой спецификации. Другими словами, выполнение штатной процедуры добавления клиенту новой внешней сети может привести к неожиданному результату — удалению из конфигурации ESG уже используемой внешней сети. При этом никаких ошибок система не сообщит.

По логам PostgreSQL явно видно, что 15-я сеть удаляется из таблицы gateway_interface:

2026-03-18 09:46:22.687 UTC [20410] LOG: execute <unnamed>: /* Method: unknown */ /* delete com.vmware.vcloud.fabric.net.model.GatewayInterfaceModel */ delete from gateway_interface where id=$1 and version_number=$22026-03-18 09:46:22.687 UTC [20410] DETAIL: parameters: $1 = 'bae7ddcc-e662-4641-a72c-2078f0cad9d3', $2 = '0'

Пробуем провести второй тест. Возвращаем обратно Ext-Net-15. Затем снова запускаем визард и добавляем следующую внешнюю сеть — Ext-Net-4. После выбора сети переходим на вторую страницу визарда, где видим, что сеть Ext-Net-15 уже отмечена флажком. Нажимаем Save.

2026-03-18 09:53:15,308 | DEBUG | pool-jetty-50 | NsxVEdge | Placement required for edge TEST-02. Existing portgroup ids [2088d79c-2ea5-496a-81ce-b96532961a1b, <== Ext-Net-03051371ef-6a9a-4bfc-a486-ecd08d475369, <== Ext-Net-024d2e7c20-12bf-4e90-a9fc-ecaf1b88ccdc, <== Ext-Net-013f656fff-4f16-4fec-8cf3-81fafe386d96 <== Ext-Net-15] do not contain all new portgroup ids [4d2e7c20-12bf-4e90-a9fc-ecaf1b88ccdc, <== Ext-Net-01051371ef-6a9a-4bfc-a486-ecd08d475369, <== Ext-Net-022088d79c-2ea5-496a-81ce-b96532961a1b, <== Ext-Net-03d84cd6a6-480c-43f2-a4f6-16acccf3ba0e, <== Ext-Net-043f656fff-4f16-4fec-8cf3-81fafe386d96 <== Ext-Net-15]| requestId=f3953158-5c29-4558-8739-73e7f94bbb18,request=PUT https://<API_Public_URL>/api/admin/edgeGateway/116ac26a-5b67-41bf-b303-8d3feba8a9f7/action/updateProperties,requestTime=1773827594957,remoteAddress=<source_IP>:51115,userAgent=Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 ...,accept=application/+json;version 38.0.0-alpha

Как видно из лога, в этом случае все сети сохраняются в итоговой спецификации задачи редактирования ESG.

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

Также при редактировании списка сетей через опцию Edit для самого GW все сети отображаются корректно, так как к ним фиксируются обращения в БД vCD и они успешно попадают в спецификацию задачи и не исчезают с ESG.

Опережая вопросы: REST API в решении данной задачи мы не используем. Вы можете проверить нас в обоих гайдах: Schema reference и OpenAPI. В обоих документах указано, что они применимы только для NSX-T.  

К чему все это было?

Такая фича (или баг) наблюдается на всех последних версиях vCD, так как логику взаимодействия с NSX-V уже давно не изменяли. Не зная о таких особенностях, можно очень легко оставить заказчика без существующего сетевого соединения и даже не заметить этого. В качестве Workaround можно каждый раз пролистывать все страницы с отмеченными сетями или производить редактирование на уровне GW.

А если вы любите виртуализацию, особенно вот это увлекательное копание в технических тонкостях, приходите на техническую вечеринку – «Виртуализация: just for fun». Мероприятие очное и неформальное, а главное – никакой корпоративной цензуры.