Компания VMware в последние несколько месяцев постоянно работает над тонкими клиентами для управления виртуальной инфраструктурой VMware vSphere: ESXi Embedded Host Client для управления отдельными хостами vSphere и HTML5 Web Client для управления виртуальным датацентром через vCenter. Напомним, что совсем недавно мы писали про HTML5 Web Client версий 1.8 и 1.9, а на днях вышли обновления HTML5 Web Client 1.10 и 1.11.

Новые возможности веб-клиентов версий 1.10 и 1.11:

• Мастер добавления виртуального хранилища VMFS.
• Просмотр информации о сетевом экране и сервисах хоста ESXi.
• Возможность апгрейда VMware Tools (только в интерактивном режиме).
• Просмотр деталей адаптеров VMkernel.
• Возможность выбрать политику хранилищ (storage policy) при редактировании размещения виртуального диска.
• Возможность выбрать любое расположение виртуального диска при создании виртуальной машины.
• Редактируемые настройки DRS.
• При создании ВМ можно выбрать SDRS-рекомендации, даже если SDRS пока отключен.
• Возможность управления алармами на вкладке Alarms внизу.
• Упрощенная процедура апгрейда Web Client.

Видно, что работа кипит, но видно также, что и осталось работы достаточно много - а до релиза новой версии vSphere нужно успеть выпустить финальную версию веб-клиента, так как толстого C#-клиента уже не будет.

Скачать VMware HTML5 Web Client 1.11 можно по этой ссылке.

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

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

DRS Doctor соединяется с vCenter и отслеживает действия, которые происходят в кластере DRS, в реальном времени. Самое интересное, что утилита выводит причину для каждой миграции DRS, что раньше было доступно только в файлах дампов. Так можно узнать, чем руководствуется DRS при выборе хоста для vMotion виртуальных машин между ними.

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

Утилита поставляется в качестве средства командной строки для Linux. Для работы вам понадобится установленный Python. Инструкции по установке на CentOS доступны здесь, а скачать DRS Doctor можно по этой ссылке.

Не так давно компания VMware выпустила интересный и полезный документ, который пригодится очень многим Enterprise-администраторам виртуальной инфраструктуры - "Oracle Databases on VMware Best Practices Guide".

Как и остальные документы серии Best Practices Guide, данный документ предоставляет вполне конкретные рекомендации и лучшие практики по эксплуатации СУБД Oracle на платформе VMware vSphere.

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

• VMware Support for Oracle Databases on vSphere - рассказывает о политиках поддержки СУБД Oracle на платформе vSphere.
• Server Guidelines - рекомендации по выбору и конфигурации серверов.
• Virtual CPU Guidelines - как правильно сайзить виртуальные процессоры ВМ.
• Memory Guidelines - лучшие практики по использованию оперативной памяти (что очень важно для баз данных).
• Storage Guidelines - как правильно выбирать тип хрананилища, настраивать его и правильно эксплуатировать (в том числе Virtual SAN).
• Networking Guidelines - лучшие практики по конфигурации сетевого взаимодействия (виртуальные коммутаторы, сетевые адаптеры и т.п.).
• Guest Operating System Guidelines - как правильно настроить гостевую ОС, чтобы база данных работала быстро.
• Database Guidelines - общие принципы правильной архитектуры решений Oracle на платформе vSphere.
• ESXTOP/rESXTOP - средства мониторинга производительности серверов.
• Backup and Recovery - резервное копирование и восстановление, а также защита данных.
• High Availability - обеспечение высокой доступности и средства отказоустойчивости.
• Disaster Recovery - восстановление после масштабных сбоев с помощью решений vSphere Replication, SRM и прочих.
• VMware Engineered Systems - использование готовых референсных архитектур (например, EVO:RAIL) для организации больших инфраструктур.

Скачать "Oracle Databases on VMware Best Practices Guide" можно по этой ссылке.

На днях мы писали о том, что компания VMware выпустила релизную версию своей минимальной операционной системы Photon OS 1.0, которая предназначена для исполнения виртуальных контейнеров Docker. Многие сразу задумались о том, как дело обстоит с работой контейнеров с хранилищами своих данных.

Как раз в этой связи компания VMware выпустила технологическое превью драйвера vSphere Docker Volume Driver, позволяющего напрямую работать с виртуальными хранилищами прямо из контейнеров Docker (версии 1.9 или выше).

Архитектура решения выглядит так:

Как видно из картинки, нам потребуется установить Volume Driver на серверы VMware ESXi, а также плагины vSphere Docker Volume Plugin на виртуальные машины Docker Host, где будут исполняться наши контейнеры. Также мы видим, что в качестве хранилищ поддерживаются практически все, что поддерживает платформа vSphere: тома VMFS (локальные и общие), NFS-хранилища, а также тома Virtual SAN (и соответственно их политики по обеспечению избыточности данных в целях отказоустойчивости).

Рассмотрим развертывание решения vSphere Docker Volume Driver по шагам.

1. На серверы VMware ESXi 6.0 или выше устанавливается компонент vSphere Data Volume Driver в виде обычного VIB-пакета.

Делается это примерно так:

[root@esxi-hp-08:~] esxcli software vib install \

  -d "/vmfs/volumes/569c904a-8880cc78-a5c7-a0369f56ddc0/\

  vmdkops/vmware-esx-vmdkops-0.1.0.tp.zip" --no-sig-check -f

  Installation Result

Message: Operation finished successfully.

Reboot Required: false

VIBs Installed: VMWare_bootbank_esx-vmdkops-service_1.0.0-0.0.1

VIBs Removed:

VIBs Skipped:

[root@esxi-hp-08:~]

Предварительно нужно загрузить драйвер по этой ссылке.

2. Проверяем статус установленных пакетов.

[root@esxi-hp-08:~] /etc/init.d/vmdk-opsd status

  vmdkops-opsd is running pid=12343527

[root@esxi-hp-08:~]

3. Развертываем Photos OS, которая будет служить нам как Docker Host.

Скачать Photon OS можно по этой ссылке.

4. Устанавливаем VMDK Plugin (Docker Volume Plugin) на хост ESXi.

Проверяем версию Docker:

root@photon-machine [ ~ ]# docker version

  Client:

Version:      1.11.0

API version:  1.23

Go version:   go1.5.4

Git commit:   4dc5990

Built:        Wed Apr 13 19:36:04 2016

OS/Arch:      linux/amd64

Server:

  Version:      1.11.0

  API version:  1.23

  Go version:   go1.5.4

  Git commit:   4dc5990

  Built:        Wed Apr 13 19:36:04 2016

  OS/Arch:      linux/amd64

  root@photon-machine [ ~ ]# 

  Install the RPM (I’ve used “-U” out of habit, but “-i” can also be used):

Устанавливаем RPM-пакет с плагином в гостевую ОС:

root@photon-machine [ ~ ]# ls

  docker-volume-vsphere-0.1.0.tp-1.x86_64.rpm

  root@photon-machine [ ~ ]# rpm -Uvh docker-volume-vsphere-0.1.0.tp-1.x86_64.rpm

  Preparing...                          ################################# [100%]

  Updating / installing...

  1:docker-volume-vsphere-0:0.1.0.tp-################################# [100%]

  File: '/proc/1/exe' -> '/usr/lib/systemd/systemd'

  Created symlink from /etc/systemd/system/multi-user.target.wants/\

docker-volume-vsphere.service to /usr/lib/systemd/system/docker-volume-vsphere.service.

5. Проверяем статус плагина:

root@photon-machine [ ~ ]# systemctl status docker-volume-vsphere

  * docker-volume-vsphere.service - "Docker Volume Driver for vSphere"

Loaded: loaded (/usr/lib/systemd/system/docker-volume-vsphere.service;\

enabled; vendor preset: enabled)

Active: active (running) since Mon 2016-05-30 09:04:21 UTC; 28s ago

Main PID: 256 (docker-volume-v)

CGroup: /system.slice/docker-volume-vsphere.service

`-256 /usr/local/bin/docker-volume-vsphere

May 30 09:04:21 photon-machine systemd[1]: Started "Docker Volume Driver\

  for....

  Hint: Some lines were ellipsized, use -l to show in full.

  root@photon-machine [ ~ ]#

6. Создаем том для использования его контейнером.

root@photon-machine [ ~ ]# docker volume create --driver=vmdk \

  --name=MyVolume -o size=20gb

MyVolume

7. Проверяем созданный том.

root@photon-machine [ ~ ]# docker volume ls

  DRIVER              VOLUME NAME

vmdk                MyVolume

root@photon-machine [ ~ ]#

8. Смотрим детали.

root@photon-machine [ ~ ]# docker volume inspect MyVolume

  [

  {

  "Name": "MyVolume",

  "Driver": "vmdk",

  "Mountpoint": "/mnt/vmdk/MyVolume",

  "Labels": {}

  }

  ]

root@photon-machine [ ~ ]#

9. Теперь с машины с Photon OS запустим контейнер с образом Ubuntu внутри и направим его хранилище к только что созданному.

root@photon-machine [ ~ ]# docker run -it -v MyVolume:/MyVolume ubuntu bash

  root@bd9410fb4c1d:/# ls

  Myvolume  bin  boot  dev  etc  home  lib  lib64  media  mnt  opt  proc  \

  root  run  sbin  srv  sys  tmp  usr  var

  root@fe8c21d003fa:/# df

  Filesystem                                      1K-blocks    Used Available Use% Mounted on

  overlay                                           8122788 6095776   1591356  80% /

  tmpfs                                             4085412       0   4085412   0% /dev

  tmpfs                                             4085412       0   4085412   0% /sys/fs/cgroup

  /dev/disk/by-path/pci-0000:0b:00.0-scsi-0:0:0:0  20642428   44992  19548860   1% /MyVolume

  /dev/root                                         8122788 6095776   1591356  80% /etc/hosts

  shm                                                 65536       0     65536   0% /dev/shm

  root@fe8c21d003fa:/#

  root@bd9410fb4c1d:/# cd Myvolume/

  root@bd9410fb4c1d:/Myvolume# ls

root@bd9410fb4c1d:/Myvolume#

10. Также можно создавать хранилища и на кластерах Virtual SAN.

Тома можно создавать с учетом политики FTT или QoS. Например:

docker volume create --driver=vmdk --name=vol2 -o size=20gb -o vsan-policy-name=FTT=0

11. Сами VMDK-диски с хранилищами Docker можно посмотреть в обычном браузере хранилищ.

Например, для кластера Virtual SAN их можно найти в следующем месте:

Более подробная информация о драйвере размещена тут, тут и тут (там же есть более подробная информация о его развертывании).

Мы как-то писали о технологии vSphere Integrated Containers (VIC), которая подразумевает запуск виртуализованных контейнеров Docker (и прочих) в маленьких виртуальных машинах с легковесной ОС на базе дистрибутива Linux.

Этой ОС и является VMware Photon OS 1.0, которая окончательно вышла на днях. Это первая релизная версия этой операционной системы от VMware.

При использовании Photon OS каждый контейнер исполняется в своей виртуальной машине, но не в обычной, а в созданной "на лету" с помощью технологии Instant Clone.

VMware Photon OS обеспечивает следующие возможности для контейнеров приложений (в частности, Docker):

• Средства быстрого обновления (tdnf), которые позволяют сканировать и своевременно обновлять устаревшие пакеты приложений.
• Большой набор библиотек в репозиториях, которые требуются для работы различных приложений на платформе Photon OS.
• Построенная на ядре 4.2 система Photon OS поддерживает файловую систему btrfs со всеми ее возможностями в дополнение к overlayfs.
• До 26% улучшения производительности по сравнению с бета-версиями (на базе микробенчмарков). Теперь время загрузки ядра составляет примерно 200 миллисекунд. Сама ОС занимает в оперативной памяти 384 МБ, а на диске 396 МБ.
• Очень много было сделано в плане безопасности - проведено тщательное ревью всего исходного кода Photon OS, код был проверен различными тулзами, а также привлекались сторонние компании для поиска потенциальных уязвимостей.

Также в дополнение к Photon OS стала доступной и онлайн-документация - Photon Administration Guide.

Скачать VMware Photon OS 1.0 и присоединиться к комьюнити разработчиков на GitHub можно по этой ссылке.

Посмотрите также процесс установки Photon OS от Андрея Коновалова:

Чуть больше недели назад компания VMware выпустила очередное обновление своего тонкого клиента для управления отдельными хост-серверами VMware ESXi Embedded Host Client 1.5 (на самом деле, это версия v9). Напомним, что о прошлой версии Embedded Host Client v8 мы писали вот тут (а здесь - о том, что данный клиент уже входит в стандартную поставку ESXi).

Новые возможности Host Client 1.5:

Основное:

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

Хост-сервер:

• Добавление, редактирование и удаление пользователей.
• Добавление, редактирование и удаление ролей.
• Добавление пермиссий для хост-серверов и виртуальных машин.
• Появился GUI для настройки параметров автостарта ВМ.

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

• Пофикшена проблема с нераскрывающимися комбобоксами при редактировании или создании виртуальных машин (в Safari).
• Пофикшена проблема с добавлением устройств PCI passthrough.
• Пофикшена проблема с добавлением сетевых адаптеров SR-IOV.
• Исправлена проблема с отключением горячего добавления CPU и памяти.
• Добавлен пункт меню "reset to native resolution" в браузерной консоли ВМ.
• Добавлен пункт меню для работы консоли ВМ во вкладке или полном окне.
• Исправлена проблема с экспортом виртуальных машин, которая могла приводить к нечаянному скачиванию дисковых образов. Добавили подтверждающий диалог.

Хранилища:

• Добавлена возможность поиска в таблице с iSCSI target.
• Добавлено поле ввода при создании хранилища VMFS для возможности указания точного размера раздела при кастомном разбиении диска на разделы.

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

• Исправлено много ошибок, которые проявлялись при редактировании правил фаервола.
• Добавлена поддержка средств балансировки NIC teaming и управления полосой канала (traffic shaping) для виртуальных коммутаторов vSwitch и их портгрупп.

Скачать последнюю версию VMware ESXi Embedded Host Client 1.5 можно по этой ссылке.

Некто 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). В принципе, ничто вам не мешает воспользоваться обоими калькуляторами и сравнить результаты, которые должны, по идее, более-менее сходиться.

Совсем недавно мы писали о новых возможностях vSphere HTML5 Web Client версий 1.6 и 1.7, а на днях подоспели уже адейты 1.8 и 1.9. Видно, что VMware очень торопится, чтобы успеть доработать тонкий клиент перед полным списанием vSphere C# Client в следующей версии платформы vSphere.

Давайте взглянем на новые возможности VMware vSphere HTML5 Web Client 1.8 и 1.9:

• Теперь можно просматривать и редактировать настройки кластера VMware DRS и DPM.
• Можно просматривать настройки heartbeat datastores и механизма VMware HA admission control.
• На уровне кластера можно просматривать и редактировать совместимость ВМ по умолчанию.
• Мастер добавления хоста приобрел раздел настроек режима lockdown mode.
• При добавлении хоста в кластер теперь можно создавать новый пул ресурсов с виртуальными машинами этого хоста.
• Алармы теперь отображаются в нижней панели, что освободило место в центре.
• Возможность монтирования установщика VMware Tools в ВМ.
• При создании виртуальной машины в кластере DRS можно выбрать различные рекомендации кластера хранилищ (datastore cluster recommendations).
• При клонировании ВМ можно отключить Storage DRS (SDRS).
• Мастер добавления отдельного хоста ESXi теперь позволяет выбрать размещение виртуальных машин.

Также было сделано множество мелких улучшений и исправлений ошибок. Скачать VMware vSphere HTML5 Web Client 1.9 можно по этой ссылке.

Интересный пост о технологии VVols появился на блогах VMware. Дескать, их часто спрашивают - почему средства балансировки нагрузки на хранилища Storage DRS не поддерживаются для томов VVols?

Для ответа на этот вопрос надо рассмотреть, как работает традиционная архитектура хранилищ, которая была до VVols и кластеров Virtual SAN. Обычный дисковый массив или хост можно представить набором носителей двух типов (HDD и Flash), которые дают суммарно некоторую емкость.

Например, у нас 160 ТБ на СХД, которые мы разбиваем на LUN по 8 ТБ, итого получая 20 томов VMFS. Допустим, половина емкости у нас HDD, а половина - SSD. Тогда мы создадим 2 датастор-кластера (datastore cluster), в каждом из которых будет по 10 томов VMFS:

Кластер на SSD-носителях будет хранилищем яруса Gold, а HDD - Silver. Технология Storage DRS предназначена, чтобы балансировать виртуальные машины в рамках яруса между LUN для обеспечения их равномерной загрузки, как по емкости, так и по вводу-выводу. А в случае необходимости машину можно также и перенести между ярусами (Silver->Gold) с помощью технологии Storage vMotion.

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

В случае же с VVols дело обстоит совсем иначе: на все хранилище создается один Storage Container, который объединяет собой все 160 ТБ доступной емкости - и Flash, и HDD. И этот контейнер представляет собой единственный объект для хранения виртуальных машин с томами VVols:

То есть все операции по балансировке данных виртуальных машин (на уровне дисковых объектов VVols) передаются на сторону СХД, которая лучше знает, как правильно распределять данные и обеспечивать необходимый уровень обслуживания на базе политик (Storage Policies), привязанных к ярусам. Это, конечно же, требует некоторой работы со стороны производителей систем хранения, зато избавляет от забот саму VMware, которая универсализовала технологию VVols и средства работы с ней.

То есть, VVols не требует наличия Storage DRS - технологии, которая уйдет со временем на уровне отдельных аппаратных хранилищ, но будет полезной для балансировки в среде, где есть несколько СХД или кластеров хранилищ от одного или нескольких вендоров.

Компания VMware стремительными темпами развивает свое средство для управления виртуальной инфраструктурой vSphere через браузер на базе технологии HTML5 - VMware HTML5 Web Client. Напомним, что недавно было окончательно объявлено, что следующая версия VMware vSphere не будет иметь "толстого" клиента vSphere Client, сделанного на C#, а старый и тормозной Web Client заменят новым и, возможно, быстро работающем (хотя многие очень сомневаются в этом).

Если еще пару недель назад мы писали про VMware HTML5 Web Client версии 1.5, то до сегодняшнего дня успело выйти аж два обновления - VMware HTML5 Web Client 1.6 и 1.7.

Давайте посмотрим, что нового VMware добавила в последних версиях своего тонкого клиента к vCenter:

• Открытие консоли ВМ из контекстного меню действий.
• Миграция виртуальной машины в объект "виртуальный сервис" (vApp).
• Добавление отдельного хоста ESXi в датацентр или папку Hosts.
• Менеджер снапшотов теперь имеет древовидное представление с подробной информацией о каждом снапшоте. Пока еще менеджер снапшотов работает в режиме Read Only. При этом можно откатиться на любой выбранный снапшот.
• Выбор спецификации для кастомизации в мастере клонирования ВМ, а также возможность фильтра по гостевым ОС.
• Просмотр сообщений об ошибках для случаев, когда ВМ не может включиться в DRS-кластере.
• Для кластера VMware HA можно просматривать информацию об ответных действиях в случае сбоя.
• Возможность просмотра порт-групп для виртуальных коммутаторов.
• Было исправлено несколько серьезных ошибок.

Подробнее о новых обновлениях VMware HTML5 Web Client 1.6 и 1.7, а также загрузить последнюю актуальную версию клиента vSphere можно по этой ссылке.

Компания VMware давненько не выпускала обновления своего главного средства для управления облачной инфраструктурой VMware vSphere. Но в самом конце мая вышел долгожданный апдейт - VMware vCloud Director 8.1. Напомним, что vCloud Director - это продукт, предназначенный для сервис-провайдеров, которые продают ресурсы публичного облака по моделям IaaS/SaaS (рапространяется по программе vCloud Air Network Program).

Основная идея новой версии vCloud Director - это полная поддержка средства сетевой виртуализации корпоративной инфраструктуры VMware NSX, а также нововведения в интерфейсе, которые ранее были доступны только через API-вызовы.

Посмотрим на полный список новых возможностей VMware vCloud Director 8.1:

• Expanded UI Access to Features - поддержка функций, ранее доступных только через API, в консоли vCloud Director Web Console.
• Virtual Machine Affinity Rules - теперь через vCloud Director Web Console или через vCloud API можно задавать правила раздельного/совместного существования виртуальных машин на хостах ESXi (Affinity Rules).
• Object Extensibility - эта новая фича заключается в том, что теперь можно использовать расширения object extensions, представляющие собой внешние приложения, которые дополняют или перекрывают логику vCloud Director для комплексных операций, таких как, например, развертывание виртуальных сервисов vApp.
• Advanced Virtual Machine Properties and Host Configurations - если ваш сервис-провайдер включил поддержку кастомных конфигураций ESXi-хостов, то можно использовать метаданные объектов vCenter для виртуальных машин, которые могут быть использованы, например, для корректного плейсмента ВМ на хостах.
• VDC Permissions - администраторы облака, отвечающие за конкретных клиентов, могут ограничить доступ к VDC отдельным пользователям или группам.
• Tenant throttling - администратор может ограничить объем ресурсов, который потребляет организация или пользователь. Это позволяет убедиться в том, что пользователь не выест все ресурсы в условиях нескольких одновременно запущенных долгосрочных операций.
• Unattended Installation - теперь установка возможна в автоматическом режиме с помощью заранее подготовленного сценария.
• Expanded Hardware Version and Guest OS support - теперь поддерживается обновленная версия виртуального железа Hardware Version 11, а также гостевые ОС Windows 10.
• Полная поддержка последней версии VMware NSX - теперь уже решение VMware vShied Manager не поддерживается, а пользователям vCD предлагается мигрировать на платформу NSX.

Обновиться на vCloud Director 8.1 можно только с версии 8.0 или придется ставить его заново. Скачать решение vCD можно по этой ссылке.

На сайте проекта VMware Labs появилась еще одна полезная утилита для траблшутинга инфраструктуры виртуальных ПК VMware Horizon View. Средство VMware Logon Monitor позволяет собирать необходимую для решения проблем и поддержки информацию с рабочих ПК пользователей во время их логина в свои десктопы.

По умолчанию Logon Monitor собирает следующие метрики:

• Время логина
• Время старта сессии
• Время последней синхронизации профиля
• Время загрузки командной оболочки (shell load)
• Инициализация механизма Windows Folder Redirection
• Инициализация групповых политик
• Время старта процессов Windows
• Время начала исполнения скрипта групповых политик
• Время начала исполнения сценариев PowerShell
• Использование памяти

Сопоставляя данные отметки времени, администратор инфраструктуры Horizon View может понять, на каком именно этапе возникает проблема, вызывающая задержку при начале работы пользователя со своим десктопом и приложениями. В качестве настольных ОС поддерживаются Windows 7 и Windows 10, в комментариях пишут также, что Windows 8.1 x64 не поддерживается.

В ближайшее время также ожидается поддержка утилиты VMware Logon Monitor такими продуктами VMware, как Horizon Agent, Horizon Persona Management и механизмом App Volumes.

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

Скачать VMware Logon Monitor можно по этой ссылке.

Очень часто мне, как и любому администратору виртуальной инфраструктуры 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-скрипта для описанного сценария, в котором все просто и понятно относительно того, как устанавливается рассмотренная выше расширенная настройка для вывода количества и списка виртуальных машин:

Connect-VIServer -Server 192.168.1.50 -User root -Password vmware123

$vms = Get-View -ViewType VirtualMachine -Property Name
$DCUIString = "{color:yellow}

  {esxproduct} {esxversion}
 Hostname: {hostname}

  IP: {ip}

  

  Virtual Machines: " + $vms.Count + "

  {/color}

  {color:white}

  "
foreach ($vm in $vms) {

  $DCUIString += "`t`t" + $vm.Name + "`n"

  }
Set-VMHostAdvancedConfiguration -Name Annotations.WelcomeMessage -Value $DCUIString
Disconnect-VIServer -Confirm:$false

Конечно же, если у вас много виртуальных машин на хосте, то они просто не влезут на приветственный экран ESXi, но 15 виртуальных машин у Вильяма влезли без проблем:

Кстати, если вы хотите вывести только включенные виртуальные машины, то вы можете просто добавить фильтр:

-Filter @{"Runtime.PowerState" = "PoweredOn"} 

в конце строчки, где используется командлет Get-View.

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

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

Вот эти порты, протоколы и коммуникации для компонентов NSX:

• Client PC > NSX Manager 443/TCP (NSX Manager Administrative Interface)
• Client PC > NSX Manager 80/TCP (NSX Manager VIB Access)
• ESXi Host > ESXi Host 6999/UDP (ARP on VLAN LIFs)
• ESXi Host > NSX Controller 1234/TCP (User World Agent Connection)
• ESXi Host > NSX Manager 5671/TCP (AMQP)
• ESXi Host > NSX Manager 8301, 8302/UDP (DVS Sync)
• ESXi Host > vCenter Server 80/TCP (ESXi Host Preparation)
• NSX Controller > NSX Controller 2878, 2888, 3888/TCP (Controller Cluster – State Sync)
• NSX Controller > NSX Controller 30865/TCP (Controller Cluster -State Sync )
• NSX Controller > NSX Controller 7777/TCP (Inter-Controller RPC Port)
• NSX Controller > NTP Time Server 123/TCP (NTP client connection)
• NSX Controller > NTP Time Server 123/UDP (NTP client connection)
• NSX Manager > DNS Server 53/TCP (DNS client connection)
• NSX Manager > DNS Server 53/UDP (DNS client connection)
• NSX Manager > ESXi Host 443/TCP (Management and provisioning connection)
• NSX Manager > ESXi Host 8301, 8302/UDP (DVS Sync)
• NSX Manager > ESXi Host 902/TCP (Management and provisioning connection)
• NSX Manager > NSX Controller 443/TCP (Controller to Manager Communication)
• NSX Manager > NTP Time Server 123/TCP (NTP client connection)
• NSX Manager > NTP Time Server 123/UDP (NTP client connection)
• NSX Manager > Syslog Server 514/TCP (Syslog connection)
• NSX Manager > Syslog Server 514/UDP (Syslog connection)
• NSX Manager > vCenter Server 443/TCP (vSphere Web Access)
• NSX Manager > vCenter Server 902/TCP (vSphere Web Access)
• REST Client > NSX Manager 443/TCP (NSX Manager REST API)
• vCenter Server > ESXi Host 80/TCP (ESXi Host Preparation)
• vCenter Server > NSX Manager 80/TCP (Host Preparation)
• VTEP > VTEP 8472/UDP (Transport network encapsulation between VTEPs.)

Зачастую в тестовом окружении вам нужно создать несколько томов VMFS (например, для тестирования технологии Storage DRS и создания кластера хранилищ), но диск на машине только один. В этом случае можно вручную нарезать этот диск на разделы и отформатировать их в тома VMFS 5, которые будут использоваться в качестве виртуальных хранилищ.

Для этих целей можно использовать 2 утилиты, входящие в состав VMware ESXi 6 - PartedUtil и vmkfstools. Помните, что метод, изложенный ниже, не поддерживается для производственных систем. Используйте его только в тестовом окружении!

Итак, заходим на хост ESXi, напрямую или по SSH. Сначала нужно найти имя устройства. Для этого можно воспользоваться командой:

fdisk –l

Либо для подробной информации можно взять следующую:

esxcli storage core path list

В качастве вывода мы получим что-то вроде этого:

sata.vmhba34-sata.0:0-t10.ATA_____WDC_WD10EALX2D009BA0__________________________WD2DWCATR6576288

UID: sata.vmhba34-sata.0:0-t10.ATA_____WDC_WD10EALX2D009BA0__________________________WD2DWCATR6576288

Runtime Name: vmhba34:C0:T0:L0

Device: t10.ATA_____WDC_WD10EALX2D009BA0__________________________WD2DWCATR6576288

Device Display Name: Local ATA Disk (t10.ATA_____WDC_WD10EALX2D009BA0__________________________WD2DWCATR6576288)

Adapter: vmhba34

Channel: 0

Target: 0

LUN: 0

Plugin: NMP

State: active

Transport: sata

Adapter Identifier: sata.vmhba34

Target Identifier: sata.0:0

Adapter Transport Details: Unavailable or path is unclaimed

Target Transport Details: Unavailable or path is unclaimed

Maximum IO Size: 33553920

Можно сделать это и из vSphere Client:

Далее получаем таблицу разделов следующей командой (имя диска берем из поля Device):

partedUtil getptbl "t10.ATA_____WDC_WD10EALX2D009BA0__________________________WD2DWCATR6576288"

Диск этот пуст, и мы получим примерно такой вывод:

msdos

29185 255 63 468862128

Например, вы хотите создать на этом диске 5 разделов (LUN) по 10 ГБ каждый. При размере сектора 512 байт, размер каждого такого диска будет 20971519 секторов. При этом первые 2048 секторов диска надо пропустить, чтобы оставить место под GPT-таблицу и выровнять разделы по лучшим практикам (под 512-байтные секторы).

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

P1 2048-20973567

P2 20973568-41945087

P3 41945088-62916607

P4 62916608-83888127

P5 83888128-104859647

Претворяем его в жизнь с помощью partedUtil:

partedUtil setptbl "t10.ATA_____WDC_WD10EALX2D009BA0__________________________WD2DWCATR6576288" gpt "1 2048 20973567 AA31E02A400F11DB9590000C2911D1B8 0" "2 20973568 41945087 AA31E02A400F11DB9590000C2911D1B8 0" "3 41945088 62916607 AA31E02A400F11DB9590000C2911D1B8 0" "4 62916608 83888127 AA31E02A400F11DB9590000C2911D1B8 0" "5 83888128 104859647 AA31E02A400F11DB9590000C2911D1B8 0" 

Что такое "AA31E02A400F11DB9590000C2911D1B8" в данной команде? Это GUID разделов VMFS.

Далее с помощью partedUtil getptbl или другой команды выведем список разделов и получим следующее:

gpt

  29185 255 63 468862128

  1 2048 20973567 AA31E02A400F11DB9590000C2911D1B8 vmfs 0

  2 20973568 41945087 AA31E02A400F11DB9590000C2911D1B8 vmfs 0

  3 41945088 62916607 AA31E02A400F11DB9590000C2911D1B8 vmfs 0

  4 62916608 83888127 AA31E02A400F11DB9590000C2911D1B8 vmfs 0

  5 83888128 104859647 AA31E02A400F11DB9590000C2911D1B8 vmfs 0 

Разделы созданы, осталось отформатировать их под VMFS 5. Для этого воспользуемся утилитой vmkfstools и создадим Datastore 1 на первом разделе диска:

vmkfstools -C vmfs5 -S Datastore1 t10.ATA_____WDC_WD10EALX2D009BA0__________________________WD2DWCATR6576288:1

Аналогичные действия нужно будет проделать и с оставшимися четырьмя датасторами, после чего они станут видны в клиенте vSphere. Более подробно о процедуре изложено в KB 1009829.

Компания VMware на днях распространила официальную информацию о том, что клиент vSphere Client, написанный на C#, не будет выпущен для следующей версии платформы vSphere (вероятно, седьмой). Вместо него будут использоваться средства управления на базе двух следующих веб-платформ:

• VMware Host Client (который вы знаете также как ESXi Embedded Host Client) для управления отдельными серверами ESXi через веб-интерфейс. Как многие из вас помнят, начиная с vSphere 6.0 Update 2, он включен в стандартную поставку VMware ESXi. Также он доступен и на сайте проекта VMware Labs как отдельный виртуальный модуль.

• VMware vSphere HTML5 Web Client для управления инфраструктурой виртуализации через VMware vCenter (о нем мы писали вот тут). Он построен на базе технологии HTML5 и полностью заменяет собой функционал тонкого клиента VMware vSphere Web Client, который сейчас работает на основе тормозной технологии Adobe Flex (он же Flash). Он включает в себя консоли Platform Services Controller UI и vCenter Server Appliance Management UI.

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

Самое интересное в этом то, что прямо сейчас VMware не имеет релизной версии HTML5 Web Client, а только некий продукт, находящийся в статусе Technical Preview на сайте проекта VMware Labs (который, однако, весьма часто обновляется и поддерживается). Обещают, что в новой версии платформы клиент на базе HTML5 будет уже полностью готов, и переход на него пройдет безболезненно, но мы-то с вами знаем, что это не так. Новые пользователи обязательно выступят "тестировщиками" первой версии продукта. Кроме того, каков бы ни был тонкий клиент на HTML5, он все равно не будет работать так быстро, как C#-клиент, к которому привыкли многие пользователи.

Как раз вокруг этого и развернулась нешуточная дискуссия вот в этом посте, где недовольные администраторы жалуются на поведение VMware. В частности, среди минусов приводится неунифицированная среда Host Client и HTML5 Client, возможные проблемы совместимости в разных версиях браузеров, замороченность и сложность пользовательского интерфейса Web Client и прочее. И они правы - проблемы неизбежны. Например, у меня вечером обновился Google Chrome, а утром я узнал, что управление виртуальными машинами у меня в корпоративной инфраструктуре из 1000 хостов не работает.

На сайте проекта VMware Labs появилось интересное средство - VMware GOLD vApp STIG Assessment and Remediation Tool (START), которое представлет собой Docker-контейнер, способный обследовать любую удаленную Linux-систему по протоколу Security Content Automation Protocol (SCAP) в реализации OpenSCAP и исправить найденные уязвимости согласно стандарту STIG (Security Technical Implementation Guide).

На базе преконфигуренных шаблонов утилита START может обнаруживать уязвимости в других системах, после чего к ним можно применять различные действия средствами Ansible. Вы также можете видеть результаты обследования и исправления систем (assessment reports, remediation reports и hardening reports). Отчеты имеют метку времени и детали о каждой машине для быстрой идентификации системы. Кроме того, можно проверить последние полученные отчеты на различия в соответствии, а также можно указать произвольные xml-файлы отчетов для сравнения.

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

VMware выпустила большую серию обучающих видеороликов, разъясняющих подробности работы утилиты START:

• Installation and setup
• Installing OpenSCAP on Target
• Managing STIGs
• Assessing Remote Machine Using XCCDF
• Assessing Remote Machine Using OVAL
• Remediating Remote Machine
• Hardening Remote Machine
• Viewing Historical Reports
• Getting Started in CLI Mode
• Fixing Results in CLI Mode
• Comparing Results in CLI Mode
• Полезные приемы при работе с системой START:
  • Запуск приложения в режимах User Interface mode и CLI mode одновременно.
  • Использование OpenSCAP, Ansible, xsltproc и Tomcat 7 из контейнеров с использованием всех их фич.
• Больше деталей о файле утилиты - Dockerfile - который используется для создания образа контейнера.

Срество VMware GOLD vApp STIG Assessment and Remediation Tool доступно для загрузки с GitHub по этой ссылке. Текст лицензии доступен тут.

Если вы часто заходите на хост-серверы VMware ESXi по SSH, то вам может оказаться полезным плагин sshAutoConnect для vCenter, который позволяет добавить соответствующий пункт в контекстное меню vSphere Client для хостов ESXi.

Плагин sshAutoConnect состоит из двух файлов - xml, который определяет конфигурацию плагина, и, собственно, dll-библиотека с плагином. Инсталляция плагина проста - нужно положить эти два файла в отдельную папку в папке плагинов vCenter по адресу:

C:\Program Files (x86)\VMware\Infrastructure\Virtual Infrastructure Client\Plugins

Далее просто идете в vSphere Client в раздел плагинов Plug-ins > Manage Plug-ins… и активируете плагин:

Для конфигурации используется файл sshAutoConnect.xml, выглядит он примерно так:

<?xml version="1.0" encoding="utf-8" ?>
  

  <credentials>
  

  <default>
    

    <login>root</login>
    

    <password>d3d3LnZtZHVkZS5mcg==</password>
  

  </default>
  

  <custom_servers>
    

    <server name="server-esx-01.vmdude.fr">
      <login>root</login>

      <password>d3d3Lmh5cGVydmlzb3IuZnI=</password>
    </server>
    

    <server name="server-esx-02.vmdude.fr">
      <login>root</login>
      

      <password>d3d3LnZtd2FyZS5mcg==</password>
    </server>
  

  </custom_servers>
  

</credentials>

sshAutoConnect соединяется с хостами ESXi по логину и паролю, указанному в секции <default>, но если в разделе <custom_servers> есть логин и проль для конкретного хоста - будут использованы эти данные. Пароли тут записаны в виде base64, о том, как их получать написано вот тут.

Ну и загрузить плагин sshAutoConnect вместе с исходным кодом можно с репозитория на GitHub по этой ссылке.

Какое-то время назад мы писали о том, что технология дедупликации страниц памяти Transparent Page Sharing (TPS) с приходом больших страниц памяти становится ненужной (а в последних версиях vSphere и вовсе она отключена). Но это не значит, что сейчас TPS нигде не используется совсем - ведь большие страницы, при условии недостатка ресурсов памяти на хост-сервере, гипервизор ESXi может разламывать на маленькие, после чего дедуплицировать их.

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

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

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

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

Так вот в последних версиях VMware vSphere механизм TPS работает не так просто. По умолчанию используется Salting, а в качестве этой самой соли используется UDID виртуальной машины, который всегда уникален для данного сервера vCenter. То есть перед снятием хэша со страницы памяти происходит добавление соли к исходным данным, а поскольку соль одинакова только для конкретной ВМ, то и дедупликация страниц со стороны TPS происходит только на уровне отдельной виртуальной машины (Intra-VM TPS).

Механизм Salting используется по умолчанию, начиная со следующих версий гипервизоров:

• ESXi 5.0 Patch ESXi500-201502001
• ESXi 5.1 Update 3
• ESXi 5.5, Patch ESXi550-201501001
• ESXi 6.0

Управлять этим механизмом можно из расширенных настроек хоста VMware ESXi (Advanced Settings, раздел Mem). По умолчанию используется расширенная настройка Mem.ShareForceSalting в значении 2. Это означает, что salting включен и работает Intra-VM TPS.

Если же мы поставим эту настройку в значение 0, как на рисунке выше, то соль перестанет добавляться к хэшу при работе алгоритма TPS, а значит он будет работать для всех виртуальных машин на хосте (Inter-VM TPS).

Ну и, как становится понятным, TPS можно включить для отдельной группы виртуальных машин на хосте ESXi, для чего нужно использовать одинаковую соль для этих виртуальных машин. Для этого в расширенных настройках виртуальной машины нужно добавить параметр sched.mem.pshare.salt с одинаковым значением у всех нужных вам ВМ (это также можно сделать и в vmx-файле).

В этом случае значением настройки Mem.ShareForceSalting должно быть 1 или 2 (разницы тут особой нет, кроме того, что если у вас используется значение 1, то при отсутствии соли включится Inter-VM sharing).

Ну и в таблице ниже приведем различия в работе алгоритма TPS для различных значений Mem.ShareForceSalting и в зависимости от заполненности sched.mem.pshare.salt для виртуальных машин.

Для более детальной информации вы можете обратиться к статье KB 2097593.

Совсем недавно мы писали об обновлении следующего поколения тонкого клиента vSphere HTML5 Web Client версий 1.3 и 1.4, а вчера вышел HTML5 Web Client 1.5.

Новые возможности и улучшения VMware vSphere HTML5 Web Client 1.5:

• Теперь можно смотреть статус и редактировать настройки EVC-совместимого кластера.
• Можно просматривать состояние кластеров VMware DRS и HA.
• Возможность просмотра информации о профиле хоста (host profile) в настройках.
• Возможность просматривать статус lockdown mode и пользователей в списке исключений, имеющих доступ.
• Функция снятия снапшота виртуальной машины.
• Новый список TCP/IP stacks для хостов.
• Из списка датасторов теперь можно открыть Datastore Browser из контекстного меню.

Скачать VMware vSphere HTML5 Web Client 1.5 можно по этой ссылке.

На прошлой неделе компания VMware обновила не только клиент для управления хостами VMware ESXi Embedded Host Client до версии 8, но и выпустила обновление нового тонкого клиента для управления виртуальной инфраструктурой vSphere HTML5 Web Client 1.4. Напомним, что в конце апреля мы уже писали про новые возможности версии HTML5 Web Client 1.2, а ниже рассмотрим новые возможности сразу двух версий - 1.3 и 1.4, которые были выпущены с очень небольшим интервалом совсем недавно.

Итак, что нового в vSphere HTML5 Web Client 1.3/1.4:

• Теперь при создании виртуальной машины можно выбрать кластер хранилищ (datastore cluster) в качестве хранилища ВМ (но пока нельзя отключить DRS).
• Возможность загрузить файл на Datastore ([Datastore] -> Manage -> Files). При этом не требуется Client Integration Plugin.
• Виртуальные машины теперь можно мигрировать между пулами ресурсов (Resource Pools).
• Лучше стало работать добавление устройств к виртуальной машине - теперь есть единое меню.
• Имена файлов самого виртуального модуля теперь отражают версии клиента (OVA и RPM).
• В Inventory теперь больше информации о виртуальных сервисах vApps.
• Появилась возможность редактирования настроек SCSI-контроллера.
• Появилась возможность горячего удаления CD/DVD-приводов.
• Также было исправлено несколько серьезных багов, список которых приведен вот тут.

Скачать последнюю версию vSphere HTML5 Web Client 1.4 можно по этой ссылке.

Мы уже много писали про клиент для управления хост-серверами VMware ESXi Embedded Host Client, который поставляется в виде виртуального модуля, доступного на сайте проекта VMware Labs. Начиная с версии VMware vSphere 6.0 Update 2, он вошел в стандартную поставку ESXi (клиент седьмой версии). Но сам Embedded Host Client продолжает также развиваться и как отдельный проект. На днях было выпущено обновление - VMware ESXi Embedded Host Client v8.

Посмотрим на основной список новых возможностей Host Client:

• Основное
  • Таблицы (гриды) теперь с фильтрами/поиском и подсветкой по паттерну поиска.
  • Большинство таблиц поддерживает контекстное меню по правой кнопке для колонок.
  • Автоисправление конфигурации прокси, когда обнаруживаются конфликты путей.
  • Улучшенная обработка малоразмерных отображений консоли.
  • Исправления приветственной страницы: нет ошибки JSON Parse error, поддержка директив {ignore}{/ignore} и {accept}Message beside checkbox{/accept} (для того, чтобы заставить пользователя принять условия показываемого при логине сообщения). Делается это в файле /etc/vmware/welcome.
  • Улучшения отображения интерфейса в разделе производительность: поиск/фильтры, улучшенное отображение линий и т.п.
• Хост ESXi
  • Поддержка опций VSAN maintenance mode.
  • Фиксы багов Advanced Configuration.
  • Улучшенное отображение аппаратных сенсоров.
• Виртуальные машины
  • Добавление звуковых контроллеров в ВМ.
  • Улучшенная валидация при добавлении последовательных портов.
  • Улучшенный интерфейс для Advanced Settings виртуальной машины.
  • Пофикшены некоторые проблемы при редактировании настроек ВМ на ESXi 5.0.
  • Поддержка добавления/удаления пробрасываемых USB-устройств (passthrough). На данный момент это доступно только для включенных машин.
  • В раздел мониторинга производительности были добавлены подразделы Disk и Network.
  • Теперь можно импортировать OVA любого размера + мастер стал удобнее и быстрее.
  • Больше функций по отсылке комбинаций клавиш в гостевую ОС (Ctrl-c, например).
  • Доступ к меню действий, когда консоль находится в полноэкранном режиме.
  • Возможность загрузки VMRC-консоли напрямую с хоста ESXi.
  • Пофикшен баг с отображением представления VM summary, которое запрашивало пароль.
  • Пофикшен баг при изменении масштаба консоли.
  • Поддержка португальской клавиатуры.
  • Отображение полной информации об IP-конфигурации ВМ в summary.
• Хранилища
  • Поддержка конфигурации software iSCSI: Enable/disable, Authentication settings, Advanced configuration, Add/remove port bindings, Add/remove static targets, Add/remove dynamic targets.
  • Отображение статуса устройства (включая условия ошибок iSCSI) теперь более очевидно - она на иконке в таблице устройств.
• Сеть
  • Возможность изменения MTU для интерфейса VMkernel.
  • Улучшенная работа с правилами фаервола.
  • Пофикшен баг с редактированием интерфейсов VMkernel для ESXi 5.5.

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

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

С 3 мая компания VMware решила изменить этот подход, представив решение NSX в трех изданиях - Standard, Advanced и Enterprise. Теперь и небольшие компании смогут использовать издание Standard за меньшую цену и постепенно расти до издания Enteprise, если возникнет потребность в большем функционале платформы.

Все три издания лицензируются по физическим процессорам серверов (чтобы соответствовать изданиям VMware Virtual SAN), однако издание Advanced лицензируется также и по пользователям, чтобы NSX было удобно применять в VDI-средах.

В целом издания VMware NSX можно описать так:

• Standard - это базовые возможности распределенной коммутации и маршрутизации, которые подходят для совместного использования с vSphere Standard. Вы сможете создавать сети VXLAN в виртуальной инфраструктуре и соединять их с физической сетью предприятия с помощью NSX Edge, но остальные интересные возможности NSX будут недоступны, так как Distributed Firewalling и балансировка нагрузки. Также доступна интеграция с OpenStack через API.
• Advanced - это уже более интересное издание, здесь уже есть интеграция с Active Directory и такие компоненты, как Edge load balancing и Distributed Firewall. Но здесь еще нет возможностей VPN и поддержки нескольких сайтов со своими vCenter. Это издание подойдет большинству пользователей, у которых есть только один датацентр. Также его удобно использовать для создания сетевой платформы инфраструктуры виртуальных ПК.
• Enterprise - это полнофункциональное издание для большой сетевой инфраструктуры, а также предприятий с несколькими ЦОД, в которых присутствует несколько серверов vCenter, объединенных между собой. Тут также присутствуют функции распределенной балансировки (пока только в режиме Tech Preview).

Приведем ниже полное сравнение возможностей изданий VMware NSX 6.2, а краткое доступно вот тут.

Компания VMware выпустила весьма полезный документ "VMware Virtual SAN 6.2 Network Design Guide", в котором приведены конкретные рекомендации по настройке и конфигурации сети при организации отказоустойчивых кластеров хранилищ.

Посмотрим, какие интересные моменты есть в документе. Например, рассматривается следующая архитектура построения кластера Virtual SAN (это Leaf-Spine архитектура):

В такой сети показатель переподписки (oversubscription) между стойками равен 4:1 (от хостов идет 16 линков по 10 Гбит к свичу, от которого идет 4 линка по 10 Гбит к Spine-коммутатору). В этом случае, если предположить, что на хостах 10 ТБ емкости, из которых 6 ТБ занимают данные виртуальных машин, и вдруг возникнет необходимость операции rebuild для кластера (при FTT=1), то при использовании 3/4 пропускной способности канала (то есть 30 Гбит/с) операция займет 26 минут. Если же объем данных на хосте увеличить до 12 ТБ, а канал уменьшить до 10 Гбит/с, то rebuild займет 156 минут. Мораль такова - нельзя перебарщивать с переподпиской, а также нужно обеспечить широкий канал между узлами кластера.

Еще из рекомендаций в документе:

• Отключите Flow Control на физическом оборудовании, у Virtual SAN есть свой механизм контроля перегрузки канала.
• Используйте vSphere Distributed Switch (VDS) совместно с Virtual SAN.
• Настройте Load Based Teaming (LBT), который балансирует нагрузку, в зависимости от загрузки физического адаптера (похоже на Virtual Port ID, только привязка к порту пересматривается каждые 30 секунд).
• Если используете несколько кластеров Virtual SAN - помещайте трафик каждого из них в отдельный VLAN.
• Если в датацентре используются большие кадры jumbo frames - используйте их в кластере Virtual SAN, но если не используются - то отдельно включать их не надо.
• Включите Cisco Discovery Protocol (CDP) и Link Layer Discovery Protocol (LLDP) в режимах и приема, и передачи.

В документе присутствует еще несколько интересных рекомендаций, прочитать которые будет особенно интересно администраторам крупных инфраструктур и больших кластеров Virtual SAN.

Интересный пост написал Duncan Epping о растянутом кластере (Stretched Cluster) Virtual SAN и обработке события изоляции площадки механизмами HA и VSAN. Изложим тут его вкратце.

Как вы знаете, растянутый кластер Virtual SAN состоит из трех компонентов - две площадки с хранилищами VSAN и виртуальными машинами и одна площадка, выступающая как "свидетель" (Witness) и необходимая для принятия решения о том, какая площадка выпала из внешнего мира (то есть с ней нет связи), а какая способна продолжать поддерживать работу виртуальных машин (как в плане хранения, так и в плане исполнения на вычислительных ресурсах хостов).

Таким образом, обычно схема растянутого кластера выглядит так:

Теперь, допустим, на основной площадке (Site 1) произошла авария - и хосты ESXi с виртуальными машинами стали частично или полностью недоступны. При этом теряется ее связь как со второй площадкой (Site 2), так и с компонентом Witness на третьей площадке.

В этом случае происходит следующее:

• Хосты площадки Site 1 имеют связь между собой, события внутренней изоляции не происходит, поэтому HA не реагирует на ситуацию.
• Однако кластер Virtual SAN понимает, что площадка Site 1 изолирована от Site 2 и Witness (нет кворума), а значит и от внешнего мира, поэтому принимает решение выключить виртуальные машины. Это поведение можно изменить, установив расширенную настройку VSAN.AutoTerminateGhostVm в значение 0 (но делать это не рекомендуется).
• На второй площадке (Site 2) происходят выборы нового Master-узла в кластере VMware HA. Этот узел сверяется со списком protectedlist (в нем пока нет машин из Site 1), добавляет новые ВМ туда и берет на себя владение машинами с первого узла, так как теперь есть кворум у второй площадки. Что такое кворум? Это 2 компонента из трех (большинство) в растянутом кластере - сама эта площадка и компонент Witness (они видят связь друг с другом). Таким образом, VMware HA на второй площадке начинает восстановление виртуальных машин первого сайта.
• Как VMware HA убеждается, что на первой площадке эти машины выключены? Да никак - просто по дизайну заложено, что кластер Virtual SAN в случае изоляции площадки Site 1 потушит все ее виртуальные машины, поэтому владение этими машинами перейдет ко второй площадке.

Ну и, конечно же, тут нельзя не порекомендовать интереснейший документ VMware vSphere 6.x HA Deepdive, в котором есть все ответы на подобные вопросы.

Как многие из вас знают, в последней версии решения VMware Horizon 7 появился механизм аутентификации True SSO. Эта штука связывает средство единой аутентификации VMware Identity Manager с решением VMware Horizon 7 для решения задач одноразовой аутентификации пользователя различными методами (пароль, смарт-карта и т.п.), чтобы после этого он получал доступ к своему виртуальному ПК и приложениям без дополнительной аутентификации в Active Directory.

Задача эта важна, поскольку, например, VMware Horizon View используется в медицинских учереждениях, а там важно, чтобы врач получал мгновенный доступ к своему ПК, который может быть виртуальным. С помощью True SSO он теперь может просто приложить смарт-карту, после чего получит доступ к своим виртуальным ресурсам, на которые даны разрешения в инфраструктуре VMware View.

VMware Identity Manager Standard включен в издания VMware Horizon 7 Advanced и Enterprise, поэтому вы сразу можете приступать к работе через механизм True SSO. Суть работы этого механизма такова - сначала пользователь авторизуется через принятый в компании метод авторизации. Это может быть один из следующих (то, что поддерживает Identity Manager):

• RSA SecurID
• Kerberos
• RADIUS authentication
• RSA Adaptive Authentication
• Сторонние провайдеры аутентификации, например, биометрические системы.

Далее пользователь уже может запустить любой десктоп или hosted-приложение уже без необходимости ввода своих паролей в Active Directory или какой-либо другой аутентификации. True SSO использует механизм SAML (Security Assertion Markup Language) для того чтобы передать User Principal Name (например, jdoe@example.com) к службе аутентификации, чтобы получить доступ к учетной записи AD. Затем Horizon 7 генерирует краткосрочные сертификаты для логина в гостевую ОС Windows виртуального ПК.

Преимущества этого метода таковы:

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

Вот как работает True SSO:

1. Пользователь аутентифицируется в VMware Identify Manager одним из способов описанных выше. После этого пользователь выбирает десктоп или приложение из доступных ему, которое он хочет запустить, в консоли VMware Identity Manager.

2. Запускается Horizon Client под учетными данными пользователя, а его креды перенаправляются на View Connection Server.

3. View Connection Server валидирует идентификацию пользователя в Identify Manager путем отсылки SAML-запроса.

4. За счет использования службы Enrollment Service, Horizon 7 просит службу Microsoft Certificate Authority (CA) сгенерировать временный сертификат от имени пользователя.

5. Horizon 7 показывает этот сертификат ОС Windows виртуального ПК.

6. Windows аутентифицирует через этот сертификат пользователя в службе Active Directory.

7. Пользователь логинится в Windows-десктоп или приложение, а удаленная сессия обслуживается через Horizon Client.

Для работы механизма True SSO вам понадобится отдельная служба Enrollment Service, которая может быть развернута на машине с ОС Windows Server 2008 R2 или Windows Server 2012 R2 (4 ГБ оперативной памяти будет достаточно). Сам True SSO поддерживается для всех клиентских Windows-систем, а также протоколов доступа к виртуальным ПК, включая Blast Extreme и HTML Access.

На сайте Hands-on-Labs (HOL), где компания VMware размещает практические задания для администраторов в виде онлайн-лабораторных работ, появилась лабораторка, посвященная VMware vRealize Automation 7. Кстати, не стоит путать Hands-on-Labs, где нужно выполнять определенные задачи в консолях, и демо продуктов VMware Feature Walkthrough, основная цель которых показать доступные фичи отдельных решений.

Лабораторная работа по "HOL-SDC-1633 vRealize Automation 7: What's New" доступна по этой ссылке:

Вы сможете самостоятельно узнать о новой архитектуре развертывания решения, новых мастерах и новой службе vIDM Identity Management service.

Лабораторная работа по VMware vRealize Automation 7 содержит в себе 6 модулей:

• What's New Overview
• Architecture, Installation and VMware Identity Manager
• Converged Blueprint Basics - IaaS, NSX and Application Authoring
• Converged Blueprints Advanced - XaaS, Dependencies and Parameters
• Mission Extensible: Event Broker for Lifecycle Extensibility
• Enhanced vRA Troubleshooting with Log Insight 3 

Все вместе они займут три с половиной часа вашего времени. Вы поработаете с Converged Blueprint Designer и создадите собственные NSX Micro-Segmented blueprints, а также интегрируете решение с такими продуктами для управления жизненным циклом систем, как Puppet. Кроме того, вы сможете самостоятельно создать рабочие процессы в Event Broker, поработаете с ITSM-утилитами и проведете поиск и решение проблем в виртуальной инфраструктуре с помощью Log Insight content pack.

Интересная штука - при свежей установке или обновлении на VMware vCenter Server 6.0, если вы обычным пользователем без глобальных административных привилегий зайдете на вкладку Monitor -> Hardware Status -> Sensors для просмотра данных аппаратных сенсоров одного из хостов, вы увидите сообщение:

No host data available

Оказывается, это известная проблема, и описана она в KB 2112847. На данный момент для нее нет решения, кроме как добавить данному пользователю Global Permissions через Web Client.

Для этого нужно сделать следующее:

1. Зайти в Web Client под аккаунтом Administrator@vsphere.local или другим, у которого есть административные привилегии по управлению SSO.

2. Перейти на вкладку Administration > Global Permissions > Manage.

3. Нажать иконку + и добавить пользователю Global Permissions, выбрав его из соответствующего домена/группы.

Помните, что Global Permissions дают неограниченный доступ к просмотру и управлению объектами датацентра.

Есть пара интересных постов, на базе которых мы попробуем вкратце описать поведение кластера VMware Virtual SAN в случае, если при развертывании виртуальной машины кластер не способен обеспечить требуемые политики хранилищ (Storage Policies).

1. Обычный кластер Virtual SAN.

Если при развертывании новой ВМ в кластере VSAN невозможно обеспечить требуемые политики хранилищ (например, не хватает места для создания зеркалируемых объектов реплик), а именно:

• NumberOfFailuresToTolerate (FTT)
• NumberOfDiskStripesPerObject (SW)
• FlashReadCacheReservation (FRCR)

то виртуальная машина не сможет быть развернута в кластере. Но есть такая настройка Force Provisioning для VM Storage Policy, которая позволяет игнорировать указанные 3 параметра при развертывании новой ВМ в кластере.

Однако надо понимать, что при использовании Force Provisioning происходит не понижение требований кластера к хранилищу виртуальной машины (например, вместо FTT=2 можно было бы проверить FTT=1), а использование следующих параметров:

• NumberOfFailuresToTolerate = 0
• NumberOfDiskStripesPerObject = 1
• FlashReadCacheReservation = 0

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

Но кластер Virtual SAN имеет еще одну специфическую черту - если вы использовали Force Provisioning при недостатке дисковых ресурсов, то когда они освободятся, для хранилища машины будут сделаны реплики дисковых объектов и прочие операции, чтобы она все-таки соответствовала требуемым политикам хранилищ. Администраторам надо иметь эту особенность в виду.

И еще один момент - так как в случае Force Provisioning может храниться только одна копия дисковых объектов, то, например, если при переводе хоста в режим Maintenance Mode случится какой-нибудь сбой с его хранилищем - реально можно потерять эту машину целиком. Делайте бэкап и, по-возможности, не используйте Force Provisioning - старайтесь соблюдать политики хранилищ хотя бы на уровне FTT=1.

2. Растянутый кластер (Stretched Cluster).

В случае растянутого кластера появляется еще один компонент - Witness Appliance, следящий за ситуацией Split Brain, которая может появиться между площадками. Если вырубить этот виртуальный модуль и попытаться включить виртуальную машину или создать новую ВМ, то кластер Virtual SAN (несмотря на то, что он Failed и политика хранилищ не соблюдена) позволит это сделать, правда будет ругаться, что машина не соответствует текущим политикам хранилищ:

В остальном растянутый кластер ведет себя по отношению к Force Provisioning так же, как и обычный.

Постер VMware vSphere PowerCLI 10

Постер VMware Cloud Foundation 4 Architecture

Постер VMware vCloud Networking

Постер VMware Cloud on AWS Logical Design Poster for Workload Mobility

Постер Azure VMware Solution Logical Design

Постер Google Cloud VMware Engine Logical Design

Постер Multi-Cloud Application Mobility

Постер VMware NSX (референсный):

Постер VMware vCloud SDK:

Постер VMware vCloud Suite:

Управление памятью в VMware vSphere 5:

Как работает кластер VMware High Availability:

Постер VMware vSphere 5.5 ESXTOP (обзорный):