vCenter Server

Вызывает ServiceContent.about через собственный SOAP-вызов RetrieveServiceContent API vSphere по адресу /sdk — тот же вызов и эндпоинт, на который отвечает ESXi, различаются они по полю apiType.

targets:
  - id: vcenter-main
    product: vcenter
    address: https://vcenter.example.com

Аутентификация

Отсутствует — подтверждено вживую на реальном продакшн-инстансе vCenter 8.0.3, вообще без credentials.

Проверка личности вендора

Поле apiType сверяется со строкой "VirtualCenter" — реальный хост ESXi отвечает на идентичный вызов с apiType=HostAgent (см. ESXi, где та же проверка выполняется в обратную сторону). Если product: vcenter указать на хост ESXi, проба громко откажет вместо того, чтобы записать это как неверный факт.

Не то же самое, что более ранняя версия этой пробы

Раньше эта проба читала вместо этого /sdk/vimServiceVersions.xml, который отвечает идентично и для ESXi, и для vCenter (то есть никогда не мог их различить) и сообщает версию схемы API vim25 (например, "8.0.3.0"), а не настоящую маркетинговую версию продукта. Текущая проба на основе RetrieveServiceContent решает обе проблемы — настоящая версия, настоящая проверка личности.

Записываемые поля

• version — настоящая маркетинговая версия, например 8.0.3
• extra.build, если присутствует

Сопоставление с CVE

Не сопоставляется — почти все записи — вида 7.0 + update_1, которые механизм сверки не читает, так что результат был бы либо пустым, либо полным. См. Сопоставление с CVE.

Резолвер жизненного цикла

endoflife:vcenter. Календарь записывает последний уровень патчей ветки 8.0 в собственной сокращённой форме VMware (8.0 U3k / 8.0 Update 3k); начиная с 2.1 это читается как 8.0.3, так что полностью пропатченный хост 8.0 Update 3 показывается как current, а не ahead. Буква патча в конце отбрасывается — в собственной строке версии хоста сравнивать её не с чем.