Вильям Лам выложил интересный сценарий PowerCLI, который поможет вам получить информацию об использовании хранилищ и накладных расходах vSAN с использованием API.
В интерфейсе vSphere Client вы можете увидеть подробный анализ использования хранилища vSAN, включая различные системные накладные расходы, выбрав конкретный кластер vSAN, а затем перейдя в раздел Monitor->vSAN->Capacity, как показано на скриншоте ниже:
Различные конфигурации vSAN, такие как использование традиционной архитектуры хранения vSAN OSA или новой архитектуры vSAN Express Storage Architecture (ESA), а также активация функций, таких как дедупликация и сжатие vSAN, приводят к различным метрикам использования дискового пространства, которые отображаются в разделе информации.
Недавно у Вильяма спросили - а как получить информацию о накладных расходах, связанных с дедупликацией и сжатием vSAN, с использованием PowerCLI?
Хотя командлет PowerCLI vSAN Get-VsanSpaceUsage предоставляет множество метрик использования, отображаемых в интерфейсе vSphere, он не раскрывает все свойства.
Тем не менее, мы можем использовать PowerCLI для получения этой информации, используя базовый метод vSAN API, который предоставляет эти данные, в частности querySpaceUsage(). Как видно из документации по API, этот метод возвращает массив объектов типов использования vSAN, которые соответствуют данным, отображаемым в интерфейсе vSphere, с расшифровкой свойства ObjType.
Чтобы продемонстрировать использование этого API, Вильям создал пример PowerCLI-скрипта под названием vsanUsageAndOverheadInfo.ps1, в котором вам нужно просто обновить переменную $vsanCluster, указав имя нужного кластера vSAN.
После подключения к серверу vCenter вы можете просто выполнить этот скрипт, как показано ниже:
Вильям Лам написал полезную статью о новой фиче вышедшего недавно обновления фреймворка для управления виртуальной инфраструктурой с помощью сценариев - VMware PowerCLI 13.3.
Параметры загрузки ядра (kernel boot options) в VMware ESXi можно добавить во время загрузки ESXi (нажав SHIFT+O) или обновив файл конфигурации boot.cfg, чтобы повлиять на определенные настройки и/или поведение системы.
Раньше было сложно получить полную картину по всем ESXi хостам, чтобы определить, на каких из них используются пользовательские параметры загрузки, особенно в тех случаях, когда они уже не нужны или, что хуже, если кто-то вручную добавил настройку, которую вы не планировали.
В vSphere 8.0 Update 3 добавлено новое свойство bootCommandLine в vSphere API, которое теперь предоставляет полную информацию обо всех параметрах загрузки, используемых для конкретного ESXi хоста.
На днях был выпущен релиз PowerCLI 13.3, который поддерживает последние API, представленные как в vSphere 8.0 Update 3, так и в VMware Cloud Foundation (VCF) 5.2. Вы можете легко получить доступ к этому новому свойству, выполнив следующую команду в сценарии:
За месяц до VMware Explore 2024 в Лас-Вегасе компания VMware представила новую версию PowerCLI 13.3. В этом выпуске исправлены многочисленные ошибки, добавлены улучшения и новые возможности, такие как командлет для отчета о привилегиях Privilege Report и другие. Давайте разберем все детали этой новой версии PowerCLI. А о возможностях прошлой версии PowerCLI 13.2 вы можете почитать у нас тут.
Улучшения VCF SDDC Manager
В версии 13.3 было добавлено два новых командлета:
Wait-VcfTask — позволяет ожидать завершения асинхронных операций, например задач.
Wait-VcfValidation — позволяет ожидать завершения конкретных операций проверки VCF, например операций проверки доменов.
Улучшения vSphere
Был добавлен новый командлет для записи проверок привилегий, которые происходят для указанных сессий при выполнении указанного блока сценария:
Get-VIPrivilegeReport
Улучшения VSAN
В PowerCLI 13.3 было добавлено два новых командлета для настройки пороговых значений алармов:
New-AlarmTriggerArgument — создает новый триггер действия для указанного аларма.
Get-AlarmTriggerArgumentAttributeName — выводит имена атрибутов аргумента триггера тревоги для события типа "vsan.health.ssd.endurance".
Также было обновлено несколько существующих командлетов:
Get-VsanSpaceUsage — добавлена поддержка нового атрибута "коэффициент эффективности использования пространства" в типе возвращаемых данных.
Set-VsanClusterConfiguration — добавлен новый параметр "vsanmaxenabled" для включения службы vSAN Max.
Get-VsanClusterConfiguration — добавлен новый параметр "vsanmaxenabled" для проверки, включен ли кластер vSAN как vSAN Max.
Улучшения HSX
В PowerCLI 13.3 добавлено два новых командлета для настройки гостевых операционных систем:
New-HCXGuestOSNetworkCustomization - создает объект для настройки сети, который является частью кастомизации гостевой ОС.
New-HCXGuestOSCustomization - создает объект для кастомизации гостевой ОС.
Следующие два командлета обновлены для использования вышеупомянутых новых командлетов в качестве параметров:
New-HCXMigration — для настройки гостевой ОС на уровне миграции.
New-HCXMobilityGroupConfiguration — для настройки гостевой ОС на уровне группы.
Улучшения Image Builder
В PowerCLI 13.3 теперь есть поддержка Python версии 3.12. Наряду с этим добавлена поддержка OpenSSL 3.0. Поддержка OpenSSL 1.1 прекращена из-за завершения срока поддержки, объявленного в сентябре 2023 года.
Обновленные модули SDK
Следующие модули обновлены в PowerCLI 13.3:
Модули vSphere обновлены до vSphere 8.0U3.
Модули NSX обновлены до NSX 4.2.0.0.
Модули SRM и vSphere Replication обновлены до версии 9.0.1.
Модуль VCF обновлен до VMware Cloud Foundation 5.2.
Для получения более подробной информации, пожалуйста, ознакомьтесь с подробным журналом изменений и Release Notes для PowerCLI 13.3.
Если у вас нет полноценного способа резервирования конфигураций серверов ESXi, но вы задумались о том, что будет если, то вот тут есть простой и свежий сценарий, который позволить вам сделать бэкап конфигурации и восстановить конфигурацию хостов ESXi.
Автор не хотел вручную создавать резервные копии каждого ESXi хоста, так как это не масштабируется. Вместо этого он создал PowerShell скрипт под названием vCenter ESXi Config Backup, который выполняет в автоматическом режиме.
Скрипт vCenter ESXi config backup подключается к VMware vCenter, далее использует его для подключения к каждому ESXi хосту и последовательно создает резервную копию каждой конфигурации. Поскольку скрипт использует vCenter, вам не нужно включать SSH на каких-либо ESXi хостах для выполнения резервного копирования.
По умолчанию, скрипт предполагает, что вы не подключены к vCenter, и запросит вас подключиться к vCenter. Вы можете изменить это поведение, если вы уже подключены к vCenter, установив опциональный параметр connected со значением Yes.
Скрипт проверяет, существует ли указанная вами папка для резервного копирования. Если папка не существует, скрипт создаст ее.
Затем скрипт получает все ESXi хосты в vCenter, подключается к каждому из них и создает резервную копию конфигурации. Скрипт сохраняет резервную копию в указанную вами папку.
После завершения резервного копирования скрипт переименовывает файл резервной копии, добавляя к имени хоста установленную версию ESXi, номер сборки и дату резервного копирования.
Для использования скрипта необходимо предоставить несколько параметров. Первый параметр — vcenter, за которым следует FQDN-имя вашего vCenter. Второй параметр — folder, за которым следует расположение, куда вы хотите сохранить резервные копии конфигурации ESXi.
Администраторы часто ищут способ, как получить список всех снапшотов в окружении VMware vSphere, поскольку они засоряют хранилище и могут потенциально замедлить работу виртуальных машин, а также привести к их сбоям (здесь золотое правило - не использовать пользовательские снапшоты в качестве бэкапов).
Для этих целей можно использовать специализированные утилиты, такие как RVTools, а можно воспользоваться фреймворком PowerCLI. Там вы можете выполнить одну простую команду:
На сайте VMware Developer появился полезный сценарий PowerCLI, который позволяет администратору изменить текущий контроллер SCSI на новый тип для виртуальной машины на платформе VMware vSphere.
Некоторые особенности работы этого сценария:
Не проверяет, настроена ли виртуальная машина для 64-битной гостевой ОС (адаптер BusLogic не поддерживается)
Ппроверяет, работают ли VMware Tools и выключает виртуальную машину с помощью функции выключения гостевой ОС
Возвращает виртуальную машину в предыдущее рабочее состояние
Проверяет, было ли уже установлено новое значение контроллера SCSI
Функция Modify-ScsiController вызывается в самом конце скрипта. Вот различные примеры того, как функция может быть использована:
В рамках проходившей недавно конференции Explore 2023 Europe компания VMware анонсировала релиз новой версии своего основного фреймворка для управления виртуальной инфраструктурой с помощью сценариев - PowerCLI 13.2. Напомним, что о прошлой версии этого пакета - PowerCLI 13.1 - мы писали вот тут.
Этот релиз предоставляет официальную поддержку VMware Cloud Foundation (VCF) в PowerCLI, а также новые функции для vSphere, vSAN и VMware Cloud.
1. Новые SDK-модули для VCF
VMware Cloud Foundation (VCF) - это интегрированная платформа, объединяющая полный спектр программно-определяемых сервисов в единую систему. По мере того, как все больше клиентов VMware начинают использовать VCF, увеличивается и спрос на автоматизацию через CLI. До сих пор единственным вариантом был модуль PowerVCF с открытым исходным кодом, но с PowerCLI 13.2 было добавлено два официальных модуля VCF – VMware.Sdk.Vcf.CloudBuilder и VMware.Sdk.Vcf.SddcManager. Это SDK-модули, использующие ту же технологию, что и модули PowerCLI SDK для vSphere Automation, NSX, SRM и API vSphere Replication. Как и в случае со всеми SDK-модулями, примеры PowerCLI можно найти непосредственно в документации REST API для VCF.
2. Новые функции управления жизненным циклом vSphere
В PowerCLI 13.2 было добавлено два новых командлета для vLCM:
Export-LcmVMHostDesiredState экспортирует желаемое состояние хоста vSphere Lifecycle Manager
New-OfflineBundle создает автономный пакет, соответствующий требованиям vLCM, на основе введенных данных о хранилищах и спецификации программного обеспечения.
3. Новые функции vSAN
В PowerCLI 13.2 был добавлен новый командлет Get-VsanPerformanceContributor в модуль VMware.VimAutomation.Storage. Он позволяет получить список наиболее значимых объектов, влияющих на производительность vSAN. Также был расширен вывод командлета Get-VsanSpaceUsage за счет свойства EsaObjectOverheadGB, которое предоставляет информацию о дополнительных накладных расходах для объектов vSAN ESA на хранение метаданных и обеспечение высокой производительности.
4. Новые функции VMware Cloud
В PowerCLI 13.2 были расширены командлеты New-VmcSddc и New-VmcSddcCluster за счет добавления поддержки хостов I4I.
5. Обновленные SDK-модули
В PowerCLI 13.2 были обновлены все модули, предоставляющие привязки к API. А именно:
Модули vSphere обновлены до версии vSphere 8.0 Update 2
Модули NSX обновлены до версии NSX 4.1.2
Модули SRM и vSphere Replication обновлены до версии 8.8
Модуль Horizon обновлен до VMware Horizon 8 2306
Скачать последнюю версию фреймворка VMware PowerCLI 13.2 можно по этой ссылке.
Еще в 2015 году мы писали о том, что проект VMware Sample Exchange вышел в бета-версии. Это портал, предназначенный для разработчиков средств автоматизации виртуальной инфраструктуры, где они могут скачивать примеры кода на разных языках и для разных платформ под множество компонентов виртуальной среды.
За прошедшие 8 лет этот проект накопил огромное количество различных сценариев и примеров кода как от сотрудников VMware, так и от сообщества разработчиков, которые постоянно добавляют туда новые сэмплы (вы тоже можете это делать).
Если при первоначальном запуске портала там было всего 250 сэмплов, то теперь их стало более двух тысяч, как видно на скиншоте ниже:
Посмотрите, какое огромное количество языков и платформ представлено на портале, одних только дэшбордов для решения vRealize (Aria) Operations - 300 штук!
Примерно столько же представлено и сценариев для автоматизации инфраструктуры средствами PowerShell/PowerCLI, а вот это уже - большая находка.
На сайте проекта VMware Labs вышло небольшое обновление утилиты Power Actions версии 1.0.3. Напомним, что о прошлой версии мы писали вот тут. Это средство представляет собой плагин для клиента vSphere, который обеспечивает простой способ исполнения скриптов PowerCLI пользователями, не имеющими опыта работы с PowerShell. Утилита также реализует библиотеку скриптов, куда вы можете загрузить готовые скрипты PowerCLI, которые вы хотите сделать доступными для всех сотрудников вашей организации.
Давайте посмотрим, что нового в VMware Power Actions 1.0.3:
В апреле этого года мы писали о первой версии самостоятельного (ранее это были функции HTML5 клиента) решения VMware Power Actions 1.0. Этот продукт представляет собой плагин для клиента vSphere, который обеспечивает простой способ исполнения скриптов PowerCLI пользователями, не имеющими опыта работы с PowerShell. Средство также реализует библиотеку скриптов, куда вы можете загрузить готовые скрипты PowerCLI, которые вы хотите сделать доступными для всех сотрудников вашей организации.
Пользователи могут легко выполнить эти скрипты, используя удобный интерфейс для указания параметров скрипта.
Это обеспечивает мощный механизм расширения клиента vSphere с помощью настраиваемых сценариев PowerCLI. Все скрипты выполняются с использованием прав пользователя, который вошел в клиент vSphere. Таким образом, если у пользователя нет разрешения на выполнение определенных операций, он не сможет выполнить эти операции с помощью Power Actions.
Вот как это работает:
На днях на сайте проекта VMware Labs стала доступна обновленная версия Power Actions 1.0.2. Давайте посмотрим, что там нового:
Исправление для бага 1491 (установка не выполняется, когда отсутствует интернет-соединение)
Добавлены настройки прокси-сервера, позволяющие развертывание в средах с проксированием (баг 1495)
Настройка Thumbprint сервера vCenter заменена на настройку Disable vCenter Server Certificate Verification (отключение проверки сертификатов)
Установка изменена так, чтобы она не завершалась неудачей, если пароль виртуального модуля (Virtual Appliance) не был успешно установлен.
Загрузить виртуальный модуль VMware Power Actions 1.0.2 можно по этой ссылке. Кстати, небольшое количество исправлений за столь долгое время говорит о том, что в целом-то инструмент работает хорошо.
В этом году компания VMware серьезно взялась за доработку своих фреймворков по автоматизации операций в виртуальной инфраструктуре. Это было обусловлено тем, что исторически у VMware накопилось большое количество средств автоматизации, которые когда-то были привязаны к специфическим продуктам и интерфейсам, потом эти продукты эволюционировали, объединялись в различные линейки, а старые интерфейсы продолжали тянуться за разными решениями, управлять которыми до сих пор можно несколькими разными способами, а с учетом различных платформ и вспомогательных сервисов таких способов становится слишком много.
Использование командлетов PowerShell/PowerCLI для автоматизации предлагает множество преимуществ, таких как простота установки на множестве различных операционных систем и мощный язык сценариев, поддерживающий команды, специфичные для VMware.
PowerCLI отлично интегрируется с экосистемой VMware, обеспечивая совместимость и бесшовную интеграцию с продуктами vSphere, vSAN, NSX, VMC, SRM и другими. Несмотря на то что PowerCLI работает автономно со своим собственным циклом выпуска, VMware стремимся синхронизировать его с официальными релизами vSphere. Это гарантирует, что клиенты PowerCLI не будут долго ждать доступа к новым функциям и возможностям, поставляемым в новых версиях VMware vSphere.
Вызовы VMware PowerCLI
Как и в других сферах автоматизации, сейчас есть некоторые проблемы, с которыми сталкиваются как в самой VMware, так и клиенты при использовании PowerCLI. В первую очередь здесь стоит возможность использовать PowerCLI на всех платформах, на которых работает PowerShell. Большинство людей ассоциируют PowerShell с Microsoft Windows, что вполне логично, но PowerShell Core становится довольно популярным на платформах Linux и MacOS. VMware стремится поддерживать эти платформы на том же уровне, что и для Windows.
Во-вторых, по мере эволюции VMware vSphere и других продуктов VMware, PowerCLI также должен меняться, и делать это быстро, чтобы успевать за нововведениями продуктовой линейки. Этот быстрый темп не должен влиять на удобство использования и качество командлетов PowerCLI. Поэтому стоит задача расширения охвата PowerCLI для продуктов за более короткий период времени, при этом нужно обеспечить требуемое качество модулей и командлетов.
Поддержка нескольких платформ
Когда PowerCLI 13.0 был выпущен в ноябре 2022 года, это был первый PowerCLI, полностью совместимый с PowerShell Core, который работает на Microsoft Windows, Linux и Apple MacOS. Это означает, что образец кода или сценарий можно запустить на любой из этих платформ, запланировать с помощью cron на Linux и т.п. Это делает его очень гибким в качестве инструмента автоматизации, и это означает больше возможностей для инструментов оркестрирования операций.
Автоматизация средств автоматизации
В выпуске PowerCLI 12.4 VMware представила инновационный подход к генерации командлетов: через механизмы автоматизации. Была автоматизирована генерация командлетов для vSphere Automation API, которая была выпущена в рамках нового модуля под названием VMware.SDK.vSphere. Этот подход позволяет быстро создавать командлеты и модули для поддержки новых функций, обеспечивая при этом качество и последовательность.
Однако успех этой стратегии во многом зависит от качества API самих продуктов. Ближайшая цель VMware - обеспечить выпуск API с высокими стандартами качества, которые также соответствуют требованиям PowerCLI.
Обширность покрытия
В последующих релизах после 12.4 продолжали внедрять новые модули PowerCLI на основе подхода автоматического генерирования, такие как модули VMware.Sdk.Nsx.Policy, VMware.Sdk.SRM и VMware.Sdk.VR.
Например, введенный в PowerCLI 12.6 модуль VMware.Sdk.Nsx.Policy позволяет клиентам управлять NSX Policy API и является важной частью мультиоблачных операций, помогая устанавливать контроль над безопасностью, независимо от того, где работает ваша нагрузка.
В выпуске 12.7 были добавлены новые командлеты для указания пороговых значений проверки "здоровья" vSAN в рамках модуля VMware.CimAutomation.Storage.
Выпуск 13.0 сделал PowerCLI мультиплатформенным инструментом, что также означало, что модули, такие как VMware.ImageBuilder и VMware.DeployAutomation, должны быть совместимы с Apple MacOS и Linux. Кроме того, были добавлены новые команды для управления дисками кластера vSAN ESA и обновлен модуль VMware.VimAutomation.Cloud для поддержки функций API VMware Cloud Director 10.4.
В последнем на данный момент выпуске PowerCLI 13.1, было представлено два новых модуля: VMware.Sdk.VR для поддержки REST API VMware vSphere Replication и VMware.Sdk.Srm для поддержки REST API VMware Site Recovery Manager. Также там добавили новые командлеты для офлайн-депозиториев Lifecycle Manager, удаленного управления хранилищем данных vCenter Server, прямого управления дисками vSAN, выключения кластера, монтирования удаленных хранилищ данных vSAN из расширенных кластеров vSAN и многого другого.
Что дальше?
Следующие шаги - это поддержание высокого уровня удобства использования и качества модулей и командлетов PowerCLI. VMware продолжает улучшать собственные инструменты, которые генерируют автоматизированные команды, а также проверяют и верифицируют исходные API в самих продуктах на предмет качества. Эти усилия приносят пользу всем средствам автоматизации, а не только PowerCLI.
Также будет расширяться охват PowerCLI за счет введения новых модулей и улучшений в существующих. Хорошим примером является поддержка автоматизации VMware Cloud Foundation, позволяющая клиентам контролировать, настраивать и автоматизировать эти среды так же легко, как они делают это с vSphere.
Наконец, будем продолжать поддерживаться кроссплатформенность, что позволит пользователям Windows, Linux и MacOS на равных использовать PowerCLI.
Недавно мы писали о новом релизе фреймворка для управления виртуальной инфраструктурой VMware PowerCLI 13.1. У данного средства есть очень много командлетов для автоматизации задач в различных продуктах VMware. Сегодня мы поговорим о том, как с помощью PowerCLI можно управлять задачами репликации в Site Recovery Manager (SRM) и vSphere Replication (VR). Данные операции осуществляются через REST API.
1. Подключение к серверу vSphere Replication через Connect-VrServer
Чтобы подключиться к серверу управления vSphere Replication, необходимо использовать команду Connect-VrServer. Репликация может быть настроена внутри одного сервера vCenter или между локальными и удаленными экземплярами сервера vCenter.
При настройке репликации внутри одного и того же сервера vCenter, вы можете подключиться только к локальному сайту репликации vSphere. В параметре Server укажите адрес сервера vSphere Replication. В параметрах User и Password укажите имя пользователя и пароль для экземпляра сервера vCenter, где развернут виртуальный модуль vSphere Replication.
Давайте рассмотрим объект VrServerConnection, возвращаемый командой Connect-VrServer. Он содержит свойство ConnectedPairings:
Это свойство является словарем, где хранятся все подключенные пары. Пара - это представление в API VR парных локального и удаленного сайтов. Поскольку мы только что прошли аутентификацию только на локальном сайте VR, в словаре содержится только одна запись. Это самоподключение локального vCenter.
Вы можете индексировать этот словарь по имени vCenter и получить определенный объект Pairing. Вам понадобится этот объект Pairing для вызова различных операций из API VR:
Чтобы аутентифицироваться на удаленном сервере vCenter, вы будете использовать другой набор параметров команды Connect-VrServer. Обратите внимание, что у вас должна быть настроена пара сайтов между локальным и удаленным сайтами vSphere Replication.
На этот раз для параметра LocalServer укажите уже доступный объект VrServerConnection. Для параметра RemoteServer укажите имя удаленного VC. Для параметров RemoteUser и RemotePassword укажите имя пользователя и пароль удаленного VC. Обратите внимание, что с VR мы можем настроить несколько удаленных сайтов:
Теперь, если вы проверите свойство ConnectedPairings объекта VrServerConnection, вы увидите, что в словаре появилась вторая пара, позволяющая вам вызывать операции API на удаленном сайте:
В качестве альтернативы вы можете аутентифицироваться на локальном и удаленном сайтах с помощью одного вызова Connect-VrServer:
Для начала вам нужно получить ВМ, которую вы хотите реплицировать. Используйте команду Invoke-VrGetLocalVms, для которой нужно указать параметры PairingId и VcenterId. У нас есть эти идентификаторы в объекте Pairing, который мы сохранили в переменной $remotePairing:
Вы также можете применить фильтр к этому вызову. Параметр FilterProperty указывает свойство ВМ, которое будет использоваться для поиска. В данном случае это свойство Name. Параметр Filter указывает значение свойства, которое вы ищете. Результатом этого вызова является объект VirtualMachineDrResponseList, который содержит список ВМ, соответствующих указанному фильтру. В нашем случае это будет список с одной ВМ:
Настройка HDD-дисков машин для репликации
При настройке репликации на основе хоста, вы должны указать жесткие диски ВМ, которые будут реплицированы. Для каждого реплицируемого диска вы должны указать хранилище данных на целевом vCenter. В этом примере мы будем реплицировать все жесткие диски нашей ВМ на одном целевом хранилище данных на удаленном vCenter.
Вот как получить целевое хранилище данных на удаленном vCenter, используя команду Invoke-VrGetVrCapableTargetDatastores:
Здесь для VcenterId укажите идентификатор удаленного vCenter. Укажите параметры FilterProperty и Filter, чтобы выбрать целевое хранилище данных по имени.
Жесткие диски доступны в свойстве Disks нашего объекта VirtualMachine, сохраненного в переменной $replicatedVm.
Пройдитесь по списку Disks и инициализируйте объекты ConfigureReplicationVmDisk для каждого жесткого диска. Сохраните эти конфигурации в переменной массива $replicationVmDisks:
Сначала вам нужно инициализировать объект ConfigureReplicationSpec. Помимо различных настроек репликации, мы должны указать конфигурацию репликации диска, сохраненную в переменной $replicationVmDisks, для параметра Disk. Также вам нужно указать идентификатор целевого vCenter и идентификатор реплицируемой ВМ.
Затем используйте команду Invoke-VrConfigureReplication для настройки репликации. В качестве параметров укажите PairingId и объект ConfigureReplicationSpec:
Результатом операции является объект TaskDrResponseList, который в нашем примере содержит список из одной задачи. Если хотите, вы можете указать массив объектов ConfigureReplicationSpec и реплицировать несколько ВМ одним вызовом.
Чтобы дождаться завершения задачи настройки репликации, получите задачу, пока ее свойство Status не будет равно чему-то отличному от "RUNNING":
Invoke-VrGetTaskInfo -TaskId $task.List[0].Id
В следующем разделе мы будем использовать командлеты из модуля VMware.Sdk.Srm для создания группы защиты и плана восстановления для только что созданной репликации.
3. Подключение к Site Recovery Manager с помощью Connect-SrmSdkServer
Для подключения к серверу Site Recovery Manager используйте командлет Connect-SrmSdkServer. Не используйте старый командлет Connect-SrmServer, уже доступный в модуле VMware.VimAutomation.Srm, так как он не совместим с командлетами модуля VMware.Sdk.Srm.
Site Recovery Manager поддерживает только одно соединение между локальными и удаленными сайтами SRM. Вы можете подключиться либо только к локальному сайту, либо вы можете аутентифицироваться на удаленном сайте сервера vCenter в том же вызове. Поскольку далее мы будем создавать группу защиты и план восстановления, мы выберем второй вариант. Обратите внимание, что у вас должна быть настроена пара сайтов между локальными и удаленными сайтами SRM.
Если мы посмотрим на объект SrmServerConnection, возвращенный командлетом Connect-SrmSdkServer, мы увидим, что он содержит свойство с именем ConnectedPairing. В этом случае это один объект Pairing, который представляет пару между локальным и удаленным сайтами SRM. Вам потребуется этот объект Pairing для вызова различных операций из API SRM:
4. Создание Protection Group и Recovery Plan для Host Based Replication
В этой главе мы будем использовать репликацию на основе хоста, которую мы настроили ранее. Сначала мы инициализируем HbrProtectionGroupSpec с уже реплицированной ВМ:
В этом примере мы повторно используем идентификатор ВМ, который мы сохранили в переменной $replicatedVm, поскольку он совместим между API VR и SRM. Если вам нужно получить реплицированную ВМ с помощью модуля VMware.Sdk.Srm, используйте командлет Invoke-SrmGetReplicatedVms:
Чтобы завершить этот пример, мы создадим Recovery Plan для Protection Group. Для этого сначала инициализируйте RecoveryPlanCreateSpec, требуемый командлетом Invoke-SrmCreatePlan:
После того, как вы закончили взаимодействовать с сервером SRM, закройте соединение, используя командлет Disconnect-SrmSdkServer:
Disconnect-SrmSdkServer "MySrmAddress.com"
Чтобы закрыть соединение с сервером VR, используйте командлет Disconnect-VrServer:
Disconnect-VrServer "MyVrAddress.com"
Вы можете объединить модули PowerCLI VMware.Sdk.Vr и VMware.Sdk.Srm для автоматизации всего сценария создания репликации на основе хоста и использования ее с группой защиты и планом восстановления. Если вы хотите автоматизировать репликацию на основе массива, доступную с модулем VMware.Sdk.Srm, обратитесь к статье "Array Based Replication with PowerCLI 13.1". Также вы можете ознакомиться со статьей "vSphere Replication REST API with PowerShell: Configure VM replication".
Таги: VMware, SRM, PowerCLI, Replication, Automation, DR
Давайте посмотрим, что нового появилось в этом обновлении:
1. Новые модули SDK для SRM и vSphere Replication
С релизом SRM и vSphere Replication 8.6 эти два продукта получили новые REST API. Фактически, это был первый публичный API, выпущенный для vSphere Replication. Это дало возможность автоматически создавать модули PowerCLI для этих продуктов, как это уже было ранее для NSX и vSphere. Как и в случае с vSphere, теперь можно найти примеры PowerCLI непосредственно в документации REST API vSphere Replication и SRM.
2. Улучшения vLCM
В PowerCLI 13.1 были добавлены новые параметры в командлет Set-VMHost, которые позволяют задавать конфигурацию LCM хоста ESXi таким же образом, как вы задаете конфигурацию LCM кластера. Это новая функция, поддерживаемая только в vSphere 8.0 Update 1. Также были представлены командлеты для создания новых офлайн-репозиториев LCM с помощью PowerCLI.
3. Новые командлеты для vSAN
PowerCLI 13.1 имеет большое количество новых функций для vSAN. Появились новые командлеты для управления удаленным хранилищем данных vSAN, прямого управлением дисками и выключения кластера vSAN.
4. Изменения в VMware Cloud Director
Для VMware Cloud Director был изменен механизм аутентификации Connect-CIServer, и теперь он аутентифицируется через новый эндопоинт аутентификации API vCD. Это позволит без проблем работать командлету с будущими версиями vCD. Также был обновлен командлет Import-CIVappTemplate для работы с последними версиями API. В связи с этим, были внесены некоторые изменения в интерфейс командлета, что может привести к необходимости переработки некоторых ваших скриптов Cloud Director.
5. Поддержка модуля ImageBuilder для Python
В PowerCLI 13.0 модули ImageBuilder и AutoDeploy были портированы для работы на платформах Linux и MacOS. Это требует от пользователей иметь предустановленный Python для работы этих модулей. В версии 13.0 они поддерживали только Python 3.7.x, теперь же поддерживаются все версии выше Python 3.7.1.
Загрузить обновленную версию VMware PowerCLI 13.0 можно по этой ссылке. Документация доступна тут.
На днях компания VMware выпустила первую версию плагина, предназначенного для исполнения типовых сценариев PowerCLI - Power Actions 1.0. Об этом средстве мы уже упоминали, когда в начале 2021 года компания VMware выпустила обновленную версию vSphere HTML5 Web Client.
Power Actions - это плагин клиента vSphere, который обеспечивает простой способ исполнения скриптов PowerCLI с пользователями, не имеющими опыта работы с PowerShell. Это средство также предоставляет библиотеку скриптов, куда вы можете загрузить готовые скрипты PowerCLI, которые вы хотите сделать доступными для всех сотрудников вашей организации. Пользователи могут легко выполнить эти скрипты, используя удобный пользовательский интерфейс для указания параметров скрипта. Это обеспечивает мощный механизм расширения клиента vSphere с помощью настраиваемых сценариев PowerCLI.
А что насчет безопасности и прав доступа? Все скрипты выполняются с использованием прав пользователя, который вошел в клиент vSphere. Таким образом, если у пользователя нет разрешения на выполнение определенных операций, он не сможет выполнить эти операции с помощью Power Actions.
1. Установка
Power Actions распространяется в виде виртуального модуля (Virtual Appliance). Вы можете загрузить файл OVA со страницы Power Actions на сайте VMware Labs. Там же вы можете загрузить полное руководство пользователя, которое содержит подробные инструкции по установке. После установки Power Actions вы можете использовать его через Developer Center в клиенте vSphere.
2. Библиотека сценариев
Основная функция Power Actions - запуск сценариев из вашей библиотеки сценариев. Поэтому первым делом нужно создать библиотеку сценариев и загрузить в нее ваши скрипты.
Библиотеки сценариев на самом деле являются библиотеками контента, так что любую библиотеку контента можно использовать как библиотеку сценариев. Если у вас нет библиотеки контента, вы можете создать новую с помощью PowerCLI или клиента vSphere. Следующим шагом будет импорт ваших сценариев в библиотеку сценариев. Вы можете загружать сценарии по одному через клиент vSphere или целые коллекции сценариев через PowerCLI.
3. Запуск скриптов
После того, как вы загрузили свои скрипты в библиотеку, вы можете начать запускать их. У вас есть два варианта запуска скрипта - непосредственно из библиотеки или через контекстное меню. В обоих случаях, когда вы выполняете скрипт с параметрами, вам будет предложено ввести их. Однако, когда вы запускаете скрипт из контекстного меню, некоторые параметры будут автоматически заполнены для удобства.
Давайте более подробно рассмотрим, как это работает. В нашей библиотеке скриптов Power Actions мы импортировали простой скрипт PowerCLI, который создает снапшоты коллекции виртуальных машин. Вот как выглядит этот скрипт:
Когда мы запустили сценарий из библиотеки, мы получим диалог, в котором нам нужно указать обязательные параметры:
Если мы хотим выполнить сценарий из контекстного меню, мы можем кликнуть правой кнопкой по виртуальной машине и выбрать "Power Actions" -> "Run script".
В итоге, мы получим диалог, где нужно выбрать скрипт для исполнения, и потом нам нужно будет ввести параметры. В этом случае в список параметров будут автоматически добавлены параметры ВМ, для которой мы вызвали контекстное меню:
4. Мониторинг исполнения сценариев и просмотр результатов
На следующем экране Power Actions мы увидим представление "Script run". Здесь мы можем отслеживать выполнение скриптов и просматривать результаты исполнения. Также на этой странице можно остановить выполнение сценария.
5. Консоль сценария
Еще одна полезная возможность Power Actions - это встроенная консоль PowerShell с последней предустановленной версией PowerCLI. Когда вы отроете консоль, она автоматически соединится с vCenter Server, используя текущий пользовательский аккаунт vSphere Client. Вы можете использовать эту консоль для выполнения отдельных команд или готовых командлетов. Имейте в виду, если вы переключитесь на другое представление vSphere Client или запустите еще один экземпляр Power Actions, а потом вернетесь в консоль, то ваша сессия будет создана снова, а все переменные из памяти прошлого сеанса будут потеряны.
Скачать виртуальный модуль Power Actions и документацию к нему можно по этой ссылке.
Осенью прошлого года VMware анонсировала первую версию фреймворка
PowervRLICloud, предназначенного для управления окружением VMware vRealize LogInsight Cloud (этот продукт сейчас называется Aria Operations for Logs). Это PowerShell модуль, который реализует абстракции VMware vRealize LogInsight Cloud API для простого доступа к возможностям функций управления этим решением посредством сценариев.
Многие администраторы сталкиваются с необходимостью обновления пакета 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. Здесь есть следующие нюансы:
Начиная с версии 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, то можно выполнить следующий сценарий:
Итак, рассмотрим обновление 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
Загружаем бандл на vSphere Lifecycle Manager (либо VIB-пакет может быть загружен этим продуктом автоматически)
Выполняем функцию Remediate для накатывания VMware Tools для ВМ на хостах ESXi
После успешного апдейта, локальный репозиторий VMware Tools также будет обновлен.
Несмотря на то, что хост не нужно перезагружать после обновления, он все равно должен быть помещен в режим обслуживания (maintenance mode). В противном случае, процесс обновления может выглядеть успешным, но в реальности изменений на хосте не произойдет.
Теперь посмотрим на процесс обновления VMware Tools методом Single Image:
В этом случае можно изменить только версию VMware Tools, а остальное можно оставить как есть.
Создаем общий репозиторий для нужной версии VMware Tools
Этот подход создает центральный репозиторий VMware Tools для нескольких хостов. В этом случае они не будут использовать локальный репозиторий, а на общем хранилище будет использоваться общая папка, которая станет новым репозиторием. Преимуществом данного подхода является обслуживание только одного экземпляра репозитория. Процесс создания этого репозитория описан в KB 2129825.
Как это выглядит по шагам:
1. Создаем на общем томе VMFS папку и устанавливаем для нее разрешения:
cd /vmfs/volumes/datastore
mkdir vmtools-repository-name
chmod 700 vmtools-repository-name
2. Если вы хотите использовать уже использованный репозиторий, то папку надо очистить:
3. Добавляем файлы, загруженные из Customer Connect и распакованные, в эту папку - у вас получится две подпапки, содержащие нужные файлы:
На скриншоте показан пример для VMware Tools под Windows. Если вы хотите использовать старые тулзы для Linux, то их нужно добавить в папку vmtools. Также посмотрите вот эту нашу статью о VMware Tools.
5. Если вы делаете процедуру впервые, то нужно настроить хосты ESXi для использования данной папки репозитория вместо используемой локальной папки по умолчанию. Для этого вам нужно добавить расширенную настройку UserVars.ProductLockerLocation (по умолчанию она указывает на /locker/packages/vmtoolsRepo/). Напомним, что /productLocker - это символьная ссылка, поэтому нужно использовать полный путь.
Так как мы обсуждаем массовое обновление тулзов, то имеет смысл показать здесь применение данного способа с использованием PowerCLI:
Для вывода текущей директории Locker выполняем следующий командлет:
Get-VMHost | Get-AdvancedSetting -Name "UserVars.ProductLockerLocation" | Select-Object Entity, Value
Для изменения директории выполняем такой командлет:
Будьте аккуратны при вызове второй команды, так как она меняет параметр на всех хостах, которые вы указали.
6. После этого вам нужно будет перезагрузить хост для обновления символьной ссылки /productLocker.
Шаг 2 - Автоматизация процесса обновления тулзов в гостевых ОС виртуальных машин
Теперь мы готовы автоматизировать апдейты VMware Tools в гостевой ОС. Так как мы говорим о массовом обновлении пакетов, то мы не будем обсуждать вариант с логином в гостевую ОС, монтирования ISO-образа и запуском exe-файла.
Сначала посмотрим, какие версии сейчас установлены в виртуальных машинах, с помощью PowerCLI. Запускаем следующую команду:
Это не самая удобная нотация, но она соответствует той, что мы видим на странице 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:
Уделите особое внимание тому факту, какие ВМ вы поместите в переменную $VMs. При таком подходе для обновления VMware Tools вы не сможете запланировать создание предварительных снапшотов ВМ.
Многие пользователи применяют сценарии PowerCLI (недавно, кстати, вышла 13-я версия этого пакета) для автоматизации виртуальной инфраструктуры VMware vSphere на базе фреймворка PowerShell.
При этом для скриптов часто встает вопрос безопасного хранения данных учетных записей (логин-пароль), чтобы не указывать их прямым текстом в исходниках сценариев. Компонент PowerCLI credential store использует хранилище учетных записей, которое, в свою очередь, использует Windows data protection API для шифрования данных учетных записей и хранения их в файле. Поэтому PowerCLI credential store доступен только в Windows и не является кроссплатформенным. А что насчет пользователей Linux и MacOS?
Некоторое время назад Microsoft выпустила два полезных кроссплатформенных модуля SecretManagement и SecretStore (подробнее об этом тут). SecretManagement предоставляет командлеты, которые позволяют пользователям управлять паролями в различных хранилищах, а SecretStore - это, собственно, само хранилище и есть. Эти два модуля можно использовать вместо стандартного хранилища VICredential. Чтобы проиллюстрировать, как работать с ними, в VMware сделали пример модуля с разными версиями командлетов VICredential.
Первый шаг - это регистрация и конфигурация защищенного хранилища. В примере использования модуля, упомянутом выше, можно использовать Initialize-VISecret, который реализует эту процедуру - регистрирует SecretStore как хранилище по умолчанию и настраивает окружение так, чтобы пароль не запрашивался при доступе к хранилищу.
function Initialize-VISecret {
[CmdletBinding()]
param(
[string]$Vault = "VMwareSecretStore"
)
Этот режим по пользовательскому опыту близок к VICredentialStore, так как пароли хранятся в зашифрованном виде, но сам пароль при доступе к нему не запрашивается. В примере используется SecretStore по умолчанию, но можно изменить хранилище на любое по вашему выбору, а именно:
Чтобы сохранить креды в хранилище, нужно использовать командлет Set-Secret модуля SecretManagement. Сами креды в этом командлете идентифицируются по имени, но в примере ниже креды описываются двумя идентификаторами - имя пользователя и сервер, к которому нужно получить доступ. Такими образом, командлет New-VISecret склеивает строки "VISecret", сервер и имя пользователя в один идентификатор, который и используется для получения пароля.
Если вы хотите сохранить креды более чем для одного продукта, вы можете изменить функцию так, чтобы заменить VISecret на другую специфичную для продукта строку, чтобы создать идентификатор, например, "VMCSecret" для VMware Cloud. Можно передавать пароль простым текстом или в виде защищенной строки.
Также вы можете удалить креды из хранилища, используя командлет Remove-VISecret, который создает идентификатор и вызывает функцию Remove-Secret для удаления кредов. Если вы используете SecretStore в качестве хранилища, вы можете очистить его полностью с помощью функции Reset-SecretStore.
Создание нового идентификатора выглядит так:
function New-VISecret {
[CmdletBinding()]
[Alias("Set-VISecret")]
param (
[Parameter(Mandatory=$true)]
[string]$Server,
[Parameter(Mandatory=$true)]
[string]$User,
[string]$Password,
[securestring]$SecureStringPassword,
[string]$Vault
)
begin {
if ([string]::IsNullOrWhiteSpace($password) -and (-not $secureStringPassword)) {
Throw "Either Password or SecureStringPassword parameter needs to be specified"
}
if (-not [string]::IsNullOrWhiteSpace($password) -and $secureStringPassword) {
Throw "Password and SecureStringPassword parameters cannot be both specified at the same time"
}
}
process {
$params = @{
"Name" = "VISecret|"+$server+"|"+$User
}
if ($password) {
$params += @{"Secret" = $password}
} elseif ($secureStringPassword) {
$params += @{"SecureStringSecret" = $secureStringPassword}
} elseif ($Vault) {
$params += @{"Vault" = $Vault}
}
Set-Secret @params
}
}
Последний командлет в примере - это Connect-VIServerWithSecret. Он сочетает в себе оба командлета, приведенных выше, что дает интегрированный инструмент для работы по аналогии с командлетом Connect-VIServer для VICredentialStore. Вы можете вызвать Connect-VIServerWithSecret с логином и паролем, но использовать параметр -SaveCredentials для сохранения кредов в хранилище.
После этого вы можете опускать параметры учетной записи, а Connect-VIServerWithSecret будет автоматически получать пароль из хранилища и соединяться с сервером vCenter. При использовании VICredentialStore, если у вас сохранены креды только к одному серверу, вы можете соединяться с ним через Connect-VIServer без указания имени пользователя. А для использования функции Get-Secret параметр -Username является обязательным, так как не проверяется, что в хранилище сохранена только одна учетная запись. Чтобы упростить жизнь в этом случае есть глобальная переменная $global:defaultUser, значение которой и будет использоваться в Connect-VIServerWithSecret.
Недавно мы писали о выходе новой версии фреймворка для автоматизации операций в виртуальной инфраструктуре средствами сценариев VMware PowerCLI 13. Одной из его частей является модуль Horizon PowerCLI module, с помощью которого можно управлять различными аспектами VDI-инфраструктуры. Сегодня мы посмотрим, как это делается.
Модуль PowerCLI для Horizon служит прослойкой для управления конфигурациями виртуальной инфраструктуры десктопов посредством View API, который можно также использовать и путем прямого доступа. Помимо этого, в рамках инструментария по управлению VDI-cредой есть и набор дополнительных функций, доступных в репозитории на GitHub.
В дополнение к View API, инфраструктура Horizon также предоставляет и RESTful API, который называется VMware Horizon Server API. Он предназначен для взаимодействия с Connection Server (подробнее об этом можно прочитать тут).
Итого, мы имеем три основных набора инструментов:
Для начала работы с Horizon через PowerCLI вам нужно выполнить следующие действия:
Устанавливаем VMware PowerCLI
Загружаем и устанавливаем advanced functions
Обращаемся к документации
1. Установка VMware PowerCLI
Основные инструкции по установке находятся здесь. Для начала установки просто открываем Windows PowerShell Admin console и выбиваем команду:
Install-Module VMware.PowerCLI
Далее разрешаем локальное исполнение сценариев командой:
Set-ExecutionPolicy RemoteSigned
2. Установка Advanced Functions
Идем по этой ссылке в репозиторий на GitHub и загружаем пакет по кнопке Download ZIP:
Распаковываем zip-файл и копируем подпапку Hv.Helper в папке modules в одну из директорий модулей на вашем компьютере. Чтобы узнать нужный путь, нужно проверить переменную окружения $env:PSModulePath. Она может быть одной из следующих:
User specific: %UserProfile%\Documents\WindowsPowerShell\Modules
System wide: C:\Program Files\WindowsPowerShell\Modules
Разблокируем расширенные функции, чтобы их можно было исполнять. В командной строке PowerShell под администратором выполняем следующий набор команд:
dir ‘C:\Program
Files\WindowsPowerShell\Modules\VMware.HvHelper\’ |
Unblock-File
После этого будет создана глобальная переменная DefaultHVServers, которая содержит информацию о подключениях к серверам Horizon Connection Servers. Обратиться к ней можно через $Global:DefaultHVServers.
Самое интересное содержится в свойстве ExtensionData. Давайте назначим его переменной $Services и рассмотрим поближе:
Если вы посмотрите документацию к View API, то сможете понять назначение этих записей. Свойство ExtensionData содержит информацию о доступе к любым функциям View API.
Давайте рассмотрим несколько примеров. Сначала используем простую команду для получения всех серверов Horizon Connection Servers в рамках пода (pod). Команда View API ниже использует сервис ConnectionServer и метод ConnectionServer_List для назначения результатов переменной $hvServers1.
Теперь используем одну из расширенных функций для вывода списка всех виртуальных десктопов, в зависимости от состояния агента Horizon Agent в них. Это полезно, чтобы понять, в нормальном ли состоянии там находятся агенты, или они пришли в некорректное состояние ошибки.
Итак, выводим список десктопов, где юзер залогинен, но в текущей сессии он не присоединен:
Затем вы можете написать свой сценарий, который выводит десктопы, где Horizon Agent находится в одном из перечисленных некорректных состояний. Далее можно предпринять шаги по исправлению ситуации - например, перезагрузить машины, чтобы в некоторых из них ошибка исправилась (к примеру, для статуса AGENT_ERR_NEED_REBOOT).
Сценарий ниже позволяет как раз это и сделать. Вам нужно поменять параметры, специфические для вашей среды, такие как имя Connection Server, пользователь, пароль и другое. Если вы не хотите использовать пароль в открытом виде, то можете убрать его из команд Connect-HVServer и Connect-VIServer - тогда он будет запрошен в интерактивном режиме.
Также обратите внимание на параметр -WhatIf в команде Restart-VMGuest - он позволяет вам получить возможный результат исполнения команды без необходимости ее фактического исполнения.
####################################################################
# Get List of Desktops that have Horizon Agent in problem states.
# Reboot the OS of each of these.
####################################################################
#region variables
###################################################################
# Variables
###################################################################
$cs = 's1-hcs1.mydomain.com' #Horizon Connection Server
$csUser = 'administrator' #Connection Server user
$csPassword = 'mypassword' #Connection Server user password
$csDomain = 'mydomain' #Connection Server domain
$vc = 'vcenter1.mydomain.com' #vCenter Server
$vcUser = 'administrator@vsphere.local' #vCenter Server user
$vcPassword = 'mypassword' #vCenter Server password
$baseStates = @('PROVISIONING_ERROR',
'ERROR',
'AGENT_UNREACHABLE',
'AGENT_ERR_STARTUP_IN_PROGRESS',
'AGENT_ERR_DISABLED',
'AGENT_ERR_INVALID_IP',
'AGENT_ERR_NEED_REBOOT',
'AGENT_ERR_PROTOCOL_FAILURE',
'AGENT_ERR_DOMAIN_FAILURE',
'AGENT_CONFIG_ERROR',
'UNKNOWN')
#endregion variables
#region initialize
###################################################################
# Initialize
###################################################################
# --- Import the PowerCLI Modules required ---
Import-Module VMware.VimAutomation.HorizonView
Import-Module VMware.VimAutomation.Core
Set-PowerCLIConfiguration -InvalidCertificateAction Prompt
# --- Connect to Horizon Connection Server API Service ---
$hvServer = Connect-HVServer -Server $cs -User $csUser -Password $csPassword -Domain $csDomain
# --- Get Services for interacting with the View API Service ---
$services= $hvServer.ExtensionData
# --- Connect to the vCenter Server ---
Connect-VIServer -Server $vc -User $vcUser -Password $vcPassword
#endregion initialize
#region main
###################################################################
# Main
###################################################################
Write-Output ""
if ($services) {
foreach ($baseState in $baseStates) {
# --- Get a list of VMs in this state ---
Write-Host ("Get VMs with baseState: " + $baseState) -ForegroundColor Yellow
$ProblemVMs = Get-HVMachineSummary -State $baseState
foreach ($ProblemVM in $ProblemVMs) {
$VM = Get-VM -Name $ProblemVM.Base.Name
# --- Reboot each of the Problem VMs ---
Restart-VMGuest -VM $VM
# Add -WhatIf to see what would happen without actually carrying out the action.
}
}
Write-Output "", "Disconnect from Connection Server."
Disconnect-HVServer -Server $cs
} else {
Write-Output "", "Failed to login into Connection Server."
pause
}
# --- Disconnect from the vCenter Server ---
Write-Output "", "Disconnect from vCenter Server."
Disconnect-VIServer -Server $vc
#endregion main
Некоторое время назад мы писали о том, что линейка продуктов VMware vRealize превратилась в VMware Aria, а решение vRealize Log Insight стало носить название Aria Operations for Logs. Напомним, что этот продукт представляет собой платформу для аналитики лог-файлов, мониторинга и решения проблем инфраструктуры в облаке.
Сегодня мы поговорим о том, как использовать API-вызовы в сценариях PowerCLI для выполнения операций в Aria Operations for Logs.
Итак, сначала вам нужно получить API-токен с портала Cloud Services Portal (CSP). Заходим в настройки аккаунта в раздел API Tokens и генерируем новый:
При создании токена нужно задать его имя, время жизни и к каким компонентам облачной инфраструктуры будут иметь доступ операции с использованием этого токена. Выбираем компонент vRealize Log Insight Cloud Admin и нажимаем Generate внизу экрана:
После этого появится всплывающее окно, где можно скопировать новый токен - его следует сохранить в безопасное место.
Теперь можно использовать сценарии PowervRLI. Сначала нужно установить командлеты из Powershell Gallery с помощью следующей команды (это можно также сделать и в офлайн режиме с помощью инструкций, доступных на GitHub):
После этого вам нужно ввести API-ключ токена, полученный из CSP, после выполнения команды Connect-vRLI-Cloud. Далее произойдет соединение с облачным инстансом Aria Logs:
Вы можете выполнить команду Get-AlertDefinitions для получения списка алертов Aria Logs, чтобы команда аудита имела возможность понимать, какие события могут происходить. Вывод можно экспортировать в файл, чтобы он был доступен членам команды.
Теперь выполним запрос через API, чтобы получить некоторые события из окружения Aira Logs. Запросы нужно писать в формате SQL, которые указываются в качестве переменной:
После этого будет сгенерирован вывод команды, который можно послать для ревью и анализа:
На этой неделе компания VMware выпустила обновление своего фрейморка для управления виртуальной инфраструктурой PowerCLI 13. Напомним, что о версии PowerCLI 12.7 мы писали в июле этого года вот тут.
Давайте посмотрим, что нового появилось в VMware PowerCLI 13:
1. Первая полностью кросс-платформенная версия
В тринадцатой версии PowerCLI был завершен переход к полной кросс-платформенности, который начался еще в 2018 году, когда Microsoft выпустила первую мультиплатформенную версию PowerShell. С тех времен множество модулей было портировано на другие платформы, и сейчас удалось достичь полного соответствия доступных командлетов на всех платформах.
Завершился этот процесс портированием последних двух модулей ImageBuilder и AutoDeploy, которые ранее были доступны только для Windows.
Так как Python требуется для ImageBuilder, команда PowerCLI решила его больше не включать в состав пакета, но теперь Python версии 3.7 является обязательным требованием для использования именно модуля ImageBuilder. Также вам потребуется установить и несколько дополнительных пакетов для Python (six, psutil, lxml, pyopenssl). В PowerCLI User’s Guide теперь есть инструкции о том, как установить все эти компоненты на поддерживаемых платформах.
Кроме того, в PowerCLI теперь есть настройка, которая указывает путь к инсталляции Python. Вы можете использовать следующую команду:
Set-PowerCLIConfiguration -PytonPath "<path to the Python installation>"
2. Обновление модуля VMware Cloud Director
Теперь в плане поддержки vCD в PowerCLI 13 было сделано несколько улучшений. Во-первых, появилась поддержка vCD 10.4, а также поддержка API-функций vCD 10.4 (API версии 37.0). Во-вторых, в некоторые командлеты были добавлены новые параметры и наборы параметров. Например, в командлете New-CIVM появился набор параметров, который позволяет создать пустую виртуальную машину, а также командлет New-OrgVdc с параметром -StorageProfile.
Также командлет Get-NetworkPool был расширен - теперь можно получать пулы для инсталляций NSX-T. Ну и некоторые API изменились - теперь вместо командлета Get/New/Set/Remove-OrgNetwork актуален командлет Get/New/Set/Remove-OrgVdcNetwork, который был добавлен уже достаточно давно.
3. Поддержка архитектуры VMware vSAN Express Storage Architecture (ESA)
Напомним, что в новой версии VMware vSAN 8 появилась новая архитектура Express Storage Architecture (ESA). Теперь было добавлено несколько новых командлетов (Get-VsanEsaEligibleDisk и Add/Get/Remove-VsanStoragePoolDisk), а также расширены некоторые уже существующие (New/Set-Cluster and Get-VsanClusterConfiguration), чтобы обеспечить поддержку vSAN ESA.
4. Обновления модуля NSX
Чтобы обеспечить пользователей информацией об использовании нового модуля NSX SDK в руководство owerCLI user’s guide была добавлена отдельная глава. Также в PowerCLI 13 был убран старый способ доступа к NSX API через командлеты Get-NsxtPolicyService, Get-NsxtGlobalManagerService и Get-VmcSddcNetworkService.
5. Улучшения поддержки HCX
В PowerCLI 13 появилось несколько новых возможностей в плане поддержки решения VMware HCX. Теперь модуль HCX позволяет включить seed checkpoint, а также смигрировать кастомные атрибуты виртуальных машин.
При апгрейде с прошлых версий на PowerCLI 13 через Update-Module вы можете столкнуться с ошибкой (подробнее тут). Это потому, что сертификаты для подписки модулей были изменены - они подписаны другим издателем. Чтобы обойти проблему, просто удалите старый модуль и переустановите его с помощью командлета Install-Module.
Скачать VMware PowerCLI 13 можно по этой ссылке (а Release Notes находятся здесь). Установка модуля происходит командой:
Как вы знаете, на прошедшей конференции Explore 2022 компания VMware анонсировала новые версии платформы виртуализации vSphere 8 и решения для создания отказоустойчивых хранилищ vSAN 8. Недавно эти решения стали доступны для скачивания как Initial Availability (IA), поэтому сейчас самое время развертывать их в своих тестовых окружениях для проверки перед большим апгрейдом.
Начать можно с виртуальной тестовой лаборатории, то есть инсталляции в рамках одного сервера или рабочей станции, где сервисы ESXi, vCenter и vSAN поднимаются в виртуальных машинах.
Для этой цели известный блоггер и инженер VMware Вильям Ламм создал на PowerCLI специальный сценарий Automated vSphere & vSAN 8 Lab Deployment, который автоматизирует развертывание компонентов виртуальной лаборатории на базе vSphere и vSAN восьмой версии.
Как видно на картинке, скрипт предназначен, чтобы развернуть три виртуальных сервера ESXi, создать на их базе кластер vSAN, а также развернуть виртуальный модуль управления vCenter Server Appliance (vCSA).
Итак для этого вам понадобятся:
Действующий vCenter Server не ниже седьмой версии
Компьютер Windows, Mac или Linux с установленным PowerShell Core и фреймворком PowerCLI 12.1 Core
Перед исполнением сценария вам нужно заполнить все его параметры, относящиеся к вашей текущей инфраструктуре и к создаваемой тестовой лаборатории, а также распаковать содержимое ISO-образа виртуального сервера vCSA.
Пример исполнения сценария показан ниже:
В итоге процесс будет выполняться пошагово до его завершения с информацией о каждом шаге:
Ну и после всего этого в vSphere Client вы увидите вашу созданную виртуальную тестовую лабораторию с тремя хостами ESXi и сервером управления vCenter / vCSA:
Скачать сценарий Automated vSphere & vSAN 8 Lab Deployment можно по этой ссылке, там же есть более подробная информация о том, как его использовать.
На днях компания VMware объявила о выпуске обновленной версии своего фреймворка для управления виртуальной инфраструктурой с помощью скриптов - PowerCLI 12.7. Напомним, что о прошлой версии PowerCLI 12.6 мы рассказывали вот тут.
Итак, давайте посмотрим на новые возможности PowerCLI 12.7:
1. Мультиплатформенный модуль VUM
Теперь модуль, предназначенный для обновлений компонентов виртуальной инфраструктуры, работает на платформах Linux и macOS, что очень давно просили пользователи. До этого момента оставалось только 2 модуля, которые не были портированы на эти ОС, теперь же PowerCLI стал полностью мультиплатформенным фреймворком (кстати, 40% всех его пользователей работают на Linux и macOS).
2. Улучшения модуля NSX
В PowerCLI 12.6 появился новый модуль NSX SDK, в этом же релизе для него появились функции поддержки последнего NSX API, включая удаленную аутентификацию в командлете Connect-NsxServer с использованием параметра -UseRemoteAuthentication. Также был улучшен механизм использования командлета Get-NsxOperation.
3. Новые параметры конфигурации кластера vSAN
Теперь для кластера vSAN можно установить пороговые значения для механизма health check, используя параметр -CapacityThreshold для командлетов Set-VsanClusterConfiguration и New-VsanHealthCheckThreshold. Например, так:
Также можно отключить/включить исторические данные vSAN health check, а также смонтировать/размонтировать датастор с другого кластера как удаленный датастор с помощью командлета Set-VsanClusterConfiguration.
Кроме перечисленного, в PowerCLI 12.7 появилось много небольших улучшений, таких как, например, увеличение производительности при работе с решениями SRM и HCX. Более подробный список улучшений приведен в Release Notes. Документация по работе с командлетами VMware PowerCLI 12.7 находится тут.
В апреле компания VMware выпустила обновление своего основного фреймворка для управления виртуальной инфраструктурой и ее компонентами из командной строки PowerCLI 12.6. О прошлой версии PowerCLI 12.5 мы писали в январе вот тут, а сегодня расскажем, что появилось нового в весеннем обновлении.
Основные улучшения и нововведения:
1. Байндинги PowerShell для интерфейсов NSX Policy Manager API.
Теперь появился новый модуль VMware.Sdk.Nsx.Policy, который реализует байндинг PowerShell для программных интерфейсов NSX Policy Manager API.
2. Новые командлеты для управления виртуальным модулем vCenter Server Appliance.
Теперь для управления резервными копиями vCenter Server Appliance можно использовать следующие командлеты:
New-ApplianceBackupJob - стартует задачу резервного копирования на уровне файлов vCenter Server на бэкап-сервер.
Wait-ApplianceBackupJob - мониторит прогресс задачи резервного копирования и возвращает в ApplianceBackupJob.
Get-ApplianceBackupJob - получает список завершенных или находящихся в исполнении задач резервного копирования.
Get-ApplianceBackupPart - получает список частей (parts), которые могут быть включены в задачу РК, а также их размер в резервной копии. Обязательные части всегда включаются в бэкап.
3. Поддержка SRM 8.5.
Модуль VMware.VimAutomation.Srm был обновлен и теперь поддерживает решение VMware Site Recovery Manager 8.5.
4. Исправления ошибок.
VMware приводит таблицу с багофиксами:
Product /Category
Cmdlet Name
Description
Status
HCX
New-HCXMigration
VM with multiple networks attached and if migration is triggered without mapping all the source networks to the target, the validation does not throw an error
Fixed
HCX
New-HCXMigration
Initiating a Non-Mobility migration using New-HCXMigration cmdlet does not show the network mapping in the migration dashboard UI
Fixed
vSAN
Get-VsanView
Get-VsanView throws ‘Object reference not set to an instance of an object.’ on PowerShell 7.2.2.
Fixed
HCX
Get-HCXVM
Get-HCXVM cmdlet throws “Unexpected character encountered while parsing value: <. Path ”, line 0, position 0..” when the number of VMs available in the inventory is very big
Fixed
HCX
Get-HCXMigration
Get-HCXMigration cmdlet throws an error if any of the migrations were triggered without providing the ‘TargetStorageProfile’ param
Fixed
Загрузить компоненты фреймворка VMware PowerCLI 12.6 можно по этой ссылке. Release notes доступны тут.
Все необходимые функции для работы с API по управлению сертификатами были добавлены в PowerCLI версии 12.4 в конце прошлого года, и теперь можно полноценно управлять ими с помощью сценариев.
Вот какие командлеты используются в VMware vSphere 7 (некоторые из них доступны и в более ранних версиях платформы) для получения информации о сертификатах, их добавления и удаления:
Для работы с Trusted Certificate Store
можно использовать командлет Get-VITrustedCertificate, который проверяет корневые сертификаты на сервере vCenter Server и/или на присоединенных хостах ESXi (параметры issuer, expiration date, serial number и другие). Вот пример, как проверить хранилища сертификатов на серверах на предмет устаревших сертификатов:
#Check the trusted certificate store of the vCenter and all connected ESXi servers for expired certificates
Get-VITrustedCertificate | Where-Object { $_.NotValidAfter -lt (Get-Date) }
Если мы хотим добавить сертификат или цепочку сертификатов в центр сертификации (certificate authority), который мы используем для хранилища сертификатов, можно использовать командлет Add-VITrustedCertificate:
#Read the certificate or certificate chain from a .pem file
$trustedCertChain = Get-Content "C:\Users\jdoe\Downloads\ca-chain.cert.pem" -Raw
#Add it to the trusted certificate stores of the vCenter and the ESXi servers
Add-VITrustedCertificate -PemCertificateOrChain $trustedCertChain
Также есть командлет Remove-VITrustedCertificate для удаления доверенных сертификатов, которые нам больше не нужны (используйте ее очень осторожно, ведь можно случайно удалить используемый сертификат). В интерфейсе этой функции нет, чтобы администратор случайно не удалил нужные сертификаты из цепочек. Вот как это работает:
2. Управление SSL-сертификатами компьютеров на сервере vCenter Server
Если у нас есть несколько компьютеров, с которых администраторы получают доступ к vSphere Client, и мы хотим, чтобы сертификаты принимались по умолчанию, мы должны заменить сертификаты на сгенерированные доверенным центром сертификации (trusted certificate authority).
Сначала с помощью этого командлета проверяем текущий сертификат машины vCenter:
Get-VIMachineCertificate -VCenterOnly
После этого создаем запрос на подписку сертификата (certificate signing request, CSR) для vCenter Server. Можно использовать командлет VIMachineCertificateSigningRequest:
После того, как мы получим файл сертификата от центра сертификации, мы можем заменить сертификат машины vCenter с помощью командлета Set-VIMachineCertificate:
Перед установкой SSL-сертификата машины мы должны убедиться, что корневой сертификат нашего CA добавлен в хранилище сертификатов vCenter Server. Помните, что замена сертификата вызовет перезагрузку vCenter.
3. Управление SSL-сертификатами машин для серверов ESXi
Если мы хотим управлять сертификатами полностью самостоятельно, нужно также заменить и сертификаты хостов ESXi. Рабочий процесс в этом случае выглядит несколько сложнее. Сначала нужно изменить настройку режима управления сертификатами хостов ESXi на custom на сервере vCenter и перезагрузить его.
После этого нужно сгенерировать CSR-запрос для сервера ESXi. Шаг похож на оный для vCenter Server, только нужно будет указать параметр CommonName. Это должно быть FQDN-имя хоста или его IP-адрес. Убедитесь, что CommonName совпадает с идентификатором, по которому вы добавляли этот хост в vCenter.
Так же, как и для vCenter, перед установкой сертификата машины нужно убедиться, что корневой сертификат нашего центра сертификации добавлен в доверенное хранилище сертификатов на хосте ESXi и других серверах, с которыми он взаимодействует, то есть остальные хосты ESXi и vCenter.
$vmhost = Add-VMHost -Name <ESXi host's FQDN> or <ESXi host's IP address> `
-Location (Get-Datacenter "My Datacenter")`
-User "My User" `
-Password "My Password"
Компания VMware объявила о первом релизе PowerCLI в этом году - на днях стала доступна для загрузки версия PowerCLI 12.5. Напомним, что о прошлой версии этого фреймворка для управления виртуальной инфраструктурой с помощью сценариев мы писали вот тут.
Давайте посмотрим, что там появилось нового:
1. Функции vCenter Server Appliance Service Management
Теперь PowerCLI поддерживает обращение к онпремизной инфраструктуре AWS, которая называется Outpost (стала доступной в конце прошлого года). Для этого есть командлет Get-VmcOutpost, который позволяет получить список доступных аутпостов для организации в VMC. Также при создании SDDC с помощью командлета New-VmcSddc есть параметр -Outpost, который позволяет создать объект в рамках аутпоста.
3. Поддержка Hot add / Remove для процессоров и памяти
Теперь есть новые параметры, в командлетах создания и настройки ВМ (Set-VM и New-VM), которые позволяют включить функции горячего добавления памяти и процессоров, а также удаления процессоров. Вот эти параметры:
-CpuHotAddEnabled (включить CPU Hot Add)
-CpuHotRemoveEnabled (включить CPU Hot Remove)
-MemoryHotAddEnabled (включить Memory Hot Add)
4. Включение шифрованной миграции vMotion
Теперь для командлетов создания и настройки ВМ (Set-VM и New-VM) есть параметр -MigrationEncryption, который позволяет включить шифрованную миграцию.
5. Обновления для Horizon 8.4
Модуль Horizon был обновлен и теперь включает в себя байндинги для Horizon 8.4 API.
Больше информации о новом релизе вы можете узнать вот тут. Скачать VMware PowerCLI 12.5 можно по этой ссылке.
Компания VMware выпустила обновление главного фреймворка для управления виртуальной инфраструктурой с помощью командных сценариев - PowerCLI 12.4. Напомним, что в прошлый раз об обновлении этой платформы мы писали вот тут. В обновленной версии PowerCLI появилось несколько новых возможностей:
1. Новый API интерфейс - RestAPI
Раньше PowerCLI имел 2 основных пути коммуникации с vSphere API:
Get-View (SOAP API bindings)
Get-CISService (JSON-RPC)
Теперь новые PowerCLI API байндинги позволяют работать vSphere REST API и предоставляют практически нативный интерфейс PowerShell.
Модуль, реализующий эти функции, называется vSphere Automation API SDK. Чтобы начать использовать новые возможности через автоматизацию REST API, нужно скачать новую версию PowerCLI - пакет будет называться "VMware.Sdk.vSphere". Он содержит в себе субмодули для взаимодействия со всеми REST API, которые есть в VMware vSphere.
В REST API есть методы для исполнения API и работы со структурами данных, которые используются как входные параметры для API. Новые API байндинги предоставляют низкоуровневые PowerShell функции для работы со всеми этими методами и структурами.
Функция Invoke используется для исполнения методов REST, таких как GET/PUT/POST и DELETE:
Функция Initialize используется для создания структуры данных, которая будет передана к REST API. Например, так выглядит создание структуры "локальный аккаунт":
Раздел документации vSphere API Documentation был существенно обновлен - туда были добавлены примеры, показывающие вызов REST API через PowerCLI. Например, вот раздел Create Local Accounts.
2. Новый vSphere Management Module
Для управления платформой vSphere теперь появился новый модуль. Это модуль на базе PowerShell, для построения которого используется архитектура модулей vSphere Automation API SDK, о которой рассказано выше. На данный момент в модуле 6 командлетов, позволяющих управлять сертификатами (по ссылкам вы можете почитать о них):
Недавно мы писали о новой версии решения для виртуализации и доставки настольных ПК и приложений VMware Horizon версии 2106. Помимо новых фич, в обновленной платформе появилось много приятных небольших нововведений, одно из них - это возможность вывести список всех событий VMware Horizon прямо в интерфейсе клиента:
Такого рода вещи стали возможны благодаря интерфейсам Audit Events API. Теперь для получения событий пользователям не нужно идти в базу данных с помощью SQL-запросов, а можно просто получать события через API.
Вильям Лам с помощью PowerCLI-сценария обработал файл с определениями событий C:\Program Files\VMware\VMware View\Server\LDAP\ldif\VDIEventStrings_en.ldf на сервере Connection Server и выяснил, что всего в Horizon есть на данный момент 858 типов событий. Эти события он вынес в отдельную табличку:
Также хотим напомнить вам об утилите VMware Horizon Event Notifier, которая соединяется с одной или несколькими базами данных Horizon View Event Database, вытаскивает оттуда выбранные администратором события (ошибки, предупреждения, инфо) и шлет письма на указанный email-адрес. При этом поддерживается возможность работы с несколькими БД, что позволяет собирать алерты с разных инсталляций VMware View (они же View Pods).
На сайте проекта VMware Labs обновился основной клиент VMware vSphere на базе технологии HTML5 (он же vSphere Client в составе платформы VMware). Напомним, что старый клиент Web Client на базе Adobe Flex ушел в прошлое, и VMware предлагает использовать только новый клиент для управления виртуальной инфраструктурой.
Кстати, VMware vSphere HTML5 Web Client версии 5.0 (build 15670023) - это первое обновление клиента за довольно долгое время. Давайте посмотрим, что там появилось нового:
Обновлена документация (в том числе инструкции, где находятся файлы и сервисы клиента)
Добавлен новый язык для функции Code Capture - теперь записанные во время сессии действия могут транслироваться в код на языке Go.
PowerActions - это новый механизм интеграции PowerCLI и vSphere Client. Теперь в клиенте есть функциональность по запуску отдельных команд и сценариев PowerCLI, а также функции их хранения в библиотеке скриптов. Исполнение кастомных действий скриптов можно привязать к объектам из inventory в клиенте.
Функцию PowerActions надо включать отдельно при развертывании клиента (см. документ PowerActions_documentation_Fling50.pdf).
Базовая операционная система виртуального модуля vSphere Client была заменена на Photon OS, поэтому апгрейд с прошлой версии не поддерживается - придется развертывать все по-новой.
Загрузить новую версию клиента VMware vSphere HTML5 Web Client 5.0 можно по этой ссылке. Инструкции по установке и использованию доступны тут. Также много всего интересного есть в комбо-боксе выбора компонентов загрузки:
У компании VMware есть полезная бесплатная электронная книга
PowerCLI Cookbook for VMware vSAN, посвященная управлению инфраструктурой отказоустойчивых хранилищ с помощью сценариев, которая будет полезна всем администраторам хранилищ виртуальных сред vSphere / vSAN.
В книге на 127 страницах подробно рассказывается о командлетах для управления всеми аспектами хранилищ с помощью PowerCLI. В документе 3 основных блока:
Configuration Recipes - разбор примеров использования сценариев для настройки самого окружения vSAN, а именно:
Настройка vSAN в новом или существующем кластере
Добавление хостов
Настройка сетевого окружения
Выделение дисков под хранилища
Настройка HA и DRS
Настройка дедупликации и компрессии
Настройка шифрования
Конфигурация vSAN Performance Service
Operational Recipes - это практические примеры сценариев для ежедневного использования и подробный разбор их параметров, а также описание процедур, которые нужно регулярно выполнять в кластере.
Reporting Recipes - это набор рецептов для вывода информации о конфигурациях, метриках и состояниях, а также представления данных в удобном виде.
RSS
