Новости Статьи VMware Veeam StarWind vStack Microsoft Nakivo Citrix Symantec События Релизы Видео Контакты Авторы RSS
Виртуализация и виртуальные машины

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

Более 6180 заметок о VMware, AWS, Azure, Veeam, Kubernetes и других

VM Guru | Ссылка дня: Какие есть версии и номера билдов VMware vCenter, ESXi, Tools и Connection Server?

Редактирование настроек SMBIOS (hardware manufacturer и vendor) для виртуального (Nested) VMware ESXi 


Вильям Лам написал интересную статью о том, как можно редактировать настройки SMBIOS для вложенного/виртуального (Nested) VMware ESXi в части hardware manufacturer и vendor.

Nested ESXi продолжает оставаться полезным ресурсом, который часто используется администраторами: от прототипирования решений, воспроизведения проблем клиентов до автоматизированных развертываний лабораторий, поддерживающих как VMware Cloud Foundation (VCF), так и VMware vSphere Foundation (VVF).

Хотя с помощью Nested ESXi можно сделать почти все, но имитировать или симулировать конкретные аппаратные свойства, такие как производитель или поставщик (hardware manufacturer и vendor), не совсем возможно или, по крайней мере, очень сложно. Коллега Вильяма Люк Хакаба нашел хитрый трюк, играя с настройками загрузочных ROM виртуальной машины по умолчанию, которые поставляются с ESXi и VMware Desktop Hypervisors (платформы Workstation/Fusion).

Виртуальная машина vSphere может загружаться, используя либо BIOS, либо EFI прошивку, поэтому в зависимости от желаемого типа прошивки вам нужно будет изменить либо файл BIOS.440.ROM, либо EFI64.ROM. Эти файлы ROM можно найти в следующих каталогах для соответствующих гипервизоров VMware:

  • ESXi: /usr/lib/vmware/roms
  • VMware Fusion: /Applications/VMware Fusion.app/Contents/Library/roms
  • VMware Workstation: C:\Program Files (x86)\VMware\VMware Workstation\x64

Примечание: не редактируйте файлы ROM по умолчанию, которые поставляются с гипервизором VMware, сделайте их копию и используйте измененную версию, которую могут использовать виртуальные машины в VMware vSphere, Fusion или Workstation. Кроме того, хотя эта статья посвящена виртуальной машине Nested ESXi, это также должно работать и на других гостевых операционных системах для отображения информации SMBIOS.

Редактирование BIOS

Шаг 1 - Скачайте и установите Phoenix BIOS Editor. Установщик Phoenix BIOS Editor имеет проблемы при запуске на системе Windows Server 2019, и единственным способом завершить установку - это изменить совместимость приложения на Windows 8, что позволит успешно завершить установку.

Шаг 2 - Скачайте и откройте файл BIOS.440.ROM с помощью Phoenix BIOS Editor, затем перейдите на панель DMI Strings для изменения нужных полей.

Когда вы закончите вносить все изменения, перейдите в меню "Файл" и нажмите "Собрать BIOS" (Build BIOS), чтобы создать новый файл ROM. В данном примере это файл BIOS.440.CUSTOM.ROM.

Шаг 3 - Скопируйте новый файл ROM в хранилище вашего физического хоста ESXi. Вы можете сохранить его в общей папке, чтобы использовать с несколькими виртуальными машинами Nested ESXi, ИЛИ вы можете сохранить его непосредственно в папке отдельной виртуальной машины Nested ESXi. Второй вариант позволит вам повторно использовать один и тот же кастомный файл ROM в нескольких виртуальных машинах, поэтому, с точки зрения тестирования, возможно, вам захочется создать несколько файлов ROM в зависимости от ваших нужд и просто перенастроить виртуальную машину для использования нужного файла ROM.

Шаг 4 - Чтобы кастомный файл ROM мог быть использован нашей виртуальной машиной Nested ESXi, нам нужно добавить следующую дополнительную настройку (Advanced Setting) виртуальной машины, которая указывает путь к нашему кастомному файлу ROM:

bios440.filename = "BIOS.440.CUSTOM.ROM"

Шаг 5 - Наконец, мы можем включить нашу виртуальную машину Nested ESXi, и теперь мы должны увидеть кастомную информацию SMBIOS, как показано на скриншоте ниже.

Редактирование EFI

Шаг 1 - Скачайте и установите HEX-редактор, который может редактировать файл EFI ROM. Например, ImHex - довольно удобный с точки зрения редактирования, но поиск определенных строк с помощью этого инструмента является нетривиальной задачей.

Шаг 2 - Скачайте и откройте файл EFI64.ROM с помощью редактора ImHex и найдите строку "VMware7,1". Как только вы найдете расположение этой строки, вам нужно аккуратно отредактировать значения hex, чтобы получить желаемые ASCII строки.

Кроме того, вы можете использовать UEFITool (версия 28 позволяет модифицировать ROM), который имеет гораздо более удобный и функциональный поиск, а также позволяет извлекать часть файла ROM для редактирования с помощью HEX-редактора. В этой утилите можно использовать поиск (CTRL+F), и как только он находит нужный раздел, двойным щелчком по результату переходите к точному месту в файле ROM. Чтобы извлечь раздел для редактирования, щелкните правой кнопкой мыши и выберите "Extract as is" и сохраните файл на рабочий стол.

Затем вы можете открыть конкретный раздел с помощью ImHex, чтобы внести свои изменения.

После того как вы сохранили свои изменения, не теряйте указатель в UEFITool. Теперь мы просто заменим раздел нашим измененным файлом, щелкнув правой кнопкой мыши и выбрав "Replace as is", указав измененный раздел. Вы можете подтвердить, что изменения были успешными, просто найдя строку, которую вы заменили. Затем перейдите в меню "Файл" и выберите "Сохранить образ файла" (Save image file), чтобы создать новый файл ROM. В данном случае - это файл EFI64.CUSTOM.ROM.

Шаг 3 - Скопируйте новый файл ROM в хранилище вашего физического хоста ESXi. Вы можете сохранить его в общей папке, чтобы использовать с несколькими виртуальными машинами Nested ESXi, ИЛИ вы можете сохранить его непосредственно в папке отдельной виртуальной машины Nested ESXi.

Шаг 4 - Чтобы наш кастомный файл ROM мог быть использован виртуальной машиной Nested ESXi, нам нужно добавить следующую дополнительную настройку ВМ в файл vmx, которая указывает путь к нашему кастомному файлу ROM:

efi64.filename = "EFI64.CUSTOM.ROM"

Шаг 5 - Наконец, мы можем включить виртуальную машину Nested ESXi, и теперь мы должны увидеть кастомную информацию SMBIOS.

Как видно на скриншоте, Вильяму удалось изменить только модель оборудования, но не значение вендора.

Примечание: хотя автору и удалось найти строку "VMware, Inc." для вендора, изменение значения не оказало никакого эффекта, как показано на скриншоте выше, что, вероятно, указывает на то, что эта информация может храниться в другом месте или содержаться в каком-то встроенном файле.


Таги: VMware, VMachines, ESXi, Hardware, Nested, Blogs

Состояние автоподключения сетевого адаптера vmnic виртуальной машины при ее старте - статус StartConnected


Оказывается у сетевого адаптера виртуальной машины vmnic есть свойство, определяющее, будет ли он автоматически присоединяться к виртуальной машине при ее запуске. Свойство это называется StartConnected, оно может быть не установлено по каким-то причинам, что может привести к проблемам.

Как написал Farnky, проверить это свойство у всех виртуальных машин в окружении vCenter можно следующей командой:

#Get-VM "your target VM" | Get-NetworkAdapter | Set-NetworkAdapter -StartConnected $true -confirm:$false | select Parent, ConnectionState | Format-List

Если вы увидите в результатах значение NoStartConnected, значит этот адаптер vmnic не будет подключен при запуске ВМ:

 

Исправить эту ситуацию можно следующей командой:

#Get-VM "your target VM" | Get-NetworkAdapter | Set-NetworkAdapter -StartConnected $true -confirm:$false | select Parent, ConnectionState | Format-List


Таги: VMware, VMachines, vNetwork, Blogs

UTM - настольная платформа виртуализации для Apple macOS и iOS


Те из вас, кто работает на компьютерах Apple Mac, часто используют виртуальные машины Windows, которые запускаются в виртуальных средах VMware Fusion и Parallels Desktop.

Однако Eric Sloof недавно обратил внимание на интересный продукт - платформу виртуализации UTM.

UTM предназначен для создания и запуска виртуальных машин на устройствах Apple. Это комплексный системный эмулятор и хост виртуальных машин, специально разработанный для iOS и macOS. Созданный на мощной платформе QEMU, UTM позволяет пользователям быстро запускать различные операционные системы, такие как Windows и Linux, на устройствах Mac, iPhone и iPad.

UTM является настоящим открытием для пользователей Apple Silicon (процессоры M1/M2). Он использует фреймворк виртуализации Hypervisor от Apple, позволяя операционным системам ARM64 работать на скоростях, почти идентичных скорости нативной работы.

Для владельцев Mac на Intel доступна возможность виртуализации операционных систем x86/x64. Но на этом возможности UTM не заканчиваются - он также предлагает менее производительную эмуляцию для запуска x86/x64 на Apple Silicon и ARM64 на Intel. Эта универсальность расширяется за счет поддержки ряда других эмулируемых процессоров, включая ARM32, MIPS, PPC и RISC-V, делая ваш Mac по-настоящему универсальной платформой.

UTM не только про современные ОС - он также способен вдохнуть жизнь и в классические операционные системы. Будь то старая система PowerPC, SPARC или x86_64, UTM позволяет запускать их на разных платформах в виде виртуальных машин. Любопытные пользователи могут посмотреть галерею, где представлены различные системы, которые может эмулировать UTM.

Вот, например, эмуляция MacOS 9.2.1:

Пользователи Mac на Apple Silicon могут вывести виртуализацию на новый уровень с помощью UTM. Он позволяет запускать несколько экземпляров macOS, что особенно полезно для разработчиков и пользователей, ориентированных на безопасность. Однако эта функция доступна исключительно на Mac на базе ARM с установленной macOS Monterey или более новой версией.

UTM выделяется среди другого ПО для виртуализации благодаря своему дизайну, который создан исключительно для macOS и платформ Apple. Он гармонично сочетается со стилем Big Sur, предлагая пользовательский опыт, который действительно напоминает Mac, включая все ожидаемые функции конфиденциальности и безопасности.

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

Скачать UTM для ваших Apple-устройств можно по этой ссылке.


Таги: UTM, MacOS, iOS, Apple, VMachines

Как предотвратить исполнение виртуальных машин vCLS на Failover-хосте VMware vSphere HA


Дункан Эппинг опубликовал интересный пост о том, как предотвратить исполнение виртуальных машин vCLS на VMware vSphere HA Failover Host. Напомним, что vSphere Clustering Service (vCLS) - это служба, которая позволяет организовать мониторинг доступности хостов кластера vSphere, без необходимости зависеть от служб vCenter. Она реализуется тремя агентскими виртуальными машинами в кластере, где 3 или более хостов, и двумя, если в кластере два хоста ESXi. Три машины нужны, чтобы обеспечивать кворум (2 против 1) в случае принятия решения о разделении кластера.

Для тех, кто не знает, сервер vSphere HA Failover Host — это хост, который используется, когда происходит сбой и vSphere HA должен перезапустить виртуальные машины. В некоторых случаях клиенты (обычно партнеры в облачных решениях) хотят предотвратить использование этих хостов для любых рабочих нагрузок, поскольку это может повлиять на стоимость использования платформы.

К сожалению, в пользовательском интерфейсе вы не можете указать, что машины vCLS не могут работать на определенных хостах, вы можете ограничить работу ВМ vCLS рядом с другими виртуальными машинами, но не хостами. Однако есть возможность указать, на каких хранилищах данных могут находиться виртуальные машины, и это может быть потенциальным способом ограничения хостов, на которых могут работать эти ВМ. Как?

Если вы создадите хранилище данных, которое недоступно назначенному Failover-хосту vSphere HA, то машины vCLS не смогут работать на этом хосте, так как хост не сможет получить доступ к датастору. Это обходной путь для решения проблемы, вы можете узнать больше о механизме размещения хранилищ данных для vCLS в этом документе. Обратите внимание, что если остальная часть кластера выйдет из строя и останется только Failover-хост, виртуальные машины vCLS не будут включены. Это означает, что механизм балансировки нагрузки VMware DRS также не будет функционировать, пока эти ВМ недоступны.


Таги: VMware, vSphere, HA, vCLS, VMachines, DRS, Blogs

Российские платформы виртуализации - сравнение от TAdviser и Softline


Мы помним, что некоторые из вас просили рассказать о российских альтернативах платформам виртуализации от ведущих мировых вендоров. Оказывается, еще в 2022 году компании TAdviser и Softline подготовили подробное описание и сравнение российских платформ виртуализации по разным критериям, которое является хорошей отправной точкой для тех, кто больше не имеет возможности использовать продукты VMware.

Вот основные ссылки на информацию о российских производителях ПО для серверной виртуализации:

Ну а вот результаты сравнения этих платформ:

Обратите внимание, что данное исследование и сравнение сделано в декабре 2022 года, с тех пор многое могло измениться (в зависимости от активности разработчиков).

Полную версию этого отчета на 47 страницах можно скачать по этой ссылке (нужно заполнить форму внизу страницы):


Таги: VMachines

Скрипт для быстрого изменения SCSI-контроллера виртуальной машины на платформе VMware vSphere


На сайте VMware Developer появился полезный сценарий PowerCLI, который позволяет администратору изменить текущий контроллер SCSI на новый тип для виртуальной машины на платформе VMware vSphere.

Некоторые особенности работы этого сценария:

  • Не проверяет, настроена ли виртуальная машина для 64-битной гостевой ОС (адаптер BusLogic не поддерживается)
  • Ппроверяет, работают ли VMware Tools и выключает виртуальную машину с помощью функции выключения гостевой ОС
  • Возвращает виртуальную машину в предыдущее рабочее состояние
  • Проверяет, было ли уже установлено новое значение контроллера SCSI

Функция Modify-ScsiController вызывается в самом конце скрипта. Вот различные примеры того, как функция может быть использована:

Скачать данный сценарий можно по этой ссылке.


Таги: VMware, PowerCLI, Storage, Hardware, VMachines

5 способов закрыть неотвечающую виртуальную машину в VMware vSphere из консоли ESXi


Администраторы виртуальной инфраструктуры VMware vSphere время от времени сталкиваются с проблемой завершения зависших виртуальных машин. Если в клиенте vSphere Client сделать этого не удаются, приходится заходить в сервисную консоль ESXi или в командную строку PowerCLI/PowerShell и проводить там операции по завершению процесса этой ВМ. Сегодня мы расскажем о 5 способах, которыми это можно сделать.

1. С использованием PowerCLI

Stop-VM - это командлет, используемый для завершения работы виртуальной машины. На самом деле он используется для выключения ВМ, но добавление параметра kill приведет к завершению соответствующих процессов ВМ на ESXi, фактически уничтожая ее. Делается это так:

Stop-VM -kill <отображаемое имя ВМ> -Confirm:$false

2. С использованием esxcli

Esxcli - это интерфейс командной строки (CLI), который предоставляет доступ к ряду пространств имен, таких как vm, vsan, network и software, позволяя выполнять задачи, изменять настройки и так далее. Таким образом, если вам нужно завершить работу неотвечающей виртуальной машины с использованием esxcli, можно действовать следующим образом:

  • Получить список виртуальных машин, размещенных на ESXi:

esxcli vm process list

Красным выделен идентификатор World ID виртуальной машины.

  • Скопируйте значение World ID и выполните команду:

esxcli vm process kill --type=soft -w=796791

Команда не выдает никакой обратной связи, кроме случаев, когда она не сможет найти виртуальную машину или вы укажете неверный параметр.

Параметр type принимает три значения:

  • Soft – позволяет процессу VMX завершиться корректно, аналогично команде kill -SIGTERM
  • Hard – немедленно завершает процесс VMX, аналогично команде kill -9 или kill -SIGKILL
  • Force – останавливает процесс VMX, когда не работают варианты Soft или Hard

3. С использованием утилиты vim-cmd

Vim-cmd - это еще одна утилита командной строки, очень похожая на esxcli, но с несколько иным синтаксисом. Также она может использоваться для управления ВМ и другими ресурсами. Соответственно, вот как используется vim-cmd для завершения работы ВМ:

1. Выведите все ВМ на текущем подключенном хосте ESXi и запишите vmid (первый столбец) неотвечающей ВМ:

vim-cmd vmsvc/getallvms

2. Получите состояние питания ВМ, используя ее vmid. Этот шаг необязателен, так как вы уже знаете, что с ВМ что-то не так:

vim-cmd vmsvc/power.getstate 36

3. Сначала попробуйте вариант power.shutdown:

vim-cmd vmsvc/power.shutdown 36

4. Если по какой-то причине ВМ не удается выключить, попробуйте использовать вместо этого power.off:

vim-cmd vmsvc/power.off 36

Следующий скриншот демонстрирует пример использования указанных выше команд для завершения работы ВМ.

4. С использованием esxtop

Esxtop - это отличная утилита, которая предоставляет информацию о том, как ESXi использует системные ресурсы. Она может использоваться для устранения неполадок, сбора статистики производительности и многого другого.

Вот как это делается:

Нажмите Shift+v, чтобы изменить представление на виртуальные машины:

Нажмите <f>, чтобы отобразить список полей, затем нажмите <c>. Это добавит столбец с идентификатором Leader World ID (LWID) в представление. Нажмите любую клавишу, чтобы вернуться в главное меню.

  • Найдите зависшую виртуальную машину в столбце Name и запишите ее LWID.
  • Нажмите k и введите значение LWID в строке запроса World to kill (WID). Нажмите Enter:

Чтобы быть полностью уверенным, подождите 30 секунд перед тем, как проверить, что виртуальная машина больше не отображается в списке. Если она все еще там, попробуйте снова. В случае неудачи, скорее всего, вам придется перезагрузить хост ESXi.

5. С помощью традиционной команды kill

Это самый грубый метод завершения работы виртуальной машины. Но он документирован на сайте VMware, хотя и немного по-другому. Виртуальная машина представляет собой серию процессов, выполняемых на ESXi. Используя команду ps ниже, можно вывести процессы, связанные, например, с виртуальной машиной под названием Web Server.

ps | grep "Web Server"

Если вы внимательно посмотрите, вы увидите, что значение во втором столбце одинаково для всех процессов. Это значение идентификатора VMX Cartel, которое, хотя и отличается от значения World ID, все же может быть использовано для завершения работы виртуальной машины следующим образом:

kill 797300

Если процессы продолжают работать, попробуйте kill -9 <идентификатор процесса>:

kill -9 797300


Таги: VMware, ESXi, VMachines, vSphere

Установка платформы виртуализации vStack


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


Таги: vStack, VMachines, Enterprise

Архитектура платформы виртуализации vStack и ее технические возможности


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


Таги: vStack, VMachines

Новое на VMware Labs: Horizon Instant Clone Associated VMs


На сайте проекта VMware Labs появилась очередная новая утилита - Horizon Instant Clone Associated VMs. Это инструмент, разработанный для помощи администраторам в управлении внутренними виртуальными машинами, связанными с их пулами Horizon. С помощью него вы легко можете определить неиспользуемые виртуальные машины и удалить их всего в несколько кликов, а также сэкономить ценное дисковое пространство и навести порядок в виртуальной инфраструктуре.

Инструмент Horizon Instant Clone Associated VMs содержит несколько полезных функций для операций с виртуальными машинами в инфраструктуре Horizon:

  • Генерация отчетов - возможность создания отчетов, которые показывают связь внутренних ВМ Instant Clone с пулами Horizon. Отчеты доступны в форматах HTML и Excel (.xlsx).
  • Удаление неиспользуемых ВМ - утилита позволяет вам определить и быстро удалить неиспользуемые внутренние ВМ. Эта функция может помочь вам освободить дисковое пространство и навести порядок в вашей виртуальной среде.

  • Определение "сиротских" (orphaned) внутренних ВМ - есть возможность определить "сиротские" внутренние ВМ, которые были удалены, но все еще отображаются в окружении vCenter Server. Выполнив пару действий, вы можете удалить эти ВМ и повысить эффективность вашей виртуальной среды.
  • Удаление внутренних ВМ, указанных в текстовом файле - утилита позволяет вам удалить внутренние ВМ, перечисленные в текстовом файле. Эта штука особенно полезна, когда вам нужно быстро и эффективно удалить большое количество ВМ, имена которых известны.

Для работы продукта вам понадобится Windows 10 x64 / Windows Server 2016 или более поздние, PowerShell версии 5.1 и позднее, а также модуль VMware PowerCLI.

Скачать Horizon Instant Clone Associated VMs можно по этой ссылке.


Таги: VMware, Labs, Horizon, VMachines, Storage

Преимущества шаблонов виртуальных машин (VMTX) в vSphere Content Library


Вильям Лам опубликовал интересную статью о шаблонах виртуальных машин (VM Templates), разъясняющую некоторые возможности по их использованию в библиотеках контента.

Часто неправильно понимаемой возможностью библиотеки контента vSphere является управление и распространение шаблонов виртуальных машин (VM Templates), которая была представлена в vSphere 6.7 Update 2.

Для библиотек контента в vSphere 5.0 контент распространялся с использованием репликации на основе запроса, при которой на клиентском vCenter Server настраивалась подписка на контент сервера-издателя vCenter Server, а затем контент скачивался на сервер подписчика, как показано на рисунке ниже.

Эта первоначальная архитектура библиотеки контента vSphere упрощала любому vCenter Server, независимо от его домена Single Sign-On, создание подписки и загрузку контента (файлы ISO, OVF/OVA и другие) из vSphere Content Library сервера-издателя.

Создание подписки на библиотеку контента vSphere полностью управлялось подписывающимся vCenter Server, если он знал URL подписки и учетные данные для подключения к серверу-издателю vCenter Server. Хотя это упрощало подписку на контент из библиотеки контента vSphere для всех, это также означало, что для больших организаций с множеством серверов vCenter Server требовалась дополнительная задача по настройке каждого подписывающегося vCenter Server.

После того как контент был синхронизирован с подписчиком vCenter Server, не было простого способа контролировать, какие пользователи могут развертывать определенные OVF/OVA из библиотеки контента vSphere, что может быть проблемой для организаций, которые требуют тонкого контроля доступа к развертыванию рабочих нагрузок. Как гарантировать, что конкретные пользователи/группы развертывают подходящие или последние образы?

Когда возможность управления шаблонами VMTX была добавлена в библиотеку контента vSphere, это не только ввело новую функцию Check-In/Check-Out для шаблонов виртуальных машин, но и добавило новый метод управления распространением образов виртуальных машин через несколько серверов vCenter с использованием новой репликации на основе push, которая исходит от сервера-издателя vCenter Server.

Вместо того чтобы идти на каждый подписывающийся vCenter Server для создания подписки на библиотеку контента vSphere, теперь вы можете управлять всеми подписками непосредственно с сервера-издателя vCenter Server. Этот дополнительный метод репликации библиотеки контента vSphere требует, чтобы все серверы vCenter Server, которые хотят подписаться на образы VMTX, участвовали либо в Enhanced Linked Mode (ELM), либо в Hybrid Linked Mode (HLM), где онпремизный vCenter Server публикует контент на vCenter Server VMware Cloud на AWS (в обратную сторону пока не поддерживается).

Поскольку подписка на библиотеку контента vSphere управляется и настраивается на сервере-издателе vCenter Server, должно существовать доверие между сервером-издателем и сервером-подписчиком vCenter Server, чтобы иметь возможность создавать подписку с сервера-издателя vCenter Server, и именно поэтому требуется один из вариантов Linked-режимов, чтобы иметь возможность использовать новую возможность синхронизации VTMX.

Имея такое сопряжение, чтобы управлять и создавать подписки на ваши серверы-подписчики vCenter Server, включая образы VMTX, вам нужно выбрать желаемую библиотеку контента vSphere на вашем сервере-издателе vCenter Server и в новой вкладке "Subscriptions", как показано на скриншоте ниже.

Хотя при использовании новой функции VMTX в библиотеке контента vSphere есть некоторые узкие места, есть и большие преимущества перед управлением традиционными образами OVF/OVA. Некоторые администраторы знают, что нет способа контролировать, каким пользователям разрешено развертывать из конкретных образов OVF/OVA из библиотеки контента vSphere.

С VMTX у вас на самом деле есть возможность назначать детализированные права пользователям и группам, которые определяют, кто может видеть и развертывать конкретные образы VMTX, что является результатом того, что образ VMTX является частью инвентаря vSphere, что означает, что вы получаете преимущества от механизма прав vCenter Server.

Ниже приведен пример, где есть два образа VMTX: Photon-3.0 и Photon-4.0 в одной библиотеке контента vSphere, и права назначаются таким образом, что они соответственно отображаются на пользователя lob1-user и lob2-user, которым затем разрешено развертывать на основе прав, которые усатновлены на образы VMTX.

Кроме того, мы можем также ограничить, какой контент должен видеть конкретный подписывающийся vCenter Server, особенно если у ваших развертываний vCenter Server есть различные требования по контенту. С моделью на основе pull, все пользователи в подписывающихся серверах vCenter Server смогут видеть только все OVF/OVA из опубликованной библиотеки контента vSphere, и это может быть или не быть желаемым результатом в зависимости от потребностей вашей организации.

Альтернативный подход к ограничению доступа к OVF/OVA заключается в создании нескольких библиотек контента vSphere с сервера-издателя vCenter Server, но это может привести к дублированию контента, который должен быть в нескольких библиотеках, что потребляет дополнительное место хранения и добавляет дополнительную сложность.

С новым же подходом вы можете управлять одной библиотекой контента vSphere со всеми желаемыми VMTX, а затем использовать права vSphere для предоставления дополнительного контроля доступа в каждом подписывающемся vCenter Server. Наконец, чтобы гарантировать, что каждый подписывающийся vCenter Server не загружает ненужные образы VMTX, которые не могут быть использованы, вы всегда должны рассматривать возможность включения настройки "Загрузка контента библиотеки по мере необходимости" и предварительно загружать только тот контент, который, как вы знаете, может или будет использоваться подписывающимся vCenter Server.


Таги: VMware, vCenter, Templates, VMachines, vSphere, Blogs

Возможности массового обновления VMware Tools для виртуальных машин на платформе VMware vSphere


Многие администраторы сталкиваются с необходимостью обновления пакета VMware Tools в большом количестве виртуальных машин, работающих на серверах ESXi платформы VMware vSphere.

Общие сведения об обновлении VMware Tools

На данный момент можно использовать один из трех способов массового VMware Tools в большой инфраструктуре:

  • Применение средства VMware vSphere Lifecycle Manager (ранее его функционал был частью VMware Update Manager)
  • Написание сценариев для фреймворка VMware vSphere PowerCLI
  • Использование сторонних утилит для обновления тулзов

В отличие от версий аппаратной обеспечения (VM Hardware), компания VMware рекомендует всегда использовать последнюю версию пакета VMware Tools, для которого есть матрицы совместимости с различными версиями хостов ESXi. Посмотреть их можно по этой ссылке.

Например, мы видим, что VMware Tools 2016 года все еще можно использовать в ВМ на ESXi 7.0 U3. Также виртуальная машина на сервере VMware ESXi 5.5 может иметь текущую версию VMware Tools (сейчас это 12.1.5).

Напомним, что VMware Tools - это не только часть дистрибутива vSphere, но и отдельный продукт, который можно скачать с портала Customer Connect.

Есть несколько вариантов по загрузке этого пакета:

  • Бандл для общего репозитория Locker (например, VMware-Tools-windows-12.1.5-20735119.zip) - он используется для создания локального или общего репозитория с нужной версией VMware Tools.
  • Установщик в гостевой ОС, который можно запустить в ней как исполняемый файл (VMware-tools-12.1.5-20735119-x86_64.exe.zip).
  • Пакеты для GuestStore (gueststore-vmtools-12.1.5-20735119-20735876.zip) - это новая возможность, которая появилась в vSphere 7.0 U2. GuestStore сделан не для обновления VMware Tools, но может использоваться для этой цели (это тема для отдельной статьи).
  • Офлайн VIB-пакет с тулзами (VMware-Tools-12.1.5-core-offline-depot-ESXi-all-20735119.zip) - он используется как Baseline для обновления VMware Tools на хостах.

Исторически пакет VMware Tools, в основном, выпускался для Windows и Linux. Есть также версии этого пакета и для FreeBSD, Solaris и MacOS. Здесь есть следующие нюансы:

  • Тулзы версии 10.3.5 for Linux были заморожены в разработке, вместо них теперь есть пакет open-vm-tools.
  • Начиная с версии VMware Tools 10.2.0, инсталляция на базе Perl-скриптов для FreeBSD больше не поддерживается. В этом случае также надо использовать open-vm-tools.
  • Последняя версия тулзов для гостевых ОС Solaris - это 10.3.10.

Как мы увидим дальше, очень важно знать, какая версия VMware Tools размещена локально на хосте ESXi после его установки. Эта версия может быть использована для проверки актуальных пакетов в виртуальных машинах. Для быстрой проверки текущей версии пакета на хосте можно использовать следующую команду:

esxcli software component get | grep VMware-VM-Tools -B 1 -A 14

Если вы хотите использовать для этого PowerCLI, то можно выполнить следующий сценарий:

	
$Result = @()

foreach ($ViHost in (Get-VMhost)) {

    $esxcli = $ViHost | Get-esxcli -V2

    $ToolsVersion = ($esxcli.software.component.get.Invoke() | Where-Object {$_.name -eq "VMware-VM-Tools"}).Version

    $Result += [PSCustomObject] @{

        HostName = $ViHost.Name;

        ToolsVersion = $ToolsVersion}

}

$Result

Способы обновления VMware Tools

Итак, рассмотрим обновление VMware Tools одним из двух способов:

  • Обновление VMware Tools как отдельного пакета ПО

В этом случае для нужно версии тулзов можно использовать любое средство, например Microsoft System Center, которое предназначено для массового развертывания программ. Также вы можете использовать любые скрипты и другие средства в режиме тихой установки (silent install).

  • Обновление VMware Tools посредством функционала vSphere

При развертывании и апгрейде хостов ESXi на них помещаются соответствующие версии VMware Tools (чтобы узнать список версий, загляните сюда). По умолчанию пакеты помещаются в папку /productLocker на хосте ESXi - это symbolic link, то есть просто указатель на настроенную папку. Чтобы узнать, какая версия VMware Tools является текущей, сервер vCenter сравнивает установленную версию тулзов в ВМ с версией, которая хранится в разделе /productLocker. Если актуальная версия в гостевой ОС меньше хранящейся на хосте, то в vSphere Client вы увидите соответствующее предупреждение:

Далее вам нужно выполнить процедуру, состоящую из двух основных шагов:

  • Настраиваем хост ESXi для использования определенной версии VMware Tools
  • Автоматизируем процесс обновления тулзов в гостевых ОС виртуальных машин

Шаг 1 - Настройка хоста ESXi для использования определенной версии VMware Tools

Надо сказать, что не рекомендуется вручную обновлять содержимое папки /productLocker, так как это не поддерживаемый официально процесс, и при апгрейде хоста вы можете получить более старую версию пакета. Также вы можете использовать конкретную версию VMware Tools для всех ВМ (например, ту, что содержит исправление конкретного бага).

Используем vSphere Lifecycle Manager для обновления VMware Tools на хостах ESXi

Это рекомендуемый способ обновления пакета VMware Tools, здесь может быть использован один из двух пакетов обновления хостов в кластере:

Если вы обновляете кластер, используя базовые уровни (baselines), вы можете создать кастомный образ, который включает желаемые версии VMware Tools, либо вы можете развернуть тулзы с использованием кастомного бейзлайна.

Давайте посмотрим на обновление с использованием метода Baseline:

  • Просто скачиваем VMware Tools Offline VIB bundle

После успешного апдейта, локальный репозиторий VMware Tools также будет обновлен.

Несмотря на то, что хост не нужно перезагружать после обновления, он все равно должен быть помещен в режим обслуживания (maintenance mode). В противном случае, процесс обновления может выглядеть успешным, но в реальности изменений на хосте не произойдет.

Теперь посмотрим на процесс обновления VMware Tools методом Single Image:

Это более современный метод обновления тулзов на хостах в кластере. Вам нужно выбрать нужную версию VMware Tools как дополнительного компонента при определении образа.

В этом случае можно изменить только версию VMware Tools, а остальное можно оставить как есть.

Создаем общий репозиторий для нужной версии VMware Tools

Этот подход создает центральный репозиторий VMware Tools для нескольких хостов. В этом случае они не будут использовать локальный репозиторий, а на общем хранилище будет использоваться общая папка, которая станет новым репозиторием. Преимуществом данного подхода является обслуживание только одного экземпляра репозитория. Процесс создания этого репозитория описан в KB 2129825.

Как это выглядит по шагам:

1. Создаем на общем томе VMFS папку и устанавливаем для нее разрешения:

cd /vmfs/volumes/datastore
mkdir vmtools-repository-name
chmod 700 vmtools-repository-name

2. Если вы хотите использовать уже использованный репозиторий, то папку надо очистить:

rm -rf /vmfs/volumes/datastore/vmtools-repository-name/*

3. Добавляем файлы, загруженные из Customer Connect и распакованные, в эту папку - у вас получится две подпапки, содержащие нужные файлы:

На скриншоте показан пример для VMware Tools под Windows. Если вы хотите использовать старые тулзы для Linux, то их нужно добавить в папку vmtools. Также посмотрите вот эту нашу статью о VMware Tools.

4. Устанавливаем правильные разрешения:

chmod -R 700 /vmfs/volumes/datastore/vmtools-repository-name/*

5. Если вы делаете процедуру впервые, то нужно настроить хосты ESXi для использования данной папки репозитория вместо используемой локальной папки по умолчанию. Для этого вам нужно добавить расширенную настройку UserVars.ProductLockerLocation (по умолчанию она указывает на /locker/packages/vmtoolsRepo/). Напомним, что /productLocker - это символьная ссылка, поэтому нужно использовать полный путь.

Так как мы обсуждаем массовое обновление тулзов, то имеет смысл показать здесь применение данного способа с использованием PowerCLI:

  • Для вывода текущей директории Locker выполняем следующий командлет:

Get-VMHost | Get-AdvancedSetting -Name "UserVars.ProductLockerLocation" | Select-Object Entity, Value

  • Для изменения директории выполняем такой командлет:

Get-VMHost | Get-AdvancedSetting -Name "UserVars.ProductLockerLocation" | Set-AdvancedSetting -Confirm:$false -Value "/vmfs/volumes/datastore/vmtools-repository-name/"

Будьте аккуратны при вызове второй команды, так как она меняет параметр на всех хостах, которые вы указали.

6. После этого вам нужно будет перезагрузить хост для обновления символьной ссылки /productLocker.

Шаг 2 - Автоматизация процесса обновления тулзов в гостевых ОС виртуальных машин

Теперь мы готовы автоматизировать апдейты VMware Tools в гостевой ОС. Так как мы говорим о массовом обновлении пакетов, то мы не будем обсуждать вариант с логином в гостевую ОС, монтирования ISO-образа и запуском exe-файла.

Сначала посмотрим, какие версии сейчас установлены в виртуальных машинах, с помощью PowerCLI. Запускаем следующую команду:

Get-VM | Select-Object Name, @{N="ToolsVersion"; E={$_.ExtensionData.Config.Tools.ToolsVersion}}

Это не самая удобная нотация, но она соответствует той, что мы видим на странице VM Summary на сервере vCenter. Для получения параметров этой команды используйте маппинг-файл версий.

4 способа автоматизации обновления VMware Tools в гостевой ОС:

1. Обновляем VMware Tools немедленно или ставим запланированную задачу через vCenter

Через интерфейс не всегда удобно работать с массовым обновлением, но в данном случае это можно сделать с помощью отфильтрованного списка ВМ и установки настроек по срабатыванию действий с объектами.

vSphere Lifecycle Manager имеет довольно мощный функционал в этом плане. Процесс обновления можно запланировать на базе состояния питания ВМ. Также можно задать опции предварительного создания снапшота ВМ.

Выбираем нужный кластер, идем на вкладку Updates и выбираем VMware Tools. Фильтруем нужные нам ВМ или выбираем все, далее кликаем Upgrade to match host. В следующих окнах у вас будет множество опций для создания запланированной задачи:

 

Вы можете не только настроить создания снапшота перед апдейтом, но и задать число часов, по истечении которых снапшот будет удален. Также в состав снапшота может входить и состояние оперативной памяти.

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

Дефолтные настройки для этих параметров вы можете установить здесь: Menu -> Lifecycle Manager -> Settings -> VMs:

2. Мгновенное обновление VMware Tools через vSphere PowerCLI

Для обновления тулзов на выбранных хостах (или всех) используется командлет Update-Tools. Он инициирует процесс обновления пакета изнутри гостевой ОС. По умолчанию Update-Tools ждет завершения обновления, после чего инициируется процесс перезагрузки ВМ. Это поведение можно изменить, используя параметры NoReboot и RunAsync.

Следующая команда начинает процесс обновления в виртуальной машине Win2019-01 в рамках задачи:

Get-VM Win2019-01 | Update-Tools –RunAsync

Чтобы посмотреть статус выполняемых задач, используйте команду Get-Task:

Так как это команда PowerShell - ее также можно добавить в запланированные задачи.

3. Обновление VMware Tools при следующей загрузке ВМ в интерфейсе vSphere Client

В рамках окна обслуживания виртуальные машины обычно можно перезагружать. Его, как раз, можно использовать и для обновления VMware Tools. Для этого надо настроить ВМ для проверки версии тулзов при загрузке. Если установленная версия меньше необходимой (по ссылке в /productLocker), то начинается процесс апдейта.

Для изменения политики обновлений, выберите нужный кластер и перейдите на вкладку Updates, где выберите VMware Tools. Там можно фильтровать список ВМ:

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

4. Обновление тулзов при следующей загрузке с использованием vSphere PowerCLI

Сначала посмотрим, текущую конфигурацию ВМ через PowerCLI:

Get-VM | Select-Object Name, @{N="ToolsVersion"; E={$_.ExtensionData.Config.Tools.ToolsUpgradePolicy}}

Здесь могут быть следующие политики - manual и UpgradeAtPowerCycle. Нам нужно использовать вторую. Итак, сначала определяем переменные:

$vmConfigSpec = New-Object VMware.Vim.VirtualMachineConfigSpec
$vmConfigSpec.Tools = New-Object VMware.Vim.ToolsConfigInfo
$vmConfigSpec.Tools.ToolsUpgradePolicy = "UpgradeAtPowerCycle"

Далее применяем эти политики к виртуальным машинам:

$VMs = Get-VM -Name "Win*"
$VMs.ExtensionData.ReconfigVM_Task($vmConfigSpec)

Уделите особое внимание тому факту, какие ВМ вы поместите в переменную $VMs. При таком подходе для обновления VMware Tools вы не сможете запланировать создание предварительных снапшотов ВМ.


Таги: VMware, Tools, Update, vSphere, ESXi, VMachines, PowerCLI

После обновления Microsoft Windows KB5022842 не включаются виртуальные машины на VMware vSphere с опцией Secure Boot


Недавно компания Microsoft выпустила обновление KB5022842 для Windows от 14 февраля, которое, к сожалению, приводит к неработоспособности виртуальных машин на платформе VMware vSphere 7, если для них включен режим безопасной загрузки (Secure Boot). Проблема описана вот тут (Microsoft также подтвердила со своей стороны), там же есть и PowerCLI-скрипт для выявления таких машин:

$secureBoot2022VMs = foreach($datacenter in (Get-Datacenter)) {
  $datacenter | Get-VM |
    Where-Object {$_.Guest.OsFullName -Match 'Microsoft Windows Server 2022' -And $_.ExtensionData.Config.BootOptions.EfiSecureBootEnabled} |
      Select-Object @{N="Datacenter";E={$datacenter.Name}},
        Name,
        @{N="Running OS";E={$_.Guest.OsFullName}},
        @{N="Secure Boot";E={$_.ExtensionData.Config.BootOptions.EfiSecureBootEnabled}},
        PowerState
}
$secureBoot2022VMs | Export-Csv -NoTypeInformation -Path ./secureBoot2022VMs.csv

При попытке запустить такую ВМ она не включится, а в логе vmware.log в папке с ВМ вы увидите такие записи:

2023-02-15T05:34:31.379Z In(05) vcpu-0 - SECUREBOOT: Signature: 0 in db, 0 in dbx, 1 unrecognized, 0 unsupported alg.
2023-02-15T05:34:31.379Z In(05) vcpu-0 - Hash: 0 in db, 0 in dbx.
2023-02-15T05:34:31.379Z In(05) vcpu-0 - SECUREBOOT: Image DENIED.

Ситуация была исправлена со стороны VMware в патче обновлений vSphere 7 Update 3k (KB 90947), который предлагается установить всем пользователям, затронутых этой ситуацией.

Отметим, что с виртуальными машинами на vSphere 8 никаких неприятностей не произошло.

Скачать VMware vSphere 7 Update 3k можно по этой ссылке. Release Notes находятся тут.

Спасибо Сергею за новость.


Таги: VMware, vSphere, Bug, Secure Boot, VMachines, ESXi, Update, Microsoft, Windows

Новые возможности RVTools 4.4.1


На днях обновилась известная многим администраторам виртуальной инфраструктуры утилита RVTools до версии 4.4.1. Напомним, что она предназначена для помощи пользователю VMware vSphere в различных аспектах при выполнении рутинных операций в виртуальной среде серверов ESXi и виртуальных машин. В прошлый раз об RVTools 4.3.1 мы писали вот тут.

Давайте посмотрим, что нового появилось в RVTools 4.4.1:

  • Теперь утилита разрабатывается на Visual Studio 2022.
  • RVTools использует обновленный VMware vSphere Management SDK 8.0.
  • Log4net обновлен до версии 2.0.15.
  • Компонент RVToolsPasswordEncryption теперь использует mac-адрес вместо фиксированной строки для шифрования пароля.
  • Новые колонки на странице vInfo: емкость диска в MiB, Folder ID, роль Fault tolerance, операции Reboot/Poweroff, опция EFI Secure boot, SMBIOS UUID.
  • Новая колонка на странице vCPU - Numa Hotadd Exposed. Это булевое значение, показывающее работает ли NUMA-топология при включенном CPU hotadd.
  • Новые колонки на странице vDisk: Disk UUID и Disk sharing mode.
  • На всех страницах, относящихся к ВМ, колонка с тэгами поставлена перед колонкой Datacenter. Также изменен текст тултипа VM UUID на "VirtualCenter-specific 128-bit UUID of a virtual machine".
  • Новые колонки на странице vSource: version, patch level и VI SDK Server.
  • На странице vHealth путь /storage/archive исключен из проверки free disk capacity, так как этот раздел может быть заполнен изначально в нормальной конфигурации (подробнее тут).
  • Исправлена ошибка с некорректным отображением колонки Primary IP Address на странице vInfo.
  • Решена проблема на странице vNetwork, когда нельзя было понять, является ли IP-адрес типом ipv4 или ipv6.

Скачать новую версию RVTools 4.4.1 можно по этой ссылке. Описание отображаемых параметров находится тут.


Таги: VMware, RVTools, Update, vSphere, ESXi, VMachines

Вышло обновление утилиты Imager версии 2.1.0


На сайте проекта VMware Labs появилось первое обновление в этом году - новая версия утилиты Imager 2.1.0. Напомним, что о второй ее версии мы писали вот тут, она предназначена для создания полностью чистой виртуальной машины с гостевой ОС Windows 10 на борту с нуля в рамках простого, автоматизированного и бесшовного процесса. Администратору нужно просто указать установочный ISO-образ, а утилита Imager сделает всю работу по созданию полностью готовой к использованию ВМ с помощью средств Sysprep.

Давайте посмотрим, что нового появилось в Imager 2.1.0:

  • Виртуальные машины теперь можно создавать с паравиртуализованными драйверами хранилищ (PVSCSI) и сетевых адаптеров (VMXNET3). Использование этих драйверов является предпочтительным с точки зрения производительности, пропускной способности и эффективности использования CPU.
  • Можно экспортировать ВМ на любом этапе исполнения плана билда в форматы OVF и OVA.
  • Компоненты Imager 2.1 и Managed VM Agent 2.1 были обновлены для поддержки последних версий продуктов VMware Workstation Pro 17.0 и Workstation Player 17.0.

Скачать VMware Imager 2.1.0 можно по этой ссылке.


Таги: VMware, Imager, Labs, Update, VMachines

Сжатие и дедупликация в VMware vSAN 8 на архитектуре ESA (Express Storage Architecture)


Недавно мы писали о новой версии платформы VMware vSAN 8 и архитектуре ESA (Express Storage Architecture). На прошлой неделе состоялся релиз этого продукта в рамках доступности vSphere 8 Initial Availability.

Дункан Эппинг недавно рассказал о том, как работает сжатие и дедупликация в рамках этой архитектуры. Напомним, что главное отличие ESA от OSA (Original Storage Architecture) заключается в том, что она позволяет достичь максимальных показателей производительности и эффективности на базе высокопроизводительных систем хранения, таких как флэш-память TLC на основе технологии NVMe.

Ключевыми структурными особенностями vSAN 8 ESA является переработанная и запатентованная файловая система (log-structured file system, LFS), новый оптимизированный для записи менеджер объектов (log-structured object manager), а также новый формат дисковых объектов.

Итак, в архитектуре OSA сжатие и дедупликация срабатывают непосредственно до того, как данные сохраняются на диск на каждом из хостов, где они в итоге оказываются. В vSAN ESA сжатие данных (compression) включено по умолчанию и работает все время на самом верхнем уровне архитектуры (до низких уровней слоев vSAN), как показано на диаграмме ниже:

Суть изменения заключается в том, что данные сначала сжимаются, а только потом передаются по сети. Например, вы сжимаете блок 4К до 2К, и далее он отправляется в сеть. Это требует меньше канала, а также меньше ресурсов на шифрование - вам нужно посчитать контрольную сумму для 2К блока вместо 4К.

Сжатие данных происходит только на исходном хосте, а целевой хост отвечает только за их помещение на диски. Это уменьшает совокупное потребление ресурсов и более эффективно расходует пропускную способность сети.

При создании политики хранения на вкладке Storage rules вы можете выбрать один из четырех вариантов сжатия:

  • No Preference (по умолчанию)
  • No space efficiency
  • Compression only
  • Deduplication and compression

Надо отметить, что дедупликация данных еще не реализована для архитектуры ESA, поэтому вариант Deduplication and compression не актуален на данный момент.

Итак, как мы уже сказали компрессия включена по умолчанию, поэтому она будет работать при выбранных вариантах No Preference и Compression only. Если вы выберете No space efficiency, то сжатие данных будет отключено.

Дункан создал 3 виртуальных машины и три политики хранения. Машина VM_CompDisabled получила политику "Comp_Disabled", где выбран вариант "No space efficiency".

Пока нет способа в интерфейсе увидеть, включено реально ли сжатие в рамках политики или нет, но вы можете воспользоваться следующей командой, указал UUID объекта из скриншота выше:

cmmds-tool find -t DOM_OBJECT -u <UUID>

Если в выводе команды вы найдете строку ("compressionState" i1), то это значит, что компрессия данных отключена:

Еще один момент - так как компрессия работает на верхнем уровне и не имеет связи с оборудованием и компонентами хостов ESXi, то при изменении политики хранения не происходит переработки уже записанных данных. Просто все новые данные, приходящие на источник, начинают (или прекращают) сжиматься и в этом виде попадают на хранилища.


Таги: VMware, vSAN, ESA, Storage, Compression, VMachines, Blogs

Вышло VMware Fusion 22H2 Tech Preview - новые возможности платформы виртуализации для macOS


Вчера мы писали об обновленной настольной платформе виртуализации для Windows и Linux - VMware Workstation 22H2 Tech Preview, которая стала доступна для тестирования пользователями за несколько месяцев до релиза. Одновременно с этим VMware выпустила технологическое превью этого продукта и для macOS - VMware Fusion 22H2 Tech Preview.

Давайте посмотрим, что нового появится в платформе виртуализации для Маков:

1. Поддержка гостевых ОС Windows 11 на платформах Intel и Apple Silicon

Помните мы писали о первом превью VMware Fusion на аппаратной платформе Apple Silicon и сложностях, которые были у команд VMware и Apple в ковидные времена? Так вот VMware доработала продукт Fusion, и теперь он работает на процессорах M1, где еще и поддерживается новая ОС Windows 11 в качестве хостовой и гостевой.

Чтобы обеспечить поддержку Windows 11, от платформы виртуализации требуется поддержка механизма Trusted Platform Module. В этом релизе для работы Virtual TPM module (vTPM) были добавлены некоторые функции. В частности, vTPM имеет реализацию механизма Fast Encryption, который предполагает шифрование только критических частей виртуальных машин и их локальных хранилищ, что намного ускоряет производительность ВМ, практически не уменьшая уровень безопасности.

Устройство vTPM может быть добавлено к любой виртуальной машине, но у нее должно быть включено Full или Fast шифрование. Делается это в разделе VM Settings > Encryption, здесь мы видим возможность выбора механики шифрования:

Второй момент - это автогенерация паролей для пользователя и использование локального Mac Keychain для хранения ключей шифрования, что освобождает пользователя от необходимости вводить пароль при каждой загрузке ВМ.

Также в этой категории было сделано еще 2 улучшения:

  • 2D-графические драйверы для Windows on ARM - теперь, чтобы Windows 11 смотрелась в виртуальной машине хорошо, VMware добавила ранние версии драйверов WDDM, которые позволяют настроить параметры отображения для 4К-окружений и более высоких разрешений.
  • Драйверы vmxnet3 для Windows on ARM - теперь VMware Tools ISO on ARM содержат в себе не только графические драйверы, но и реализацию улучшенных сетевых драйверов .

2. Улучшенная поддержка ВМ Linux на платформе Apple Silicon

VMware работает с комьюнити разных операционных систем и open-source проектов, таких как Mesa и open-vm-tools, чтобы обеспечить максимальную поддержку Linux на аппаратной платформе Apple Silicon. Постоянно выпускаются патчи для ядра, а также улучшения графического драйвера Mesa SVGA, чтобы надежно работало аппаратное 3D-ускорение на базе фреймворков OpenGL 4.3 + GLES 3.1 для виртуальных машин Linux с Mesa 22.1.1 и более поздних версий (для этого нужна версия ядра 5.19+).

Open-source драйверы устройств vmwgfx дают качественный пользовательский опыт пользователю и возможности корректного отображения различных разрешений в гостевой ОС.

Тут надо отметить также функцию Auto-Fit Guest Display, которая в составе Open-VM-Tools v12.0.5 позволяет выравнивать разрешение гостевой ОС, которое меняется, когда пользователь изменяет размер окна консоли. Это работает по аналогии с Debian Bookworm/Testing или Sid и Fedora 37/Rawhide. Также разрешение может быть жестко задано в меню View > Resize Virtual Machine.

3. Прочие улучшения

  • Для платформ Intel и Apple Silicon используется один бинарник .dmg, который организации могут использовать для массового развертывания платформы виртуализации.
  • Исправления багов Kernel 5.15+, которые идут постоянно в тесной работе с сообществом, позволяют устранять ошибки, проявляющиеся при загрузке. Уже сейчас система Fusion работает в дистрибутивах Debian, Fedora и Kali, и поддержка новых платформ будет постоянно расширяться.

4. Ограничения релиза

Надо понимать, что VMware сделала еще не все нужные пользователям вещи, а именно:

  • Fusion пока не будет поддерживать работу ВМ между разными архитектурами (например, ВМ x86_64 на маках M1). 
  • Виртуальные машины macOS пока не поддерживаются, но VMware работает над этим.
  • Дистрибутивы Ubuntu 20.04.4 и 22.04 для arm64 пока не загружаются - VMware также работает над устранением этой проблемы.

Скачать VMware Fusion Tech Preview 22H2 можно по этой ссылке. Руководство по тестированию этого технологического превью находится тут, а основное комьюнити с форумом и прочими ресурсами находится на этой странице.


Таги: VMware, Fusion, Update, Apple, Silicon, Hardware, M1, VMachines, Windows, Linux

На VMware Labs обновилась утилита Imager до версии 1.1


На сайте проекта VMware Labs вышло обновление утилиты Imager версии 1.1. Напомним, что это средство позволяет создать полностью чистую виртуальную машину с гостевой ОС Windows 10 на борту с нуля в рамках простого, автоматизированного и бесшовного процесса. Администратору нужно просто указать установочный ISO-образ, а утилита Imager сделает всю работу по созданию полностью готовой к использованию ВМ с помощью средств Sysprep.

Давайте посмотрим на новые возможности Imager 1.1:

  • Возможность создания виртуальной машины Windows 11
  • Оптимизация образов за счет интеграции с новой версией VMware OS Optimization Tool
  • Автоматизированное создание среды WinPE
  • Поддержка зашифрованных образов Windows формата .esd
  • Возможность запуска на Windows Server 2022
  • Исправления ошибок при валидации sysprep на разных этапах создания образа
  • Улучшенная обработка ошибок при развертывании и отмене создания образа
  • Улучшенная валидация на промежуточных этапах
  • Захват логов из гостевой ОС в общий лог Imager
  • Убран этап загрузки агента Workspace ONE UEM agent
  • Различные исправления UI и CLI

Загрузить VMware Imager 1.1 можно по этой ссылке. Инструкция по использованию находится тут.


Таги: VMware, Imager, Update, Labs, Windows, VMachines

Улучшения VMware vSAN 7.0 Update 3 - пересчет голосов для обеспечения кворума при последовательных отказах


Одним из нововведений новой версии решения для обеспечения катастрофоустойчивости виртуальной инфраструктуры хранения VMware vSAN 7.0 Update 3 стал улучшенный механизм по обработке последовательных отказов. Называется он Enhanced Data Durability.

Он позволяет еще больше защитить кластер хранилищ от аварий и сбоев, которые могут происходить не в один момент, а друг за другом на протяжении некоторого времени.

Нужен он для того, чтобы в ситуации, когда отказывает одна из площадок vSAN, а потом и компонент Witness (например, в случае массового сбоя сети или аварии другой природы), хосты выжившего кластера могли продолжить работу.

Проиллюстрируем это на примере, который привел Дункан Эппинг. Предположим, у нас есть вот такая инфраструктура:

И вот у нас отказывает полностью один из датацентров. В консоли RVC мы увидим следующее:

  VM R1-R1:
Disk backing:
[vsanDatastore] 0b013262-0c30-a8c4-a043-005056968de9/R1-R1.vmx
RAID_1
RAID_1
Component: 0b013262-c2da-84c5-1eee-005056968de9 , host: 10.202.25.221
votes: 1, usage: 0.1 GB, proxy component: false)
Component: 0b013262-3acf-88c5-a7ff-005056968de9 , host: 10.202.25.201
votes: 1, usage: 0.1 GB, proxy component: false)
RAID_1
Component: 0b013262-a687-8bc5-7d63-005056968de9 , host: 10.202.25.238
votes: 1, usage: 0.1 GB, proxy component: true)
Component: 0b013262-3cef-8dc5-9cc1-005056968de9 , host: 10.202.25.236
votes: 1, usage: 0.1 GB, proxy component: true)
Witness: 0b013262-4aa2-90c5-9504-005056968de9 , host: 10.202.25.231
votes: 3, usage: 0.0 GB, proxy component: false)
Witness: 47123362-c8ae-5aa4-dd53-005056962c93 , host: 10.202.25.214
votes: 1, usage: 0.0 GB, proxy component: false)
Witness: 0b013262-5616-95c5-8b52-005056968de9 , host: 10.202.25.228
votes: 1, usage: 0.0 GB, proxy component: false)

Здесь мы видим, что у нас 1 голос на каждый из дисковых компонентов основной площадки (итого 2), 3 голоса на Witness и 2 голоса на резервной площадке.

Теперь представим, что все хосты резервной площадки отказывают полностью. У нас остается 2+3=5 голосов из 7, то есть кворум есть, все в порядке (для обеспечения кворума нужно больше 50% голосов). Но вот если у нас после этого откажет компонент Witness, имеющий 3 голоса, то у нас останется только 2 голоса из 7, кворума не будет - и это может привести к проблемам в кластере.

Для этого в vSAN 7 Update 3 сделали механизм пересчета голосов. Посмотрим на то, как выглядит картина через 5 минут после отказа резервной площадки в консоли RVC:

  VM R1-R1:
Disk backing:
[vsanDatastore] 0b013262-0c30-a8c4-a043-005056968de9/R1-R1.vmx
RAID_1
RAID_1
Component: 0b013262-c2da-84c5-1eee-005056968de9 , host: 10.202.25.221
votes: 3, usage: 0.1 GB, proxy component: false)
Component: 0b013262-3acf-88c5-a7ff-005056968de9 , host: 10.202.25.201
votes: 3, usage: 0.1 GB, proxy component: false)
RAID_1
Component: 0b013262-a687-8bc5-7d63-005056968de9 , host: 10.202.25.238
votes: 1, usage: 0.1 GB, proxy component: false)
Component: 0b013262-3cef-8dc5-9cc1-005056968de9 , host: 10.202.25.236
votes: 1, usage: 0.1 GB, proxy component: false)
Witness: 0b013262-4aa2-90c5-9504-005056968de9 , host: 10.202.25.231
votes: 1, usage: 0.0 GB, proxy component: false)
Witness: 47123362-c8ae-5aa4-dd53-005056962c93 , host: 10.202.25.214
votes: 3, usage: 0.0 GB, proxy component: false)

Итак, мы видим, что каждый из дисковых компонентов получил по 3 голоса. Компонент Witness вне площадок получил 1 голос вместо 3, а компонент Witness, поднявшийся на основной площадке также получил 3 голоса.

Теперь, если внешний компонент Witness упадет, то кворум кластера все равно будет соблюден, а машины продолжат исполняться на основной площадке. Если же резервная площадка снова войдет в строй, то голоса в кластере снова будут пересчитаны таким образом, чтобы соблюсти статус кво.

Как долго происходит пересчет голосов в кластере? Это зависит от количества дисковых объектов, голоса которых учитываются. В среднем на одну ВМ приходится по несколько секунд вычислений, поэтому общая реконфигурация состава голосов может занять до 5 минут. Зато в этом случае кластер будет более устойчив к отказам, которые в реальной жизни могут происходить один за другим.


Таги: VMware, vSAN, Update, HA, DR, VMachines, Storage

Новая возможность VMware Horizon - нанесение водяных знаков на печатаемые документы (watermarks)


Компания VMware недавно выпустила обновленную версию своего решения для виртуализации и доставки настольных ПК и приложений Horizon 8 2203. Там появилось несколько полезных новых возможностей, одной из которых стала функция по нанесению цифровых водяных знаков на документы, которые распечатывают пользователи.

Многие компании заботятся о конфиденциальности данных своих документов, особенно когда с ними работает довольно широкий круг пользователей. Это же касается и возможности сделанных ими скриншотов. Теперь при распечатке документов в Horizon 8 можно задать водяные знаки (watermarks), которые будут нанесены уже на распечатанную версию документа в целях конфиденциальности или защиты интеллектуальной собственности.

Эти функции реализуются через новую версию Horizon Agent и работают для следующих сценариев:

  • Опубликованные приложения и приложения в пуле виртуальных десктопов
  • Виртуальные десктопы и RDS-хосты
  • Режим вложенной виртуализации (Nested mode)
  • Режим работы с несколькими мониторами
  • Основная (Primary) сессия при работе пользователей в режиме совместной сессии

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

  • Текст и его цвет
  • Расположение картинки
  • Прозрачность
  • Сдвиг (margin)
  • Окантовка текста (border color)

По умолчанию водяной знак отображается черным с белой окантовкой.

В Horizon 2203 можно настроить отображение водяного знака в рамках сессии, которая используется при работе с виртуальным десктопом, выглядит это так:

Также водяные знаки теперь интегрированы в решения VMware Integrated Printing (VIP) Universal Printing Driver (UPD). Теперь в консоли есть отдельная вкладка, где администраторы могут настроить оверлей текста на печатаемых документах:

Более подробно об этой возможности Horizon 8 можно почитать вот тут.


Таги: VMware, Horizon, Update, VMachines, VDI

На сайте VMware Labs обновился продукт Virtual Machine Desired State Configuration


На сайте проекта VMware Labs вышла обновленная версия решения Virtual Machine Desired State Configuration 1.1.

Администраторам виртуальной инфраструктуры часто приходится менять параметры виртуальной машины, такие как CPU и память, чтобы проводить разного рода тюнинг и оптимизации. Для таких действий требуется перезагрузка виртуальной машины, что вызывает сложности в планировании.

Раньше подход был таким - к нужной дате/времени, согласованному с владельцами систем, происходила перезагрузка машин, которые за некоторое время уже поднимались в желаемой конфигурации (Desired State). Но это рождает довольно сложный административный процесс такого согласования.

Утилита VMDSC использует другой подход - виртуальные машины окажутся в Desired State при следующей перезагрузке гостевой ОС. Это позволяет не договариваться о простое ВМ в определенные периоды, а просто встраивать процесс реконфигурации процессора и памяти в жизненный цикл систем, когда им и так требуется перезагрузка (например, при накатывании обновлений).

Давайте посмотрим на нововведения в VMDSC 1.1:

  • Теперь есть возможность указать параметр cores_per_socket в дополнение к желаемым значениям CPU и памяти
  • Добавлена дополнительная проверка CPU, чтобы убедиться, что значение Cores per Socket соотносится с числом желаемых vCPU
  • Возможность указать только желаемые элементы VMDSC при выполнении API-запросов вместо включения их всех (например, можно указать желаемое состояние CPU или памяти, либо cores_per_socket, а не все три из них)
  • Обновления в некоторых компонентах, чтобы обеспечить поддержку параметра
  • cores_per_socket:
    • vRealize Orchestrator
    • Postman Collection
    • Модуль PowerVMDSC PowerShell
    • vRealize Log Insight Content Pack
    • Руководство по VMDSC
    • Обновления GET /configs в API-запросах

Загрузить обновленную версию Virtual Machine Desired State Configuration 1.1 можно по этой ссылке.


Таги: VMware, Labs, VMachines

Тестирование высокопроизводительных HPC-нагрузок на VMware vSphere


Недавно компания VMware опубликовала интересное тестирование, посвященное работе и масштабированию высокопроизводительных нагрузок (High Performance Computing, HPC) на платформе VMware vSphere 7.

Основной целью тестирования было сравнение нативной производительности HPC-нагрузок на голом железе (bare metal) с работой этих машин на платформе vSphere.

Рабочие нагрузки использовали message passing interface (MPI) с приложениями на базе параллельных процессов (MPI ranks), которые могли объединять несколько физических серверов или виртуальных машин для решения задач. Например, использовались задачи computational fluid dynamics (CFD) для моделирования воздушных потоков в автомобильной и авиа индустриях.

В качестве тестового стенда использовался HPC-кластер из 16 узлов на базе Dell PowerEdge R640 vSAN ReadyNodes в качестве масштабируемых блоков. R640 представлял собой одноюнитовый сервер с двумя процессорами Intel Xeon.

Топология кластера выглядела следующим образом:

  • Коммутаторы Dell PowerSwitch Z9332 соединяли адаптеры NVIDIA Connect-X6 на скорости 100 GbE по интерфейсу RDMA для MPI-нагрузок.
  • Отдельная пара коммутаторов Dell PowerSwitch S5248F 25 GbE top of rack (ToR) использовалась для сети управления гипервизором, сети vSAN и доступа к ВМ.

Для соединений использовался virtual link trunking interconnect (VLTi). В рамках теста был создан кластер vSAN с поддержкой RDMA.

Конфигурация физических адаптеров выглядела следующим образом:

Вот так выглядит набор HPC-приложений и бенчмарков из разных индустрий, на базе которых проводилось тестирование:

В процессе тестирования производилось масштабирование высокопроизводительного кластера от 1 до 16 узлов, а результаты фиксировались для физической платформы и для виртуальной среды.

Итак, первая задача о динамике жидкостей:

Вторая задача - моделирование прогнозов погоды:

Третья задача - молекулярная динамика (тут на 16 узлах уже есть отличие производительности до 10%):

Еще один бенчмарк по молекулярной динамике, тут тоже есть 10%-е падение производительности на виртуальной платформе, но заметно его становится только при большом количестве узлов:

Бенчмарк NAMD, тут все почти одинаково:

Конечно же, в процессе тестирования производился тюнинг различных настроек самой платформы vSphere и виртуальных машин, вот какие настройки использовались:

Вот так это выглядит в интерфейсе vSphere Client:

Полную версию отчета о тестировании вы можете посмотреть здесь, но из картинок выше вполне понятно, что платформа VMware vSphere и решение vSAN отлично оптимизированы для работы с высокопроизводительными вычислениями.


Таги: VMware, vSphere, HPC, Performance, VMachines

Новое на VMware Labs - утилита Imager для создания готовых ВМ на Windows 10


На сайте проекта VMware Labs появилась очередная бесплатная полезная утилита - Imager. Это средство позволяет создать полностью чистую виртуальную машину с гостевой ОС Windows 10 на борту с нуля в рамках простого, автоматизированного и бесшовного процесса. Администратору нужно просто указать установочный ISO-образ, а утилита Imager сделает всю работу по созданию полностью готовой к использованию ВМ с помощью средств Sysprep.

Этот образ можно использовать в составе пула виртуальных ПК VMware Horizon, для личного использования в тестовой лаборатории, ну или для любых других инфраструктурных целей.

Imager создает виртуальную машину в фоновом режиме, обновляет ее, устанавливает приложения и агенты, после чего выполняет операции Sysprep и финализирует образ для дальнейшего распространения. Также есть возможность остановить процесс на определенной стадии, провести некоторые ручные операции или оптимизации, после чего нажать "Continue" и продолжить рабочий процесс по созданию ВМ.

Ключевое преимущество такого подхода по сравнению с ручным созданием образа - это большая продуктивность, требуется не так много умений по конфигурации Windows (не надо работать со скриптами и специфическими кастомизациями), а также вероятность допустить ошибку в процессе настройки меньше.

Скачать утилиту VMware Imager можно по этой ссылке.


Таги: VMware, Labs, Imager, VMachines, VDI

VMware App Volumes On-Demand Applications - как это работает?


Компания VMware выпустила очень интересное видео про приложения, доставляемые пользователям в виртуальные ПК по запросу (On-Demand Applications) в инфраструктуре виртуальных томов App Volumes:

Данная функция появилась в версии App Volumes 2111 (анонсирована она была еще в 2019 году), она позволяет не монтировать VMDK с приложениями при загрузке виртуальной машины, но оставлять иконки приложений на рабочем столе. При клике на эти иконки происходит динамическое монтирование томов, выстраивание связей и подгрузка приложения в операционной системе. Это позволяет не тратить время на монтирование дисков при загрузке ВМ и ускорить логин пользователя.

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

Для того, чтобы эта функция работала, нужно в настройках пакета указать соответствующую опцию:


Таги: VMware, App Volumes, Horizon, VMDK, VMachines

Максимальные параметры инфраструктуры VMware Horizon 7


Не так давно компания VMware обновила параметры Configuration Maximums, которые содержат максимальные параметры конфигураций инфраструктуры виртуализации и доставки настольных ПК VMware Horizon 7 (напомним, что актуальная на сейчас версия 2111 стала доступна в декабре прошлого года).

Давайте посмотрим на актуальные пределы конфигураций Horizon 7, которые VMware приводит в KB 2150348 с учетом имеющихся на сегодня рекомендаций:

Лимиты архитектуры Cloud Pod Architecture

Максимальное число активных сессий в архитектуре федерации сайтов (Cloud Pod Architecture pod federation)

Версии 7.0 и 7.1: 75 000
Версия 7.2: 120 000
Версии 7.3 и 7.4: 140 000
Версии 7.5, 7.6, и 7.7: 200 000
Версии 7.8 до 7.13.x: 250 000

Максимальное число подов (Pods) в архитектуре федерации сайтов

Версии 7.0 до 7.7: 25 PODs
Версия 7.8: 50 PODs

Максимальное число сайтов (Sites) в архитектуре федерации сайтов

Версии 7.0 до 7.2: 5
Версия 7.3: 7
Версии 7.4 до 7.7: 10
Версии 7.8 до 7.13.x: 15 

Активных соединений на 1 Pod

Сессий в виртуальных десктопах:

Версии 7.0 до 7.6 : 10 000 максимально

Версии 7.7 до 7.13.x: 12 000 максимально

Сессии RDS-хостов:

20 000 максимально (10 000 сессий рекомендуется)

Управляемых агентов на 1 Pod

 

Версии 7.0 до 7.6 : 10 000 максимально

Версии 7.7 до 7.13.x: 12 000 максимально

 

Максимальное число экземпляров Connection Server на 1 Pod

7

Активных сессий на экземпляр Connection Server с прямым или туннелированным соединением по протоколам RDP, PCoIP и Blast

4 000 (2 000 рекомендуется)

Лимиты RDSH-сессий

Максимальное число сессий на RDSH

150 (60 рекомендуется)

Превышение числа 60 рекомендуется только для очень легких нагрузок.

Рекомендуемое число vCPU на RDSH

8-64 (зависит от нагрузки приложений и число vCPU должно быть меньше или равно размеру NUMA-кластера)

Рекомендуемый объем vRAM в ГБ на RDSH

16-128 (зависит от нагрузки приложений)

Максимальное число хостов RDSH на ферму

500 (появилось в версии 7.7)
200 (старые версии)

Лимиты ESXi и хранилищ виртуальных машин

Виртуальных машин на ядро CPU

8-10 рекомендуется

Виртуальных машин на vCenter

12 000 для Full Clones и Instant clones

4 000 для Linked Clones

Виртуальных машин на пул

4 000 (2 000 рекомендуется)
1 000 при использовании vTPM с технологией Instant Clone

Виртуальных машин на хранилище (datastore) 500 (нужно убедиться, что физическое хранилище выдаст нужное число IOPS для виртуальных машин)

Виртуальных машин на кластер при использовании vSAN

6 400

Число хостов на кластер vSphere                  

Для VMFS / NAS: 32
Для VSAN: 64

Число виртуальных машин на хост 200 ВМ

Параметры серверов Connection Servers

Memory

10 ГБ

vCPU

4 vCPU

Sessions per Server

4 000 сессий (2 000 рекомендуется)

Схема обеспечения высокой доступности

N + 1

Максимальное число серверов Connection Servers на один View Pod

7

Максимальное число соединений на один Unified Access Gateway (UAG) 2 000

 


Таги: VMware, Horizon, Update, VMachines, VDI

Вышло обновление RVTools 4.3.1 - что нового?


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

Давайте посмотрим, что там нового:

  • RVTools теперь использует VMware vSphere Management SDK 7.0U3.
  • Новая вкладка vSource, на которой отображается информация о сервере, где исполняется веб-сервис SDK, который используется для сбора данных (это сервер vCenter или хост ESXi).
  • Новая колонка Host UUID на вкладке vHost.
  • Новые чекбоксы в разделе Health, которые включают/отключают сообщения о безопасности и производительности.
  • Раньше колонка UUID заполнялась значениями SMBIOS UUID, которые не уникальны. Теперь там отображается уникальный 128-битный UUID.
  • Улучшение производительности при обработке данных.
  • На вкладке vHealth появились советы по улучшению производительности ввода-вывода и памяти.
  • Исправления ошибок.

Также приведем основные улучшения RVTools с момента выпуска четвертой версии:

  • Новая вкладка vUSB, отображающая хосты с присоединенными USB-устройствами.
  • Новая вкладка vFileInfo с информацией обо всех файлах на датасторах vSphere (полная информация включается чекбоксом Get fileinfo detail information").
  • Log4net обновлен до версии 2.0.12 (защита от уязвимости CVE-2018-1285).
  • Отображение информации о том, является ли объект плейсхолдером резервной инфраструктуры VMware SRM.
  • Новая колонка Virtual machine tags на вкладках vInfo, vCPU, vMemory, vDisk, vPartition, vCD, vFloppy, vNetwork, vSnapshot, vTools.
  • Новая колонка вкладки vInfo: min Required EVC Mode Key.
  • Новая колонка вкладки vMemory: Memory Reservation Locked To Max.
  • Новые колонки вкладки vRP: Resource Pool path, Resource Pool tags, число ВМ в пуле ресурсов и object ID.
  • Новые колонки вкладки vCluster: Cluster tags, custom attributes и object ID.
  • Новые колонки вкладки vHost: число ВМ в пуле ресурсов, vSAN Fault Domain Name, Host tags, in Maintenance Mode и in Quarantine Mode.
  • Новые колонки вкладки dvSwitch: Distributed VirtualSwitch tags, custom attributes и object ID.
  • Новые колонки вкладки dvPort: Distributed VirtualSwitch Port Group tags и object ID.
  • Новые колонки вкладки vDatastore: число ВМ в пуле ресурсов, Datastore tags, custom attributes и object ID.
  • Новые колонки вкладки vNetwork: ipv4 и ipv6, NIC label, "Internal Sort Column".
  • Новые колонки вкладки vDisk: Disk key, disk path, "Internal Sort Column".
  • Новые колонки вкладки vPartition: "Internal Sort Column", Disk key.
  • Новый чекбокс в настройках "Exclude tags" и параметр CLI -ExcludeTags.
  • Объем отображается не в MB, а в MiB.
  • Предупреждение о том, что данные собраны не со всех ВМ.

Скачать RVTools 4.3.1 можно по этой ссылке.


Таги: VMware, RVTools, Update, vSphere, ESXi, vCenter, VMachines

PowerShell OVF Helper - набор сценариев для развертывания OVF-шаблонов


Некоторые из вас, вероятно, знают такой сайт virten.net, где в свое время публиковалось много интересных технических статей об инфраструктуре VMware. Автор этого ресурса делает много интересных вещей, например, средство PowerShell OVF Helper.

OVF Helper - это репозиторий шаблонов для развертывания ВМ из виртуальных модулей (Virtual Appliances) в формате OVF, которые основаны на рабочем процессе развертывания в мастере создания машин vSphere Client. Через OVF Helper вы таким же образом соединяетесь с vCenter Server, заполняете нужные переменные и выполняете сценарий развертывания. Это точно так же просто, как и при использовании vSphere Client, но плюс в том, что вы можете использовать этот сценарий повторно, не проходя вручную шаги мастера клиента vSphere.

Также настроенные параметры в скрипте будут вам отличным напоминанием о том, какую конфигурацию вы использовали для виртуальных модулей.

На данный момент доступны сценарии для следующих продуктов и их версий:

Также на странице PowerShell OVF Helper размещены ссылки на OVA-модули, которые рекомендуется использовать совместно с соответствующей версией сценария.

Кстати, обратите внимание на раздел Tools на сайте автора - там много чего интересного:


Таги: VMware, vSphere, PowerShell, OVF, Virtual Appliance, Бесплатно, VMachines, Blogs

Новый документ: VMware Paravirtual RDMA for High Performance Computing


Довольно давно мы писали о технологии Remote Direct Memory Access (RDMA) которая позволяет не использовать CPU сервера для удаленного доступа приложения к памяти другого хоста. RDMA позволяет приложению обратиться (в режиме чтение-запись) к данным памяти другого приложения на таргете, минуя CPU и операционную систему за счет использования аппаратных возможностей, которые предоставляют сетевые карты с поддержкой этой технологии - называются они Host Channel Adaptor (HCA).

Также некоторое время назад мы писали о VMware Paravirtual RDMA (PVRDMA) - технологии, поддержка которой появилась еще в VMware vSphere 6.5. С помощью нее для сетевых адаптеров PCIe с поддержкой RDMA можно обмениваться данными памяти для виртуальных машин напрямую через RDMA API, что важно для нагрузок High Performance Computing (HPC) на платформе vSphere.

Работает PVRDMA только в окружениях, где есть хосты ESXi с сетевыми картами с соответствующей поддержкой, а также где виртуальные машины подключены к распределенному коммутатору vSphere Distributed Switch (VDS). Альтернативой этому режиму использования сетевых карт является технология VMDirectPath I/O (passthrough), которая напрямую пробрасывает устройство в виртуальную машину. Это, конечно, самый оптимальный путь с точки зрения производительности, однако он не позволяет использовать многие полезные технологии VMware, такие как HA, DRS и vMotion.

Недавно компания VMware выпустила интересный документ "Paravirtual RDMA for High Performance Computing", где рассматриваются аспекты развертывания и производительности PVRDMA, а также производится тестирование этой технологии в сравнении с VMDirectPath I/O и TCP/IP:

Читать весь документ, наверное, не стоит - можно довериться методике тестирования VMware и ее подходу к оценке производительности. Тестовый стенд выглядел так:

Состав оборудования и особенности тестирования:

  • 8 хостов ESXi 7.0 на платформе PowerEdge C6420 с Intel Xeon Gold 6148 CPU на борту (20 ядер / 40 потоков), 200GB RAM NVIDIA Mellanox ConnectX-5 Ex 100GbE NIC на канале RDMA
  • Карты NVIDIA Mellanox ConnectX-5 Ex NIC, соединенные через коммутатор 100GbE NVIDIA Mellanox
  • CentOS 7.6, 20 vCPUs, 100GB RAM, ВМ на датасторе vSAN, одна ВМ на хост ESXi
  • OpenMPI версии 4.1.0, использующая using openib BTL для транспорта RDMA
  • OpenFOAM версии 8, исполняющая тест cavityFine из руководства OpenFOAM. Этот тест исполняет симуляцию течения жидкости с заданными параметрами.

Тут можно просто взглянуть на следующие картинки, чтобы понять, что при использовании PVRDMA вы теряете не так уж и много в сравнении с VMDirectPath I/O.

Результаты теста по времени исполнения в секундах (для 2,4 и 8 хостов, соответственно):

Визуализация результатов при изменении числа узлов:

В среднем, потери производительности на PVRDMA составляют до 20%, зато вы получаете множество преимуществ, которые дает полная виртуализация без жесткой привязки к оборудованию - консолидация, HA и vMotion:

В сравнении с TCP дела тоже обстоят хорошо, результат лучше на 30-80%, в зависимости от числа узлов:

Скачать документ VMware Paravirtual RDMA for High Performance Computing можно по этой ссылке.


Таги: VMware, RDMA, Performance, Whitepaper, VMachines, HPC

Обновилась утилита Virtual Machine Desired State Configuration


На сайте проекта VMware Labs появилось обновление утилиты Virtual Machine Desired State Configuration. О прошлой ее версии мы писали вот тут.

Администраторам виртуальной инфраструктуры часто приходится менять параметры виртуальной машины, такие как CPU и память, чтобы проводить разного рода тюнинг и оптимизации. Для таких действий требуется перезагрузка виртуальной машины, что вызывает сложности в планировании.

Раньше подход был таким - к нужной дате/времени, согласованному с владельцами систем, происходила перезагрузка машин, которые за некоторое время уже поднимались в желаемой конфигурации (Desired State). Но это рождает довольно сложный административный процесс такого согласования.

Утилита VMDSC использует другой подход - виртуальные машины окажутся в Desired State при следующей перезагрузке гостевой ОС. Это позволяет не договариваться о простое ВМ в определенные периоды, а просто встраивать процесс реконфигурации процессора и памяти в жизненный цикл систем, когда им и так требуется перезагрузка (например, при накатывании обновлений).

Что нового появилось в VMDSC версии 1.0.1:

  • Исправлена проблема, когда сервис VMDSC мог использовать неправильный сервисный аккаунт vCenter при восстановлении соединения.
  • Сценарий первоначальной загрузки виртуального модуля теперь проверяет URL опционального сертификата vCenter CA в форматах DER или PEM.
  • Теперь в составе есть vRealize Log Insight VMDSC Content Pack (1.0), который реализует дэшборд для исторических событий VMDSC.
  • Появилась поддержка модуля PowerVMDSC, которая дает пользователям возможность взаимодействовать напрямую с VMDSC из PowerShell.

Скачать утилиту Virtual Machine Desired State Configuration версии 1.0.1 можно по этой ссылке.


Таги: VMware, VMDSC, Update, Labs, VMachines

15 действительно полезных настроек из VMware vSphere 7 Security Configuration Guide, на которых стоит обратить внимание


Как знают многие администраторы VMware vSphere, у компании есть очень полезный документ "Security Configuration Guide", который представляет собой основное руководство по обеспечению безопасности виртуальной среды. Последняя версия этого документа содержит 87 настроек (мы писали об этом тут), так или иначе влияющих на безопасность как самой платформы виртуализации, так и виртуальных машин и их гостевых операционных систем.

Документ передает концепцию "Secure by design", что означает, что среда VMware vSphere изначально настроена оптимальным образом с точки зрения безопасности, поэтому вносить изменения вам нужно только в случае наличия каких-либо специальных требований именно в вашей инфраструктуре.

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

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

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

Структура списка конфигураций и рекомендаций

Давайте сначала взглянем на колонки Excel-таблицы, которая, по-сути, и является списком настроек и рекомендаций, которые вы можете применить в своей виртуальной инфраструктуре:

  • Guideline ID - идентификационное имя рекомендации.
  • Description - лаконичная формулировка сути этой рекомендации.
  • Discussion - описание влияния настройки на конфигурацию среды и операции, а также обсуждение моментов, которые касаются удобства использования инструментов управления в связи с изменением настройки.
  • Configuration Parameter - это название расширенной настройки соответствующего компонента, которую вы можете изменить. Понятно дело, что эта колонка заполнена не всегда, так как есть рекомендации, которые регулируются не конкретными настройками, а, например, топологией или подходом к организации среды.
  • Desired value - рекомендуемое значение, часто оно является значением по умолчанию, если это не site specific.
  • Default value - то значение, которое установлено по умолчанию.
  • Is Desired Value the Default? - просто для понимания (и для референса в будущем), установлено ли желаемое значение по умолчанию.
  • Action Needed - это тип действия, который необходимо предпринять - изменить настройку, проверить конфигурацию или топологию, добавить или удалить что-то и т.п.
  • Setting Location in vSphere Client - очень полезная колонка, позволяющая вам найти нужную настройку в клиенте vSphere.
  • Negative Functional Impact in Change From Default? - это как раз информация о влиянии на функционал в случае изменения настройки.
  • PowerCLI Command Assessment - команда PowerCLI, с помощью которой можно узнать текущее значение настройки.
  • PowerCLI Command Remediation Example - команда PowerCLI по применению настройки.
  • Hardening - указывает на то, что это действительно настройка, которой нужно уделить внимание при конфигурации.
  • Site Specific Setting - говорит о том, что задать конфигурацию должен сам пользователь, в зависимости от его окружения.
  • Audit Setting - указывает, что вам необходимо время от времени проверять эту настройку, чтобы убедиться, что значение по умолчанию не было изменено необоснованно.

Само руководство разбито на 4 категории, которые понятны всем администраторам:

  • Хосты ESXi
  • Сервер vCenter
  • Виртуальные машины
  • Гостевые ОС виртуальных машин

Также в документе есть и вкладка "Deprecated" - там находятся те настройки, которые больше не актуальны. Что важно - там помечено, почему это случилось (в колонке Discussion).

Итак, давайте посмотрим на 15 самых интересных и, главное, полезных настроек, которые вы можете изменить, а также рекомендаций, которые вы можете выполнять, чтобы повысить безопасность виртуальной среды в своей инфраструктуре.

Хосты ESXi

  • Configure remote logging - это действительно правильная рекомендация. Хосты ESXi должны отправлять свои логи на удаленный сервер Syslog. Самый удобный вариант - это использовать в качестве Syslog-сервера решение VMware vRealize Log Insight. Ведь если злоумышленник проникнет на сервер ESXi, то после своей активности он эти логи удалит, и расследовать будет нечего. С централизованного внешнего сервера удалить эти данные сложнее. На работу виртуальной среды эта конфигурация не влияет.
  • Ensure ESXi management interfaces are isolated on their own network segment - это очевидная, но не всегда выполняемая администраторами конфигурация. Конечно же, вся управляющая инфраструктура виртуальной среды должна находиться в выделенном сегменте сети в своих VLAN, куда имеют доступ только администраторы. То же самое касается и сети vMotion, и сети vSAN.
  • esxi-7.shell-interactive-timeout и esxi-7.shell-timeout (Set a timeout to automatically terminate idle ESXi Shell and SSH sessions) - по умолчанию сессии командной оболочки и SSH-сессии висят постоянно, что, конечно же, представляет потенциальную угрозу. Лучше ограничить таймаут 600 секундами, чтобы никто эти сессии не смог подхватить.
  • Only run binaries delivered via VIB - эта настройка позволяет устанавливать бинарные компоненты только через VIB-пакеты, которые соответствуют установленному Acceptance Level. Если вы не пользуетесь посторонними библиотеками кустарного производства, то лучше эту настройку включить. Когда вам понадобится установить такой бинарник - просто включите эту настройку снова. Но это изменение лучше задокументировать.
  • Enable bidirectional/mutual CHAP authentication for iSCSI traffic - настраивать CHAP-аутентификацию нужно обязательно, чтобы предотвратить атаки, связанные с перехватом трафика к хранилищам. Настраивать это недолго, но зато будет больше уверенности в сохранности данных.

Сервер vCenter

  • Ensure vCenter Server management interfaces are isolated on their own network segment or as part of an isolated ESXi management network - это та же самая рекомендация по изоляции управляющей сети от сети виртуальных машин, что и для серверов ESXi. Убедитесь, что они надежно разделены с помощью VLAN и других техник.
  • Ensure that port mirroring is being used legitimately - эта настройка отключена по умолчанию, но зеркалирование трафика на портах vSphere Distributed Switch надо периодически проверять (vSphere Client -> Networking -> Distributed Switch -> Configure -> Settings -> Port Mirroring). Такой способ атаки - один из самых простых в реализации, если у злоумышленника есть доступ к настройкам VDS (обычно в них никто не заглядывает после первичной настройки). То же самое касается и отправки трафика NetFlow, управление которым производится в разделе vSphere Client -> Networking -> Distributed Switch -> Configure -> Settings -> NetFlow.
  • Limit access to vCenter Server by restricting DCLI / SSH - это разумная рекомендация, чтобы злоумышленник не смог залогиниться в консоль виртуального модуля напрямую или по SSH. Уменьшив поверхность атаки, вы сделаете среду более защищенной. Только не забудьте задокументировать это изменение.
  • Configure File-Based Backup and Recovery - не ленитесь настраивать и обслуживать бэкап конфигурации вашего управляющего сервера. Однажды это может вам пригодиться как в контексте безопасности, так и в контексте быстрого восстановления системы управления в виртуальной инфраструктуре в случае сбоя.
  • Configure remote logging - здесь те же рекомендации, что и для ESXi. Не ленитесь настраивать сервер удаленного сбора логов.

Виртуальные машины

  • Limit the number of console connections - очень часто к консоли виртуальной машины не нужно больше одного подключения ее администратора. В этом случае дефолтное количество 40 одновременных подключений лучше уменьшить до 1. Делается это в разделе VM -> Edit Settings -> VM Options -> VMware Remote Console Options.
  • Encrypt VMs during vMotion - это полезная настройка. По умолчанию, трафик vMotion шифруется, только если есть такая возможность (Opportunistic). Если у вас хватает вычислительных ресурсов и быстрая сеть, то можно установить это значение в "Required". Это обеспечит защиту от перехвата трафика vMotion, в котором есть данные гостевой ОС виртуальной машины.
  • Lock the VM guest session when the remote console is disconnected - лучше включить эту настройку и лочить сессию при отключении удаленной консоли, чтобы брошенная администратором сессия в гостевой ОС виртуальной машины не была подхвачена злоумышленником. На удобство работы это не сильно влияет. Изменить эту настройку можно в VM -> Edit Settings -> VM Options -> VMware Remote Console Options.

Гостевая ОС

  • Ensure that VMware Tools are updated - это просто еще одно напоминание, что нужно постоянно следить за тем, что пакет VMware Tools обновлен до последней версии (и желательно поддерживать единый уровень версий для всех машин). В нем содержится много компонентов (кстати, не устанавливайте ненужные), поэтому уязвимость в одном из них может скомпрометировать множество виртуальных машин. То же самое относится и к версии Virtual Hardware - следите за этим.
  • Disable Appinfo information gathering - об интерфейсе Appinfo мы писали вот тут (он же Application Discovery). Он позволяет, например, собирать информацию о запущенных приложениях внутри гостевой системы и их параметрах. Механизм Appinfo используется различными решениями, такими как vRealize Operations Manager, для мониторинга на уровне гостевой ОС. Если же вы не используете эти решения в своей виртуальной среде, то данный механизм лучше просто отключить через VMware Tools. Учитывая какое количество багов, касающихся безопасности, в последнее время находится в различных компонентах инфраструктурного ПО, лучше отключить функции Appinfo, которые включены по умолчанию для всех гостевых ОС после установки VMware Tools.

Конечно же, в документе vSphere 7 Security Configuration Guide есть много и других настроек и конфигураций, изменение которых помогут вам повысить уровень безопасности. Иногда это связано с требованиями регулирующих органов или спецификой внутренних политик организации. Поэтому обратите особенное внимание на те конфигурации, которые помечены как Site Specific, а также те, где рекомендуемые значения отличаются от дефолтных. И обязательно документируйте сделанные изменения, а также проводите регулярный аудит наиболее важных настроек.


Таги: VMware, vSphere, Security, ESXi, vCenter, VMachines

1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20    >   >>
Интересное:





Зал Славы Рекламодателя
Ближайшие события в области виртуализации:

26/08/2024:  VMware Explore 2024 Лас-Вегас
04/11/2024:  VMware Explore 2024 Барселона

Быстрый переход:
VMware VMachines Offtopic NAKIVO vStack Gartner Veeam Vinchin StarWind Nakivo IT-Grad Cloud Teradici VeeamON VMworld PowerCLI Citrix VSAN GDPR 5nine Hardware Nutanix vSphere RVTools Enterprise Security Code Cisco vGate Microsoft SDRS Parallels IaaS HP VMFS VM Guru Oracle Red Hat Azure KVM VeeamOn 1cloud DevOps Docker Storage NVIDIA Partnership Dell Virtual SAN Virtualization VMTurbo vRealize VirtualBox Symantec Softline EMC Login VSI Xen Amazon NetApp VDI Linux Hyper-V IBM Google VSI Security Windows vCenter Webinar View VKernel Events Windows 7 Caravan Apple TPS Hyper9 Nicira Blogs IDC Sun VMC Xtravirt Novell IntelVT Сравнение VirtualIron XenServer CitrixXen ESXi ESX ThinApp Books P2V Explore vSAN Update VCF NSX Aria Tanzu EUC Private AI Avi Broadcom Workstation Community Skyline HCX AI Host Client Chargeback Horizon Labs SASE Workspace ONE Networking Backup Ransomware Tools Performance Lifecycle VCP Network AWS Intel API USB SDDC Fusion Whitepaper SD-WAN Mobile VMUG SRM ARM HCI Converter Photon OS Operations VEBA App Volumes Certification VMConAWS Workspace Imager SplinterDB DRS SAN vMotion Open Source iSCSI Partners HA Monterey Kubernetes V2V vForum Learning vRNI UAG Support Log Insight AMD vCSA NSX-T Graphics NVMe HCIBench SureBackup vCloud Обучение Web Client vExpert OpenStack UEM CPU PKS vROPs Stencils Bug VTL Forum Video Update Manager VVols DR Cache Storage DRS Visio Manager Virtual Appliance PowerShell LSFS Client Datacenter Agent esxtop Book Photon Cloud Computing SSD Comparison Blast Encryption Nested XenDesktop VSA vNetwork SSO VMDK Appliance VUM HoL Automation Replication Desktop Fault Tolerance Vanguard SaaS Connector Event Free SQL Sponsorship Finance FT Containers XenApp Snapshots vGPU Auto Deploy SMB RDM Mirage XenClient MP iOS SC VMM VDP PCoIP RHEV vMA Award Licensing Logs Server Demo vCHS Calculator Бесплатно Beta Exchange MAP ONE DaaS Hybrid Monitoring VPLEX UCS GPU SDK Poster VSPP Receiver VDI-in-a-Box Deduplication Reporter vShield ACE Go nworks iPad XCP Data Recovery Documentation Sizing Pricing VMotion Snapshot FlexPod VMsafe Enteprise Monitor vStorage Essentials Live Migration SCVMM TCO Studio AMD-V KB VirtualCenter NFS ThinPrint Stretched Director ESA Troubleshooting Android Python Upgrade ML Hub Guardrails CLI VCPP Memory Driver Foundation HPC Orchestrator Optimization Bugs SVMotion Diagram Ports SIOC Plugin Helpdesk VIC VDS Migration Air DPM Flex Mac SSH VAAI Heartbeat MSCS Composer
Полезные постеры:

Постер VMware vSphere PowerCLI 10

Постер VMware Cloud Foundation 4 Architecture

Постер VMware vCloud Networking

Постер VMware Cloud on AWS Logical Design Poster for Workload Mobility

Постер Azure VMware Solution Logical Design

Постер Google Cloud VMware Engine Logical Design

Постер Multi-Cloud Application Mobility

Постер VMware NSX (референсный):

Постер VMware vCloud SDK:

Постер VMware vCloud Suite:

Управление памятью в VMware vSphere 5:

Как работает кластер VMware High Availability:

Постер VMware vSphere 5.5 ESXTOP (обзорный):

 

Популярные статьи:
Как установить VMware ESXi. Инструкция по установке сервера ESXi 4 из состава vSphere.

Включение поддержки технологии Intel VT на ноутбуках Sony VAIO, Toshiba, Lenovo и других.

Типы виртуальных дисков vmdk виртуальных машин на VMware vSphere / ESX 4.

Как настроить запуск виртуальных машин VMware Workstation и Server при старте Windows

Как работают виртуальные сети VLAN на хостах VMware ESX / ESXi.

Сравнение Oracle VirtualBox и VMware Workstation.

Что такое и как работает виртуальная машина Windows XP Mode в Windows 7.

Работа с дисками виртуальных машин VMware.

Диски RDM (Raw Device Mapping) для виртуальных машин VMware vSphere и серверов ESX.

Подключение локальных SATA-дисков сервера VMware ESXi в качестве хранилищ RDM для виртуальных машин.

Инфраструктура виртуальных десктопов VMware View 3 (VDI)

Где скачать последнюю версию VMware Tools для виртуальных машин на VMware ESXi.

Как использовать возможности VMware vSphere Management Assistant (vMA).

Как перенести виртуальную машину VirtualBox в VMware Workstation и обратно

Бесплатные утилиты для виртуальных машин на базе VMware ESX / ESXi.

Интервью:

Alessandro Perilli
virtualization.info
Основатель

Ратмир Тимашев
Veeam Software
Президент


Полезные ресурсы:

Последние 100 утилит VMware Labs

Новые возможности VMware vSphere 8.0 Update 1

Новые возможности VMware vSAN 8.0 Update 1

Новые документы от VMware

Новые технологии и продукты на VMware Explore 2022

Анонсы VMware весной 2021 года

Новые технологии и продукты на VMware VMworld 2021

Новые технологии и продукты на VMware VMworld 2020

Новые технологии и продукты на VMware VMworld Europe 2019

Новые технологии и продукты на VMware VMworld US 2019

Новые технологии и продукты на VMware VMworld 2019

Новые технологии и продукты на VMware VMworld 2018

Новые технологии и продукты на VMware VMworld 2017



Copyright VM Guru 2006 - 2024, Александр Самойленко. Правила перепечатки материалов.
vExpert Badge