Развертывание виртуальной машины vSphere через PowerSHell часть 1

Стал задаваться вопросом – как автоматизировать выполнение рутинных операций в vSphere?

Лучше бы не задавался 🙂

Начал с задачи “развернуть виртуальную машину из шаблона с указанной кастомизацией гостевой операционной системы”.

Основные проблемы, с которыми я столкнулся:

  • мною использовалась настройка кастомизации ОС “Prompt User”, спрашивающая только IP-адрес (подразумевается, что развертывание происходит в одно и то же адресное пространство). Как оказалось, проще использовать передачу “всех” параметров IP в скрипте;
  • перемещение учетной записи сервера после ее развертывания для применения групповых политик в другой контейнер Active Directory;
  • поле “Notes” получает строку. Как передать ей несколько строк, если потребуется перевод строки, я пока не разбирался;
  • за кадром остались процессы дальнейшей настройки сервера – установка обновлений и дополнительного ПО. Это будет рассмотрено в следующих частях статьи.

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

А вот что получил:

Данный скрипт берет гостевую кастомизацию “windows” (Guest Customization OS) и создает на ее основе временную кастомизацию “temp1”.

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

Далее мы создаем виртуальную машину из шаблона “windows_template”, используя подготовленную кастомизацию “temp1”. Машина создается в кластере “Cluster_name” с примечанием о том, для чего нужна эта ВМ. Диски шаблона при этом клонируются на кластер хранилищ (Datastore Cluster) с названием “Datastore_Cluster”.

Затем мы включаем виртуальную машину и ждем.

Ждем мы до тех пор, пока в AD не появится учетная запись компьютера. А эта запись должна появиться там потому, что в гостевой кастомизации настроено автодобавление ПК в домен.

Как только мы этого дождались, мы перекладываем эту учетную запись ПК в соответствующую OU.

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

Затем ждем 10 секунд пока VMware Tools 100% остановятся в ходе перезагрузки, ждем пока они будут запущены и выводим на экран сообщение о том, что сервер готов.

VMware PSC replication

Компонент Single Sign On, выполняющий проверку подлинности, появился в VMware vSphere 5.1. К vSphere 5.5 он стал “адекватнее” и стабильнее.

Его можно было поставить как на отдельный сервер, так и совместить вместе с vCenter Server.

В vSphere 6 этот компонент был объединен с другими сервисами в роли Platform Service Controller.

С тех пор и до vSphere 6.7 (или 6.7 Update 1) рекомендуемой схемой высокодоступного размещения PSC была следующая:

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

Наверное, особенно круто было заниматься обновлением этого зоопарка из 4+ систем.

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

Попутно узнал, что рекомендуемая топология – c центральным PSC.

Еще несколько KB:

А теперь к хорошим новостям: забудьте все, что только что прочитали 🙂

Начиная с vCenter 6.7 рекомендуемой топологией является встроенный PSC для любой топологии. Вы даже можете сделать vCenter HA (vCenter High Availability) для встроенного PSC, если хотите его защитить.

Ну и к вопросу резервной копии – в v6.7 появился ручной File-Based Backup, позволяющий сделать бэкап системы vCenter+PSC, восстанавливаемой с нуля с помощью этих файлов.

А в v6.7 Update 1 – возможность запуска бэкапа по расписанию.

В общем, администрирование нескольких vCenter-серверов в v6.7 стало значительно легче.

Скрипт по включению режима обслуживания MS Exchange 2013

Изредка я занимаюсь обслуживанием почтовый серверов MS Exchange. Поставить обновления и кумулятивные пакеты – в принципе несложно.

В очередной раз выполняя процедуру по выводу сервера в режим обслуживания, я подумал – почему бы не написать скрипт, содержащий шесть PowerShell-командлетов вида

в которые еще и нужно добавить имя сервера, выводимого в режим обслуживания.

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

В зависимости от выбранной опции и роли сервера скрипт выполняет требуемые PS-командлеты.

Критика приветствуется.

Приглашаем на VeeamOn в Москве 6 июня 2019 года

VeeamON Forum Россия 2019 состоится в Москве 6 июня в Отеле Хаятт Ридженси Москва Петровский Парк.

Приглашаем ознакомиться с программой, зарегистрироваться и участвовать!

Обращаю внимание, что программа состоит из 2 направлений:

  • Управление данными в облаке
  • Непрерывность бизнеса

Exchange 2013 CU22 и информация об Exchange

Я уже писал о том, что после разворачивания CU22 на Exchange 2013 вы получаете запись в реестре о том, что, оказывается, на сервере-то установлен Exchange 2013 CU20. Microsoft проблему признало и выпустило совет, как можно вручную исправить ключ реестра.

Я же по привычке делюсь скриптом, который исправит этот ключ реестра по всем вашим серверам Exchange, подразумевая что все они – Exhchange 2013 CU22.

Скрипт пройдется по всем серверам Exchange в организации, поменяет параметр реестра HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Microsoft Exchange v15\Displayname и выведет имя сервера в качестве интерактива с вами.

Если вам нужно, чтобы обрабатывались не все сервера, а только какой-то список, то:

  • список серверов нужно будет подать на вход вместо командлета Get-ExchangeServer;
  • вместо $_.name использовать более подходящий $_

P.S. История с этим апдейтом напомнила

“Здравствуйте, я бедный албанский вирус. Я пока что ничего не умею, и к сожалению, не могу причинить вред вашему компьютеру. Пожалуйста, будьте так любезны, сотрите один из важных файлов с жесткого диска вашего компьютера самостоятельно и перешлите меня 30 друзьям. И будет вам счастье. Если вы этого не сделаете я обижусь и не будет вам счастья и конфет весь следующий год! Заранее благодарен за понимание и сотрудничество”.

Проблемы с бэкапом из-за нецелого размера vmdk-диска

Обратил внимание на то, что некоторые виртуальные машины не бэкапятся через штатный VADP API. Техническая поддержка NetBackup нашла в логах, что причиной этого является дробный (нецелый) размер VMDK-диска.

Создать такой диск очень просто – указать дробный размер для терабайт в “толстом” клиенте:

Если изменить единицы измерения с терабайт на гигабайты, вы увидите, что диск занимает нецелое количество гигабайт (и соответственно, мегабайт).

Веб-клиент в этом плане получше – он сразу показывает наличие проблемы:

Лечится проблема достаточно легко:

  1. Меняете единицы измерения на мегабайты и увеличиваете размер диска в сторону ближайшего целого значения. В приведенном случае вместо 2’086’666,23925781 МБ у вас должно стать 2’086’667 МБ.
  2. Растягиваете размер файловой системы на вновь появившееся место.

Для экспресс-проверки вашей инфраструктуры вы можете воспользоваться следующим PowerCLI-скриптом:

Скрипт выведет список виртуальных машин и размер диска, имеющего дробное значение.

XenServer умер, да здравствует Citrix Hypervisor!

Кроме VMware vSphere, на свете существуют и менее известные гипервизоры, имеющие непростой жизненный путь.

Один из таких XenServer от компании Citrix: то открытый, то проприетарный; то бесплатный, то платный. А теперь и имя не нравится – вместо Citrix XenServer получаем Citrix Hypervisor 8.0.

Новое в версии 8.0:

  • Гипервизор Xen 4.11.
  • Поддержка актуальных дистрибутивов Linux и Microsoft Windows Server 2019.
  • Поддержка процессоров Xeon CascadeLake-SP.
  • Экспериментальная поддержка загрузки гостевых систем в режиме UEFI.

Анонс VMware vSphere 6.7 update 2

На днях анонсирована новая версия VMware vSphere 6.7 update 2, которая будет доступен в ближайшее время. Подборка статей с описанием различного функционала:

Также анонсирована новая версия Operations Managere 7.5:

Пара кейсов по импорту OVA-шаблонов

Возникла задача развернуть пару виртуалок Avaya.

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

Решение стандартное: сертификату vCenter рабочая станция должна доверять, причем подключаться вы должны по полному имени (FQDN) vCenter.

Один из вариантов – это добавить в доверенные узлы на вашей рабочей станции тот центр сертификации, которым воспользовался vCenter.

Для просмотра сертификата vCenter нажмите на красный значок в адресной строке:

 

Затем перейдите на вкладку “Путь сертификации”, выберите сертификат центра сертификации (самый верхний) и нажмите “Просмотр сертификата”.

Указанный сертификат необходимо установить в доверенные центры сертификации “Local Machine” на вашей рабочей станции.

После этого перезапустите браузер и подключитесь по полному имени сервера, указанному в сертификате в поле “Кому выдан” или CN.

 

Но и это еще не все – ряд виртуальных машин отказывался импортироваться, выдавая ошибки несоответствия.

Для решения данной проблемы я исключил проверку целостности OVA-архива, распаковав его и удалив файлы .cert и .mf.

P.S. соавтор Mr_Nobody подсказывает, что при развертывании через Host Client сертификаты игнорируются.