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

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

Более 6150 заметок о 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

Полезные ссылки касательно перехода на платформу Broadcom после переезда сервисов VMware


6 мая 2024 года завершился переходный этап "Day-2", в ходе которого бэкенд-система VMware была полностью смигрирована на бэкенд-систему Broadcom. На эту тему почитайте наш пост о переезде сообществ VMware в Broadcom Community (а также о переезде Flings из раздела VMware Labs).

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

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

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

1. Обновленные и переехавшие веб-сайты

2. Пока не переехавшие веб-сайты

Со временем этот список обновится, так что следите за обновлениями страницы Вильяма.


Таги: VMware, Broadcom, Blogs

Растянутый кластер VMware vSAN Stretched Cluster - где запускать сервер vCenter?


Интересный пост от John Nicholson о размещении сервера VMware vCenter в растянутом кластере vSAN Stretched Cluster. В идеальном мире у вас есть управляющий кластер, который содержит ваш сервер vCenter, а вы управляете каждым кластером из него. Но, к сожалению, в реальном мире всё сложнее:

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

Можно ли запустить сервер vCenter на управляемом им кластере?

Надо сказать, что всегда полностью поддерживался запуск сервера vCenter на управляемом им кластере. Высокая доступность (HA) в этом случае всё равно будет работать. Если вам нужно более подробно изучить этот вопрос, этот короткий видеоролик ответит на ваш вопрос.

Итак, какой лучший совет при размещении vCenter?

Используйте ephemeral port groups для всех управляющих сетей. Это предотвратит проблемы chicken-egg с виртуальными распределенными коммутаторами (vDS), которые раздражают, но с которыми можно справиться.

Автор предпочитает использовать правила DRS типа "SHOULD", чтобы vCenter "как правило" находился на узле с наименьшим номером или IP-адресом в кластере. Это полезно в ситуации, когда vCenter работает с ошибками и службы управления не запускаются, так как это упрощает поиск узла, на котором он работает. Обязательно избегайте использования правил "MUST" для этого, так как это не позволит vCenter запуститься в другом месте в случае сбоя данного узла.

А как насчет распределенного кластера? Например, у вас есть отдельный хост для запуска сервера Witness, стоит ли размещать его там?

Вот такое делать не рекомендуется. Всегда предпочтительнее запускать сервер vCenter там, где он будет защищен с помощью высокой доступности (HA), и ему не потребуется выключение для обновления хоста. Растянутые кластеры vSAN всегда поддерживают операции active/active, и многие клиенты часто настраивают их так, чтобы большинство рабочих нагрузок выполнялись в предпочтительном датацентре (preferred site). Если вы используете эту конфигурацию, рекомендуется запускать сервер vCenter во вторичном (secondary) местоположении по нескольким причинам:

  • В случае сбоя основного сайта, вы не останетесь «операционно слепым», поскольку HA со стороны vCenter будет активирована и восстановит рабочие нагрузки. Это снизит любые операционные простои, которые могли бы произойти в течение нескольких минут, пока сервер vCenter запустится на резервном узле основного сайта.
  • Он будет действовать как указатель на состояние здоровья вторичного датацентра. В целом полезно иметь какую-то рабочую нагрузку на вторичном сайте, чтобы понимать, как будут работать эти хосты, даже если это будет относительно легкая нагрузка.

Таги: VMware, vSAN, HA, Stretched, vCenter, Blogs

Траблшутинг кластеров VMware vSAN с помощью утилиты vSAN Skyline Health


Блоггер Yahya Zahedi планирует написать интересную серию постов об утилитах для траблшутинга кластеров VMware vSAN. Сейчас самыми полезными для этих целей являются следующие средства:

  • vSAN Skyline Health
  • vSAN Cluster Level Monitoring
  • vSAN Host Monitoring
  • vSAN VM Monitoring

В этом посте мы приведем его рассказ о самом функциональном продукте - vSAN Skyline Health.

Skyline Health — это средство самостоятельной диагностики, предназначенное для обнаружения и устранения проблем в средах vSphere и vSAN. Важно отметить, что хотя эта утилита часто ассоциируется с vSAN, она также доступна и для vSphere. Таким образом, она не является эксклюзивной для vSAN, ее можно и нужно использовать для vSphere.

Сегодня мы посмотрим, как использовать Skyline Health для vSAN. Вы можете получить доступ к этому средству, перейдя к кластеру vSAN, затем выбрав вкладку "Monitor" и выбрав Skyline Health в разделе vSAN. Здесь, в разделе "Overview", вы найдете две карточки: "Cluster Health Score", которая работает на основе недавних файндингов по здоровью, и "Health Score Trend", которая показывает тренд оценки здоровья за последние 24 часа. Этот тренд можно настроить, указав конкретный временной промежуток.

В разделе файндингов по здоровью есть четыре категории: Unhealthy, Healthy, Info, Silenced, которые вы можете использовать для диагностики проблем, устранения неполадок и траблшутинга. Давайте начнем с первой категории файндингов.

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

Как вы можете видеть, есть три опции:

  • Silence Alert - заглушает предупреждение и перемещает карточку в категорию Silenced.
  • Troubleshoot - показывает новую карточку с инструкциями по решению проблемы.
  • View History Details - отображает историю проблемы.

Нажмем на View History Details:

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

Если вы нажмете на "Troubleshoot", появится новая карточка, предоставляющая информацию о проблеме и основной причине для облегчения ее решения. В разделе "Why is the issue occurring?" вы найдете детали о причинах. В разделе "How to troubleshoot and fix" вы узнаете дополнительные сведения, в данном случае - какие устройства испытывают проблемы совместимости оборудования, а также рекомендуемые действия для эффективного решения.

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

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

Четвертая категория — Silenced. Если вы заглушите любые файндинги из других категорий, они появятся здесь. Если у вас есть проблемы, которые вы активно решаете в течение длительного времени, или по какой-либо другой причине предпочитаете не отображать их в категории Unhealthy или других категориях, вы можете нажать на Silence Alert, чтобы переместить их в эту категорию.

В следующем посте автор рассмотрит утилиту vSAN Cluster Monitoring.


Таги: VMware, Skyline, vSAN, Troubleshooting, Blogs

Как правильно вывести хост VMware ESXi из эксплуатации в виртуальном датацентре


Многие администраторы часто добавляют новые хосты ESXi, но довольно редко обсуждается вопрос о том, как правильно выводить из эксплуатации хост VMware ESXi. Об этом интересную статью написал Stephen Wagner.

Многих может удивить, что нельзя просто выключить хост ESXi и удалить его из окружения сервера vCenter, так как необходимо выполнить ряд шагов заранее, чтобы обеспечить успешный вывод из эксплуатации (decomission). Правильное списание хоста ESXi предотвращает появление изолированных объектов в базе данных vCenter, которые иногда могут вызывать проблемы в будущем.

Итак, процесс: как списать хост ESXi

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

Вкратце процесс выглядит так:

  • Перевод ESXi в режим обслуживания (Maintenance Mode)
  • Удаление хоста из распределенного коммутатора vSphere Distributed Switch (vDS)
  • Отключение и размонтирование томов iSCSI LUN
  • Перемещение хоста из кластера в датацентр как отдельного хоста
  • Удаление хоста из инвентаря (Inventory)
  • Выполнение расширенных процедур

Вход в режим обслуживания

Мы переходим в режим обслуживания, чтобы убедиться, что на хосте не запущены виртуальные машины. Вы можете просто щелкнуть правой кнопкой мыши по хосту и войти в режим обслуживания (Enter Maintenance Mode):

Если хост ESXi входит в состав кластера VMware vSAN, то вам будут предложены опции того, что нужно сделать с данными на нем хранящимися:

Удаление хоста из окружения vSphere Distributed Switch (vDS)

Необходимо аккуратно удалить хост из любых распределенных коммутаторов vDS (VMware Distributed Switches) перед удалением хоста из сервера vCenter.

Вы можете создать стандартный vSwitch и мигрировать адаптеры vmk (VMware Kernel) с vDS на обычный vSwitch, чтобы поддерживать связь с сервером vCenter и другими сетями.

Обратите внимание, что если вы используете коммутаторы vDS для подключений iSCSI, необходимо заранее разработать план по этому поводу, либо размонтировать/отключить iSCSI LUN на vDS перед удалением хоста, либо аккуратно мигрировать адаптеры vmk на стандартный vSwitch, используя MPIO для предотвращения потери связи во время выполнения процесса.

Размонтирование и отключение iSCSI LUN

Теперь вы можете приступить к размонтированию и отключению iSCSI LUN с выбранного хоста ESXi:

  • Размонтируйте тома iSCSI LUN с хоста
  • Отключите эти iSCSI LUN

Нужно размонтировать LUN только на выводимом из эксплуатации хосте, а затем отключить LUN также только на списываемом хосте.

Перемещение хоста из кластера в датацентр как отдельного хоста

Хотя это может быть необязательным, это полезно, чтобы позволить службам кластера vSphere (HA/DRS) адаптироваться к удалению хоста, а также обработать реконфигурацию агента HA на хосте ESXi. Для этого вы можете просто переместить хост из кластера на уровень родительского дата-центра.

Удаление хоста из инвентаря

После перемещения хоста и прошествия некоторого времени, вы теперь можете приступить к его удалению из Inventory. Пока хост включен и все еще подключен к vCenter, щелкните правой кнопкой мыши по хосту и выберите «Remove from Inventory». Это позволит аккуратно удалить объекты из vCenter, а также удалить агент HA с хоста ESXi.

Повторное использование хоста

Начиная с этого момента, вы можете войти напрямую на хост ESXi с помощью локального пароля root и выключить хост. Сделать этого можно также с помощью обновленного VMware Host Client.


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

Можно ли с помощью VMware HCI Mesh (vSAN Datastore Sharing) подключить емкости кластеров VMware vSAN OSA к ESA и наоборот?


Некоторые пользователи, применяющие архитектуру VMware HCI Mesh для подключения емкостей удаленных кластеров в архитектуру VMware vSAN Express Storage Architecture (ESA) спрашивают - а можно ли таким образом подключить и емкости кластеров OSA (Original Storage Architecture)?

Напомним, что технология HCI Mesh появилась в VMware vSphere 7 Update 1, она позволяет смонтировать датасторы удаленного кластера vSAN (который выступает в роли "сервера" для кластеров-клиентов).

Мы уже касались этого вопроса здесь и указали на то, что это на данный момент не поддерживается. Дункан Эппинг вот тут рассказал о том, что это не только не сейчас поддерживается, но и невозможно.

Делов в том, что vSAN HCI Mesh (она же технология Datastore Sharing) использует проприетарный протокол vSAN, который называется Reliable Datagram Transport (RDT). При использовании vSAN OSA применяется другая версия протокола RDT, чем та, что используется в vSAN ESA, и в данный момент эти протоколы несовместимы. В итоге, нельзя использовать vSAN Datastore Sharing для предоставления емкости кластеров OSA в ESA или наоборот.

В будущем планируется исправить эту ситуацию, но в данный момент обходного пути нет.


Таги: VMware, vSAN, OSA, ESA, Datastore, Blogs

Как предотвратить исполнение виртуальных машин 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

ChatGPT для администраторов VMware vSphere


Не секрет, что решение ChatGPT прочно вошло в ежедневный набор инструментов ИТ-специалистов, особенно разработчиков ПО. Администраторы VMware vSphere - не исключение, ведь им часто приходится разрабатывать сценарии на базе различных фреймворков и SDK, что часто включает в себя шаблонные задачи, которые вполне можно автоматизировать средствами ChatGPT.

Эрик Слуф недавно занялся этим вопросом. Начал он со следующего промта:

Could you develop a Python script for VMware vCenter to retrieve the virtual machines and allow the user to control their power states? The server details are: host name 'vc.ntpro.local', username 'administrator@ntpro.local', password 'VMware1!' Please ignore certificate errors and use tls.

Ответ ChatGPT оказался продуктивным, с рекомендацией использовать библиотеку pyvmomi для взаимодействия с VMware vCenter. Он дал совет установить библиотеку pyvmomi через pip, если это еще не сделано. Полный код на Python можно найти по этой ссылке.

Для управления проектами на Python можно использовать PyCharm Community Edition. Модуль pyvmomi важен для подобных задач и может быть удобно установлен через терминал с помощью команды pip install pyvmomi. PyCharm также предлагает графический интерфейс для работы с пакетами Python.

После создания нового файла Python вставьте скрипт, предоставленный ChatGPT, в редактор PyCharm. Для выполнения могут потребоваться некоторые корректировки, такие как обновление версий TLS. Если возникнут ошибки, ChatGPT можно использовать для устранения неполадок и поиска новых решений. Как только усовершенствованный скрипт будет реализован, он сможет успешно извлекать и управлять состояниями питания виртуальных машин из vCenter.

На следующем этапе Эрик попросил ChatGPT интегрировать базовый графический интерфейс в скрипт, используя предустановленный модуль TKInter из Python3. Полученный интерфейс отображает список виртуальных машин с функциональными элементами управления питанием. Несмотря на небольшую проблему с "задачей ожидания" во время демонстрации, основная функциональность осталась неизменной.

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


Таги: VMware, CHatGPT, Blogs, Python

Издания VMware vSphere на 2024 год в картинках


Недавно мы писали статью о том, как в этом году изменилась продуктовая линейка компании VMware, которая совсем недавно завершила интеграцию в структуры Broadcom. Вильям Лам сделал отличные картинки о том, как теперь выглядят издания VMware vSphere, а также доступные к отдельному приобретению аддоны.

Итак, самое младшее решение для малого бизнеса - VMware vSphere Essentials Plus Kit (VVEP):

Решение для малого и среднего бизнеса - VMware vSphere Standard (VVS):

Флагманская онпремизная платформа - VMware vSphere Foundation (VVF):

Флагманская облачная платформа с максимальным числом дополнительных продуктов - VMware Cloud Foundation (VCF):

Ну и сертифицированные решения VMware Validated Solutions (VVS) для инфраструктур VMware Cloud Foundation (VCF):

Спасибо Сергею за ссылку на статью Вильяма.


Таги: VMware, vSphere, Enterprise, Cloud, VCF, Broadcom, Licensing, Update, Blogs

Какие функции Datastore Sharing/HCI Mesh/vSAN Max поддерживаются для растянутых кластеров?


Недавно мы писали о сайзинге пропускной способности канала для растянутых кластеров VMware vSAN Stretched Clusters, а сегодня поговорим о том, какие технологии и архитектуры поддерживаются для функций Datastore Sharing в данном типе кластеров. Давайте посмотрим на поддержку Datastore Sharing в рамках разных сценариев, для которых работают архитектуры HCI Mesh и vSAN Max.

О поддержке данных возможностей для растянутых кластеров рассказал Дункан Эппинг. В своей заметке он ссылается на раздел vSAN Max and Disaggregated storage страницы часто задаваемых вопросов по vSAN.

Есть несколько потенциальных комбинаций растянутого кластера и перечисленных возможностей, на момент релиза VMware vSAN 8.0 Update 2 поддержка возможностей выглядит следующим образом:

  • Датастор vSAN Stretched Cluster, расшаренный с vSAN Stretched Cluster –> Поддерживается
  • Датастор vSAN Stretched Cluster, расшаренный с vSAN Cluster (не stretched) –>Поддерживается
  • Датастор vSAN Stretched Cluster, расшаренный с Compute Only Cluster (не stretched) –>Поддерживается
  • Датастор vSAN Stretched Cluster, расшаренный с Compute Only Cluster (stretched, symmetric) –>Поддерживается
  • Датастор vSAN Stretched Cluster, расшаренный с Compute Only Cluster (stretched, asymmetric) –> Не поддерживается

В чем разница между симметричным и асимметричным растянутым кластером? На следующем изображении, взятом из конфигурации vSAN Stretched Cluster, это лучше всего объяснено:

Если вы используете растянутый кластер vSAN и растянутый Compute Only, то обычно используется Asymmetric-конфигурация, поэтому шаринг датасторов в этом случае не поддерживается.


Таги: VMware, vSAN, Stretched, Storage, Blogs

Как включить аутентификацию Active Directory / LDAP / LDAPS в VMware vSphere 8


Florian Grehl на сайте virten.net опубликовал полезную статью о том, как включить аутентификацию Active Directory / LDAP / LDAPS в инфраструктуре VMware vSphere 8. Приводим ниже ее перевод.

Эта статья описывает, как интегрировать VMware vCenter Server в вашу инфраструктуру аутентификации. Источниками идентификации могут быть развертывания Microsoft Active Directory или протокола OpenLDAP.

В комплекте с управляющим сервером vCenter Server идет внутренняя база данных пользователей, которая позволяет добавлять и управлять пользователями из пользовательского интерфейса. Управление пользователями и единый вход предоставляются встроенным компонентом Platform Service Controller. В большой среде вы, возможно, захотите подключить вашу инфраструктуру виртуализации к централизованно управляемому провайдеру идентификации.

Обратите внимание, что VMware объявила о прекращении поддержки Integrated Windows Authentication (IWA). IWA был методом аутентификации, при котором вы присоединяли vCenter Server к вашему домену Active Directory. Несмотря на то, что Active Directory все еще поддерживается для аутентификации, рекомендуется использовать AD через LDAP или идентификацию с помощью ADFS. Для дополнительной информации см. KB78506.

1. Получение сертификата LDAPS

В связи с рисками безопасности, LDAPS заменяет LDAP как новый протокол каталога. Настоятельно рекомендуется использовать LDAPS, который использует SSL для установления безопасного соединения между клиентом и сервером перед обменом любыми данными. В настоящее время в пользовательском интерфейсе vCenter нет функции получения сертификата, поэтому сертификат нужно загрузить самостоятельно.

Подключитесь к vCenter Server Appliance (или любой системе с установленным OpenSSL CLI) с помощью SSH и войдите как root. Выполните следующую команду, чтобы показать сертификат LDAP:

# openssl s_client -showcerts -connect [LDAPS-Server]:636

Эта команда отображает цепочку сертификатов и информацию о сессии SSL. Вы можете использовать либо сертификат CA, либо сертификат сервера. Использование сертификата CA имеет преимущество в том, что вам не нужно перенастраивать провайдер идентификации, когда сертификат LDAPS заменяется.

Копируем содержимое между строчками -----BEGIN CERTIFICATE----- и -----END CERTIFICATE----- в текстовый файл.

После этого сохраните полученный файл с расширением .crt.

2. Добавление провайдера идентификации

  • Откройте vSphere Client.
  • Войдите как Single Sign-On Administrator.
  • Перейдите к Administration > Single Sign On > Configuration.
  • На вкладке провайдера идентификации откройте Identity Sources.
  • Нажмите ADD.

  • Измените Identity Source Type на Active Directory over LDAP.

  • Заполните остальные поля следующим образом:

Identity source name: Метка для идентификации (нужно указать имя домена)

Base distinguished name for users: Уникальное имя Distinguished Name (DN) начальной точки для поиска на сервере каталогов. Пример: Если ваше имя домена - virten.lab, то DN для всего каталога - "DC=virten,DC=lab".

Base distinguished name for groups: Уникальное имя (DN) начальной точки для поиска на сервере каталогов.

Domain name: Ваше имя домена. Пример: "virten.lab".

Domain alias: Ваше имя NetBIOS. Пример: "virten".

Username: Пользователь домена как минимум с правами просмотра.
Если вы получаете ошибку "Invalid DN syntax.", попробуйте ввести пользователя в формате DN: "uid=administrator,cn=users,dc=virten,dc=lab".

Password: Пароль пользователя домена.

Connect to: Выберите "Connect to any domain controller in the domain", если вы хотите использовать DNS для идентификации контроллеров домена или настроить статические основные и вторичные URL. При использовании статических записей вы можете либо запрашивать локальный каталог (порт 636), либо глобальный каталог (порт 3269). (Для устаревших незащищенных подключений используйте 389/3268). Пример: "ldap://dc.virten.lab:636".

  • Нажмите "Browse" рядом с сертификатом (для LDAPS).
  • Выберите файл .crt, полученный ранее от сервера LDAP.
  • Нажмите "ADD" и завершите мастер настройки.
  • В источниках идентификации ваш LDAP должен появиться в списке, и с этого момента вы можете назначать разрешения vCenter пользователям и группам из вашего каталога Active Directory.
  • Выберите ваш AD и нажмите кнопку "SET AS DEFAULT", чтобы сделать его доменом по умолчанию для аутентификации в вашем vCenter, что означает, что каждый, кто не указывает имя домена для входа, автоматически аутентифицируется в этом домене.
  • Для входа с пользователями AD вам нужно установить разрешения. Чтобы добавить пользователя/группу AD в качестве глобального администратора, перейдите к Administration > Access Control > Global Permissions.
  • Нажмите "ADD".
  • Выберите домен и начните вводить в поле поиска User/Group, чтобы выбрать Domain entity.

  • Нажмите "OK".

Теперь вы должны иметь возможность входить с помощью учетной записи Active Directory. Чтобы решать проблемы, связанные с аутентификацией, проверьте файлы журнала на vCenter Server Appliance в папке /var/log/vmware/sso.


Таги: VMware, vSphere, vCenter, LDAP, Security, Blogs

Таблица возникающих проблем и ожидаемого поведения растянутого кластера VMware vSAN при сбоях


Дункан Эппинг опубликовал интересную статью, касающуюся проблем, возникающих в растянутом кластере VMware vSAN при различных сценариях отказов в нем.

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

Во всех следующих сценариях действуют следующие условия: сайт A является предпочтительным местоположением, а сайт B - второстепенным. Что касается таблицы ниже, то первые два столбца относятся к настройке политики для виртуальной машины, как показано на скриншоте:

Третий столбец относится к местоположению, откуда виртуальная машина работает с точки зрения вычислительных ресурсов (хоста ESXi). Четвертый описывает тип сбоя, а пятый и шестой столбцы детализируют наблюдаемое в этом случае поведение.

 Site Disaster Tolerance Failures to Tolerate VM Location Failure vSAN behavior HA behavior
None Preferred No data redundancy Site A or B Host failure Site A Objects are inaccessible if failed host contained one or more components of objects VM cannot be restarted as object is inaccessible
None Preferred RAID-1/5/6 Site A or B Host failure Site A Objects are accessible as there's site local resiliency VM does not need to be restarted, unless VM was running on failed host
None Preferred No data redundancy / RAID-1/5/6 Site A Full failure Site A Objects are inaccessible as full site failed VM cannot be restarted in Site B, as all objects reside in Site A
None Preferred No data redundancy / RAID-1/5/6 Site B Full failure Site B Objects are accessible, as only Site A contains objects VM can be restarted in Site A, as that is where all objects reside
None Preferred No data redundancy / RAID-1/5/6 Site A Partition Site A Objects are accessible as all objects reside in Site A VM does not need to be restarted
None Preferred No data redundancy / RAID-1/5/6 Site B Partition Site B Objects are accessible in Site A, objects are not accessible in Site B as network is down VM is restarted in Site A, and killed by vSAN in Site B
None Secondary No data redundancy / RAID-1/5/6 Site B Partition Site B Objects are accessible in Site B VM resides in Site B, does not need to be restarted
None Preferred No data redundancy / RAID-1/5/6 Site A Witness Host Failure No impact, witness host is not used as data is not replicated No impact
None Secondary No data redundancy / RAID-1/5/6 Site B Witness Host Failure No impact, witness host is not used as data is not replicated No impact
Site Mirroring No data redundancy Site A or B Host failure Site A or B Components on failed hosts inaccessible, read and write IO across ISL as no redundancy locally, rebuild across ISL VM does not need to be restarted, unless VM was running on failed host
Site Mirroring RAID-1/5/6 Site A or B Host failure Site A or B Components on failed hosts inaccessible, read IO locally due to RAID, rebuild locally VM does not need to be restarted, unless VM was running on failed host
Site Mirroring No data redundancy / RAID-1/5/6 Site A Full failure Site A Objects are inaccessible in Site A as full site failed VM restarted in Site B
Site Mirroring No data redundancy / RAID-1/5/6 Site A Partition Site A Objects are inaccessible in Site A as full site is partitioned and quorum is lost VM restarted in Site B
Site Mirroring No data redundancy / RAID-1/5/6 Site A Witness Host Failure Witness object inaccessible, VM remains accessible VM does not need to be restarted
Site Mirroring No data redundancy / RAID-1/5/6 Site B Full failure Site A Objects are inaccessible in Site A as full site failed VM does not need to be restarted as it resides in Site B
Site Mirroring No data redundancy / RAID-1/5/6 Site B Partition Site A Objects are inaccessible in Site A as full site is partitioned and quorum is lost VM does not need to be restarted as it resides in Site B
Site Mirroring No data redundancy / RAID-1/5/6 Site B Witness Host Failure Witness object inaccessible, VM remains accessible VM does not need to be restarted
Site Mirroring No data redundancy / RAID-1/5/6 Site A Network failure between Site A and B (ISL down) Site A binds with witness, objects in Site B becomes inaccessible VM does not need to be restarted
Site Mirroring No data redundancy / RAID-1/5/6 Site B Network failure between Site A and B (ISL down) Site A binds with witness, objects in Site B becomes inaccessible VM restarted in Site A
Site Mirroring No data redundancy / RAID-1/5/6 Site A or Site B Network failure between Witness and Site A/B Witness object inaccessible, VM remains accessible VM does not need to be restarted
Site Mirroring No data redundancy / RAID-1/5/6 Site A Full failure Site A, and simultaneous Witness Host Failure Objects are inaccessible in Site A and Site B due to quorum being lost VM cannot be restarted
Site Mirroring No data redundancy / RAID-1/5/6 Site A Full failure Site A, followed by Witness Host Failure a few minutes later Pre vSAN 7.0 U3: Objects are inaccessible in Site A and Site B due to quorum being lost VM cannot be restarted
Site Mirroring No data redundancy / RAID-1/5/6 Site A Full failure Site A, followed by Witness Host Failure a few minutes later Post vSAN 7.0 U3: Objects are inaccessible in Site A, but accessible in Site B as votes have been recounted VM restarted in Site B
Site Mirroring No data redundancy / RAID-1/5/6 Site B Full failure Site B, followed by Witness Host Failure a few minutes later Post vSAN 7.0 U3: Objects are inaccessible in Site B, but accessible in Site A as votes have been recounted VM restarted in Site A
Site Mirroring No data redundancy Site A Full failure Site A, and simultaneous host failure in Site B Objects are inaccessible in Site A, if components reside on failed host then object is inaccessible in Site B VM cannot be restarted
Site Mirroring No data redundancy Site A Full failure Site A, and simultaneous host failure in Site B Objects are inaccessible in Site A, if components do not reside on failed host then object is accessible in Site B VM restarted in Site B
Site Mirroring RAID-1/5/6 Site A Full failure Site A, and simultaneous host failure in Site B Objects are inaccessible in Site A, accessible in Site B as there's site local resiliency VM restarted in Site B

Таги: VMware, vSAN, Troubleshooting, HA, DR, Blogs

Преимущества шаблонов виртуальных машин (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 ESXi 8.0?


На сайте virten.net появилась хорошая заметка о составе ISO-образа VMware ESXi 8.0, который является частью платформы VMware vSphere 8.

Сам гипервизор ESXi присутствует на рынке уже более 15 лет (раньше он назывался ESX и был построен поверх ОС Linux), и его состав и занимаемый объем на диске менялся со временем. Напомним, что в восьмой версии гипервизора VMware добавила компоненты esxio, обеспечивающие функционирование технологии Project Monterey и SmartNIC, а также составляющие поддержки архитектуры ARM.

Давайте посмотрим, как менялся объем гипервизора, входившего в установочный ISO-образ ESXi, от версии к версии:

  • ESXi 3.5 - 46,01 MB
  • ESXi 4.0 - 59,99 MB
  • ESXi 4.1 - 85,19 MB
  • ESXi 5.0 - 132,75 MB
  • ESXi 5.1 - 125,85 MB
  • ESXi 5.5 - 151,98 MB
  • ESXi 6.0 - 154,90 MB
  • ESXi 6.5 - 135,39 MB
  • ESXi 6.7 - 129,51 MB
  • ESXi 7.0 - 149,40 MB
  • ESXi 8.0 - 226,62 MB

Визуализация этих цифр выгладит так:

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

Если посмотреть на ISO-образ VMware ESXi 8.0, то там будут следующие составные части:

Визуализация этого выглядит так:

Сейчас установочный ISO-образ весит 600-650 МБ, в зависимости от содержащихся в нем апдейтов:

Также если вы перейдете на страницу загрузки VMware ESXi, то увидите, что там есть и Offline Bundle, который занимает значительно больше места на диске, а поставляется он в формате ZIP-архива:

Этот бандл нужен в качестве источника для обновлений VMware Lifecycle Manager - он содержит не только сами компоненты ISO-образа, но и все необходимые апдейты, которые можно накатить на уже установленный гипервизор, чтобы получить актуальную версию платформы.


Таги: VMware, ESXi, Storage, Blogs, vSphere

Ошибка "Fatal CPU mismatch on feature" при установке VMware ESXi 7 или 8 на сервер с процессором Intel


Как написали коллеги с сайта virten.net, при установке платформы VMware ESXi 7 или 8 на сервер с процессорами Intel Core 12 поколения возникает розовый экран смерти (PSOD), содержащий следующие сообщения:

HW feature incompatibility detected; cannot start

Fatal CPU mismatch on feature "Hyperthreads per core"
Fatal CPU mismatch on feature "Cores per package"
Fatal CPU mismatch on feature "Cores per die"

Проблема здесь заключается в том, что новая архитектура процессоров Intel идет с ядрами двух типов - Performance-cores и Efficient-cores. Начиная с vSphere 7.0 Update 2, в ядро гипервизора был добавлен параметр cpuUniformityHardCheckPanic для того, чтобы избежать подобной проблемы, которая проявляется в следующих версиях платформы виртуализации:

  • vSphere / ESXi 8.0 или более поздние
  • vSphere / ESXi 7.0 Update 2 или более поздние

1. Итак, в самом начале установки ESXi нажимаете SHIFT+O, чтобы изменить параметры загрузки. Далее в появившейся строке вводите:

cpuUniformityHardCheckPanic=FALSE

2. После этого нажимаете Enter и дожидаетесь окончания установки.

3. Затем во время первой загрузки опять нажимаете SHIFT+O и вводите ту же самую строчку.

4. А уже когда гипервизор загрузится, нужно добавить следующую строчку в параметры ядра, чтобы отключить проверку, а ESXi не вылетал в розовый экран при каждой загрузке:

# esxcli system settings kernel set -s cpuUniformityHardCheckPanic -v FALSE

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

1. Создаем флэшку USB с ISO-образом ESXi, как написано здесь.

2. Открываем файл /efi/boot/boot.cfg в редакторе и добавляем следующую опцию в строчку kernelopt= параметров ядра:

ks=usb:/KS.CFG cpuUniformityHardCheckPanic=FALSE

3. Далее вам надо создать файл /KS.CFG для конфигурации Kickstart и в секциях  %post (пост-параметры установки, но до первой загрузки) и %firstboot (первая загрузка) добавить следующее:

vmaccepteula
install --firstdisk=usb --overwritevmfs

network --bootproto=static --ip=192.168.0.26 --netmask=255.255.255.0 --gateway=192.168.0.1 --hostname=esx12.virten.lab --nameserver=192.168.0.1
rootpw VMware1!

%post --interpreter=busybox

/bin/mcopy -o -i /dev/disks/mpx.vmhba32\:C0\:T0\:L0\:5 ::BOOT.CFG /tmp/BOOT.cfg
/bin/sed -i '/kernelopt/s/$/ cpuUniformityHardCheckPanic=FALSE/' /tmp/BOOT.cfg
/bin/mcopy -o -i /dev/disks/mpx.vmhba32\:C0\:T0\:L0\:5 /tmp/BOOT.cfg ::BOOT.CFG
/bin/reboot

%firstboot --interpreter=busybox

# Enable SSH
vim-cmd hostsvc/enable_ssh
vim-cmd hostsvc/start_ssh

# Enable ESXi Shell
vim-cmd hostsvc/enable_esx_shell
vim-cmd hostsvc/start_esx_shell

# Suppress Shell warning
esxcli system settings advanced set -o /UserVars/SuppressShellWarning -i 1

# Disable CPU Uniformity Check
localcli system settings kernel set -s cpuUniformityHardCheckPanic -v FALSE

# SSH Key
cat > /etc/ssh/keys-root/authorized_keys <<EOF
ssh-rsa AAAAB3N[...] yourname
EOF

# NTP
esxcli system ntp set -s pool.ntp.org
esxcli system ntp set -e 1

4. Далее можете провести установку с USB-флэшки, а через пару минут вы уже сможете получить доступ к ESXi через консоль или по SSH.

5. Если вы используете механизм Secure Boot, то обычно секция %firstboot не применяется (так работает по умолчанию на большинстве систем). Поэтому вам потребоваться ввести команды этой секции вручную или отключить Secure Boot. С командами раздела %post все будет в порядке.

6. По окончании установки через Kickstart все будет работать:


Таги: VMware, vSphere, CPU, ESXi, Bugs, Blogs

Адаптивный механизм RAID-5 в инфраструктуре VMware vSAN 8.0 ESA (Express Storage Architecture)


Мы много писали о новой версии решения для организации кластеров отказоустойчивых хранилищ VMware vSAN 8.0, в последней версии которого появилось много всего нового, в частности архитектура ESA (Express Storage Architecture). Это новая архитектура гиперконвергентной инфраструктуры, позволяющая достичь максимальных показателей производительности и эффективности на базе высокопроизводительных систем хранения.

За счет использования флэш-памяти TLC на основе технологии NVMe, архитектура ESA имеет множество преимуществ по сравнению со стандартной vSAN Original Storage Architecture (OSA), которая также продолжает поддерживаться для стандартного на текущий момент оборудования (устройства SATA/SAS).

Дункан Эппинг недавно рассказал о том, как в архитектуре ESA работает механизм адаптивного RAID-5. Он позволяет развернуть определенную конфигурацию RAID-5, в зависимости от того, сколько хостов ESXi находится в кластере vSAN. Базовое правило тут такое:

  • RAID-5, конфигурация 2+1 - выставляется при 3-5 хостах в кластере
  • RAID-5, конфигурация 4+1, выставляется при 6 и более хостах

При схеме 2+1 вы получите 50% надбавку к сырой емкости, то есть чтобы хранить 100 ГБ данных вам потребуется 150 ГБ хранилища.

Для конфигурации 4+1 (при 6 хостах и более) вы получаете меньшую потерю емкости - всего 25%, то есть для хранения данных в объеме 100 ГБ на Capacity leg вам потребуется всего 125 ГБ емкости.

Интересная особенность Adaptive RAID-5 в том, что он постоянно следит за размером кластера в реальном времени. То есть, если у вас есть 6 хостов, а один из них падает или переходит в режим обслуживания, то vSAN автоматически переключает конфигурацию с 4+1 на 2+1 по истечении 24 часов (а потом и обратно при восстановлении исходной конфигурации).

Функциональность адаптивного RAID-5 работает и в растянутом (stretched) кластере. То есть, если у вас растянутый кластер в схеме 3+3+1, то вы увидите в нем конфигурацию RAID-5 в схеме 2+1, а если у вас кластер 6+6+1 (или более), то конфигурация будет 4+1. Если вы поместите несколько хостов в режим обслуживания, то конфигурация также изменится с 4+1 на 2+1, а потом изменится обратно на 4+1, когда хосты ESXi снова будут введены в строй.

Ну и видео о том, как это работает на практике:


Таги: VMware, vSAN, Storage, RAID, Blogs

Кастомный дэшборд CPU Core для решения VMware Aria Operations


По итогам конференции Explore 2022 компания VMware представила линейку продуктов Aria, пришедшую на смену семейству vRealize. В нее вошло онпремизное решение Aria Operations 8.10, а также облачное Aria Operations Cloud. Оба они предназначены для комплексного управления и мониторинга виртуальной облачной инфраструктуры в различных аспектах.

Одной из главных возможностей Aria Operations являются дэшборды, которые показывают различные метрики виртуальной инфраструктуры, собираемые как напрямую, так и с помощью менеджмент-паков. Сегодня мы посмотрим на интересный дэшборд CPU Core, который предоставляет информацию об используемых ядрах CPU на уровне разных объектов - от датацентров до хостов VMware ESXi.

В рамках анонсированной недавно подписки vSphere+ и решения vRealize Cloud Subscription Manager появилась возможность лицензировать компоненты виртуальной инфраструктуры vSphere и Aria на базе ядер процессоров (CPU Cores). Ниже мы посмотрим, как можно с помощью Aria Operations визуализовать распределение процессоров, чтобы оптимизировать потребление лицензий. Об этом рассказал Karthic Kumar в блоге VMware.

Дэшборд - это мощный функционал Aria Operations, который дает администратору коллекцию виджетов и связанную информацию об объектах датацентра. Мы создадим суперметрики (super metrics) и представления (Views), которые предоставляют данные для дэшборда Core distribution. Чтобы упростить процесс, используем шаблон, в котором есть следующие файлы:

  • Super Metrics (supermetrics.json)
  • Views (views.zip)
  • Dashboard(dashboard.zip)

Итак, скачиваем файл шаблона и заходим в консоль Aria / vRealize Operations под аккаунтом администратора. Нам надо импортировать суперметрики из JSON-файла, для этого идем в Configure –> Super Metrics –> Import и выбираем Supermetric.json:

После импорта у нас в списке появится суперметрика CorePerSocket. Выбираем для нее пункт Edit и включаем ее в политике по умолчанию, чтобы она применилась:

Далее нужно импортировать представления (Views), которые забирают данные суперметрик. Идем в Visualize –> Views –> Manage–> Import и выбираем файл views.zip:

После этого мы увидим импортированные представления в списке:

Теперь пришло время импортировать сам дэшборд. Идем в Visualize –> Dashboards –> Manage–> Import и выбираем файл Dashboard.zip:

Теперь можно кликнуть на Core Distribution в списке дэшбордов. Чтобы данные актуализировались может пройти до 15 минут (если вы видите надпись "No data available"):

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


Таги: VMware, vSphere, ESXi, Aria, Operations, Blogs

Сжатие и дедупликация в 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

Функция URL Filtering в VMware NSX - как это работает?


В декабре прошлого года компания VMware анонсировала обновление решения VMware NSX-T 3.2, предназначенного для сетевой виртуализации и агрегации виртуальных сетей датацентров, работающих на базе гибридной среды гипервизоров, физических серверов и контейнеров приложений Kubernetes.

В новой версии этой платформы появились функции URL Filtering, позволяющие фильтровать доступ к веб-сайтам по их адресу на базе таких параметров, как категория URL, его репутация, а также различные кастомные правила. Сегодня мы приведем перевод статьи сайта Yo Go Virtual о том, как работать с этим механизмом.

URL filtering поддерживается только на шлюзе Tier-1 Gateway. Политика Access Control Policy для URL filtering применяется как к обычному http-трафику, так и для шифрованного https-канала, для которого нужно включить политику TLS Inspection, чтобы расшифровать трафик. Без включенного TLS inspection функция URL filtering будет использоваться на уровне домена с использованием расширения TLS Server Name Indication (SNI) в клиенте TLS hello. Эта возможность работает совместно с FQDN Analysis (которая ранее называлась URL Analysis в NSX-T 3.0).

Функция URL Filtering настраивается в профиле L7 access profile для правил сетевого экрана шлюза. Сначала мы включаем URL Database для кластера Edge Cluster, где мы хотим использовать эту возможность. Это вызовет скачивание базы данных URL из NSX Threat Intelligence Cloud Service.

Чтобы это сделать, идем в:

NSX Manager -> Security -> General Settings -> URL Database

Теперь надо создать L7 access profile, для чего идем в:

NSX Manager -> Inventory -> Profiles -> L7 Access Profiles

Нажимаем ADD L7 ACCESS PROFILE и вводим имя профиля:

Нажимаем Set в колонке создания одного или нескольких атрибутов Attribute Entries:

Нажимаем ADD ATTRIBUTE TYPE, где можно выбрать различные типы добавляемого атрибута...Читать статью далее->


Таги: VMware, NSX, Blogs

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 VMworld 2021 уже доступен + рекомендации от Дункана Эппинга


Компания VMware уже несколько недель назад сделала доступным каталог сессий предстоящего VMworld 2021. Некоторое время назад мы уже писали про изменения, которые произойдут в онлайн-конференции, а сегодня немного расскажем о самом каталоге будущих выступлений.

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

А вот список самого интересного от Дункана Эппинга - глубокие технические сессии от известных блоггеров и сотрудников VMware:

  • Project Monterey: Present, Future and Beyond [MCL1401] by Sudhanshu Jain and Simer Singh
  • What Is the Future of Cloud and On-Premises Storage and Availability? [MCL2590]
  • Make Sustainable Choices for Product Innovation, Operations: What Can I Do? [IC2794]
  • Core Storage Best Practices Deep Dive [MCL2071]
  • Security Deep Dive and Emerging Capabilities in VMware Cloud on AWS [SEC1362]
  • VEBA Revolutions – Unleashing the Power of Event-Driven Automation [CODE2773]
  • VDI Nerdfest 2021: Demos That Make Admins Drool [EUS1289]
  • Extreme Performance Series: Performance best practices [MCL1635]
  • 60 Minutes of Non-Uniform Memory Access (NUMA) 3rd Edition [MCL1853]
  • Best Practices for Running AI Workloads in VMs on VMware vSphere [VI1459]
  • The Future of VM Provisioning – Enabling VM Lifecycle Through Kubernetes [APP1564]
  • The Evolution of Intelligent Edge and Electrical Grid Modernization [VI1455]
  • Upskill Your Workforce with Augmented and Virtual Reality and VMware [VI1596]
  • Automating Ransomware Remediation with the VMware Carbon Black Cloud SDK [CODE2782]
  • Migration in Action with Google Cloud VMware Engine [MCL1764]

В общем, в начале октября будет точно что посмотреть и послушать!


Таги: VMware, VMworld, Blogs

Как дать пользователю VMware vSphere права на просмотр пространств имен vSphere with Tanzu


Вильям Лам рассказал о том, как быстро и просто дать пользователям клиента VMware vSphere Client разрешения для просмотра пространств имен (namespaces) кластера vSphere with Tanzu.

Соответствующее разрешение нужно добавить в настройках Single Sign-On клиента:

Single Sign On->Users and Groups-> вкладка Groups

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

После этого пользователю надо разлогиниться и залогиниться снова, а для просмотра пространств имен vSphere with Tanzu будет достаточно базовой роли Read Only для vSphere, которую можно дать разработчику (никаких изменений в конфигурацию чего бы то ни было такой пользователь внести не сможет):

Для пользователей и групп из Active Directory все работает точно таким же образом.


Таги: VMware, vSphere, Client, Tanzu, Kubernetes, Security, Permissions, Blogs

First Class Disks и их использование в VMware vRealize Automation


Некоторое время назад мы писали о First-Class Disks (FCD), которые были придуманы для того, чтобы управлять сервисами, заключенными в VMDK-диски, но не требующими виртуальных машин для своего постоянного существования.

Тома Persistent Volumes (PV) на платформе vSphere создаются как First-Class Disks (FCD). Это независимые диски без привязанных к ним ВМ. К таким относятся, например, тома VMware App Volumes, на которых размещаются приложения, и которые присоединяются к виртуальным машинам во время работы пользователя с основной машиной. Также к таким дискам относятся хранилища для cloud native приложений и приложений в контейнерах, например, работающих через Docker Plugin и драйвер Kubernetes.

При создании профиля хранилищ вы можете указать тип диска как FCD:

В VMware vSphere 7 Update 2 для FCD появилась поддержка снапшотов и их можно делать в количестве до 32 штук. Это позволяет делать снапшоты ваших K8s PV на платформе vSphere Tanzu.

В VMware vRealize Automation версии 8.2 появилась поддержка First-Class Disks (FCD), что открывает большие возможности по автоматизации операций при управлении такими хранилищами. Это функции улучшаются с каждым релизом vRA.

Eric Sloof написал небольшую заметку об использовании таких дисков с vRealize Automation. Одно из преимуществ дисков FCD - это возможность создавать их снапшоты независимо от каких-либо виртуальных машин.

При создании и редактировании описания профиля хранилищ в VMware vRealize Automation вы можете указать поддержку в дисков FCD или обычных дисков в storage profile:

Также через API в vRealize Automation вы можете получить доступ к операциям Create, Edit, Delete и List для таких дисков. Также в рамках рабочих процессов в Automation доступны и day-2 операции, такие как добавление диска, привязка/отвязывание и изменение размера.

Для снапшотов диска также доступны операции управления их жизненным циклом. Так что администраторы теперь могут придумывать и автоматизировать рабочие процессы с постоянными виртуальными дисками FCD для самых разных задач.


Таги: VMware, FCD, Storage, Disk, vRealize, Automation, Blogs

Видео для разработчиков и администраторов - создание виртуальной машины с помощью VM Service


Недавно мы писали о VM Service - службе, которая дает разработчикам и администраторам, работающих со средой контейнеров Kubernetes в решении vSphere with Tanzu, возможности по развертыванию виртуальных машин. Она была анонсирована в vSphere 7 Update 2a. Также мы рассказывали о том, как зайти в консоль вспомогательных виртуальных машин VM Service.

Пару недель назад Cormac Hogan выпустил интересное видео для разработчиков и администраторов, в котором показывается, как можно создавать виртуальные машины на базе vSphere with Tanzu с помощью YAML-манифеста для пользовательских данных и ВМ:

Ну и, конечно же, рекомендуем отличную статью "A first look at vSphere VM Service" от автора видео.


Таги: VMware, vSphere, Tanzu, Kubernetes, VMachines, Blogs

Изменение Message of the day в VMware vSphere Client


Если у вас большая Enterprise-инсталляция VMware vSphere, и вам хочется оповещать пользователей о каких-либо важных статусах, изменениях или новостях, то вы можете использовать механизм Message of the Day (MotD) - сообщение, которое появляется в верхней части экрана vSphere Client. Например, пользователям можно сообщить, что они работают в Sandbox-окружении:

Вильям Лам рассказал о том, как правильно можно работать с этим с точки зрения автоматизации. В интерфейсе это сообщение можно настроить в разделе Configure->Settings->Message of Day:

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

Ну и главное - как это автоматизировать, если у вас несколько окружений vCenter?

Вот такой командой можно получить сообщение дня через PowerCLI:

Get-AdvancedSetting -Entity $global:DefaultVIServer -Name vpxd.motd | select Value

К сожалению, с помощью Set-AdvancedSetting нельзя установить это сообщение, так как для обертки API это свойство находится в статусе Read Only. Поэтому нужно использовать API напрямую.

Вот так можно посмотреть текущий MotD:

$sm = Get-View $global:DefaultVIServer.ExtensionData.Content.SessionManager
$sm.Message

А вот так - обновить его:

$motd = "This is William Lam's environment, it is NOT supported. Use at your own risk"
$sm = Get-View $global:DefaultVIServer.ExtensionData.Content.SessionManager
$sm.UpdateServiceMessage($motd)


Таги: VMware, vSphere, Client, Blogs

Ограничение доступа к веб-интерфейсу VMware vSphere Client по IP-адресу


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

Вильям Ламм рассказал о простом способе ограничения доступа к UI клиента vSphere Client. Делается это через настройки сервера Apache Tomcat, на базе которого построен виртуальный модуль vCenter Server Appliance. Называется это Access Control Valve - по ссылке можно подробно изучить опции, которые можно применять, а мы же рассмотрим простой пример ниже.

Идем по SSH на vCSA и открываем там следующий файл:

/usr/lib/vmware-vsphere-ui/server/conf/context.xml 

В него добавляем следующую запись:

<Valve className="org.apache.catalina.valves.RemoteAddrValve" allow="127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1|localhost|x.x.x.x|y.y.y.y"/>

Значения x.x.x.x, y.y.y.y и далее за ними можно указать как разрешенные адреса для соединения с сервером. Блок "127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1|localhost" должен присутствовать всегда для обеспечения локального соединения сервисов самого vCenter.

Адреса, не занесенные в этот список, при соединении через веб-браузер получат 403 ошибку, при этом доступ через PowerCLI и API останется для этих адресов (поскольку это только настройка веб-сервера):

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

service-control --restart vsphere-ui


Таги: VMware, vSphere, Client, Security, Blogs

Готовые виртуальные модули Nested ESXi Virtual Appliances для тестовой лаборатории


На сайте Вильяма Лама есть специальный раздел, посвященный вложенной виртуализации (Nested Virtualization) на базе гипервизора VMware ESXi. В частности, Вильям делает сборки ESXi, которые уже подготовлены к использованию в качестве виртуальных машин как виртуальные модули (Virtual Appliances) в формате OVA. Это может понадобиться для тестовых сред, когда вам нужно развернуть большую инфраструктуру и сделать полноценный кластер, а в распоряжении есть только 1-2 физических сервера.

Также обратите внимание на наш пост о библиотеке Content Library с шаблонами виртуальных модулей Nested ESXi от Вильяма. Адрес для подписки на эту библиотеку следующий:

https://download3.vmware.com/software/vmw-tools/lib.json

Кстати, все статьи о вложенной виртуализации можно найти и у нас по тегу Nested.


Таги: VMware, ESXi, Nested, Virtual Appliance, Blogs

Как сделать хост VMware vSphere Primary (он же Master) в кластере HA


Дункан Эппинг написал интересный пост о том, что в кластере VMware HA есть возможность сделать хостам ESXi такую настройку, чтобы они выбирались как Primary при конфигурации/реконфигурации кластера. Это может оказаться полезным, например, в растянутом (Stretched) кластере, когда вам важно, чтобы Primary-хосты находились на основной площадке с целью ускорения процесса восстановления после сбоя (речь идет о 2-3 секундах в большинстве случаев, но для некоторых инфраструктур это может быть критично).

Пост этот актуален еще и потому, что настройки несколько изменились, начиная с VMware vSphere 7 Update 1, поэтому информация об этом может быть полезна для администраторов.

Прежде всего, в статье VMware KB 80594 рассказывается о том, какие настройки были изменены в механизме VMware FDM (он же HA). Самое главное, что до vCenter 7 Update 1 настройки хранились в файле /etc/opt/vmwware/fdm/fdm.cfg, теперь же они переехали в ConfigStore, работать с которым нужно путем импорта и экспорта json-файлов конфигурации.

Вот, кстати, интересующая нас табличка с изменениями параметров Advanced Settings в FDM:

Нас здесь интересует настройка node_goodness, большое численное значение которой и определяет, будет ли данный узел выбран как Primary (ранее в HA он также назывался Master).

Итак, Дункан показывает, как можно экспортировать расширенные настройки из ConfigStore:

configstorecli config current get -g cluster -c ha -k fdm
{
   "mem_reservation_MB": 200,
   "memory_checker_time_in_secs": 0
}

Все это можно также экспортировать в json-файл командой:

configstorecli config current get -g cluster -c ha -k fdm > test.json

Далее добавляем в этот json параметр node_goodness с большим значением, например, 10000000:

{
    "mem_reservation_MB": 200,
    "memory_checker_time_in_secs": 0,
    "node_goodness": 10000000
}

И импортируем его обратно в ConfigStore:

configstorecli config current set -g cluster -c ha -k fdm -infile test.json

В итоге хост ESXi 1507 был Primary:

А затем им стал узел 1505, для которого мы изменили данную расширенную настройку:

Ну и Дункан записал небольшое видео, раскрывающее весь процесс изменения данных настроек в VMware FDM / HA:


Таги: VMware, HA, vSphere, ESXi, Blogs, FDM, vCenter

Вышел VMware PowerCLI 12.2 - что нового?


Наш постоянный читатель Сергей обратил внимание на то, что на днях компания VMware выпустила обновление своего главного фреймворка для управления виртуальной инфраструктурой с помощью сценариев - PowerCLI 12.2. Напомним, что о прошлой версии PowerCLI 12.1 осенью прошлого года мы писали вот тут.

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

1. Поддержка VMware Horizon

Модуль PowerCLI для управления инфраструктурой Horizon теперь поддерживается для macOS и Linux OS.

2. Инфраструктура VMware Cloud

Появилась поддержка одного из самых популярных сервисов для обеспечения катастрофоустойчивости датацентров - DRaaS. Новые командлеты позволяют включать/отключать DRaaS в виртуальном датацентре VMC SDDC, а также добавлять и удалять инстансы SRM (Site Recovery Manager).

Вот так выглядит включение DRaaS:

Управление инстансами SRM происходит с помощью командлетов:

3. Поддержка VMware vSphere

  • Расширенная поддержка vSphere Lifecycle Manager (vLCM)
    • Новые командлеты для экспорта и импорта состояния кластера
    • Новые командлеты для получения рекомендаций vLCM (Get-LcmClusterDesiredStateRecommendation)
    • Новые командлеты для получения аппаратной совместимости компонентов со стороны vLCM
    • Улучшенный командлет Set-Cluster для добавления кастомного репозитория ROBO-окружений
  • Расширенная поддержка параметров OVF для объектов Content Library
  • Добавлена поддержка шаблонов ВМ в Content Library
  • Операция Foreach-object -Parallel теперь поддерживается

Вот так выглядит экспорт состояния кластера:

А вот так импорт:

4. Управление рабочими нагрузками

5. Поддержка NSX-T

  • Теперь поддерживаются API компонента NSX-T global manager

Больше подробностей и примеров использования новых фич вы можете найти вот в этой статье. Скачать VMware PowerCLI 12.2 можно по этой ссылке.


Таги: VMware, PowerCLI, Update, Blogs

1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13    >   >>
Интересное:





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

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 Update Avi Aria Broadcom Workstation Private AI EUC Community vSAN VCF Skyline NSX HCX AI Host Client Explore Chargeback Horizon Labs SASE Tanzu 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 ESA Troubleshooting Director Android Python Upgrade Stretched 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.

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

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

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

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

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

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

Интервью:

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