7 лет назад мы писали про утилиту ESXi-Customizer, которая позволяет добавлять кастомные драйвера в ISO-образ VMware ESXi. У того же автора (Andreas Peetz) есть еще одна замечательная утилита, которая актуальна и на сегодняшний день - ESXi-Customizer-PS. Актуальна - это значит, что ее последняя версия (от 18 апреля этого года) поддерживает последние версии платформ и фреймворка - vSphere 6.7 и PowerCLI 10.
ESXi-Customizer-PS - это PowerShell-скрипт, который на входе принимает большое число различных параметров, а на выходе дает кастомизированный ISO-образ или офлайн-бандл ESXi:
Сценарий имеет три режима работы:
Создать установочный образ ISO или Offline Bundle напрямую из хранилища VMware Online depot (стандартный режим).
Создать установочный образ ISO или Offline Bundle из скачанного ESXi Offline Bundle (параметр -izip).
Обновление локального ESXi Offline Bundle с помощью ESXi patch bundle из хранилища VMware Online depot (параметры -izip -update).
С помощью этих трех режимов вы можете добавлять бандлы из хранилища V-Front Online Depot, либо любого другого Online Depot, указав его URL, а также можно указывать локальные Offline Bundles и VIB-файлы (собственно, кастомные драйверы или кастомный софт под ESXi).
Об использовании утилиты ESXi-Customizer-PS Alex Lopez снял хороший видеотуториал:
Скрипт можно использовать множеством способов. Давайте рассмотрим основные:
1. Вызов скрипта без параметров.
Например:
.\ESXi-Customizer-PS-v2.6.0.ps1
В этом случае утилита создаст ISO-образ ESXi самой последней версии (6.7 на данный момент) и с самым последним уровнем обновлений. Вы также можете указать конкретный номер версии ESXi, для которой будет получен ISO с последними обновлениями. Например:
-v50 : ESXi 5.0 ISO
-v51 : ESXi 5.1 ISO
-v55 : ESXi 5.5 ISO
-v60 : ESXi 6.0 ISO
-v65 : ESXi 6.5 ISO
-v67 : ESXi 6.7 ISO
Также есть еще три параметра:
-outDir : записывать ISO-образ в указанную директорию.
-sip : не использует последний уровень патчей, а показывает меню, где можно выбрать конкретный патч. Новые патчи будут показаны сверху. Также будут показаны и профили, которые содержат только обновления безопасности и/или VMware Tools.
-ozip : на выходе будет сформирован не ISO, а ESXi Offline Bundle, который можно импортировать в Update Manager, указать вручную для обновления черезesxcli или использовать как входной бандл для следующих кастомизаций.
2. Использование офлайн бандла ESXi Offline Bundle как входного параметра (вместо VMware Online depot).
Например, такая команда позволит вам получить ISO-образ из офлайн-бандла:
Офлайн бандл можно скачать через VMware Patch Download portal. Некоторые вендоры также предлагают свои кастомизированные офлайн-бандлы, например HP. Офлайн бандлы VMware можно найти вот тут. Также вы можете использовать параметры из пункта 1.
3. Добавление дополнительных пакетов из присоединенных хранилищ Online depots.
Например, вот эта команда позволит добавить сетевые драйверы, отсутствующие в образе ESXi 5.5:
Данные драйверы есть в VMware Online depot, так как они есть в составе ESXi 5.0 и 5.1, но были исключены из дистрибутива ESXi 5.5. Важно, что для ESXi 6.0 такая штука для этих драйверов уже не прокатит, так как они были добавлены в черный список (blacklised).
4. Присоединение онлайн-хранилища V-Front Online Depot и других хранилищ.
Здесь надо не забывать указывать номер версии патчируемого гипервизора (в данном случае -v60 - это ESXi 6.0).
7. Расширенные параметры.
У утилиты есть еще несколько расширенных параметров, которые дают еще больше возможностей по кастомизации образов ESXi:
-log : указание пути к кастомному лог-файлу.
-test : тестирование возможности построения или обновления образа без накатывания реальных изменений. Экономит массу времени, так как не перестраивает ISO или zip, а также не качает обновления и образы из VMware Online depot.
-nsc : это опция -noSignatureCheck, которая отключает проверку сигнатуры при выполнении функции экспорта. Ее нужно использовать, если вы получаете ошибку типа "Could not find trusted signer." (пакет с некорректными или отсутствующими сигнатурами).
-ipname, -ipdesc, -ipvendor: задание собственных атрибутов в профиле образа. По умолчанию в имени и описании останутся прежние значения с приставкой "customized", а имя вендора не изменится.
-remove vib1[,...]: удаление одного или нескольких VIB-пакетов из кастомного образа.
Скачать ESXi-Customizer-PS-v2.6.0.ps1 можно по этой ссылке.
Мы иногда пишем о том, что большие обновления как хост-серверов VMware ESXi, так и управляющих компонентов VMware vCenter / vCenter Server Appliance всегда лучше ставить заново, а не делать апгрейд с предыдущих версий (если у вас, конечно, есть такая возможность). Да, вы не сохраните логи и исторические данные, но это позволит вам избежать различных проблем, связанных с устаревшими компонентами, которые останутся при обновлении и могут вступить в конфликт с новыми функциями при определенных обстоятельствах.
Такой вот пример приводит и Mike Foley в статье про механизм безопасной загрузки хостов vSphere Secure Boot. Когда он обновил свою инфраструктуру на VMware vSphere 6.7 с версии 6.5, он решил проверить функции Secure Boot и возможности модуля TPM 2.0.
Но когда он включил эти возможности в UEFI BIOS, он получил "розовый экран смерти" (PSOD) сервера ESXi:
Причина оказалась проста - для некоторых legacy-драйверов при обновлении не были обновлены их сигнатуры для VIB-пакетов, поэтому механизм Secure Boot не может эти сигнатуры проверить и выводит хост в PSOD при загрузке.
Чтобы найти эти драйверы, он запустил скрипт secureBoot.py, который показывает модули, препятствующие безопасной загрузке:
/usr/lib/vmware/secureboot/bin/secureBoot.py -c
Вывод оказался примерно таким:
[root@esxi-117] /usr/lib/vmware/secureboot/bin/secureBoot.py -c Secure boot CANNOT be enabled:
Failed to verify signatures of the following vib(s): [
net-tg3
dell-configuration-vib
net-i40e
net-igb
net-ixgbe
vmware-esx-perccli-1.05.08
ima-qla4xxx
misc-cnic-register
net-bnx2
net-bnx2x
net-cnic
net-qlcnic
net-qlge
scsi-bnx2fc
scsi-bnx2i
scsi-qla4xxx
scsi-megaraid-sas
lsu-lsi-mptsas-plugin].
All tardisks validated. All acceptance levels validated
Посмотрев на каждый драйвер по отдельности, он понял, что все это старые Linux-драйверы, которые были заменены в новых версиях VMware vSphere своими Native-аналогами. Например, для драйвера net-tg3 есть аналогичный нативный драйвер ntg3, а для net-bnx2i есть bnxnet.
Поэтому далее Майк просто удалил все VIB-пакеты со старыми драйверами следующей командой:
В итоге его хост смог безопасно загрузиться через Secure Boot. Также Майк далее в статье рассматривает решение еще одной специфической проблемы, которая встречается довольно редко.
Ну а мы еще раз напомним - если есть возможность поставить новую мажорную версию ESXi с нуля - лучше скачайте ISO-образ и сделайте это, вместо того, чтобы "быстро и безопасно" обновиться на новую версию.
Некто Bery Ju разработал интересный плагин к браузеру - темную тему для консоли VMware vSphere HTML5 Client, которая называется dark-vcenter (кстати, некоторое время назад темный режим уже был в клиенте, но его убрали). Эта тема работает для платформ VMware vSphere версий 6.5 и 6.7 под браузеры Google Chrome и Mozilla Firefox.
Это всего лишь CSS-тема для браузера, которая применяется, когда вы заходите на сервер vCenter через vSphere Client. В этом случае плагин автоматически подхватывает клиента. Ничего на самом сервере vCenter при этом не меняется.
Тема, конечно, на любителя - у многих, например, от темных фонов болят глаза. Но если кто-то работает с клиентом vSphere Client в темноте, почти без освещения, такая тема вполне может пригодиться.
На днях компания VMware обновила свое средство для управления виртуальной инфраструктурой на базе технологии HTML5 - на сайте проекта VMware Labs появился VMware vSphere Client версии 3.36.
Напомним, что о версии 3.34 этого продукта мы писали в середине февраля вот тут, поэтому давайте взглянем на новые функции и улучшения последних двух версий клиентов - VMware vSphere Client 3.36 и 3.35:
Кастомизация дополнительных устройств и опций при создании виртуальной машины или ее клонировании:
Host USB device
SCSI controller
USB controller
SATA controller
CPU > CPUID Mask > Advanced
VM Options > VMRC options
VM Options > VMware Tools > Power Operations
VM Options > Power Management > Wake up on LAN
VM Options > Advanced Configuration Parameters
VM Options > Fibre Channel NPIV
Оповещение перед тем, как происходит операция над шаблоном ВМ, который в данный момент управляется клиентом.
Улучшения интерфейса для быстрого поиска (Quick search).
Улучшения в панели управления дисками ВМ - теперь они объединяются в группы в разделе VM Summary->Edit Settings (если их больше 4 штук).
Несколько исправлений багов и мелких улучшений.
Скачать VMware vSphere Client 3.36 можно по этой ссылке.
На сайте nolabnoparty.com появилась отличная статья о том, как нужно выключать и включать кластер отказоустойчивых хранилищ VMware vSAN таким образом, чтобы не повредить данных, и включить его потом без особых проблем. Инструкция может оказаться полезной тем администраторам, которым необходимо остановить кластер vSAN целиком в целях обслуживания оборудования (серверы, коммутаторы, стойка и т.п.).
Выключение кластера vSAN
1. Для начала вам нужно выключить все виртуальные машины, кроме сервера VMware vCenter (неважно, обычный это VC или vCSA):
2. Мигрируем с помощью vMotion сервер vCenter на хост ESXi01 (тот хост, который вы считаете своим первым хостом в виртуальной инфраструктуре):
Также на первый хост ESXi настоятельно рекомендуется перевести контроллер домена Active Directory.
3. Теперь надо убедиться, что в данный момент в кластере vSAN нет процессов ресинхронизации (Resyncing Components). Для этого надо зайти в соответствующий раздел на вкладке Monitor:
На этом скриншоте видно, что никаких процессов ресинхронизации сейчас не идет. Если они у вас есть, то следует дождаться их завершения.
4. Переводим все хосты VMware ESXi (кроме ESXi01) в режим обслуживания (Maintenance Mode):
В настройках режима обслуживания уберите галку с варианта переместить машины (Move powered-off and suspended virtual machines...), а также выберите вариант не перемещать данные кластера vSAN (No data evacuation):
5. Выключите гостевую ОС виртуальной машины c VMware vCenter. Для этого в контекстном меню vCenter или vCSA выберите пункт Shut Down Guest OS:
После этого у вас, само собой, отпадет соединение с VMware vSphere Web Client:
6. Зайдите на хост ESXi через ESXi Host Client (ссылка https://<ip esxi>/ui) и переведите сервер в режим обслуживания, выбрав из контекстного меню пункт Enter maintenance mode:
Аналогично укажите, что не нужно переносить данные кластера vSAN:
Также это можно сделать следующей командой esxcli в консоли сервера:
# esxcli system maintenanceMode set -e true -m noAction
Включение кластера VMware vSAN
1. Сначала последовательно выводим хосты ESXi из режима обслуживания, начав с первого:
Сделать это также можно командой esxcli:
# esxcli system maintenanceMode set -e false
2. Включаем на хосте ESXi01 сервер vCenter и контроллер домена Active Directory:
3. Идем на вкладку Monitor и там в разделе Health убеждаемся, что все узлы в порядке и кластер vSAN прошел все проверки:
4. Только после этого включаем все виртуальные машины:
Все эти категории там не просто так - это очень удобный способ проверить совместимость вашего устройства ввода-вывода (сетевая карта, HBA-адаптер, SCSI-контроллер, USB-контроллер, и т.п.) с платформой VMware vSphere / ESXi и другими продуктами.
Например, если вы хотите узнать эти параметры для сетевой карты, то можно вывести список PCI-устройств командой vmkchdev, отфильтровав их с помощью grep по свойству vmnic (сетевой адаптер):
Здесь вот этот участок - 14e4:1657 103c:22be - для адаптера vmnic0 позволяет разложить его на 4 приведенных выше параметра:
VID = 14e4
DID = 1657
SVID = 103c
SSID = 22be
После этого вы просто вбиваете эти параметры в VMware HCL для I/O-устройств в правую колонку и смотрите, совместима ли данная сетевая карта с данной версией VMware ESXi.
Если вы отфильтруете вывод по строчке vmhba, то можете получить локальные SCSI-контроллеры или HBA-адаптеры, которые также можно проверить аналогичным образом.
В блоге VCDX133 появился интересный и полезный список основных ключевых моментов в различных аспектах проектирования инфраструктуры VMware vSphere. Он будет полезен архитекторам и системным инженерам, которые планируют внедрение большой инфраструктуры виртуализации и хотят учесть все основные функции платформы, а также избежать проблем в будущем при масштабировании архитектуры.
Кстати, этот список можно использовать как высокоуровневый опросник перед началом фазы проектирования, чтобы выяснить ключевые потребности заказчика и далее превратить это все в техническое задание на базе полученных требований.
Приведем данный список ниже:
Бизнес-задачи и проблемы
Какие основные задачи стоят при внедрении?
Какие проблемы заказчика предполагается решить?
Варианты использования платформы
Какие варианты использования инфраструктуры VMware предполагает сам заказчик?
Требования/Ограничения/Допущения
Каковы основные требования, какие ограничения учесть, о какие допущениях и неочевидных моментах нужно проинформировать заказчика.
Риски
Какие риски внедрения решения (например, простои при миграции) и каковы способы их минимизации? Есть ли специфические задачи, тесты и процедуры, которым нужно следовать в таком случае.
A. Управление виртуальным датацентром
Решения в области логической архитектуры
Общий объем объединяемых в пул ресурсов (вычислительные мощности, сети и хранилища).
Какие сервисы будет предоставлять инфраструктура.
Необходимый уровень доступности для систем управления платформой виртуализации.
Интеграция со сторонними решениями: IT Service Management, Infrastructure Management systems, Enterprise services (DNS, LDAP, NTP, PKI, Syslog, SNMP Traps), сбор данных агентами систем различных вендоров.
Необходимы ли расширенные операции, не предоставляемые из коробки?
Механизмы защиты рабочих нагрузок гипервизора (vMotion, HA и другое).
Механизмы балансировки нагрузки на гипервизор (DRS).
Решения в области физической инфраструктуры
Гипервизор: версии ESXi.
Нужен ли отдельный кластер управления?
Серверы vCenter в режиме Standalone или Linked-Mode?
Версия vCenter Server и тип установки (под Windows или в виде виртуального модуля).
База данных vCenter Server - встроенная или внешняя?
Механизмы защиты vCenter Server.
Дизайн инфраструктуры Platform Services Controller (PSC). Будет ли один домен SSO?
Нужна ли инфраструктура шифрования (PKI)? Какие требования к SSL?
Какие компоненты vSphere будут использоваться?
Нужна ли функциональность Host profiles?
Вопросы управления обновлениями ESXi, версиями VM Hardware и версиями VMware Tools.
Интеграция с антивирусами и решениями vShield/NSX.
Нужен ли пакет vRealize Suite для расширенных операций и управления частным облаком?
Нужен ли продукт vRealize Orchestrator для управления рабочими процессами операций? Нужен ли PowerCLI для сценариев автоматизации?
Нужно ли интегрировать виртуальную инфраструктуру с другими средствами управления (Enterprise Management)?
Automated vendor support mechanisms? How will VMware Skyline be used?
Нужно ли организовывать интеграцию с системами Service Desk или Change Management?
Каковы требования к механизмам vSphere HA и vSphere DRS?
Если будет использоваться HCI (Hyper-Converged Infrastructure), то какие решения будут использоваться для управления, и как это будет совместимо с vSphere?
Вопросы интеграции со службами DNS и NTP.
Ролевая модель доступа (Role Based Access Control) и интеграция с LDAP.
Какой интерфейс vCenter Server будет использоваться для администрирования и ежедневных операций (vSphere Client / Web Client).
Модель лицензирования vCenter.
Вопросы лицензирования стороннего ПО в виртуальных машинах (на хост, на виртуальный процессор vCPU и т.п.).
B. Вычислительные ресурсы
Решения в области логической архитектуры
Традиционная архитектура, технология Server-Side Flash Cache Acceleration, конвергентная или гиперконвергентная инфраструктура (связано с хранилищами).
Минимальное число хостов в кластере.
Тип сайзинга хостов в кластерах: вертикальный (Scale Up) или горизонтальный (Scale Out)?
Гомогенные или гетерогенные узлы?
Число физических процессоров на хост.
Резервирование уровня хостов в рамках доменов отказа (Failure Domains).
Необходимая емкость по CPU.
Необходимая емкость по RAM.
Решения в области физической инфраструктуры
Вендор серверов.
Тип процессоров серверов.
Фичи CPU: VT-x, Hyper-threading, Turbo Boost, включена ли NUMA?
Конфигурация серверного оборудования.
Число сокетов CPU на узел.
Модель процессора, частота и число ядер.
Нужен ли GPU?
Физическое размещение хостов.
Тип размещения: Single Rack или Multi-Rack с шарингом ресурсов?
Требования к доступности кластеров.
Нужно ли обеспечить согласованность доступности хостов с доступностью хранилищ.
Будущее расширение вычислительных ресурсов.
C. Хранилища
Решения в области логической архитектуры
Традиционные хранилища, технология Server-Side Flash Cache Acceleration, конвергентная или гиперконвергентная инфраструктура (связано с вычислительными ресурсами).
Блочные или IP-хранилища?
Средства автоматизированного управления хранилищами.
Допустимо ли использование RDM?
Метод загрузки хоста ESXi - с локального диска (DAS), LUN или PXE.
Толстые или тонкие диски для виртуальных машин?
Необходимые ресурсы хранения.
Репликация хранилищ.
Решения в области физической инфраструктуры
Вендор систем хранения.
Расчет используемой емкости хранилищ с учетом пулов хранения, затрат на репликацию и бэкап. Каковы численные требования к емкости и производительности хранилищ?
Число дисков SSD и HDD в каждой из систем хранения.
Использование дедупликации, сжатия данных, технологии Erasure Coding и Storage APIs. Нужно ли держать процент хранилищ всегда свободным?
Какой активный Working Set (рабочий объем данных) необходим?
Трешхолды для автоматизированного ярусного хранения данных (разнесения по ярусам).
Использование шифрованных дисков и сервер KMS.
Сеть хранения данных и ее организация.
Механизм загрузки хстов ESXi.
Технологии VM DirectPath I/O и SR-IOV.
Число датасторов на кластер.
Будут ли использоваться DRS и SIOC?
Будут ли применяться VMDK shares на уровне виртуальных дисков?
Будет ли использоваться технология VAAI?
Использование VASA и профилей хранилищ (storage profiles).
Будут ли использоваться синхронные или асинхронные DR-решения?
Планирование расширения хранилищ.
D. Сетевая инфраструктура
Решения в области логической архитектуры
Технология Legacy 3-Tier Switch, Collapsed Core или Clos-type Leaf/Spine?
Кластеризованные физические или отдельные коммутаторы EoR/ToR?
Растянутые логические VLAN или на уровне стойки?
Трафик будет функционально разделяться на уровне виртуальных коммутаторов или отдельных VLAN?
Многие из вас хотя бы раз задумывались о том, сколько виртуальных машин должно в среднем приходиться на один хост, а кроме того, в частности, сколько виртуальных процессоров (vCPU) могут исполняться на физических процессорах (pCPU) хост-сервера VMware ESXi.
На этот счет системные архитекторы часто дают следующие рекомендации (в соответствии с критичностью нагрузок в кластере):
Это общие рекомендации и, конечно же, не железные правила - отталкиваться нужно от имеющегося оборудования и характера нагрузок в виртуальных машинах.
Для того, чтобы регулировать это соотношение со стороны кластера балансировки нагрузки VMware DRS есть 2 специальные расширенные настройки:
MaxVcpusPerClusterPct - регулирует соотношение vCPU/pCPU на уровне всего кластера, не привязываясь к конкретным хостам ESXi (то есть сумма vCPU всех машин делится на сумму pCPU всех хостов).
MaxVCPUsPerCore - регулирует соотношение vCPU/pCPU на уровне каждого из хостов ESXi, то есть ни на одном из них это соотношение не может быть превышено.
Указываются эти расширенные настройки в разделе Configuration Parameters в vSphere Web Client при настройке DRS-кластера:
Но самое интересное - это то, что в vSpher Web Client эта настройка есть в GUI и регулирует параметр MaxVcpusPerClusterPct на уровне всего кластера (можно задать процент от 0 до 500, но разумно задавать значения от 100 до 500, если задать 500 - число vCPU может быть больше pCPU в пять раз):
А вот в vSphere Client - эта настройка уже MaxVCPUsPerCore, то есть задание CPU Overcommitment на уровне каждого из хостов ESXi, о чем и написано в интерфейсе:
Кстати, выставить эту настройку можно в диапазоне от 0 до 32.
Таги: VMware, DRS, Blogs, Web Client, Client, vSphere
На днях мы писали о том, что компания VMware выпустила обновления VMware vCenter и ESXi, закрывающие потенциальную угрозу безопасности Spectre (она же Hypervisor-Assisted Guest Mitigation - CVE-2017-5715), которая недавно была обнаружена в процессорах Intel. Для закрытия уязвимости нужно обновить не только серверы ESXi и vCenter, но и микрокод (BIOS/Firmware) серверов (более подробная информация также приведена в KB 52085).
На днях наш читатель Сергей прислал ссылку на скрипт от Вильяма Лама, который позволяет провести проверку компонентов виртуальной инфраструктуры VMware vSphere на данную уязвимость. Этот PowerCLI-скрипт содержит две функции:
Verify-ESXiMicrocodePatchAndVM
Verify-ESXiMicrocodePatch
Первая функция позволяет проверить хосты ESXi и виртуальные машины и сгенерировать отчет в разрезе виртуальных машин. Если в колонке Affected стоит значение False - значит обновления и микрокода сервера, и хоста ESXi были применены, а сами ВМ и хост-сервер не подвержены уязвимости Spectre.
Вторая функция проверяет только, что на хостах ESXi накачено обновление как микрокода, так и самого гипервизора ESXi, который видит обновленные CPU features.
Функция Verify-ESXiMicrocodePatchAndVM может быть запущена тремя способами:
Без параметров - проверяется все окружение VMware vSphere и все виртуальные машины в нем.
С параметром - ClusterName - проверяется конкретный кластер и всего его хосты и ВМ.
С параметром - VMName - проверяется только конкретная ВМ и ее хост, соответственно.
У функции Verify-ESXiMicrocodePatch также есть три способа вызова:
Без параметров - проверяются все хост-сервера в инфраструктуре vCenter.
С параметром - ClusterName - проверяется конкретный кластер и всего его хосты.
С параметром - VMHostName - проверяется конкретный хост-сервер ESXi.
Мы часто пишем о виртуальном модуле VMware vCenter Server Appliance (vCSA), который представляет собой готовую виртуальную машину для управления виртуальной инфраструктурой VMware vSphere (напомним, что это полноценная замена vCenter for Windows).
Сегодня мы покажем несколько интересных утилит командной строки vCSA, которые могут помочь вам в ежедневной эксплуатации этого управляющего сервиса.
1. Просмотр журнала Cron.
vCSA имел раньше проблемы со сжатием фалов журнала (логов), что приводило к тому, что дисковые разделы быстро заполнялись. Поэтому следующей командой можно посмотреть, когда в последний раз выполнялись запланированные задачи Cron:
ls -l /var/spool/cron/lastrun/
Для сравнения ниже приведен вывод этой команды совместно с выводом текущей даты:
vc:~ # date
Mon Dec 4 12:55:39 CET 2017
vc:~ # ls -l /var/spool/cron/lastrun/
total 0
-rw------- 1 root root 0 Dec 3 20:00 cron.daily
-rw------- 1 root root 0 Dec 4 12:15 cron.hourly
-rw------- 1 root root 0 Dec 1 20:00 cron.weekly
Как мы видим, крон успешно выполнялся для ежечасной задачи, ежедневной и еженедельной. Если же крон отвалился, то значит, скорее всего, устарел пароль root. Узнать это можно следующей командой:
grep "Authentication token is no longer valid; new one required" /var/log/messages.0.log | head
Если в выводе этой команды будет что-то вроде этого:
<timestamp> vcenter /usr/sbin/cron[<ID>]: Authentication token is no longer valid; new one required
значит пароль root устарел.
2. Смена устаревшего пароля root.
Если ваш пароль root устарел, и крон-таски vCSA не запускаются, то сменить его проще всего будет следующей командой (обратите внимание, что это НЕ слово change):
chage -l root
У вас запросят старый пароль и попросят задать новый:
Password change requested. Choose a new password.
Old Password:
New password:
После этого можно снова вывести срок действия пароля с помощью chage (тут видно, что он устареет через 99999 дней, то есть 274 года):
vc:~ # chage -l root
Minimum: 0
Maximum: 99999
Warning: 7
Inactive: -1
Last Change: Dec 27, 2016
Password Expires: Never
Password Inactive: Never
Account Expires: Never
3. Перезапуск служб vCSA.
Если вы хотите поправить странное поведение vCSA, которое может быть связано с некорректным поведением сервисов Linux внутри виртуального модуля, то можно перезапустить все службы:
Можно перезапустить, например, только vSphere Client:
service-control --stop vsphere-client
Список запущенных служб узнается так:
service-control --list
А вот так узнается статус того или иного сервиса:
service-control --status
4. Работа с LVM
Если вам надо увеличить виртуальные диски VMDK, а потом расширить тома LVM, то можете прочитать вот эту нашу статью. Чтобы не использовать API Explorer или PowerCLI, можно выполнить следующую команду для просмотра томов LVM:
Для идентификации дисковых устройств и их типов можно выполнить следующее:
lsscsi
Вывод будет примерно таков:
vc:~ # lsscsi
[0:0:0:0] disk VMware Virtual disk 1.0 /dev/sda
[0:0:1:0] disk VMware Virtual disk 1.0 /dev/sdb
[0:0:2:0] disk VMware Virtual disk 1.0 /dev/sdc
[0:0:3:0] disk VMware Virtual disk 1.0 /dev/sdd
[0:0:4:0] disk VMware Virtual disk 1.0 /dev/sde
[0:0:5:0] disk VMware Virtual disk 1.0 /dev/sdf
[0:0:6:0] disk VMware Virtual disk 1.0 /dev/sdg
[0:0:8:0] disk VMware Virtual disk 1.0 /dev/sdh
[0:0:10:0] disk VMware Virtual disk 1.0 /dev/sdi
[0:0:12:0] disk VMware Virtual disk 1.0 /dev/sdj
[0:0:14:0] disk VMware Virtual disk 1.0 /dev/sdk
[1:0:0:0] cd/dvd NECVMWar VMware IDE CDR00 1.00 /dev/sr0
Когда вы поймете, какой том нужно увеличить, выполните команду:
vpxd_servicecfg storage lvm autogrow
Надо помнить, что это сработает только для томов под управлением LVM (например, для disk 1 (sda) с разделом / - не сработает).
5. Поиск "загрязняющих" файлов.
Чтобы найти логи, которые могут засорить корневой раздел или раздел /storage/log, выполните одну из следующих команд:
du -a /var | sort -n -r | head -n 10
du -a /storage/log | sort -n -r | head -n 10
6. Изменение режима ротации логов (Log Rotation).
Сначала перейдем в папку с логами:
cd /etc/logrotate.d
Далее сделаем бэкап настроек:
cp dnsmasq ./dnsmasq.old
Затем откроем настройки:
vi dnsmasq
И поменяем слово "weekly" (еженедельно) на "daily" (ежедневно), например:
После этого можно удалить старый большой лог следующими командами:
cd /var/log
rm dnsmasq.log
7. Удаление файлов, которые не удалились.
Бывает так, что вы удалили большой файл, а дисковое пространство не высвободилось - и это видно командой df -h. Это происходит потому, что какой-то из процессов в памяти еще держит файл (при этом не обязательно использует его). Чтобы узнать, что это за процесс выполняем команду:
Автор известного технического блога о платформе VMware vSphere, Frank Denneman, совместно с одним из коллег выпустил весьма интересную книгу "vSphere 6.5 Host Resources Deep Dive".
В рамках 570-страничного талмуда авторы рассказывают все технические детали управления ресурсами на уровне хоста ESXi, такими как память, процессор, стек работы с хранилищами и сетевая архитектура. Довольно много содержимого книги посвящено архитектуре NUMA-узлов и оперативной памяти, механикам работы CPU и ядра VMkernel, а также прочим самым глубоким моментам программных и аппаратных компонентов хоста ESXi.
По уверению авторов книга покрывает, например, следующие технические вопросы:
Оптимизация рабочих нагрузок для систем Non-Uniform Memory Access (NUMA).
Объяснение того, как именно работает механика vSphere Balanced Power Management, чтобы получить преимущества функциональности CPU Turbo Boost.
Как настроить компоненты VMkernel для оптимизации производительности трафика VXLAN и окружений NFV.
В общем, книга очень крутая и мудрая. Скачать ее можно по этой ссылке.
Как многие из вас знают, в рамках платформы VMware vSphere коммуникация между ее компонентами происходит на базе SSL-сертификатов. Если на сервере vCenter вы используете собственные сертификаты с ограниченным сроком действия, то их надо регулярно продлять и обновлять, иначе однажды вы не сможете выполнять привычные операции в виртуальной инфраструктуре.
Например, если сертификат vCenter устареет, то при попытке выполнить горячую миграцию vMotion, вы получите сообщение о невозможности соединения с демоном vpxd и ошибкой "server certificate chain not verified" в консоли vSphere Client. Если при этом посмотреть вот в этот лог-файл:
/var/log/vmware/vmware-sps/sps.log
то можно увидеть там подобные сообщения:
com.vmware.vim.vmomi.client.exception.SslException: com.vmware.vim.vmomi.core.exception.
CertificateValidationException: Server certificate chain not verified
Чтобы посмотреть сроки действия текущих сертификатов, нужно воспользоваться следующими командами на хосте vCSA (vCenter Server Appliance):
/usr/lib/vmware-vmafd/bin/vecs-cli entry list –store MACHINE_SSL_CERT –text |less
/usr/lib/vmware-vmafd/bin/vecs-cli entry list –store machine –text |less
По умолчанию сервер vCenter предупреждает администратора об истечении срока действия сертификатов за 30 дней. О том, как заменить сертификаты хорошо рассказано вот тут.
Этот срок можно поменять, для этого:
Зайдите в vSphere Web Client.
Выберите vCenter Server, перейдите на вкладку Manage и далее в подвкладку Settings.
Нажмите Advanced Settings, далее Edit и введите в фильтр слово "threshold".
Измените значение ключа vpxd.cert.threshold на нужное количество дней.
Ну а чтобы аларм об истечении сертификатов точно сработал, нужно зайти в Alarm settings –> Certificate Status и убедиться, что установлена галка Enable this alarm.
Некоторое время мы писали о портале WhatMatrix, где можно посмотреть относительно свежие сравнения платформ виртуализации, а также некоторых других технологий и решений. Хотим напомнить об этом интересном средстве, особенно в контексте последних изменений - на сайте было добавлено много новых категорий сравнений, а скоро будет добавлено еще больше (не только глобальные продукты, но и нишевые решения):
Сравнения представлены в различных категориях:
Application Delivery Controllers - это так называемые контроллеры доставки приложений, то есть ПО, которое оптимизирует трафик на входящем/исходящем канале на уровне датацентра, балансирует нагрузку и выполняет прочие служебные задачи.
DR for Virtual Environments - это решения для обеспечения катастрофоустойчивости виртуальных машин и сервисов на уровне датацентра.
Cloud Management Platforms - это решения для управления онпремизной и публичной облачной инфраструктурой.
SDS and HCI - различные решения для хранения данных в виртуальной среде и гиперконвергентные платформы управления виртуальной инфраструктурой.
Virtualization - это, собственно, платформы виртуализации, наиболее интересная часть.
Cloud Storage Gateways - средства транислирования облачных API-запросов к хранилищам на блочный уровень.
UDM (Unified Device Management) - комплексные решения для управления пользовательскими устройствами.
Backups for Virtual Environments - средства резервного копирования виртуальных машин.
В ближайшем будущем также появится сравнение публичных облаков (Public Cloud Comparison), что для многих суперактуальная штука сегодня:
Разработчики портала утверждают, что в ближайшее время также будет добавлено около 170 значительных изменений, что превратит ресурс в главный источник знаний о различиях в корпоративном софте для датацентров. Будет даже добавлен обзор Blockchain-решений. Также обещают кастомизацию сравнений и результатов под конкретные требования пользователя, чтобы не ставить его перед выбором, какие продукты подставлять в сравнения и как между собой сравнивать их результаты.
Интересно, что для некоторой справедливости, при каждой загрузке страницы вендоры и их продукты в колонки для сравнения подставляются случайным образом (в рамках выбранной категории, есественно).
В общем, заходите на WhatMatrix.com и решайте сами - адекватно там все или нет.
Некоторые из вас помнят, что в VMware vSphere 6.5 одной из новых возможностей гипервизора ESXi 6.5 стала функция его безопасной загрузки (Secure Boot). Об этом мы уже упоминали в посте с видеороликами о новых возможностях vSphere 6.5:
Суть механизма безопасной загрузки в vSphere 6.5 заключается в том, что загрузка подписанного кода гипервизора ESXi контролируется со стороны UEFI firmware, а также не разрешается исполнение неподписанных пакетов.
UEFI (Unified Extensible Firmware Interface) - это замена традиционному BIOS в серверах и настольных ПК. Механизм Secure Boot - это один из "протоколов" UEFI, который предоставляет возможности контроля загрузки подписанного кода за счет хранения цифровых сертификатов, которые хранятся в микрокоде (firmware) компьютера (signature database). Это все позволяет убедиться в том, что некий root kit не будет присутствовать в составе загружаемых компонентов и не предоставит доступ злоумышленнику на самом низком уровне.
Большинство UEFI содержит набор сертификатов по умолчанию типа x509 Microsoft UEFI Public CA, а также позволяет устанавливать собственные сертификаты дополнительно. Надо отметить, что эти сертификаты поставляются производителем серверов и обновляются вместе с его микрокодом.
Для обеспечения безопасной загрузки используются следующие компоненты:
Загрузчик ESXi (boot loader) - он убеждается в том, что цифровая сигнатура кода не была изменена. Загрузчик подписан сертификатом Microsoft UEFI Public CA. Он также содержит VMware public key, с помощью которого проверяются компоненты VM Kernel, Secure Boot Verifier, а также пакеты VIB.
Ядро VM Kernel - это также подписанная часть кода. Первое, что делает VM Kernel, это запускает Secure Boot Verifier.
Secure Boot Verifier - он также хранит VMware public key и проверяет аутентичность всех VIB-пакетов, которые загружаются во время загрузки ESXi.
VIB-пакеты (vSphere Installation Bundles) - эти пакеты, помимо реализуемых ими сервисов, содержат файл XML descriptor и файл цифровой подписи (digital signature file). Во время загрузки ESXi в памяти создается "карта" содержимого каждого из VIB-пакетов, соответственно не требуется проверять каждый из его файлов, а достаточно проверить подпись пакета целиком (это быстрее работает).
Вот как выглядит процесс загрузки хоста ESXi с точки зрения Secure Boot:
Включение питания.
UEFI Firmware валидирует загрузчик ESXi Boot Loader на предмет соответствия сертификату Microsoft внутри микрокода UEFI.
ESXi Boot Loader валидирует компонент VM Kernel на предмет соответствия сертификату в Boot Loader.
VM Kernel запускает компонент Secure Boot Verifier.
Secure Boot Verifier валидирует каждый VIB-пакет на соответствие сертификату VMware, который находится в хранилище Secure Boot Verifier.
Запускаются необходимые сервисы управления (DCUI, hostd и т.п.).
При апгрейде VMware ESXi прошлых версий с помощью ESXCLI происходит обновление сигнатур VIB-пакетов, но Boot Loader остается прежним, поэтому когда вы включите Secure Boot - возникнет ошибка. Как следствие - нужно будет переустановить ESXi.
Если вы обновляете ESXi из ISO-образа, то для некоторых старых VIB-пакетов сигнатуры могут не обновиться (например, кастомные драйвера, которые вы устанавливали отдельно), что приведет к неудаче при безопасной загрузке. То есть для нормального обновления из ISO нужно, чтобы все VIB-пакеты в этом образе обновили все предыдущие VIB. Надо отметить, что VIB-пакеты уровня Community supported не поддерживаются для безопасной загрузки (так как они не подписаны).
В составе VMware vSphere 6.5 есть специальный скрипт, который проверяет возможность безопасного апгрейда прошлой версии платформы.
Сначала надо проверить, что серверы поддерживают UEFI secure boot. Далее надо убедиться, что все ваши VIB-пакеты имеют хотя бы уровень Partner Supported, и у вас нет Community Supported пакетов.
Если вы обновили хост на ESXi 6.5, то можно выполнить следующий скрипт для проверки возможности включения Secure Boot:
/usr/lib/vmware/secureboot/bin/secureBoot.py -c
Результатом будет строчка "Secure Boot can be enabled" или "Secure boot CANNOT be enabled".
Если вы включите Secure Boot в микрокоде сервера, но у вас есть неподписанные пакеты, то при загрузке сервера вы увидите розовый экран и сообщение о том, что нельзя проверить подписи VIB-пакетов:
Чтобы выйти из этой ситуации, надо выключить безопасную загрузку, удалить неподписанные VIB-пакеты и снова включить ее.
Еще одна фишка включенной функции Secure Boot - это то, что вы не сможете установить неподписанные VIB-пакеты с опцией force подобным образом:
Если говорить о модуле TPM, то он тут не участвует, и мало того - TPM 2.0 вообще не поддерживается со стороны VMware vSphere 6.5.
Ну и последнее. Если вы хотите использовать Secure Boot вместе с механизмом vSphere Auto Deploy, то вы должны добавить сертификат VMware в список UEFI firmware whitelist (DB). Это требуется потому, что только ESXi Boot Loader подписан сертификатом Microsoft, а часть кода PXE-загрузчика, которая грузится до Boot Loader, подписана сертификатом VMware. Более подробно об этом написано в KB 2148532.
Интересный пост написал Cormac Hogan, касающийся конфигурации растянутых кластеров VMware vSphere Stretched Clusters и размещения компонентов Witness VM для них. Если у вас есть 2 площадки и два растянутых кластера VMware vSAN между ними, то сама собой напрашивается следующая конфигурация:
Но так делать, конечно же, нельзя - и вот почему. Допустим у вас отказал сайт 2, на котором не было Witness-машин. Только в этом случае у вас будет все хорошо - для каждого из кластеров будет кворум (Witness VM+узел), и они продолжат нормальную работу.
Но если у вас откажет сайт 1, то вы лишитесь сразу двух Witness VM (и WA, и WB), узлы на площадке 2 окажутся изолированными, и все виртуальные машины на них будут недоступны (нет кворума):
А что для случая, если машины Witness VM разместить на разных площадках?
Да тоже ничего хорошего - откажет сайт 1, вследствие чего виртуальные машины выжившего сайта 2 кластера A будут недоступны (не будет кворума, ведь WA, присматривающий за эти узлом умер на первой площадке). Ну а поскольку WB является как раз виртуальной машиной, данного узла кластера A ставшего недоступным, то и у выжившего узла кластера B также не будет кворума. В итоге и виртуальные машины кластера B при данном сбое будут недоступны.
Поэтому нельзя перекрестно конфигурировать Witness VM для двух растянутых кластеров на двух площадках - нужно использовать третью площадку, чтобы кворум обеспечивался при любом виде сбоя на уровне одного из сайтов.
Начиная с VMware vSphere 6.0, компания VMware предлагает администраторам очень удобный механизм для назначения прав доступа на самом высоком уровне при наличии нескольких серверов VMware vCenter - глобальные пермиссии (global permissions).
Для тех, кто использует режим vCenter Enhanced Linked Mode (ELM) с несколькими географически разделенными площадками и разнородными инфраструктурами, глобальные пермиссии - это отличное решение, так как они создаются один раз, после чего распространяются и (что самое главное) поддерживаются в согласованном состоянии на всех серверах vCenter связанной инфраструктуры в рамках одного домена Single Sign-On (SSO).
Вильям Лам, известный своими сценариями для автоматизации инфраструктуры vSphere, написал удобный скрипт GlobalPermissions.ps1, позволяющий добавлять и удалять глобальные пермиссии. Он содержит методы New-GlobalPermission и Remove-GlobalPermission, для которых можно задавать следующие параметры:
vc_server - хост сервера vCenter
vc_username - имя пользователя vCenter
vc_password - пароль пользователя vCenter
vc_user - пользователь vCenter, которому будут назначаться пермиссии
vc_role_id - идентификатор Role ID, который связан с ролью vSphere на данном vCenter Server
propagate - значение true или false для распространения пермиссий вниз по уровням иерархии
Чтобы получить параметр vc_role_id, нужно соединиться с vCenter Server и указать имя роли, выполнив сниппет ниже. В данном примере мы получаем ID административной роли с именем Admin:
(Get-VIRole -Name Admin).ExtensionData.RoleId
Вот пример создания новой глобальной пермиссии для одного из пользователей:
Как знают все администраторы vSphere, в инфраструктуре виртуализации есть основной пароль компонента Single Sign-On (SSO), являющегося частью служб Platform Service Controller (PSC). SSO отвечает за предоставление токена авторизации пользователю, который соединяется с vCenter и использует остальные решения, которые с ним интегрированы.
Если вы забыли пароль SSO, то никак не сможете администрировать основные службы PSC и vCenter. Также вы не сможете никаким способом повысить одного из пользователей с любой ролью до администратора SSO.
Но есть способ восстановить/сбросить пароль Single Sign-On, если вы используете vCenter Server Appliance (vCSA). Для этого нужно зайти на vCSA под пользователем root (его же вы не забыли, правда?):
После чего ввести команду для доступа к шеллу:
shell.set --enabled true
После этого напишите shell и нажмите Enter:
Далее запустите VDC админ-тул, и вы увидите вот такой результат:
Нажмите клавишу <3>, после чего у вас попросят ввести аккаунт (Account UPN), для которого будет сгенерирован временный пароль. Введите administrator@vsphere.local:
После этого с данным паролем войдите в vCenter Single Sign-On:
Ну а там уже перейдите в Administration>Single Sign On > Users и выберите Edit для пользователя Administrator. Там можно сменить пароль:
Это, кстати, говорит о том, что пароль root для vCenter Server Appliance нужно хранить особенно внимательно и не забывать.
Фишка этого блога в том, что там пишут вовсе не о продуктах StarWind (хотя они и очень полезные), а о различных технологиях, тем или иным образом имеющих отношение к виртуализации. Вот, например, некоторые из тем:
Компания VMware сделала доступным весьма полезный ресурс StorageHub, который будет интересен всем тем, кто хочет узнать все об использовании виртуальных и физических хранилищ под виртуальные машины на базе платформы VMware vSphere. Также на StorageHub есть документы и об инструментах обеспечивающих доступность виртуальных сервисов (например, VMware Site Recovery Manager):
Этот виртуальный модуль в формате OVA создан для того, чтобы развернуть хост-серверы ESXi в виде виртуальных машин на платформе vSphere в целях обучения и тестирования. Помните, что VMware не поддерживает вложенную (nested) виртуализацию в производственной среде.
Вот конфигурация виртуального модуля:
GuestType: ESXi 6.5[новое]
Virtual Hardware 11 [новое]
2 vCPU
6 GB памяти
2 x VMXNET vNIC
1 x PVSCSI Adapter [новое]
1 x 2GB HDD (под установку самого ESXi)
1 x 4GB SSD (для использования с vSAN, по умолчанию пустой)
1 x 8GB SSD (для использования с vSAN, по умолчанию пустой)
Для запуска виртуального ESXi 6.5 вам потребуется как минимум VMware vSphere 6.0 Update 2. Кстати, а вот какие улучшения появились для виртуального ESXi, которые можно опробовать в версии 6.5:
Поддержка Paravirtual SCSI (PVSCSI)
GuestOS Customization
Поддержка ESXi 6.5 со стороны vSphere 6.0 Update 2
Поддержка Virtual NVMe
Скачать виртуальный модуль VMware ESXi 6.5 Virtual Appliance можно по этой ссылке.
А недавно на сайте blog.igics.com появился интересный и полезный PowerCLI-сценарий, который позволит вам вывести в одном гриде (или в файл) все виртуальные машины и версии VMware Tools в них. Вы, конечно же, можете посмотреть версии VMware Tools в vSphere Client, но если у вас большая инфраструктура, да еще и несколько серверов vCenter, то следить за версиями тулзов во всех виртуальных машинах через клиент будет затруднительно.
И тут на помощь вам придет следующий скрипт:
######################################################################################################################################
# Author: David Pasek
# E-mail: david.pasek@gmail.com
# Twitter: david_pasek
# Creation Date: 2016-11-25
#
# Use case:
# Key use case of this script is to report VMtools from all VMs in vCenter
#
# Disclaimer:
# Use it on your own risk. Author is not responsible for any impacts caused by this script.
######################################################################################################################################
#
# CHANGE FOLLOWING VARIABLES BASED ON YOUR SPECIFIC REQUIREMENTS
# vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
#
# Report type - table, grid, file, csv-file
$REPORT_TYPE = "csv-file"
# Report file name without file extension. Extension is automatically added. File is created in current working directory.
$REPORT_FILE_NAME = "report-vmtools"
######################################################################################################################################
Clear-Host
# We need VMware PowerCLI snapin
$o = Add-PSSnapin VMware.VimAutomation.Core
$o = Set-PowerCLIConfiguration -InvalidCertificateAction Ignore -Confirm:$false
# Connect to vCenter
Write-Host "Connecting to vCenter ..."
$VC = Read-Host "Enter one vCentre Server or multiple vCenter servers delimited by comma."
Write-Host "Enter vCenter credentials ..."
$CRED = Get-Credential
Connect-VIServer -Server $VC -Credential $CRED -ErrorAction Stop | Out-Null
# Add new property (ToolsVersion) to VM
New-VIProperty -Name ToolsVersion -ObjectType VirtualMachine -ValueFromExtensionProperty 'Config.tools.ToolsVersion' -Force | Out-Null
# Initalize report
$Report = @()
foreach ($vm in Get-VM) {
# Numbers mapping is from https://packages.vmware.com/tools/versions
Switch ($vm.ToolsVersion) {
7302 {$GuestToolsVersion = "7.4.6"}
7303 {$GuestToolsVersion = "7.4.7"}
7304 {$GuestToolsVersion = "7.4.8"}
8192 {$GuestToolsVersion = "8.0.0"}
8194 {$GuestToolsVersion = "8.0.2"}
8195 {$GuestToolsVersion = "8.0.3"}
8196 {$GuestToolsVersion = "8.0.4"}
8197 {$GuestToolsVersion = "8.0.5"}
8198 {$GuestToolsVersion = "8.0.6"}
8199 {$GuestToolsVersion = "8.0.7"}
8290 {$GuestToolsVersion = "8.3.2"}
8295 {$GuestToolsVersion = "8.3.7"}
8300 {$GuestToolsVersion = "8.3.12"}
8305 {$GuestToolsVersion = "8.3.17"}
8306 {$GuestToolsVersion = "8.3.18"}
8307 {$GuestToolsVersion = "8.3.19"}
8384 {$GuestToolsVersion = "8.6.0"}
8389 {$GuestToolsVersion = "8.6.5"}
8394 {$GuestToolsVersion = "8.6.10"}
8395 {$GuestToolsVersion = "8.6.11"}
8396 {$GuestToolsVersion = "8.6.12"}
8397 {$GuestToolsVersion = "8.6.13"}
8398 {$GuestToolsVersion = "8.6.14"}
8399 {$GuestToolsVersion = "8.6.15"}
8400 {$GuestToolsVersion = "8.6.16"}
8401 {$GuestToolsVersion = "8.6.17"}
9216 {$GuestToolsVersion = "9.0.0"}
9217 {$GuestToolsVersion = "9.0.1"}
9221 {$GuestToolsVersion = "9.0.5"}
9226 {$GuestToolsVersion = "9.0.10"}
9227 {$GuestToolsVersion = "9.0.11"}
9228 {$GuestToolsVersion = "9.0.12"}
9229 {$GuestToolsVersion = "9.0.13"}
9231 {$GuestToolsVersion = "9.0.15"}
9232 {$GuestToolsVersion = "9.0.16"}
9233 {$GuestToolsVersion = "9.0.17"}
9344 {$GuestToolsVersion = "9.4.0"}
9349 {$GuestToolsVersion = "9.4.5"}
9350 {$GuestToolsVersion = "9.4.6"}
9354 {$GuestToolsVersion = "9.4.10"}
9355 {$GuestToolsVersion = "9.4.11"}
9356 {$GuestToolsVersion = "9.4.12"}
9359 {$GuestToolsVersion = "9.4.15"}
9536 {$GuestToolsVersion = "9.10.0"}
9537 {$GuestToolsVersion = "9.10.1"}
9541 {$GuestToolsVersion = "9.10.5"}
10240 {$GuestToolsVersion = "10.0.0"}
10245 {$GuestToolsVersion = "10.0.5"}
10246 {$GuestToolsVersion = "10.0.6"}
10247 {$GuestToolsVersion = "10.0.8"}
10249 {$GuestToolsVersion = "10.0.9"}
10252 {$GuestToolsVersion = "10.0.12"}
10272 {$GuestToolsVersion = "10.1.0"}
0 {$GuestToolsVersion = "Not installed"}
2147483647 {$GuestToolsVersion = "3rd party - guest managed"}
default {$GuestToolsVersion = "Unknown"}
}
$vminfo = New-Object -Type PSObject -Property @{
Name = $vm.Name
VMhardwareVersion = $vm.Version
ToolsVersion = $vm.ToolsVersion
GuestToolsVersion = $GuestToolsVersion
}
$Report += $vminfo
}
# Show report
Switch ($REPORT_TYPE) {
"grid" { $Report | select Name,VMhardwareVersion,ToolsVersion,GuestToolsVersion | Out-GridView }
"file" { $Report | select Name,VMhardwareVersion,ToolsVersion,GuestToolsVersion | Out-File -FilePath "$REPORT_FILE_NAME.txt" }
"csv-file" { $Report | select Name,VMhardwareVersion,ToolsVersion,GuestToolsVersion | export-csv "$REPORT_FILE_NAME.csv" }
default { $Report | select Name,VMhardwareVersion,ToolsVersion,GuestToolsVersion | Format-Table }
}
Disconnect-VIserver -Server $VC -Force -Confirm:$false
Форму отчета можно редактировать в переменной $REPORT_TYPE, которая задает одно из следующих представлений:
Стандартный вывод таблицы PowerShell в терминале (значение table)
Представление PowerShell GridView (grid)
Текстовый файл, содержащий таблицу (file)
Файл Comma separated values (csv-file)
Прогнав скрипт, мы получим вот такой результат, из которого можно сделать вывод о том, в каких виртуальных машинах нужно обновить VMware Tools (показывается еще и Virtual Hardware Version):
Как многие из вас знают, совсем недавно компания VMware сделала доступной для скачивания новую версию серверной платформы виртуализации VMware vSphere 6.5. Традиционно, с каждой новой версией происходит увеличение максимумов конфигурации различных компонентов платформы. Приведем их сравнение ниже:
Хосты VMware ESXi 6.5 и виртуальные машины:
Максимальная конфигурация
vSphere 6.5
vSphere 6.0
Объем RAM на виртуальную машину
6 ТБ
4 ТБ
Видеопамяти на ВМ
2 ГБ
512 МБ
Логических CPU на хост ESXi
576
480
Общее число путей к хранилищам на сервере ESXi
2048
1024
Число адресуемых FC LUN ID
16383
1032
Логических томов на хост ESXi
512
256
Серверы vCenter:
Максимальная конфигурация
vSphere 6.5
vSphere 6.0
Хостов ESXi на один vCenter Server
2000
1000
Включенных виртуальных машин
25000
10000
Зарегистрированных виртуальных машин
35000
15000
Число хостов в виртуальном датацентре
2000
500
Виртуальных машин на один кластер
8000
4000
Хостов на один распределенный виртуальный коммутатор (virtual distributed switch, vDS)
2000
1000
И познавательная инфографика максимальных конфигураций платформы виртуализации ESX/ESXi от первой версии до 6.5 от virten.net (кликабельно):
Ну и, конечно, полезно посмотреть документ "Configuration Maximums vSphere 6.5", который был также обновлен с выходом новой версии платформы.
Как мы уже писали, в новой версии VMware vSphere 6.5 компания VMware существенно улучшила функции виртуального модуля VMware vCenter Server Appliance (vCSA). В частности, в него был добавлен VMware Update Manager (VUM), который по традиции также идет отдельным разделом и диском VMDK, как и остальные сервисы. Расскажем ниже об увеличении раздела диска vCSA, которое описано в статье Вильяма Лама.
Давайте взглянем на таблицу разделов vCSA 6.5, каждому из которых соответствует диск VMDK, в сравнении с vSphere 6.0:
Disk
6.0 Size
6.5 Size
Назначение
Mount Point
VMDK1
12GB
12GB
/ and Boot
/ and Boot
VMDK2
1.2GB
1.8GB
Temp Mount
/tmp
VMDK3
25GB
25GB
Swap
SWAP
VMDK4
25GB
25GB
Core
/storage/core
VMDK5
10GB
10GB
Log
/storage/log
VMDK6
10GB
10GB
DB
/storage/db
VMDK7
5GB
15GB
DBLog
/storage/dblog
VMDK8
10GB
10GB
SEAT (Stats Events and Tasks)
/storage/seat
VMDK9
1GB
1GB
Net Dumper
/storage/netdump
VMDK10
10GB
10GB
Auto Deploy
/storage/autodeploy
VMDK11
N/A (Previously InvSrvc 5GB)
10GB
Image Builder
/storage/imagebuilder
VMDK12
N/A
100GB
Update Manager
/storage/updatemgr
Как мы видим, кое-где изменились размеры стандартных разделов, для Image Builder поменялась точка монтирования, а также добавился отдельный раздел VUM на 100 гигабайт, которого не было раньше.
Размер каждого из разделов можно менять на горячую в настройках ВМ, ну а потом нужно из гостевой ОС vCSA расширить раздел на образовавшееся свободное пространство диска. Вот какие изменения произошли в версии vSphere 6.5 на эту тему:
Теперь вместо команды vpxd_servicecfg для расширения логического тома нужно использовать следующий скрипт: /usr/lib/applmgmt/support/scripts/autogrow.sh
Посмотрим на расширение раздела с Net Dumper (VMDK9) с помощью нового VAMI API.
Выполним команду df -h, чтобы вывести таблицу разделов на vCSA:
Теперь в vSphere Client идем в настройки виртуальной машины vCSA и переходим в раздел управления дисками, где увеличиваем размер девятого виртуального диска с 1 ГБ до 5 ГБ:
Затем идем в браузере по адресу https://[VCSA-HOSTNAME]/apiexplorer, где выбираем пункт "appliance" в разделе Select API и нажимаем кнопку Login, после чего вводим логин/пароль от vCenter Server:
Скроллим до операции POST /appliance/system/storage/resize и раскрываем ее, чтобы увидеть детали:
Теперь нажимаем кнопку "Try it out!" и, в случае успешного выполнения, код ответа (Response Code) будет 200. Также эту же операцию можно выполнить и через PowerCLI:
Представляем очередной гостевой пост компании ИТ-ГРАД, посвященный инфраструктуре VMware vCloud Director. Как часто вы сталкиваетесь с проблемами в облачном окружении, устранить которые можно обходными путями по причине отсутствия конечного решения? Одна из таких проблем – потеря сетевого подключения у виртуальных машин на базе ОС Windows Server 2012/R2 с сетевыми адаптерами E1000/E1000e в облаке IaaS.
Многие из вас пользуются продуктом StarWind Virtual SAN для создания надежной и отказоустойчивой инфраструктуры хранилищ под виртуализацию VMware vSphere и Microsoft Hyper-V. С помощью этого продукта можно построить недорогую инфраструктуру небольшого офиса или филиала, начиная с двух серверов VMware ESXi или Hyper-V.
Возможно вы также знаете, что StarWind также является популяризатором технологий виртуализации, особенно в сфере хранения данных виртуальных машин. У них есть замечательный портал на эту тему.
Большой плюс этого блога - он не привязан к продуктам StarWind и даже к сфере виртуальных хранилищ. Если вы посмотрите на правую колонку авторов (да, автор VM Guru там тоже есть), то увидите там нескольких популярных блоггеров в сфере виртуализации. Пишут они на самые разные темы, последняя статья, как вы видите, о развертывании SQL Server 2016 на Windows Server Core.
Представляю вам функцию Compare-VMHost из моего PowerCLI модуля Vi-Module, которая позволяет сравнивать один или группу хостов ESXi с эталонным хостом. Что именно будет сравниваться, регулируется параметром –Compare. На данный момент функция умеет сравнивать по следующим критериям...
Дункан Эппинг уже рассказал о трех новых возможностях обновленной версии VSAN:
Программное шифрование неиспользуемых данных (Data at rest).
Технология Nested Fault Domains (FDs), которая обеспечивает двухуровневую защиту "растянутых" кластеров (stretched clusters) - локально и между сайтами. Получается RAID 1 между сайтами, а внутри сайта можно организовать RAID 1, 5 или 6.
Новые улучшения с точки зрения средств управления виртуальной инфраструктурой - интеграция со средством vReealize Automation, отправка состояния жизнедеятельности на vCenter (healthchecks), мониторинг сетевой активности кластеров хранилищ и другое.
В новой бете VSAN ожидается еще несколько интересных возможностей, так что подписывайтесь на нее вот тут.
Некто Kim Bottu в своем блоге опубликовал интересный калькулятор, предназначенный для определения того, сколько хостов, хранилища, физических/виртуальных процессоров, памяти и кэша вам потребуется, чтобы поддерживать кластеры VMware Virtual SAN для вашей инфраструктуры виртуальных хранилищ.
VMware VSAN 6.2 Online resource calculator представляет собой Excel-таблицу, размещенную в облаке Microsoft OneDrive, в которой показаны только редактируемые поля для ввода данных, влияющие на результат (а параметры, которые используются в качестве исходных данных, можно посмотреть в таблице, начиная с ячейки EO:1660).
В верхней части таблицы черным шрифтом обозначаются ресурсы, которые рассчитываются только для того, чтобы можно было исполнять виртуальные машины в кластере Virtual SAN, а красным шрифтом выделен тот объем ресурсов, который вам потребуется, чтобы обеспечить требуемый уровень избыточности и отказоустойчивости.
В синей (верхней) области таблицы данные параметры рассчитываются для All-Flash архитектуры кластера Virtual SAN, а зеленая часть предназначена для расчетов гибридной архитектуры (обычные HDD-диски для данных, а SSD-носители - для кэша).
Также жирным шрифтом выделены реальные ресурсы (процессоры хостов, память, хранилища), которые вам нужно приобрести для своей инфраструктуры, а обычным шрифтом - вспомогательные параметры (как именно эти ресурсы распределяются).
Калькулятор весьма интересный, доступ к нему можно получить по этой ссылке. Кроме того, напомним, что мы писали еще об одном калькуляторе для VMware Virtual SAN от компании VMware, который также помогает вам проводить сайзинг инфраструктуры VSAN и считать совокупную стоимость владения такой инфраструктурой (TCO - total cost of ownership). В принципе, ничто вам не мешает воспользоваться обоими калькуляторами и сравнить результаты, которые должны, по идее, более-менее сходиться.
Очень часто мне, как и любому администратору виртуальной инфраструктуры VMware, требуется знать версию того или иного объекта. Это может быть версия VMTools/vHardware виртуальной машины или версия vSphere хоста ESXi или версия VMFS-датастора (продолжите список сами). И каждый раз вы начинаете судорожно вспоминать, как это делается, где и какой скрипт искать или пускаетесь в поиски по форумам или обращаетесь к доктору Google).
Вильям Лам написал интересный пост об изменении приветственного экрана физической консоли VMware ESXi. Некоторые из вас знают, что внешний вид DCUI-консоли ESXi можно менять в файле /etc/vmware/welcome.
Но руками залезать в него не нужно, вместо этого можно использовать расширенную настройку ESXi Advanced Setting, которая называется Annotations.WelcomeMessage. Ее можно изменить с помощью сценария PowerCLI / PowerShell.
Часто администраторам нужно узнать, на каком из хостов находится виртуальная машина, например, это сервер vCenter, который выключен по тем или иным причинам. В этом случае поможет вывод имен виртуальных машин прямо в физическую DCUI консоль сервера ESXi, к которой можно получить доступ напрямую с сервера или по SSH.
Ниже приведен PowerCLI-скрипта для описанного сценария, в котором все просто и понятно относительно того, как устанавливается рассмотренная выше расширенная настройка для вывода количества и списка виртуальных машин:
Конечно же, если у вас много виртуальных машин на хосте, то они просто не влезут на приветственный экран ESXi, но 15 виртуальных машин у Вильяма влезли без проблем:
Кстати, если вы хотите вывести только включенные виртуальные машины, то вы можете просто добавить фильтр:
-Filter @{"Runtime.PowerState" = "PoweredOn"}
в конце строчки, где используется командлет Get-View.
RSS
