АйТи Фреш
Главная / Статьи / Серверы и хостинг
Серверы и хостинг

vCenter 9: Native Key Provider создан, а vTPM не добавляется — покупать TPM для хоста не надо

Автор: Семёнов Евгений Сергеевич, директор ООО «АйТи-Фреш» · · ~24 мин чтения
vCenter 9: Native Key Provider создан, а vTPM не добавляется — покупать TPM для хоста не надо
Иллюстрация к статье «vCenter 9: Native Key Provider создан, а vTPM не добавляется — покупать TPM для хоста не надо».

Вы создали в vCenter Native Key Provider, увидели его в списке — а мастер добавления устройства всё равно отказывается давать виртуальной машине Trusted Platform Module. Дальше обычно рождается заявка в снабжение на TPM-модули под материнки серверов. В подавляющем большинстве случаев это лишние деньги и лишние недели ожидания: виртуальный TPM не опирается на чип хоста. Ниже — чем аппаратный TPM отличается от vTPM, три причины отказа из Broadcom KB 369538 и порядок, в котором я их проверяю, как снять фатальную галочку TPM-only с уже созданного провайдера, зачем NKP обязательный бэкап в PKCS#12, что будет с машинами при потере vCenter без бэкапа, какие версии и лицензии нужны, и разбор стенда проектной компании «Смета и форма» на 40 рабочих мест, где на закупке сэкономили около 90 тысяч рублей.

Аппаратный TPM сервера и vTPM виртуалки — это разные устройства

Ситуация узнаваемая. Вы честно прошли по документации: зашли в vCenter Server → Configure → Security → Key Providers, нажали Add → Add Native Key Provider, дали имя, провайдер появился в списке. Идёте к виртуалке, Edit Settings → Add New Device — а пункта Trusted Platform Module либо нет вовсе, либо мастер отвечает что-то про несовместимость политики шифрования. Первая мысль почти у всех одинаковая: значит, на хостах нет физического TPM, надо закупать модули. Стоп. В девяти случаях из десяти закупка здесь не нужна вообще, и вы просто не заметили одно из трёх ограничений самого провайдера ключей.

Разведём два устройства, потому что их путают постоянно — и в переписке с заказчиком, и в тикетах интеграторов. Аппаратный TPM 2.0 на материнской плате сервера — это физический чип, с которым работает сам гипервизор: ESXi складывает туда измерения доверенной загрузки (attestation), там же может лежать локальный ключ, которым шифруется конфигурация хоста. Это про доверие к хосту. Виртуальный TPM (vTPM) — это программно эмулируемое устройство внутри конкретной виртуальной машины. Гостевая ОС видит обычный TPM 2.0, ставится Windows 11, включается BitLocker, работает Credential Guard. Секреты vTPM хранятся не в железе, а в отдельном зашифрованном файле NVRAM рядом с ВМ на датасторе, и шифруются ключом, который выдаёт провайдер ключей из vCenter.

Отсюда главный практический вывод: vTPM опирается на подсистему шифрования виртуальных машин, а не на чип материнской платы. Хосту физический TPM для vTPM не нужен — нужен рабочий и правильно настроенный key provider. Именно поэтому вложенные лаборатории на nested ESXi, где TPM нет и быть не может по определению, спокойно поднимают Windows 11 с виртуальным TPM. И именно поэтому старый сервер 2016 года выпуска без TPM-хедера на плате остаётся полноценным хостом под защищённые Windows-ВМ.

Проверить, что реально стоит в вашем сервере, можно прямо из консоли ESXi по SSH — полезно хотя бы для того, чтобы честно ответить безопаснику, а не гадать:

esxcli hardware trustedboot get

Вывод покажет два поля: Drtm Enabled и Tpm Present. Если Tpm Present: false — это не приговор для vTPM. Это всего лишь означает, что на хосте не будет аттестации доверенной загрузки и что провайдер ключей с ограничением TPM-only на такой хост не приедет.

Коротко о требованиях, чтобы не спорить с безопасником и бухгалтерией. Native Key Provider встроен в vCenter начиная с vSphere 7.0 Update 2 и есть в vSphere 8 и 9; и vCenter, и ESXi должны быть не старше 7.0 U2. По документации Broadcom NKP позволяет включать vTPM во всех редакциях vSphere, а вот полноценное шифрование виртуальных машин (VM Encryption) требует vSphere Enterprise Plus. Для Windows 11 vTPM обязателен — без TPM 2.0 установщик не пойдёт; для Windows Server 2025 он нужен, чтобы работали BitLocker, Credential Guard и прочие функции, опирающиеся на TPM. Внешний KMS для всего этого не требуется.

Не оформляйте закупку TPM-модулей «чтобы заработал vTPM», пока не прошли три проверки из KB 369538. Физический TPM 2.0 на хосте нужен для attestation, vSphere Trust Authority и в том случае, если вы сами ограничили провайдер ключей галочкой TPM-only. Для самого vTPM — не нужен.
Цифры и версии: Аппаратный TPM сервера и vTPM виртуалки — это разные устройства — схема
Цифры и версии: Аппаратный TPM сервера и vTPM виртуалки — это разные устройства. Открыть схему в полном размере

Три причины отказа из KB 369538 — проверяю ровно в этом порядке

Broadcom собрал диагностику этой ошибки в статье KB 369538 «Unable to add vTPM on virtual machine or enable host encryption», и распространяется она и на vCenter 8.x, и на vCenter 9.x. То есть это не детская болезнь новой версии, которую вылечит следующий патч, а устойчивое поведение продукта на протяжении двух мажорных релизов. Симптомы там перечислены ровно те, что вы видите: «Cannot apply encryption policy. You must set default key provider», «Trusted Key provider is not compatible with host», предупреждения о несовместимости хоста с Native Key Provider, а в логах vpxd — строка NativeKeyProviderNotSupported.

Причин по этой KB ровно три, и они не пересекаются. Первая: провайдер создан, но не назначен провайдером по умолчанию — тогда политика шифрования просто не к чему привязаться. Вторая: хост не входит в vSphere-кластер — standalone-хосты Native Key Provider не поддерживают вообще. Третья: на провайдере включено ограничение «использовать только с хостами, защищёнными TPM», а на хосте физического TPM 2.0 нет или он выключен в BIOS. Я всегда иду именно по этому списку сверху вниз, потому что первая причина лечится за десять секунд, вторая — за минуту, а третья требует аккуратной процедуры с бэкапом.

Прежде чем лезть в интерфейс, полезно посмотреть, что говорит сам vCenter. На VCSA логи vpxd лежат по стандартному пути, и нужная строка ищется в одну команду:

grep -iE 'NativeKeyProviderNotSupported|KeyProviderNotFound|CryptoKey' /var/log/vmware/vpxd/vpxd.log | tail -n 50

Если там сыпется NativeKeyProviderNotSupported — вы почти наверняка в причине номер два или номер три. Если сыпется что-то про отсутствие ключевого провайдера по умолчанию — в причине номер один. Это экономит полчаса тыканья по вкладкам.

Отдельно проверьте прошивку самой виртуальной машины. Устройство vTPM добавляется только к ВМ с прошивкой EFI, к машине на BIOS его не прицепить, и мастер про это скажет неявно — просто не покажет пункт в списке устройств. Если вы конвертировали старую ВМ и забыли переключить VM Options → Boot Options → Firmware на EFI, вы будете искать проблему в провайдере ключей, которого она не касается. И да, ВМ должна быть выключена.

Если в vpxd.log видно NativeKeyProviderNotSupported — проблема на стороне провайдера или топологии кластера, а не в железе. Начинайте с проверки Set as Default и членства хоста в кластере, это две самые дешёвые гипотезы.
vCenter 9: Native Key Provider создан, а vTPM не добавляется — покупать TPM для хоста не надо — схема
Схема к статье. Открыть схему в полном размере

Галочка Use key provider only with TPM protected ESXi hosts — главная ловушка

При создании Native Key Provider в мастере есть скромный чекбокс: «Use key provider only with TPM protected ESXi hosts». Он не обязателен. Но выглядит он как рекомендация, и половина администраторов ставит его по принципу «звучит безопаснее, пусть будет». Через десять минут эти же люди пишут в чат, что vTPM не добавляется ни на одной машине кластера. Логика проста и жестока: галочка ограничивает область действия провайдера хостами, у которых включён физический TPM 2.0. Нет TPM на хосте — провайдер туда не приедет, ВМ на этом хосте зашифровать нечем, vTPM добавить нельзя.

Скажу прямо, где эта галочка спорная. С точки зрения безопасности она осмысленна: ключ провайдера (KDK), который vCenter раздаёт хостам и из которого ESXi сам выводит ключи шифрования даже без связи с vCenter, на хосте с TPM 2.0 защищён чипом, а на хосте без TPM такой аппаратной привязки нет. То есть галочка реально повышает планку против кражи самого сервера или его загрузочного носителя. Но она же превращает провайдер в жёсткий фильтр по железу, а в парке из пяти хостов, где два куплены до 2018 года, это моментальная блокировка проекта. Я включаю её только там, где весь кластер однороден и TPM 2.0 гарантированно включён на каждом узле — и где заказчик понимает, что новый разнородный хост в такой кластер просто так не воткнуть.

Теперь неприятное. Отредактировать эту настройку у существующего провайдера нельзя — в свойствах готового NKP такого переключателя нет, а штатное «обновление» провайдера через PowerCLI (Set-KeyProvider) меняет только ключ, а не ограничение по TPM. По KB 369538 путь ровно один: сделать Back Up провайдера, удалить его, восстановить из бэкапа и при восстановлении снять ограничение TPM-only. Порядок действий — в следующем абзаце, а тот же сценарий в PowerCLI выглядит так:

$kp = Get-KeyProvider -Name 'nkp-main'
Export-KeyProvider -KeyProvider $kp -FilePath 'D:\secure\nkp-main.p12' -Password (Read-Host -AsSecureString)
# удаление провайдера — в vSphere Client, после проверки файла бэкапа
Import-KeyProvider -FilePath 'D:\secure\nkp-main.p12' -Password (Read-Host -AsSecureString) -DryRun
Import-KeyProvider -FilePath 'D:\secure\nkp-main.p12' -Password (Read-Host -AsSecureString)

Ключ -TpmRequired у Import-KeyProvider как раз и включает ограничение TPM-only — при восстановлении его просто не указываете. Прогон с -DryRun проверяет файл и пароль без создания провайдера.

Сначала бэкап: Key Providers → выбрать провайдер → Back Up → задать пароль → сохранить файл PKCS#12 в надёжное место, желательно в парольный менеджер, а не в папку «Разное» на рабочем столе. Затем удаление провайдера. Затем Add → Restore Native Key Provider, указываете тот же файл и пароль, и на этом шаге не ставите галочку TPM-only. После восстановления обязательно проверьте, что провайдер снова помечен по умолчанию, и при необходимости нажмите Set as Default — иначе рискуете упереться в причину номер один сразу после того, как вылечили причину номер три.

Опасный момент: если провайдером уже зашифрованы ВМ или к ним прицеплен vTPM, удаление провайдера без действующего бэкапа означает безвозвратную потерю доступа к этим машинам. Сначала убедитесь, что файл PKCS#12 существует, что вы помните пароль и что он лежит вне того же vCenter. Только потом жмите Delete.
Порядок действий: Галочка Use key provider only with TPM protected ESXi hosts — главная ловушка — схема
Порядок действий: Галочка Use key provider only with TPM protected ESXi hosts — главная ловушка. Открыть схему в полном размере

Standalone-хост: Native Key Provider живёт только в кластере

Это второе ограничение, о котором почти не пишут в популярных инструкциях, а оно ломает ровно те сценарии, где vTPM нужен чаще всего — небольшие внедрения. По KB 369538 хост обязан входить в vSphere-кластер: standalone-хосты, добавленные в vCenter прямо в объект Datacenter, Native Key Provider не поддерживают. Провайдер вы создадите, он будет виден и даже помечен как default, но конкретный хост его не получит, и любая попытка выдать ВМ на этом хосте vTPM закончится NativeKeyProviderNotSupported.

Лечится это тривиально и бесплатно: создаёте объект Cluster внутри датацентра и перетаскиваете туда хост. Кластер из одного хоста — совершенно легальная конфигурация. Включать vSphere HA и DRS при этом не обязательно, лицензии на них не нужны, сам факт членства в кластере достаточен. У меня в проектах на два-три хоста кластер создаётся всегда, даже когда никакой отказоустойчивости не планируется: это бесплатно и снимает целый класс будущих вопросов, включая этот.

Отдельная ловушка — регресс. Хост выводили в maintenance для замены памяти, отсоединяли от vCenter, а потом добавили обратно, но не в кластер, а рядом с ним. Внешне всё зелёное, ВМ работают. И только через две недели, когда кто-то создаёт новую Windows 11 именно на этом хосте, всплывает отказ. Если у вас после планового обслуживания вдруг перестал добавляться vTPM только на одной машине — первым делом посмотрите, в кластере ли её хост, а не в корне датацентра.

Практический вывод: единственный хост в датацентре — это не повод отказываться от vTPM. Это повод за минуту создать вокруг него кластер.

Бэкап провайдера — не гигиена, а условие запуска

По KB 396471 «Configure vSphere Native Key Provider» свежесозданный провайдер получает статус Not backed up и в таком состоянии не может использоваться. Это не рекомендация из раздела «хорошие практики», это блокирующее условие. Люди регулярно спотыкаются именно тут: провайдер создан, галочку TPM-only не ставили, хост в кластере, всё правильно — а vTPM не даётся, потому что кнопку Back Up никто не нажал. Проверяется за пять секунд по колонке статуса в списке провайдеров. Пока бэкапа нет, vCenter поднимает алерт, и даже если его закрыть, он возвращается каждые 24 часа. После бэкапа статус проходит Warning (vCenter раздаёт провайдер хостам) и становится Active.

Сам бэкап — это файл в формате PKCS#12 (.p12). Пароль задаётся галочкой «Protect Native Key Provider data with password» и формально опционален, ставьте всегда: без пароля вы получаете файл, который в одиночку даёт доступ к ключам шифрования всех ваших защищённых ВМ, и хранить его придётся так же строго, как ключи от сейфа. С паролем это уже двухфакторная история. Храните файл вне контура vCenter — в парольном менеджере компании или в офлайновом хранилище. Классический провал: бэкап NKP лежит на файловой шаре внутри той же виртуальной инфраструктуры, которую он же и разблокирует. Потеряли vCenter вместе с датастором — потеряли и бэкап.

Важно понимать модель отказа. Пока хосты живы и хранят ключ провайдера, машины с vTPM продолжают работать и даже перезагружаться: ESXi выводит ключи сам, без связи с vCenter. Беда начинается, когда vCenter умер окончательно, а бэкапа провайдера нет — ни файла .p12, ни file-based бэкапа VCSA, который тоже сохраняет NKP. Новый vCenter создаст новый провайдер с другим ключом, и ВМ с vTPM, чей файл NVRAM зашифрован старым ключом, не включатся после переустановки или замены хоста, переноса на другие хосты или в другой vCenter. Спасти такую машину можно только удалив vTPM — вместе с ним пропадают ключи BitLocker, Windows Hello и прочие секреты гостя. Файл .p12 с паролем — это то, что возвращает их к жизни на новом vCenter.

Автоматизировать проверку удобно через PowerCLI. В модулях есть набор командлетов — Get-KeyProvider, Set-KeyProvider, Export-KeyProvider, Import-KeyProvider, Register-KeyProvider и Unregister-KeyProvider (командлета New-KeyProvider нет, Native Key Provider создают в vSphere Client). Синтаксис под свою сборку сверяйте через Get-Help, а не копируйте из блогов вслепую:

Connect-VIServer vcenter.example.local
Get-KeyProvider -Type NativeKeyProvider | Format-List *
Export-KeyProvider -KeyProvider (Get-KeyProvider -Name 'nkp-main') -FilePath 'D:\secure\nkp-main.p12' -Password (Read-Host -AsSecureString)
Get-Help Import-KeyProvider -Full

Минимальный полезный контроль — раз в квартал прогонять Get-KeyProvider и глазами проверять, что провайдер по умолчанию тот, что нужно, и статус не Not backed up.

Если в вашей организации есть регламент хранения ключей — файл бэкапа NKP должен попасть в него отдельной строкой. По моему опыту, это самая часто теряемая сущность во всей vSphere: её создают один раз при внедрении и больше не вспоминают до аварии.

Разбор из практики: «Смета и форма», 40 рабочих мест и миграция на Windows 11

Осенью прошлого года ко мне пришла проектная компания «Смета и форма»: 40 рабочих мест, из них 18 — сметчики и бухгалтерия на тонких клиентах к терминальному серверу, остальные 22 — конструкторы и ГИПы с персональными виртуалками в VDI-подобной схеме на трёх хостах. Задача была понятная и срочная: расширенная поддержка Windows 10 у них не продлевалась, парк надо было переводить на Windows 11, а установщик Windows 11 требует TPM 2.0. Собственный админ развернул vCenter, создал Native Key Provider, упёрся в отказ добавления vTPM и подготовил заявку на закупку: три TPM-модуля под материнские платы плюс работы по установке, суммарно порядка 90 тысяч рублей и три недели ожидания поставки под заказ.

Стенд был такой: три хоста — два Dell PowerEdge R650 (2021 год, TPM 2.0 на плате есть, но в BIOS он был выключен) и один R630 2016 года без модуля вообще. Все три на ESXi 8.0 U3 под свежеобновлённым vCenter 9. Два R650 лежали в кластере PROD, а R630 держали отдельно под тестовые задачи — и в инвентаре он висел прямо в датацентре, без кластера. Первое, что я увидел в списке провайдеров: статус Not backed up. Второе — в свойствах провайдера значилось ограничение по TPM. Классический комплект из всех трёх причин KB 369538 сразу.

Разбирали по порядку и уложились в один вечер, без окна простоя для боевых ВМ. Нажали Back Up с паролем, файл PKCS#12 положили в корпоративный парольный менеджер и продублировали на офлайновый носитель в сейфе. Удалили провайдер — зашифрованных ВМ на тот момент не было ни одной, риск нулевой. Восстановили из бэкапа без галочки TPM-only. Назначили Set as Default. Хост R630 завернули в новый кластер TEST из одного узла, HA и DRS не включали. Статус провайдера прошёл Warning и стал Active. Выждали пять минут, как рекомендует KB 396471, и на тестовой ВМ с прошивкой EFI устройство Trusted Platform Module добавилось с первого раза — включая ту машину, что стояла на R630 вообще без физического TPM.

Итог: заявку на закупку отозвали, 90 тысяч рублей остались в бюджете, миграция стартовала на неделю раньше плана. Что при этом сделали дополнительно и считаю правильным: на обоих R650 включили TPM 2.0 в BIOS всё равно — не ради vTPM, а ради нормальной аттестации хостов на будущее, если заказчик дорастёт до vSphere Trust Authority. Параллельно убедились, что ежедневный file-based бэкап VCSA уходит на внешнее хранилище, а не на датастор того же кластера. И записали бэкап провайдера в регламент: проверка статуса раз в квартал, перевыпуск и перекладка файла — при каждом мажорном обновлении vCenter. Единственное, о чём я предупредил заказчика честно: пока весь парк хостов не станет однородным по TPM, включать ограничение TPM-only в провайдере нельзя, иначе R630 моментально выпадет из схемы.

Если у вас разнородный парк хостов — часть с TPM, часть без — не включайте ограничение TPM-only ни при каких уговорах. Вы получите кластер, в котором vTPM работает через раз в зависимости от того, куда DRS переселил машину.
Цифры и версии: Разбор из практики: «Смета и форма», 40 рабочих мест и миграция на Windows 11 — схема
Цифры и версии: Разбор из практики: «Смета и форма», 40 рабочих мест и миграция на Windows 11. Открыть схему в полном размере

Чек-лист: что делаю по шагам и на что можно забить

Порядок действий, который я прогоняю на любом стенде, где не добавляется vTPM, занимает минут десять и в подавляющем большинстве случаев закрывает вопрос без единой закупки. Сначала — три пункта из KB 369538, потом — прошивка и состояние самой ВМ, и только в самом конце, если ничего не помогло, разговор про железо. Обратная последовательность — самая дорогая ошибка в этой теме.

Что можно спокойно отложить. Аттестация хостов и vSphere Trust Authority — это отдельный большой проект, который не нужен для того, чтобы Windows 11 просто установилась; браться за него ради vTPM нет смысла. Внешний KMS-сервер тоже избыточен для компании до 50 рабочих мест: Native Key Provider бесплатен, встроен и полностью закрывает сценарий шифрования ВМ и vTPM, а внешний KMS — это ещё одна отказоустойчивая система, которую надо кому-то обслуживать. Полное шифрование дисков виртуальных машин можно не включать: vTPM работает и на незашифрованной ВМ, шифруется только файл NVRAM с секретами гостя.

На что забивать нельзя. На бэкап провайдера — это условие работы, а не украшение. На проверку default-провайдера после любых манипуляций с ключами. И на дисциплину однородности кластера: если вы включили TPM-only, любой новый хост без включённого в BIOS TPM 2.0 тихо выпадет из схемы, и обнаружится это в самый неподходящий момент — при vMotion во время планового обслуживания.

Если после всех шагов vTPM всё равно не добавляется — снимите свежий фрагмент vpxd.log и идите в поддержку с ним, а не с гипотезой про TPM-модули. Диагноз по логу ставится за минуты, а закупка железа «на всякий случай» стоит денег и не решает исходную проблему.

Частые вопросы

Нужен ли физический TPM 2.0 на хосте ESXi, чтобы добавить виртуальной машине vTPM?

Нет. Секреты vTPM хранятся в зашифрованном файле NVRAM рядом с виртуальной машиной, а ключ выдаёт провайдер ключей из vCenter. Аппаратный TPM хоста нужен для аттестации доверенной загрузки и vSphere Trust Authority, а также обязателен, если вы сами включили на провайдере ограничение Use key provider only with TPM protected ESXi hosts. Для самого vTPM он не требуется — виртуалки с vTPM спокойно работают даже на вложенном ESXi.

Можно ли снять галочку TPM-only у уже созданного Native Key Provider?

В свойствах готового провайдера такого переключателя нет, а Set-KeyProvider в PowerCLI меняет только ключ. По KB 369538 порядок такой: сделать Back Up провайдера с паролем, удалить провайдер, восстановить его из файла PKCS#12 и на шаге восстановления не ставить ограничение (в PowerCLI — Import-KeyProvider без ключа -TpmRequired). После восстановления проверьте признак провайдера по умолчанию и при необходимости снова нажмите Set as Default. И убедитесь, что бэкап действительно рабочий, до удаления.

Почему vTPM не добавляется на standalone-хосте?

Native Key Provider по KB 369538 поддерживается только на хостах, входящих в vSphere-кластер. Хост, добавленный в vCenter прямо в объект Datacenter, провайдер не получит, и в vpxd.log будет NativeKeyProviderNotSupported. Решение бесплатное: создайте кластер и перенесите туда хост. Кластер из одного узла допустим, включать HA и DRS для этого не нужно.

Что произойдёт с машинами с vTPM, если vCenter умрёт?

Пока хосты работают и хранят ключ провайдера, ВМ с vTPM продолжают запускаться: ESXi выводит ключи сам, без vCenter. Но если vCenter потерян без бэкапа Native Key Provider (файла .p12 или file-based бэкапа VCSA), новый vCenter не сможет восстановить тот же ключ — после переустановки хоста или переноса на другие хосты такие ВМ не включатся, и спасти их можно только удалив vTPM вместе с секретами гостя (BitLocker и т. п.). Поэтому файл бэкапа обязан храниться с паролем и вне той инфраструктуры, которую он разблокирует.

Провайдер создан правильно, а vTPM всё равно не предлагается в списке устройств. Что ещё смотреть?

Проверьте три вещи. Первая: прошивка виртуальной машины должна быть EFI, к машине на BIOS vTPM не добавляется. Вторая: машина должна быть выключена. Третья: у вашей учётной записи должны быть привилегии Cryptographic operations, включая Manage key servers, — под ограниченной ролью пункт просто не отображается. И проверьте статус провайдера: если он Not backed up, использовать его нельзя.

Стоит ли ставить внешний KMS вместо Native Key Provider небольшой компании?

Для компании до 50 рабочих мест — как правило, нет. Native Key Provider доступен начиная с vSphere 7.0 Update 2, встроен в vCenter 8 и 9 и по документации Broadcom позволяет включать vTPM во всех редакциях vSphere; для шифрования дисков ВМ понадобится Enterprise Plus. Внешний KMS — это ещё одна система, которую надо резервировать и обслуживать. Смысл в нём появляется, когда есть требования регулятора к внешнему хранению ключей или когда нужен один KMS на несколько vCenter.

Какую лицензию vSphere нужно иметь, чтобы пользоваться Native Key Provider для vTPM?

По документации Broadcom Native Key Provider позволяет включать vTPM во всех редакциях vSphere начиная с 7.0 Update 2. Отдельная лицензия нужна только если вы хотите шифровать сами виртуальные машины и их диски — это функция vSphere Enterprise Plus. Для установки Windows 11 или включения BitLocker внутри Windows Server 2025 на vTPM достаточно имеющейся редакции.

Столкнулись с похожей задачей? Обращайтесь — решим

Если у вас происходит что-то из описанного в этой статье — или любая другая проблема с ИТ-инфраструктурой, — обращайтесь в любое время. Мои специалисты и я лично разберём ситуацию, найдём настоящую причину и доведём до решения.

Возьмёмся и за разовую задачу, и за постоянное обслуживание. Первичная консультация — бесплатно и без обязательств.

📞 +7 903 729-62-41 💬 MAX: +7 903 729-62-41 ✈ Telegram @ITfresh_Boss

С уважением, Семёнов Евгений Сергеевич, директор «АйТи Фреш» — IT-аутсорсинг для компаний до 50 рабочих мест, 15+ лет практики

Источники

© ООО «АйТи-Фреш» · Москва · Все статьи