System Center 2022 VMM и неактуальный перечень версий ОС Linux в свойствах ВМ

Если вы работаете с System Center VMM и используете в качестве гостевых ОС в управляемых виртуальных машинах современные версии Linux систем, то, наверняка, могли заметить, что в VMM в свойствах ВМ нет возможности указания некоторых последних версий этих ОС. Как правило, этот перечень ОС, расширялся в релизных версиях VMM при переходе между разными линейками System Center. Но крайне редко этот перечень обновлялся с установкой очередного кумулятивного обновления к VMM. В итоге практически всегда в VMM приходится работать с неактуальным списком версий ОС.

Такая ситуация с перечнем ОС имеет довольно давние корни и уже стала фактически традицией для VMM. Порой дело доходило до смешного – когда в официальной документации к Hyper-V была обозначена поддержка той или иной версии Linux, а в консоли управления VMM эта версия Linux отсутствовала. У некоторых коллег это не могло не вызывать вопросов.

После недавней миграции на System Center 2022 VMM стало понятно, что даже в самой "модной" версии VMM эта проблема имеет свой прежний вид и все ВМ с новыми Linux системами приходится обозначать как "Other Linux (64-bit)". Оно, конечно, жить не мешает и на функциональность ВМ по сути не влияет, но тяга к прекрасному заставляет идти на разные авантюры, как, например, поступил автор статьи "Adding New Operating Systems to Virtual Machine Manager". Он поведал нам о том, как он прямой правкой БД накормил VMM расширенным перечнем ОС, совместимым с VMWare API 6.7, до такой степени, что консоль VMM в конечном итоге перестала работать.

По началу метод прямой правки БД вызвал у меня некоторые сомнения, но позже я нашёл одну архивную статью "New KB: System Center Virtual Machine Manager 2008 R2 identifies Windows 2000 virtual machine Operating System as Unknown", где упоминалась статья базы знаний Microsoft KB2025530. Самой этой статьи я найти не смог, но есть другая старая статья "SCVMM 2008 R2 identifie les machines virtuelles Windows 2000 comme inconnue", которая косвенно подтверждает предположение о том, что в KB2025530 был описан метод прямой правки БД VMM для редактирования перечня ОС, как вполне допустимое явление.

Ну что же, попробуем повторить этот фокус, разумеется, не забыв предварительно сделать резервную копию БД VMM.

Подключимся к БД VMM и следующим SQL-запросом получим полный перечень ОС из таблицы tbl_IL_OS:

SELECT * FROM [VirtualManagerDB].[dbo].[tbl_IL_OS]

Для System Center 2022 CU1 VMM СУБД вернёт нам 113 строк.

В нашей ситуации в перечне ОС отсутствует пара версий ОС, используемых у нас в VMM, -  Debian GNU/Linux 11 и Debian GNU/Linux 12. Попробуем их добавить.

Если в целом структура данных в таблице более или менее понятна, то поначалу было сомнение в том, как именно генерировать идентификатор в колонке OSId. Но когда я присмотрелся к данным этой колонки, то увидел "пасхалку" (эти идентификаторы никак нельзя назвать сгенерированными), после которой возникло предположение, что в поле можно записать любую отсебятину, которая, как минимум, должна быть уникальна в рамках таблицы.

Итак, для вставки в таблицу новой записи для ОС "Debian GNU/Linux 11 (64 bit)" можем выполнить SQL-запрос следующего вида:

INSERT INTO [VirtualManagerDB].[dbo].[tbl_IL_OS] (OSId, Name, Description, Edition, ProductType, Version, Architecture, OSFlags, VMWareGuestId, OSType)
VALUES (NEWID(), 'Debian GNU/Linux 11 (64 bit)', 'Debian GNU/Linux 11 (64 bit)', NULL, NULL, NULL, 'amd64', 28, 'debian11_64Guest', 1)

Второй пример запроса для вставки "Debian GNU/Linux 12 (64 bit)":

INSERT INTO [VirtualManagerDB].[dbo].[tbl_IL_OS] (OSId, Name, Description, Edition, ProductType, Version, Architecture, OSFlags, VMWareGuestId, OSType)
VALUES (NEWID(), 'Debian GNU/Linux 12 (64 bit)', 'Debian GNU/Linux 12 (64 bit)', NULL, NULL, NULL, 'amd64', 28, 'debian12_64Guest', 1)

Проверяем результат, отобрав записи только по интересующей нас ОС:

SELECT * FROM [VirtualManagerDB].[dbo].[tbl_IL_OS] WHERE Name LIKE 'debian%' ORDER BY Name

В результате мы должны увидеть добавленные в таблицу строки

Теперь, чтобы проверить результат в консоли VMM, перезапустим консоль, если она была открыта ранее.

В свойствах ВМ теперь появился выбор добавленной нами версии ОС:

Первичные тесты показали, что после добавления пары новых ОС и назначения их в свойствах ВМ, консоль VMM работает вполне штатно. Миграция ВМ между хостами кластера, инициированная из VMM, никаких проблем не также не выявила. Поэтому, можно предположить, что данный способ - работоспособный.

Однако следует понимать, что такое вмешательство в БД ни в коем разе не является поддерживаемой Microsoft процедурой и гипотетически может "выстрелить" в перспективе, например, при развёртывании очередного CU к VMM, где в ходе обновления будет предпринята попытка расширения перечня ОС.