Управляем VMware Cloud Director через MCP-сервер: от API к текстовым командам

Каждый раз управляя облаком, мы совершаем повторяющиеся действия: создаем сеть, виртуальную машину, настраиваем правила Firewall и NAT… Все это интересно и удобно первые несколько раз, а потом тебя начинает напрягать не самый отзывчивый интерфейс и кликов по UI набегают сотни, а то и тысячи в месяц. Но ведь можно же делегировать все эти рутинные приседания ИИ-агенту?

Да, именно так мы и сделали у себя в Облаке VMware, но спокойствие, в этой статье мы его вам продавать не будем. Здесь расскажем тем, кто администрирует свой дата-центр или облачный тенант на базе VMware, как прикрутить к нему Claude Code, Open Code или любого другого MCP-совместимого агента без написания собственной обертки над API. Ну и само собой, мы сделаем это так, чтобы разбушевавшийся агент не смог наворотить лишнего, даже если очень захочет.

«А почему бы просто не дать агенту curl?»

Когда я только начал изучать, какие ИИ-возможности управления VMware Cloud Director есть, выяснилось, что ничего готового вендор не предлагает (по крайней мере на момент публикации). А хотелось, чтобы у наших заказчиков была возможность управлять облаком просто обозначив задачку агенту. Но как это провернуть? Может просто стоит дать LLM-агенту доступ к сырому API через универсальный HTTP-инструмент? Если этот вопрос возник и у вас, отвечу вам мемом:

А если серьезно, то при таком исполнении, нас ждет ряд проблем.

1. Мало того что VMware Cloud Director API — это несколько сотен эндпоинтов. Начиная с версии 9.5 у продукта появился еще и второй параллельный API, который живет рядом с унаследованным. Дальше — больше: он отдает ответы в JSON, тогда как предыдущий вариант — в XML. И что самое печальное, два этих API не взаимозаменяемы. Если не прописать инструкции ясно, скорее всего агент будет тратить лишние токены на угадывание правильного пути и параметров запроса.

2. По той же причине агент может начать дергать не ту «ручку» или дергать не в том порядке: например, будет пытаться получить детали о виртуалке до того, как получил ее ID.

3. У агента буквально не будет никаких ограничений на деструктивные операции, а это неизбежно приведет кого-нибудь из пользователей к ситуации: «я что-то сказал и все исчезло» (от создателей «я что-то нажал и все пропало»). А мы хотим следовать принципу safe by design и не наделять лишними полномочиями ни агента, ни юзера от греха подальше.

В общем, мы сочли, что без MCP-сервера тут не обойтись, поскольку в случае с ним, не будет сложностей, перечисленных выше, а наиболее частотные сценарии превратятся в именованные тулзы. Агент больше не будет составлять запрос к API с нуля — он просто вызовет vm_power_action(vm_id, action="restart"), и сервер сам соберет нужный HTTP-запрос к нужной версии API. Дело осталось за малым, написать сам MCP-сервер. Мы собрали операции, которые требуются нашим клиентам чаще всего, написали свой инструмент и выложили на Git. Чтобы модель не заблудилась в названиях, действовали по принципу «одна задача — один инструмент». Подробнее про группы задач расскажу далее.

Архитектура решения и первые шаги

Использовать MCP сервер можно с любым удобным ИИ-агентом, главное организовать доступ от него к тенанту VMware. У нас получилась следующая комбинация:

Для настройки нам понадобится:

• ИИ-агент;

• Docker Compose;

• MCP Server VMware Cloud Director;

• Username и API Token от учетной записи тенанта VMware Cloud Director.

Шаг 1. Клонируем репозиторий и собираем образ

git clone https://github.com/cloud-ru/vmware-clouddirector-mcp.git 
cd vmware-clouddirector-mcp 
docker build -t vmware-clouddirector-mcp:latest 

Шаг 2. Проверяем, что сервер поднимается и видит тенант

docker run -i --rm \  --name vmware-clouddirector-mcp \  -e VCD_BASE_URL=https://your\_vcd\_instance\_address \ 
-e VCD_USERNAME=your_username \ 
-e VCD_API_TOKEN=your_api_token \ 
-e VCD_ORG=your_organization \ 
-e VCD_API_VERSION=39.1 \ 
vmware-clouddirector-mcp:latest & 

docker logs -f vmware-clouddirector-mcp 

Если в логах нет ошибок аутентификации — останавливаем тестовый контейнер (docker stop vmware-clouddirector-mcp) и переходим к подключению агента.

Шаг 3. Подключаем Claude Code

claude mcp add vmware-cloud-director \ -e 
VCD_BASE_URL=https://your\_vcd\_instance\_address \ -e 
VCD_USERNAME=your_username \ -e VCD_API_TOKEN=your_api_token \ -e 
VCD_ORG=your_organization \ -e VCD_API_VERSION=39.1 \ -- \ docker run --rm -i --network host -e VCD_BASE_URL -e VCD_USERNAME -e VCD_API_TOKEN -e VCD_ORG -e 
VCD_API_VERSION vmware-clouddirector-mcp:latest

Подробнее в документации Claude Code по MCP. Для OpenCode процесс аналогичен, актуальный синтаксис — в доке OpenCode.
Рабочий лайфхак: попросите агента настроить подключение, большинство современных агентов с этим справляются.

Что может наш MCP-сервер и почему именно это

На момент публикации наш MCP-сервер поддерживает 36 инструментов в 8 категориях: Аутентификация и core‑запросы

• ovcd_login — аутентификация в VMware Cloud Director;

• list_orgs — вывод доступных организаций (Tenant);

• list_vdcs — вывод доступных виртуальных дата центров (VDC);

• get_vdc_details — получение детальной информации по VDC;

• get_resource_usage — получение подробной статистики использования ресурсов.

Управление приложениями

• olist_vapps — вывод списка виртуальных приложений;

• vapp_power_action — управление активностью виртуальных приложений (start, stop, restart, suspend, resume);

• vapp_clone — клонирование виртуального приложения.

Управление виртуалками

• olist_vms — вывод списка виртуальных машин;

• search_vms — поиск виртуальной машины по имени или VDC;

• get_vm_details — получение детальной информации по виртуальной машине;

• get_vm_details_with_id — получение детальной информации по виртуальной машине с определенным id;

• vm_power_action — управление активностью виртуальной машины (start, stop, restart, suspend, resume)

• vm_configure — изменение конфигурации виртуальной машины (CPU и RAM).

Снапшоты

• vm_create_snapshot — создание снапшота виртуальной машины;

• vm_list_snapshots — вывод списка снапшотов виртуальной машины;

• vm_restore_snapshot — восстановление из снапшота виртуальной машины.

Хранилище

• list_datastores — вывод списка доступных storage profiles;

• vm_add_disk — добавление нового диска виртуальной машине;

• vm_list_disks — вывод списка дисков виртуальной машины;

• vm_resize_disk — изменение размера диска виртуальной машины.

Сети

• list_networks — вывод списка виртуальных сетей;

• list_firewall_rules — вывод списка правил фаервола с EdgeGWs;

• create_org_network — создание виртуальной сети;

• list_nat_rules — ввод списка NAT правил с EdgeGWs;

• list_dhcp_pools — вывод списка DHCP пулов с EdgeGWs;

• list_ip_allocations — вывод списка аллоцированных IP адресов с EdgeGWs.

Шаблоны и каталоги

• list_catalogs — вывод списка каталогов в организации;

• list_catalog_items — вывод списка объектов в каталоге;

• get_template_details — получение детальной информации по шаблонам виртуальных машин.

Мониторинг

• list_tasks — вывод списка задач и операций;

• get_vm_metrics — получение метрик производительности виртуальной машины;

• list_events — вывод списка событий;

• get_org_health — получение статуса состояния организации;

• get_resource_metrics — получение метрик использования ресурсов;

• health_check — проверка статуса подключения к VMware Cloud Director.

У вас, наверное, возник вопрос: «почему есть возможность создать ВМ, но нет возможности ее удалить»? Деструктивные вызовы мы не стали добавлять сознательно: если вашей команде нужны операции удаления, их придется выполнять вручную или через отдельный, явно подтверждаемый путь. А то дадим «из коробки» возможность удалять, а завтра ваш агент деградирует и снесет половину инфраструктуры. Если уж очень хочется, можно взять за основу наш код и прописать себе все, что душе угодно, кто мы такие чтобы вам запрещать? Главное делайте все осознанно. По итогу ваш агент должен получить ограниченную, но все-таки власть над облаком. Я вот после установки и подключения спросил агента, что он знает про мои ресурсы:

Как убедиться в том, что через MCP-сервер ваш агент не пытался удалить все, что нажито непосильным трудом? Элементарно: заходите в разделы Task и Events и смотрите что делалось с инфраструктурой пока вы спали, сидели на очередном митинге или пили кофе. Запросы вывода состояния там отображаться не будут, но любые включения, выключения, создания, изменения видны как на ладони.

Практическая польза и крошечный недостаток

Благодаря возможности управлять облаком с помощью текстовых команд, можно автоматизировать часть регулярных задач без привязки к рабочему месту или коду: передаем задачу агенту, а там он уже сам уточняет, что понадобится для готового результата. Вот пример:

Но есть во всем этом крошечный недостаток, который я пока не придумал как обойти, не теряя в безопасности. MCP-сервер авторизуется в тенанте Cloud Director с помощью API Token, который принадлежит конкретному пользователю (например, админу организации). Но если сценарий нужно реализовать для нескольких пользователей, под каждого придется создавать отдельный MCP. В целом, это не то чтобы проблема: вы сами видели, что создание MCP-сервера не такой уж сложный и длительный процесс. Но если у вас есть идеи, как дать нескольким пользователям возможность пользоваться одним сервером, не плодя секреты в .env-файликах, делитесь в комментариях.

Код доступен as is. И, конечно, перед использованием MCP для автоматизации вашего облака, мы рекомендуем сначала провести тестирование ваших рабочих сценариев в stage-среде.

Всем побольше правильных ответов от ИИ-агентов и стабильной инфраструктуры!