Этой статьёй я хочу открыть серию статей, целью каждой из которых будет описание одной из написанных мной функций PowerCLI или так называемых командлетов (cmdlets), предназначенных для решения задач в виртуальных инфраструктурах, которые невозможно полноценно осуществить с помощью только лишь встроенных функций PowerCLI. Все эти функции будут объединены в один модуль - Vi-Module. Как им пользоваться, можете почитать здесь.

На проходящей сейчас в Барселоне конференции VMworld Europe 2015 компания VMware раскрыла окончательные подробности технологии vSphere Integrated Containers (VIC), которая позволяет работать с инфраструктурой виртуализованных приложений Docker на базе существующей виртуальной инфраструктуры VMware vSphere.

Начнем обзор технологии VIC вот с этого видео, в котором показано, как поднять nginx на Photon OS:

Ключевым понятием инфраструктуры контейнеров является VCH - Virtual Container Host. На самом деле это не хост, а виртуальный объект, состоящий из ресурсов ресурсного пула (Resource Pool) VMware vSphere или кластера хостов ESXi целиком. Это позволяет создавать контейнеры в нескольких доменах в рамках одного или нескольких VCH (например, Production, Staging и Test).

Каждый VCH обслуживает собственный кэш образов, которые загружаются из публичного хаба Docker или из частных репозиториев. Файловые системы ВМ в контейнерах размещаются в виртуальных дисках VMDK, которые уже лежат на обычных VMFS-хранилищах.

Само управление инфраструктурой VIC происходит через плагин к vSphere Web Client. Также есть интерфейс командной строки и PowerCLI. Вот, например, процесс создания VCH:

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

Photon Controller использует механизм VMFork (сейчас эта технология называется VMware Instant Clone и доступна в vSphere 6) для создания мгновенных экземпляров виртуальных машин на базе Photon OS (за менее, чем 1 секунду) с нужным приложением по запросу от пользователя.

То есть, на базе Photon OS развертывается новая машина через VMFork, а в ней уже тянется контейнер из нужного репозитория.

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

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

vSphere Integrated Containers на данный момент находятся в статусе Technology Preview, об их доступности будет сообщено дополнительно.

Возможно не все из вас в курсе, что есть такая полезная и бесплатная утилита как vSphere Configuration Backup, которая позволяет просто и через GUI настроить резервное копирование и восстановление конфигурации серверов VMware ESXi и баз данных SQL.

Возможности утилиты:

• Автоматическое резервное копирование конфигов серверов ESXi 4, 5 и 6 (протестировано vSphere 4.1, 5.0, 5.1, 5.5, 6).
• Резервное копирование любой локальной базы данных и ее конфигурации.
• Управление точками восстановления и удаление устаревших бэкапов (только для бэкапов ESXi).
• Для всего бэкапа конфига ESXi создается только один файл.
• В имени архива бэкапа указан номер билда ESXi.
• Сжимает резервные копии конфигурации ESXi для экономии места на диске.
• Не требует установки.
• Шифрует пароли.
• Конфигурируется из GUI через Configuration Manager.exe.

Как пользоваться vSphere Configuration Backup:

• Запускаем "Configuration manager.exe" для настройки параметров.
• Добавляем хосты ESXi (добавлять vCenter нельзя).
• Выбираем БД SQL Server для резервного копирования.
• Устанавливаем папку для бэкапов и политику хранения резервных копий (сколько хранить и когда удалять).
• Создаем таску планировщика для запуска "ESXi Configuration Backup.exe".

Скачать vSphere Configuration Backup можно по этой ссылке.

Иногда администраторам хранилищ в VMware vSphere требуется передать логический том LUN или локальный диск сервера под другие цели (например, отдать не под виртуальные системы или передать в другой сегмент виртуальной инфраструктуры). В этом случае необходимо убедиться, что все данные на этом LUN удалены и не могут быть использованы во вред компании.

Раньше это приходилось выполнять путем загрузки из какого-нибудь Linux LiveCD, которому презентован данный том, и там удалять его данные и разделы. А в VMware vSphere 6 Update 1 появился более простой способ - теперь эта процедура доступна из графического интерфейса vSphere Web Client в разделе Manage->Storage Adapters:

Теперь просто выбираем нужный адаптер подсистемы хранения и нажимаем Erase для удаления логических томов устройства (будут удалены все логические тома данного устройства):

Теперь можно использовать этот локальный диск по другому назначению, например, отдать кластеру VSAN.

Ну и также отметим, что в следующей версии утилиты ESXi Embedded Host Client компания VMware сделает возможность не только удаления таблицы разделов, но и добавит средства их редактирования:

Несколько лет назад мы писали про политики сложности паролей в VMware vSphere, которые определяют, какой пароль можно установить для пользователей ESXi. Аутентификация на ESXi реализуется с помощью подключаемых модулей аутентификации (Pluggable Authentication Modules, PAM), которые обладают различными возможностями, такими как интеграция с Active Directory, большая устойчивость к подбору пароля и дополнительные возможности (например, задание сложности пароля для различных классов символов).

Разберем сначала структуру политики сложности пароля:

retry=3 min=N0,N1,N2,N3,N4

• retry=3 - допустимое число попыток ввода пароля.
• N0 - минимальная длина пароля, который имеет только символы из класса 1 (это символы букв в нижнем регистре - например, abc).
• N1 - это минимальная длина пароля, который обязательно имеет символы из двух классов (классы 1,2 и 3 - это символы букв в нижнем и верхнем регистре, а также цифры - например, abcABC).
• N2 - пароли, имеющие в составе слова, должны быть длиной не менее 8 символов. Например, vmwareee.
• N3 - это минимальная длина пароля, который обязательно имеет символы из классов 1, 2 и 3 (это буквы в нижнем и верхнем регистрах, а также цифры - например, abcABC123).
• N4 - это минимальная длина пароля, который обязательно имеет символы из классов 1, 2, 3 и 4 (это буквы в нижнем и верхнем регистрах, а также цифры и спецсимволы - например, abcABC123!).

Напомним политики паролей, которые были в VMware ESXi 5.x:

ESXi 5: retry=3 min=8,8,8,7,6

Это значит, что можно было:

• Задать пароль длиной в 8 символов из первого класса, например: thsmypwd
• Задать пароль длиной в 8 символов из первого и второго класса, например: thsmypwD
• Задать пароль из 8 символов, содержащем слово, например: vmwareee
• Задать пароль длиной в 7 символов из первого, второго и третьего класса, например: VMware1
• Задать пароль длиной в 6 символов из первого, второго и третьего класса, например: Vare1!

В VMware ESXi 6 политика сложности пароля была еще усложнена и теперь является такой:

retry=3 min=disabled,disabled,disabled,7,7

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

Но самое интересно, что политики сложности пароля ESXi теперь можно редактировать не в PAM-файлах сервисной консоли, а в расширенных настройках хоста в разделе Security (картинка кликабельна):

То есть, просто меняете параметр Security.PasswordQualityControl и перезагружаете хост ESXi.

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

$PasswordPolicy = "retry=3 min=8,8,8,7,6"
$VMHosts = Get-VMHost | Where { $_.ConnectionState -eq "Connected" }
foreach ($VMHost in $VMHosts)
{
$VMHosts | Get-AdvancedSetting -Name "Security.PasswordQualityControl" | Set-AdvancedSetting -Value $PasswordPolicy -Confirm:$false
}

Интересный пост, касающийся поддержки VMware Tools в смешнном окружении, опубликовали на блогах VMware. Если вы взглянете на папку productLocker в ESXi, то увидите там 2 подпапки /vmtools и /floppies:

Это файлы, относящиеся к пакету VMware Tools, устанавливаемому в гостевые ОС виртуальных машин. Перейдем в папку /vmtools:

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

В папке floppies находятся виртуальные образы дискет, которые могут понадобиться для специфических гостевых ОС при установке драйверов (например, драйвер устройства Paravirtual SCSI):

Интересно, что папка productLocker занимает примерно 150 МБ, что составляет где-то половину от размера установки VMware ESXi. Именно поэтому рекомендуют использовать образ ESXi без VMware Tools ("no-tools") при использовании механизма Auto Deploy для массового развертывания хост-серверов.

Самая соль в том, что версия пакета VMware Tools на каждом хосте разная и зависит от версии VMware ESXi. Например, мы поставили на хосте VMware vSphere 5.5 виртуальную машину и установили в ней тулзы. Консоль vCenter покажет нам, что установлена последняя версия VMware Tools:

Однако если у нас смешанная инфраструктура (то есть, состоит их хостов разных версий), то при перемещении машины на хост с более высокой версией, например, vSphere 5.5 Update 2/3, она будет показана как ВМ с устаревшей версией пакета (VMware Tools: Running (Out-of-Date):

Поэтому возникает некоторая проблема в смешанной среде, которую можно решить очень просто - как правило VMware Tools от хоста с большей версией подходят ко всем предыдущим. Например, тулзы от vSphere 6.0 подойдут ко всем хостам до ESXi 4.0 включительно. vSphere 6 Update 1 выпадает из списка (постепенно поддержка старых версий уходит):

Таким образом, лучше всего распространить тулзы от vSphere 6 на все хосты вашей виртуальной инфраструктуры. Для этого создадим общий для всех хостов датастор SDT и через PowerCLI проверим, что к нему имеет доступ несколько хостов, командой:

Get-Datastore | where {$_.ExtensionData.summary.MultipleHostAccess -eq “true”}

Далее создадим на этом датасторе папку productLocker:

в которую положим VMware Tools от ESXi 6.0:

Далее нужно пойти в раздел:

Manage > Settings > Advanced System Settings > UserVars.ProductLockerLocation

и вбить туда путь к общей папке, в нашем случае такой:

/vmfs/volumes/SDT/productLocker

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

Get-VMhost -Location <cluster name> | Set-VMHostAdvancedConfiguration -Name "UserVars.ProductLockerLocation" -Value "/vmfs/volumes/SDT/productLocker"

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

Зайдем на хост ESXi через PuTTY и перейдем в папку с /productLocker командой cd. Вы увидите путь к локальной папке с тулзами на хосте, так как это ярлык:

Удалим этот ярлык:

rm /productLocker

После чего создадим новый ярлык на общую папку на томе VMFS с тулзами от vSphere 6.0:

ln -s /vmfs/volumes/SDT/productLocker /productLocker

Посмотрим, что все смонтировалось, командой ls:

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

Компания VMware выпустила обновление для прошлой версии платформы виртуализации - vSphere 5.5 Update 3. Не секрет, что большое количество компаний еще использует версию 5.5, так как на больших предприятиях процесс апгрейда ПО и лицензий протекает очень медленно. Поэтому данное обновление им будет весьма кстати.

Что нового в VMware vSphere 5.5 Update 3:

• Управление механизмом ротации логов - теперь можно задавать ограничение по размеру лог-файлов в vmx (для каждого лога) и количество хранимых логов.
• Сертификация адаптера PVSCSI – теперь устройство виртуальных дисков PVSCSI можно использовать для кластеров MSCS, а также кластеризации приложений, таких как Microsoft SQL или Exchange. Это позволит существенно повысить производительность по сравнению с адаптерами LSI Logic SAS.
• Поддержка новых процессоров серверов - теперь платформа поддерживает последние поколения процессоров от Intel и AMD. Подробнее об этом написано в VMware Compatibility Guide.
• Аутентификация серверов ESXi в Active Directory – ESXi поддерживает шифрование AES256-CTS/AES128-CTS/RC4-HMAC для коммуникации Kerberos между ESXi и Active Directory.
• Поддержка новых баз данных - теперь vCenter Server поддерживает следующие СУБД:
  • Oracle 12c R1 P2 (12.1.0.2)
  • Microsoft SQL Server 2012 Service Pack 2
  • Microsoft SQL Server 2008 R2 Service Pack 3
• Поддержка новых операционных систем - новые гостевые ОС теперь полностью поддерживаются:
  • CentOS 7.0
  • Oracle Linux 7.0
  • Ubuntu 14.10
  • Windows 10
  • RHEL 6.6
  • RHEL 7 .1
  • CentOS 7.1
  • Oracle Linux 7.1
• File Transfer Log – теперь в лог-файлы пишется информация о файлах, переданных на хост ESXi или загруженных с него через vSphere Web Client или vSphere Client.

Также были обновлены несколько сопутствующих продуктов для виртуальной инфраструктуры. Вот ссылки:

• VMware vCenter Server 5.5 Update 3 [Release Notes] [Скачать]
• VMware ESXi 5.5.0 Update 3 [Release Notes] [Скачать]
• VMware vCenter Orchestrator Appliance 5.5.3 [Release Notes] [Скачать]
• VMware vCenter Site Recovery Manager 5.8.1 [Release Notes] [Скачать]
• VMware vSphere Replication 5.8.1 [Release Notes] [Скачать]
• vRealize Operations Management Pack for MEDITECH 1.0.0 [Release Notes] [Скачать]

Напомним, что в каждом из документов Release Notes есть раздел What's New, где можно узнать о новых возможностях соответствующего продукта.

Как мы недавно писали, в вышедшем обновлении VMware vSphere 6 Update 1 есть полноценное средство обновления компонентов виртуальной инфраструктуры vSphere Update Manager (VUM), доступное для vSphere Web Client. Ранее VUM можно было использовать только из "толстого" (C#) клиента vSphere Client, и это было одной из ключевых причин неиспользования веб-клинта от VMware в крупных инфраструктурах.

Теперь vSphere Update Manager полноценно присутствует как оснастка Web Client:

Кстати, если вы хотите использовать Update Manager в vCenter Server Appliance (vCSA), то вам все равно придется скачать ISO-шник vCenter для Windows, так как VUM находится именно там.

В левом сайдбаре можно выбрать нужный сервер Update Manager и работать с ним. Пройдитесь по настройкам на вкладках:

Далее нужно создать новый базовый уровень (Baseline) по обновлениям. Нажмите зеленый плюсик в разделе Hosts Baselines:

Также базовый уровень можно создать для виртуальных машин (обновления VMware Tools) и виртуальных модулей (Virtual Appliances):

Создадим новый базовый уровень:

Отмечаем правила для обновления виртуальных модулей:

На вкладке Patch Repository вы видите не только список автоматически добавленных патчей для хостов, но и можете добавить патчи вручную через Web Client:

Для разных хостов можно применять разные образы обновлений VMware ESXi (добавляются вручную) и даже делать это одновременно:

В разделе VA Upgrades можно посмотреть доступные версии виртуальных модулей, а удобная функция по клику на ссылку "EULA" в соответствующей колонке позволяет не принимать условия лицензии каждый раз при развертывании. Нажимаем "Go to compliance page":

Попадаем в раздел vCenter, где мы можем привязывать базовые уровни к хостам, сканировать на наличие обновлений, тестировать обновления путем их "отстаивания" на выделенных для целей стейджинга хост-серверах, а также проводить обновление хостов (Remediate):

В контекстном меню Web Client для хостов есть пункт Update Manager, который позволяет вызвать его функции (например, просканировать на наличие обновлений или обновить):

Более подробно об Update Manager для vSphere Web Client можно прочитать вот тут. Материалы статьи взяты тут.

После краткого анонса на прошедшей недавно конференции VMworld 2015, компания VMware объявила о выпуске первого пакета обновления для своей флагманской платформы виртуализации - VMware vSphere 6 Update 1 (включая ESXi 6.0 Update 1 и vCenter 6.0 Update 1).

Что нового появилось в Update 1 (полезного, прямо скажем, немного):

• Customer Experience Improvement Program (CEIP) - возможность принять участие в программе улучшения продуктов VMware (без передачи данных о клиенте).
• Интерфейс Suite UI теперь включен по умолчанию в vSphere Web Client.
• Поддержка SSLv3 теперь отключена по умолчанию.
• vCSA Authentication for Active Directory - теперь виртуальный модуль с vCenter поддерживает только методы шифрования AES256-CTS/AES128-CTS/RC4-HMAC для аутентификации Kerberos между vCSA и Active Directory.
• Поддержка установщика HTML 5 для нового развертывания и апгрейда:
  • Установка с установщиком HTML 5 для целевого vCenrer Server - поддерживается.
  • Апгрейд с установщиком HTML 5 для целевого vCenrer Server - не поддерживается.
  • Апгрейд vCenter Server из командной строки - поддерживается.
• Виртуальный модуль vCSA можно развернуть как напрямую на ESXi, так и через сервер vCenter на хосте ESXI.
• Возможность конвертации vCSA во внешний Platform Services Controller (PSC).
• Интерфейс VMware Appliance Management Interface (VAMI) в виртуальном модуле vCSA теперь вернулся и доступен по ссылке https://[ip-адрес или имя VCSA]:5480.

• Возможность накатывания патчей по URL (по умолчанию указан онлайн-репозиторий VMware).
• Отдельный HTML 5 интерфейс для PSC, доступный по ссылке:

https://[IP-адрес VCSA]/psc

Это нужно для того, чтобы администратор мог работать с конфигурациями Single Sign-On (SSO) и другими связанными функциями, когда vSphere Web Client по каким-либо причинам недоступен.

• Build-2-Build upgrade support - обновлять виртуальный модуль vCSA можно по новой схеме обновлений: не обязательно ставить новый модуль поверх предыдущей версии. Теперь можно смонтировать новый ISO-образ в уже готовую виртуальную машину с vCSA и запустить процедуру обновления.

Скачать VMware vSphere 6 Update 1 можно по этой ссылке.

Также был выпущен VMware vSphere Update Manager 6.0 Update 1. В VUM 6.0 U1 появились следующие новые возможности:

• Наконец-то стал доступен полноценный Update Manager Web Client. Одна из главных причин, по которым пользователи не отказывались от старого vSphere Client для Windows (так как в нем есть полноценный VUM), теперь устранена.

Также в Update Manager появилось следующее:

• libxml обновлен до версии 2.9.2.
• Опция реинициализации СУБД для VUM теперь доступна Update Manager Utility в категории Database Settings.
• Поддержка новых СУБД.
  • Microsoft SQL 2008 R2-SP3
  • Microsoft SQL 2012 SP2 (Standalone и Clustered)
  • Microsoft SQL 2014(Clustered)
• Microsoft XML обновлен на MSXML6.dll.
• Oracle (Sun) JRE package обновлен на версию 1.7.0_80.
• По умолчанию отключена поддержка SSLv3.

Скачивается VMware vSphere Update Manager 6.0 Update 1 вместе с vCenter.

На проходящей сейчас конференции VMworld 2015 было сделано множество интересных анонсов (впрочем, как и всегда). Конечно же, мы расскажем о всех тех, что достойны внимания. Одна из самых интересных новостей - это анонс новой версии решения для создания кластеров хранилищ VMware Virtual SAN 6.1.

Давайте взглянем на новые возможности этого решения:

1. Virtual SAN Stretched Cluster.

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

2. Virtual SAN for Remote Office / Branch Office (ROBO)

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

3. Virtual SAN Replication with vSphere Replication

Virtual SAN 6.1 теперь может использовать технологию vSphere Replication для асинхронной репликации данных на любые расстояния в комбинации с VMware Site Recovery Manager (SRM), чтобы получилось полностью законченное решения для восстановления инфраструктуры после сбоев.

Например, можно создать синхронно реплицируемый растянутый кластер хранилищ на расстояниях с latency менее 5 мс, а средствами vSphere Replication откидывать данные в географически удаленный датацентр:

4. Поддержка Multi-Processor Fault Tolerance (SMP-FT).

Теперь виртуальные машины, защищенные технологией FT, полностью поддерживаются со стороны VMware Virtual SAN 6.1, то есть кластер непрерывной доступности из виртуальных машин теперь защищен как со стороны вычислительных ресурсов, так и со стороны хранилищ.

5. Поддержка Windows Server Failover Clustering (WSFC) and Oracle Real Application Cluster (RAC).

В новой версии VSAN теперь поддерживаются технологии кластеризации от Oracle и Microsoft. Для Oracle RAC можно запускать несколько экземпляров Oracle RDBMS на одном хранилище. Точно так же можно использовать и кластеры Microsoft WSFC поверх хранилищ Virtual SAN:

6. Максимальная производительность и высокая скорость отклика.

Здесь было сделано 2 серьезных улучшения:

• Поддержка ULLtraDIMM SSD хранилищ, которые втыкаются в канал оперативной памяти (слоты DIMM), работающие с очень быстрым откликом на запись (менее 5 микросекунд). Это позволяет сделать хост All Flash с емкостью на 12 ТБ в форм-факторе блейд-сервера с троекратно большей производительностью, чем у внешних массивов.
• NVMe – интерфейс Non-Volatile Memory Express (NVMe), который был специально разработан для SSD, чтобы максимально распараллеливать операции на программном и аппаратном уровне. В тестах VMware, использующих эту технологию, было получено 3,2 миллиона IOPS на 32-узловом кластере при примерно 100 тысячах операций в секунду на одном хост-сервере ESXi.

7. Virtual SAN Health Check Plug-in.

Теперь плагин, который был ранее доступен только на VMware Labs, стал частью решения VMware Virtual SAN 6.1. Теперь вся необходимая информация о жизнедеятельности кластера хранилищ видна в VMware vSphere Web Client:

8. Virtual SAN Management Pack for vRealize Operations.

Теперь для решения vRealize Operations есть отдельный Virtual SAN Management Pack, который позволяет осуществлять мониторинг кластера хранилищ и своевременно решать возникающие проблемы:

Более подробно о решении VMware Virtual SAN 6.1 можно узнать на этой странице. О доступности решения для загрузки будет объявлено несколько позже.

В ближайшее время мы расскажем еще о нескольких интересных анонсах с VMworld 2015 - stay tuned.

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

Итак, что нового в VMware ESXi Embedded Host Client 2:

Хост ESXi

• Улучшенное представление производительности в интерфейсе
• Композитная метрика CPU/память на одном графике

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

• Поддержка снапшотов
• Поддержка отображения консоли в полноэкранном режиме
• Поддержка функции обрезания консоли до удобного представления (shrink)
• Возможность создания гостевой машины с Mac OS

Хранилища

• Полноценный файловый браузер (операции copy/move/delete/create directory/upload/download)
• Возможность зарегистрировать ВМ из контекстного меню виртуальной машины
• Возможность создания/монтирования хранилищ NFS
• Создание и расширение хранилищ VMFS (только для ранее неразмеченных дисков)
• Опреации Mount/Unmount для VMFS

Сетевое взаимодействие

• Вывод правил сетевого экрана (пока в режиме read-only)

Основные возможности

• По двойному клику на заголовок окна - оно увеличивается
• Поддержка перетаскивания границы с зажатым "Alt" для изменения размера окна
• Возможность переопределить локаль (но пока официально поддерживается только en-US)
• Указание таймаута сессии с клиентом

Обновляться очень просто - надо просто обновить один vib-пакет, в котором распространяется веб-клиент для ESXi:

[root@mini:~] esxcli software vib update -v /esxui-3015331.vib
Installation Result
Message: Operation finished successfully.
Reboot Required: false
VIBs Installed: VMware_bootbank_esx-ui_0.0.2-0.1.3015331
VIBs Removed: VMware_bootbank_esx-ui_0.0.2-0.1.2976804
VIBs Skipped:

Скачать ESXi Embedded Host Client 2 можно по этой ссылке.

На сайте проекта VMware Labs появилась наиполезнейшая вещь - ESXi Embedded Host Client. Это написанный полностью на JS и HTML 5 веб-клиент для сервера VMware ESXi, который все так долго ждали:

Этот клиент работает только для управления хостами VMware ESXi (его нельзя использовать для управления сервером vCenter). Он позволяет производить следующие операции с хост-сервером и виртуальными машинами:

• Операции с состоянием ВМ (включение, выключение, приостановка и прочее)
• Создание новой виртуальной машины с нуля или развертывание из виртуального модуля OVF/OVA (для OVA поддержка пока ограничена)
• Настройка сервисов времени NTP на хосте
• Отображение информации о машинах, их конфигурациях, событиях, задачах, нотификациях и алертах
• Получение доступа к консоли виртуальной машины
• Настройка сетевого окружения на хосте ESXi
• Настройка расширенных параметров (advanced settings)
• Конфигурация сервисов, работающих на хосте

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

Для установки Embedded Host Client просто загрузите VIB-пакет приложения во временную папку и установите его командой:

# esxcli software vib install -v /tmp/esxui.vib

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

https://<адрес ESXi или IP>/ui/

Если у вас ESXi 5.5 или ESXi 6.0, полученный обновлением с версии 5.5, то вам нужно заглянуть сюда. Скачать ESXi Embedded Host Client можно по этой ссылке.

Если вы администратор VMware vSphere со стажем, то наверняка попадали в такую ситуацию: по какой-то причине отключается сервер VMware vCenter (он может работать, но не отвечать на подключения), а с ним вместе недоступна и его база (на том же хосте или на отдельном) - и вам нужно искать хост ESXi с этими ВМ, чтобы поднять всю виртуальную инфраструктуру. А хостов ESXi в кластере у вас может быть несколько десятков.

Можно, конечно, сделать правило DRS для vCenter, чтобы он не перемещался по хостам, но в случае срабатывания аварийного восстановления VMware HA, сервер vCenter вполне может поменять хост, так как HA забивает на правила DRS.

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

Set-PowerCLIConfiguration -DefaultVIServerMode Multiple -Scope Session

Теперь можно соединиться со всеми серверами одновременно и найти там vCenter. Делается это следующей командой:

connect-viserver @("esx1","esx2","esx3") -user root -password password

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

Далее просто ищем нужную виртуальную машину по ее имени:

(get-vm vCenter01).vmhost
(get-vm SQL01).vmhost

В выводе этих команд будут хосты ESXi, на которых они зарегистрированы. Остается только открыть к ним консоль через vSphere Client и включить эти машины.

Каждый администратор VMware vSphere рано или поздно сталкивается с тем, что хост VMware ESXi выпадает в "Pink Screen of Death" (PSOD - розовый экран смерти):

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

В VMware vSphere Web Client в представлении Hosts and Clusters нажимаем правой кнопкой на сервере vCenter, далее в контекстном меню выбираем пункт "Export System Logs...":

Далее выбираем интересующий нас хост VMware ESXi:

Затем отчекиваем все галки, кроме CrashDumps:

После экспорта файла открываете его в текстовом редакторе и ищете строчку "@bluescreen":

Ниже вы увидите подробности о произошедшей ошибке:

В данном случае мы видим, что имеет место проблема с драйвером виртуального сетевого адаптера (vNIC) E1000. Можно заменить его на VMXNET3 (как описано в KB 2059053), и проблема уйдет. Ну и прочие подобные ошибки можно гуглить, по PSOD ESXi уже есть много информации на форумах.

У многих администраторов VMware vSphere зачастую возникает необходимость понизить версию виртуального аппаратного обеспечения (hardware version) виртуальной машины. Это может понадобиться в следующих случаях (и не только):

• когда толстый клиент vSphere Client не поддерживает всех функций новой версии Virtual Hardware
• новая версия железа не поддерживается старыми хостами VMware ESXi, которые вы еще не успели обновить
• если вы пользуетесь услугами внешнего провайдера IaaS (аренда виртуальных машин), то у провайдера может оказаться не самая последняя версия платформы, и при миграции в его облако обновленное Virtual Hardware не будет поддерживаться

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

То даунгрейд можно сделать одним из трех способов:

1. Перед апгрейдом виртуального обеспечения нужно сделать снапшот виртуальной машины. При откате к нему произойдет и откат к предыдущей версии виртуального железа.
2. Можно использовать VMware Converter Standalone для V2V-миграции, при которой можно выбрать нужную версию Virtual Hardware.
3. Можно создать новую виртуальную машину с нужной версией железа (например, на старом хосте ESXi), к которой прицепить диск от исходной ВМ.

Не так давно компания VMware выпустила интересный документ "VMware Virtual SAN 6.0 Proof of Concept Guide", который позволяет представить себе в голове план пошаговой имплементации решения VSAN во всех его аспектах (хосты ESXi, настройка сети, тестирование решения, производительность, средства управления и т.п.).

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

Основные разделы документа освещают следующие темы:

• Подготовительные работы
• Настройка сетевого взаимодействия
• Включение функций кластера хранилищ
• Функциональность платформы VMware vSphere при операциях в кластере VSAN
• Масштабирование кластера VSAN на несколько узлов
• Политики хранилищ
• Мониторинг состояния кластера
• Тестирование производительности
• Симуляция аппаратных отказов и тестирование поведения кластера
• Управление кластером Virtual SAN

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

Скачать "VMware Virtual SAN 6.0 Proof of Concept Guide" можно по этой ссылке.

Недавно компания VMware выпустила очень интересный документ "What’s New in VMware vSphere 6 - Performance", в котором рассказывается о том, какие улучшения были сделаны в новой версии vSphere 6.0, касающиеся различных аспектов производительности платформы (вычислительные ресурсы, хранилища и сети).

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

Например, вот сводная картинка улучшения производительности vCenter (версия 6.0 против 5.5) при тяжелых нагрузках на Microsoft SQL Server 2012 в зависимости от числа объектов, которые находятся под управлением сервиса (размер Inventory). Данные приведены в количестве операций в минуту. Результаты впечатляют:

Улучшения кластеров отказоустойчивых хранилищ VMware Virtual SAN (результаты по конфигурации All-Flash еще не обработаны):

С точки зрения производительности виртуальных сетевых адаптеров VMXNET 3, платформа vSphere 6.0 научилась выжимать из них более 35 гигабит в секунду при работе с физическими адаптерами 40 GbE:

Ну и в целом в документе есть еще много чего интересного - скачивайте.

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

Вот способ сделать security banner для VMware ESXi. В VMware vSphere он бывает двух видов:

1. Login banner

Это текст, который показывается после ввода имени пользователя, но до ввода пароля:

Чтобы его поменять нужно залогиниться на хост VMware ESXi и с помощью редактора vi или nano отредактировать следующий файл:

# vi /etc/issue

Нажмите клавишу <i>, чтобы перейти в режим редактирования. После того, как вы внесете нужные изменения, нажмите <esc> и потом напишите ZZ, после чего нажмите ввод, чтобы сохранить изменения. Затем перезагрузите демон SSH следующей командой:

# /etc/init.d/SSH restart

2. Баннер MOTD.

Это баннер, который показывают пользователю после успешного логина по SSH. Чтобы задать его (по умолчанию он пустой), нужно отредактировать следующий файл через vi:

# vi /etc/motd

Также можно не лазить на хост VMware ESXi, а открыть vSphere Web Client, перейти в Manage->Settings и в разделе Advanced System Settings поискать по строчке "etc.". Там будет 2 параметра:

• Config.Etc.issue - это текст для security banner
• Config.Etc.motd - текст для баннера motd

То же самое можно сделать и в толстом клиенте vSphere Client:

Время от времени у пользователей VMware vSphere возникает ошибка, связанная с тем, что виртуальный диск VMDK виртуальной машины оказывается залоченным (то есть эксклюзивно используемым процессом VMX одного из хостов ESXi). В этом случае виртуальная машина не отвечает на попытки включить ее или переместить на другой хост-сервер средствами VMware vMotion. При этом процесс vmx вполне может быть запущен не на том хосте ESXi, на котором машина отображается в VMware vSphere Client или Web Client. Такое может случиться при падении хоста ESXi, массовом отключении питания или неполадках в сети SAN, а также и в некоторых других случаях.

Например, может быть вот такое сообщение об ошибке при включении машины:

Could not power on VM: Lock was not free

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

Делается это следующим образом:

1. Находим хост, исполняющий vmx-процесс виртуальной машины с залоченным VMDK.

Для этого заходим по SSH на один из серверов ESXi (эта процедура работает для версий vSphere 5.5 P05 и 6.0, а также более поздних) и переходим в папку /bin:

#cd /bin

С помощью утилиты vmfsfilelockinfo ищем владельца лока нужного VMDK-файла:

~ # vmfsfilelockinfo -p /vmfs/volumes/iscsi-lefthand-2/VM1/vm1.vmdk -v 192.168.1.10 -u administrator@vsphere.local

Здесь vm1.vmdk - наш залоченный виртуальный диск, а 192.168.1.10 - IP-адрес сервера VMware vCenter. Вам потребуется ввести пароль его администратора.

Вывод будет примерно таким:

vmfsflelockinfo Version 1.0
Looking for lock owners on "VM1_1-000001-delta.vmdk"
"VM1_1-000001-delta.vmdk" is locked in Exclusive mode by host having mac address ['00:50:56:03:3e:f1']
Trying to make use of Fault Domain Manager
----------------------------------------------------------------------
Found 0 ESX hosts using Fault Domain Manager.
----------------------------------------------------------------------
Could not get information from Fault domain manager
Connecting to 192.168.1.10 with user administrator@vsphere.local
Password: xXxXxXxXxXx
----------------------------------------------------------------------
Found 3 ESX hosts from Virtual Center Server.
----------------------------------------------------------------------
Searching on Host 192.168.1.178
Searching on Host 192.168.1.179
Searching on Host 192.168.1.180
MAC Address : 00:50:56:03:3e:f1

Host owning the lock on the vmdk is 192.168.1.180, lockMode : Exclusive

Total time taken : 0.27 seconds.

Из вывода можно понять 2 важные вещи:

• MAC-адрес хоста, залочившего VMDK
• IP-адрес хоста, залочившего VMDK
• Тип лока - Exclusive

Кстати, лок может быть нескольких типов:

• mode 0 - нет лока
• mode 1 - эксклюзивный лок (vmx-процесс машины существует и использует VMDK-диск)
• mode 2 - лок только для чтения (например, для основного диска, в случае если у него есть снапшоты)
• mode 3 - лок для одновременной записи с нескольких хостов (например, для кластеров MSCS или ВМ, защищенных технологией VMware Fault Tolerance).

Более подробно об этом написано в KB 2110152.

2. Точно определяем хост, машина которого держит VMDK.

Если IP-адрес показан - хост определен. Если, мало ли, по какой-то причине его нет, можно ориентироваться на MAC-адрес. Выяснить его можно следующей командой на хосте ESXi:

# vim-cmd hostsvc/net/info | grep "mac ="

3. Обнаруживаем процесс VMX, который держит VMDK.

Выполняем на найденном ESXi команду:

# lsof | egrep 'Cartel|vm1.vmdk'

Получаем что-то вроде этого:

Cartel | World name | Type | fd | Description
36202 vmx FILE 80 /vmfs/volumes/556ce175-7f7bed3f-eb72-000c2998c47d/VM1/vm1.vmdk

Мы нашли Cartel ID нужного процесса VMX (36202). Теперь выполняем команду, чтобы найти ее World ID:

# esxcli vm process list

Получаем такой вывод:

Alternate_VM27
World ID: 36205
Process ID: 0
VMX Cartel ID: 36202
UUID: 56 4d bd a1 1d 10 98 0f-c1 41 85 ea a9 dc 9f bf
Display Name: Alternate_VM27
Config File: /vmfs/volumes/556ce175-7f7bed3f-eb72-000c2998c47d/Alternate_VM27/Alternate_VM27.vmx


Alternate_VM20
World ID: 36207
Process ID: 0
VMX Cartel ID: 36206
UUID: 56 4d bd a1 1d 10 98 0f-c1 41 85 ea a5 dc 94 5f
Display Name: Alternate_VM20
Config File: /vmfs/volumes/556ce175-7f7bed3f-eb72-000c2998c47d/Alternate_VM20/Alternate_VM20.vmx
...

Видим, что World ID нашей машины - 36205.

4. Убиваем VMX-процесс, залочивший VMDK.

Ну и убиваем зависший процесс VMX следующей командой:

# esxcli vm process kill --type force --world-id <ID>

После этого с машиной и ее диском можно делать уже что требуется.

Также для более ранних версий VMware vSphere посмотрите нашу статью вот здесь.

Если вы администратор платформы виртуализации VMware vSphere, то, наверное, часто замечали, что в некоторых случаях при операциях с виртуальными машинами и ее дисками происходит "подмораживание" ВМ (или "stun", он же "quiescence"). В этот момент виртуальная машина ничего не может делать - она недоступна для взаимодействия (в консоли и по сети), а также перестает на небольшое время производить операции ввода-вывода. То есть, ее исполнение ставится на паузу на уровне инструкций, а на уровне ввода-вывода совершаются только операции, касающиеся выполняемой задачи (например, закрытие прежнего VMDK-диска и переключение операций чтения-записи на новый диск при операциях со снапшотами).

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

Когда может возникать stun виртуальной машины? Есть несколько таких ситуаций.

1. Во время операции "suspend" (постановка ВМ на паузу). Тут происходит такое подмораживание, чтобы скинуть память ВМ на диск, после чего перевести ее в приостановленное состояние.

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

3. Консолидация снапшотов (удаление всех). Здесь тоже нужно "склеить" все VMDK-диски (предварительно закрыв) и начать работать с основным диском ВМ. А вот удаление снапшота в цепочке stun не вызывает, так как не затрагивает VMDK, в который сейчас непосредственно идет запись.

4. Горячая миграция vMotion. Сначала память передается от одной машины к целевой ВМ без подмораживания, но затем происходит такой же stun, как и при операции suspend, с тем только отличием, что маленький остаток памяти (минимальная дельта) передается не на диск, а по сети. После этого происходит операция resume уже на целевом хосте. Пользователь этого переключения, как правило, не замечает, так как время этого переключения очень жестко контролируется и чаще всего не достигает 1 секунды. Если память гостевой ОС будет меняться очень быстро, то vMotion может затянуться именно во время этого переключения (нужно передать последнюю дельту).

5. Горячая миграция хранилищ Storage vMotion. Здесь stun случается аж дважды: сначала vSphere должна поставить Mirror Driver, который будет реплицировать в синхронном режиме операции ввода-вывода на целевое хранилище. При постановке этого драйвера происходит кратковременный stun (нужно также закрыть диски). Но и при переключении работы ВМ на второе хранилище происходит stun, так как нужно удалить mirror driver, а значит снова переоткрыть диски уже на целевом хранилище.

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

Не так давно мы писали о том, что компания VMware выпустила бета-версию своего основного руководства по обеспечению информационной безопасности виртуальной инфраструктуры vSphere 6.0 Hardening Guide. На днях же вышла финальная версия этого документа. Надо отметить, что документ весьма сильно поменялся по структуре и содержанию:

Согласно записи в блоге VMware, в данной версии руководства были сделаны следующие позитивные изменения:

• Сделан упор на автоматизацию воплощения рекомендаций через API, чтобы доставить меньше хлопот по ручному конфигурированию настроек. Приводятся конкретные команды PowerCLI и vCLI для исследования конфигураций и задания необходимых параметров.
• В качестве рекомендуемого значения добавлен параметр "site-specific", что означает, что конкретная имплементация данной настройки зависит от особенностей инфраструктуры пользователя.
• Появилась колонка с разносторонним обсуждением проблемы потенциальной уязвимости (с учетом предыдущего пункта).
• Дается больше информации о потенциальных рисках - на что влияет данная настройка в итоге.

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

• vSphere 4.0
• vSphere 4.1
• vSphere 5.0

• vSphere 5.1 Hardening Guide
• vSphere 5.1 Hardening Guide Change Log

• vSphere 5.5 Hardening Guide
• vSphere 5.5 Hardening Guide Change Log

• vSphere 5.5 Update 1 Hardening Guide
• vSphere 5.5 Update 1 Hardening Guide Change Log

• vSphere 6.0 - Moved to Documentation from Hardening Guide
• vSphere 6.0 Hardening Guide

• vRealize Configuration Manager PDF
• vRealize Automation (последний документ внизу)
• vCloud Director 1.5

Ну и надо обязательно добавить, что VMware Configuration Manager теперь полностью поддерживает конфигурации из руководства vSphere 6 Hardening Guide. Более подробно об этом написано в блоге VMware Security.

В новой версии VMware vSphere 6 для хостов ESXi было сделано следующее нововведение в плане безопасности - теперь после 10 неудачных попыток входа наступает блокировка учетной записи (account lockout), которая длится 2 минуты.

Этот эффект наблюдается теперь при логине через SSH, а также при доступе через vSphere Client (ну и в целом через vSphere Web Services SDK). При локальном доступе через DCUI (напрямую из консоли) такого нет.

Сделано это понятно зачем - чтобы никто не перебирал пароли рута брутфорсом.

Отрегулировать настройки блокировки можно в следующих параметрах Advanced Options хоста ESXi:

• Security.AccountLockFailures - максимальное число попыток входа, после которого аккаунт блокируется. Если поставить 0, то функция локаута будет отключена.

• Security.AccountUnlockTime - число секунд, на которое блокируется аккаунт.

Ну и напомню, что мы также писали о том, как установить таймаут сессии по SSH или ESXi Shell, а также таймаут сессии vSphere Web Client.

Многие из вас знакомы с продуктом VMware Site Recovery Manager, который позволяет построить катастрофоустойчивую виртуальную инфраструктуру за счет репликации виртуальных машин на хосты резервной площадки, помещения или стойки. Как известно, VMware SRM может использовать два типа репликации:

• Array Based Replication - репликация уровня массива, котора требует наличия соответствующего типа дискового массива на основной и резервной площадке, канала репликации, а также, собственно, программного продукта, который реализует эту репликацию. Как правило, данный тип представляет собой синхронную репликацию с возможностью быстрого переключения на резервную инфраструктуру в случае сбоя без потери данных.
• vSphere Replication - репликация уровня массива, которая не требует ничего кроме сетевого соединения между площадками, но она происходит в асинхронном режиме, а значит возможна потеря данных в случае сбоя.

Давайте попробуем рассмотреть особенность обоих методов репликации в таблице:

Также при использовании репликации уровня дискового массива рекомендуется прочитать документацию к соответствующему компоненту SRA (storage replication adapter).

Компания VMware в своем блоге затронула интересную тему - обновление микрокода для процессоров платформ Intel и AMD в гипервизоре VMware ESXi, входящем в состав vSphere. Суть проблемы тут такова - современные процессоры предоставляют возможность обновления своего микрокода при загрузке, что позволяет исправлять сделанные вендором ошибки или устранять проблемные места. Как правило, обновления микрокода идут вместе с апдейтом BIOS, за которые отвечает вендор процессоров (Intel или AMD), а также вендор платформы (HP, Dell и другие).

Между тем, не все производители платформ делают обновления BIOS своевременно, поэтому чтобы получить апдейт микрокода приходится весьма долго ждать, что может быть критичным если ошибка в текущей версии микрокода весьма серьезная. ESXi имеет свой механизм microcode loader, который позволяет накатить обновления микрокода при загрузке в том случае, если вы получили эти обновления от вендора и знаете, что делаете.

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

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

Есть два способа обновить микрокод процессоров в ESXi - через установку VIB-пакета и через обновление файлов-пакетов микрокода на хранилище ESXi. Если вы заглянете в папку /bootbank, то увидите там такие файлы:

• uc_amd.b00
• uc_intel.b00

Эти файлы и содержат обновления микрокода и идут в VIB-пакете cpu-microcode гипервизора ESXi. Ниже опишем процедуру обновления микрокода для ESXi с помощью обоих методов. Предпочтительный метод - это делать апдейт через VIB-пакет, так как это наиболее безопасно. Также вам потребуется Lunix-машина для манипуляций с микрокодом. Все описанное ниже вы делаете только на свой страх и риск.

1. Скачиваем обновления микрокода.

Можно воспользоваться вот этими ссылками:

• Intel microcode download
• AMD microcode download

Для Intel выполните команду:

tar -zxf microcode-*.tgz

После распаковки вы получите файл microcode.dat. Это файл в ASCII-формате, его надо будет преобразовать в бинарный. У AMD в репозитории есть сразу бинарные файлы (3 штуки, все нужные).

2. Делаем бинарный пакет микрокода.

Создаем следующий python-скрипт и называем его intelBlob.py:

#! /usr/bin/python
# Make a raw binary blob from Intel microcode format.
# Requires Python 2.6 or later (including Python 3)
# Usage: intelBlob.py < microcode.dat microcode.bin

import sys

outf = open(sys.argv[1], "wb")

for line in sys.stdin:
if line[0] == '/':
continue
hvals = line.split(',')
for hval in hvals:
if hval == '\n' or hval == '\r\n':
continue
val = int(hval, 16)
for shift in (0, 8, 16, 24):
outf.write(bytearray([(val >> shift) & 0xff]))

Далее создаем бинарники микрокода. Для Intel:

cat intel/*.dat | ./intelBlob.py uc_intel
gzip uc_intel

Для AMD:

cat amd/*.bin > uc_amd
gzip uc_amd

3. Метод замены файлов с апдейтом микрокода.

Тут все просто. Выполним одну из следующих команд для полученных файлов:

• cp uc_intel.gz /bootbank/uc_intel.b00
• cp uc_amd.gz /bootbank/uc_amd.b00

Далее можно переходить к шагу 5.

4. Метод создания VIB-пакета и его установки.

Тут нужно использовать утилиту VIB Author, которую можно поставить на Linux-машину (на данный момент утилита идет в RPM-формате, оптимизирована под SuSE Enterprise Linux 11 SP2, который и предлагается использовать). Скачайте файл cpu-microcode.xml и самостоятельно внесите в него изменения касающиеся версии микрокода.

Затем делаем VIB-пакет с помощью следующей команды:

vibauthor -c -d cpu-microcode.xml \
-p uc_intel.gz,boot,uc_intel,200 \
-p uc_amd.gz,boot,uc_amd,201

Если в VIB-файл не нужно включать микрокод от одного из вендоров CPU - просто уберите часть команды с "-p".

Далее устанавливаем VIB через esxcli:

esxcli software acceptance set --level=CommunitySupported
esxcli software vib install \
-v file:/vmfs/volumes/datastore1/cpu-microcode-6.0.0-0.test.0.vib

Затем проверьте наличие файлов uc_*.b00, которые вы сделали на шаге 2, в директории /altbootbank.

5. Тестирование.

После перезагрузки хоста ESXi посмотрите в лог /var/log/vmkernel.log на наличие сообщений MicrocodeUpdate. Также можно посмотреть через vish в файлы /hardware/cpu/cpuList/*, в которых где-то в конце будут следующие строчки:

Number of microcode updates:1
Original Revision:0x00000011
Current Revision:0x00000017

Это и означает, что микрокод процессоров у вас обновлен. ESXi обновляет микрокод всех процессоров последовательно. Вы можете проверит это, посмотрев параметр Current Revision.

Также вы можете запретить на хосте любые обновления микрокода, установив опцию microcodeUpdate=FALSE в разделе VMkernel boot. Также по умолчанию запрещено обновление микрокода на более ранние версии (даунгрейд) и на экспериментальные версии. Это можно отключить, используя опцию microcodeUpdateForce=TRUE (однако микрокод большинства процессоров может быть обновлен только при наличии цифровой подписи вендора). Кроме того, чтобы поставить экспериментальный апдейт микрокода, нужно включить опции "debug mode" или "debug interface" в BIOS сервера, после чего полностью перезагрузить его.

Как вы все знаете, недавно вышла платформа виртуализации VMware vSphere 6.0, и мы много писали о ее новых возможностях. На одном из блогов появились полезные таблички, в которых просто и понятно описаны численные и качественные улучшения VMware vSphere 6.0 по сравнению с прошлыми версиями - 5.1 и 5.5. Приведем их тут.

Улучшения гипервизора VMware ESXi:

Улучшения на уровне виртуальных машин:

Улучшения на уровне средства управления VMware vCenter:

Мы уже упоминали компанию opvizor на нашем сайте - она тогда называлась еще Icomasoft. Она время от времени делает утилитки для виртуальной инфраструктуры. Оказалось у нее есть могущая оказаться полезной многим утилита Snapwatcher Enterprise Edition.

Как знают администраторы VMware vSphere, снапшоты виртуальных машин в большой виртуальной инфраструктуре - это просто беда. Они плодятся неаккуратными пользователями и администраторами, создаются пачками в тестовых системах и почему-то иногда не удаляются средствами резервного копирования. Для решения таких проблем и предлагается использовать Snapwatcher:

Что умеет Snapwatcher:

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

Как это работает:

Сам продукт Snapwatcher платный ($200 за лицензию на пользователя), но у него есть триальная версия. А так как в большинстве случаев проблема со снапшотами в виртуальной среде - разовая, то можно скачать Snapwatcher бесплатно и все пофиксить.

Вскоре после выхода платформы виртуализации VMware vSphere 6.0 компания VMware выпустила апрельский патч VMware ESXi 6.0 (Build 2615704). Обновление ESXi600-201504001 описано в KB 2111975. В данном билде есть только исправления багов, его статус - Critical.

Какие ошибки были исправлены:

• Выпадение в "розовый экран смерти" при промотке логов хоста через прямое подключение к консоли сервера - DCUI (по комбинации клавиш ALT+F12).
• Stateless-хосты VMware ESXi (бездисковые, загруженные в память) могут упасть при применении профиля из VMware Host Profiles (с ошибкой A specified parameter was not correct: dvsName).
• Производительность виртуальной машины с ОС Windows, для которой включена технология Fault Tolerance, может неожиданно сильно упасть.
• Баг с непредоставлением сервером vCenter лицензии stateless-хосту.
• Когда у вас много виртуальных машин с небольшой памятью (< 128 МБ), в процессе NUMA remapping может выскочить "розовый экран смерти".

Как мы видим, баги в ESXi 6.0 еще есть, и пока некуда торопиться с обновлением с версий 5.x.

Скачать апрельский патч VMware ESXi 6.0 (Build 2615704) можно с VMware Patch Portal, введя номер билда в поиск.

Какое-то время назад мы писали о том, что на сайте проекта VMware Labs доступен пакет VMware Tools для виртуальных серверов VMware ESXi, работающих как виртуальные машины. В версии VMware vSphere 6 этот пакет по умолчанию уже вшит в ESXi 6.0, и ничего ставить дополнительно не нужно:

Это можно также просто проверить с помощью консольной команды:

Как вы знаете, в обновленной версии платформы виртуализации VMware vSphere 6.0 появились не только новые возможности, но и были сделаны существенные улучшения в плане производительности (например, вот).

В компании VMware провели тест, использовав несколько виртуальных машин с базами данных SQL Server, где была OLTP-модель нагрузки (то есть большой поток небольших транзакций). Для стресс-теста БД использовалась утилита DVD Store 2.1. Архитектура тестовой конфигурации:

Сначала на хосте с 4 процессорами (10 ядер в каждом) запустили 8 виртуальных машин с 8 vCPU на борту у каждой, потом же на хосте 4 процессорами и 15 ядер в каждом запустили 8 ВМ с 16 vCPU. По количеству операций в минуту (Operations per minute, OPM) вторая конфигурация показала почти в два раза лучший результат:

Это не совсем "сравнение яблок с яблоками", но если понимать, что хосты по производительности отличаются не в два раза - то результат показателен.

Интересен также эксперимент с режимом Affinity у процессоров для "большой" виртуальной машины. В первом случае машину с 60 vCPU привязали к двум физическим процессорам хоста (15 ядер на процессор, итого 30 ядер, но использовалось 60 логических CPU - так как в каждом физическом ядре два логических).

Во втором же случае дали машине те же 60 vCPU и все оставили по дефолту (то есть позволили планировщику ESXi шедулить исполнение на всех физических ядрах сервера):

Результат, как мы видим, показателен - физические ядра лучше логических. Используйте дефолтные настройки, предоставьте планировщику ESXi самому решать, как исполнять виртуальные машины.

Больше информации об этом тесте можно узнать из документа "Performance Characterization of Microsoft SQL Server on VMware vSphere 6".