В блоге компании VMware появился очень и очень полезный постер vCenter Server Appliance 6.0 Reference Poster, посвященный основным аспекам работы виртуального модуля vCSA для управления инфраструктурой VMware vSphere (vCenter в готовой Linux-машине).
Основные разделы постера:
Requirements and Maximums - здесь указаны требования к виртуальному модулю vCSA и его хранилищам, а также для справки приведены максимумы конфигураций vCenter Server.
Firewall Requirements - требования к портам и соединениям при взаимодействии:
PSC с PSC (Platform Services Controller)
PSC с vCenter Server
vCenter Server с vCenter Server
Migration from Deprecated to Recommended Topology - в этой секции перечислены основные высокоуровневые моменты, касающиеся миграции с устаревших топологий. Эти топологии еще поддерживаются в vSphere 6, но уже не будут работать для следующих версий платформы.
Command Line Interface - здесь приведены команды как для самого виртуального модуля (Appliance Shell), так и для шелла (Bash Shell), которые позволят выполнять основные операции с vCSA.
Knowledge Base (KB) Articles - здесь приведены заголовки 20 основных статей базы знаний (в PDF-документе они являются кликабельными), которые помогут в решении повседневных задач администрирования vCenter Server Appliance.
Скачать VMware vCenter Server Appliance 6.0 Reference Poster можно по этой ссылке. Напомним также, что большинство постеров VMware вы можете найти вот тут.
Ну и вот еще парочка полезных ссылок от VMware на тему топологий vCenter:
У компании Netwrix, выпускающей средства аудита программных решений в виртуальных и физических инфраструктурах, оказывается есть полезное решение, которое может помочь администраторам VMware vSphere в отслеживании изменений, происходящих в компонентах платформы.
Бесплатная утилита Netwrix Change Notifier for VMware позволяет осуществлять мониторинг событий в виртуальной инфраструктуре и оповещать администраторов об изменениях на регулярной основе. Это средство отслеживает изменившиеся конфигурации виртуальных датацентров, хостов VMware ESXi, пулов ресурсов, кластеров, папок, самих виртуальных машин и других объектов.
В результате аудита администратору каждые 24 часа предоставляется отчет по электронной почте в следующем виде (кликабельно):
Очень полезно, что мы видим не только изменения настроек в соответствующих компонентах, но и добавление или удаление объектов. Естественно, под эгидой бесплатной утилиты Netwrix продает и платное решение Netwrix Auditor, которое скажет, кто и когда делал изменения, предоставит расширенный поиск по событиям и репортинг нескольким пользователям, но для маленькой инфраструктуры Change Notifier окажется вполне достаточным.
Feature
Change Notifier
Netwrix Auditor
Automatic daily email reports showing all changes made during the last day
Details on what changed in VMware
Who, when and where details for every change
Before and after values for all modifications
Predefined reports based on SQL Server Reporting Services, with filtering, sorting and exporting options
Google-like search of audit data with custom search queries and custom reports
Out-of-the-box compliance reports mapped to specific regulatory standards (PCI DSS, HIPAA, SOX, FISMA/NIST800-53 and ISO/IEC 27001)
Long-term storage of audit data in a two-tiered (file-based + SQL database) storage system
Email subscriptions to scheduled reports with the ability to choose multiple recipients (or specific folders), delivery frequency and delivery format
Reports on virtual machine sprawl statistics over a selected period of time
Single installation that handles multiple VMware vSphere instances, each with its own unique settings
Advanced cross-system auditing and reporting
Скачать Netwrix Change Notifier for VMware можно по этой ссылке.
VMware продолжает обновлять свой тонкий клиент для управления виртуальной инфраструктурой - VMware vSphere HTML5 Web Client, который заменит снимаемый с производства vSphere C# Client. Еще пару недель назад мы писали про версии 1.10 и 1.11, но на днях уже вышли версии 1.12 и 1.13.
Посмотрим, что нового появилось в новых версиях веб-клиента vSphere:
На хост-серверах можно запустить процедуру "Reconfigure for HA".
Базовые возможности по настройке параметров HA-кластера.
Живое обновление дерева снапшотов (после процедур revert, delete, delete all).
Автоматический апгрейд VMware Tools в виртуальных машинах.
Выбор между 12 или 24-часовым форматом для представлений времени.
Отображение кастомных атрибутов и тэгов в разделе Summary для виртуальных машин.
Редактирование IP-настроек для интерфейса VMkernel.
Можно кликать по алармам на панели, чтобы перейти к просмотру их деталей.
Множество багофиксов.
Скачать VMware vSphere HTML5 Web Client 1.13 можно по этой ссылке.
Если у вас много виртуальных машин в Inventory сервера VMware vCenter, то при превышении порога в 100 виртуальных машин они будут автоматически сгруппированы таким образом, что их список вы будете видеть только в группах:
Это поведение удобно далеко не всем администраторам VMware vSphere, но это легко можно изменить в настройках веб-клиента. Для этого откройте файл на сервере vCenter для Windows:
Почти 2 года назад мы писали о полезном для многих администраторов платформы vSphere плагине PowerActions for vSphere Web Client, который позволяет хранить и исполнять сценарии PowerCLI прямо из vSphere Web Client, что очень удобно, когда администратор выполняет повседневные задачи по управлению виртуальной инфраструктурой, где некоторые операции автоматизированы средствами PowerShell.
То есть вы просто нажимаете в веб-клиенте правой кнопкой по объекту виртуального датацентра и из контекстного меню выбираете нужный PowerCLI-скрипт для исполнения:
Многие администраторы VMware vSphere часто используют снапшоты для отката виртуальных машин в базовую точку после внесения в них экспериментальных изменений. Но вы же знаете, что снапшоты - это плохо, поэтому в некоторых ситуациях можно заменить этот процесс на более эффективный, так как снапшот можно забыть удалить, их удаление грузит дисковую подсистему и т.п.
Итак, иногда независимые (independent) диски могут оказаться вам полезными. Если вы зайдете в настройку дисков виртуальной машины, то увидите там такие опции:
Независимость таких дисков заключается в том, что они работают независимо от снапшотов, то есть при снятии снапшота и откате к ним, независимые диски остаются в том же состоянии. И тут есть 2 подвида таких дисков:
Persistent (постоянный) - этот диск является обычным диском для записи данных, но его не касаются снапшоты.
Nonpersistent (непостоянный) - этот диск является Redo-диском, то есть если вы выключаете виртуальную машину или откатываете ее к снапшоту - изменения, сделанные в этом диске, сбрасываются.
Как раз Nonpersistent-диски - это то, что можно иногда использовать вместо снапшотов. Сделали базовую машину, поэкспериментировали в ней, выключили - и она откатилась к базовому состоянию.
А вот еще кейс, который может научить вас использованию дисков сразу всех трех типов (обычных, независимых-постоянных и независимых-непостоянных). Например, вы сделали веб-сайт, который меняться не будет еще очень долго. Делаете виртуальную машину с тремя дисками:
Обычный - для файлов веб-сервера
Nonpersistent - для контента веб-сайта
Persistent - для логов веб-сайта
Теперь, если этот сайт кто-то поменяет или заразит, какой-то фигней, можно будет просто перезагрузить виртуальную машину - и это откатит ее в начальное состояние контента (непостоянный диск), но сохранит логи для анализа действий злоумышленника (постоянный диск).
В общем, независимые диски как-то не очень используются, но ведь иногда они вполне подойдут для решения некоторых админских задач.
На сайте vcommunique.blogspot.ru появилась интересная табличка в которой приведены максимальные конфигурации хостов, серверов vCenter, виртуальных машин и других компонентов виртуального датацентра в сравнительной таблице, где представлена информация для различных версий платформы VMware vSphere и средства катастрофоустойчивости Site Recovery Manager (SRM).
Вот так прогрессировали vSphere и SRM от версии к версии:
Максимально поддерживаемая конфигурация / Версия платформы
6
5.5
5.1
5
4.1
4
Число Virtual CPU на виртуальную машину (Virtual SMP)
128
64
64
32
8
8
Объем оперативной памяти (RAM) на ВМ
4 TB
1TB
1TB
1TB
255GB
255GB
Размер виртуального диска
62 TB
62TB
2TB
2TB
2TB
2TB
Число виртуальных дисков
На хост - 2048
На Datastore Cluster - 9000
60
60
60
60
60
Логических CPU на хост
480
320
160
160
160
20
Виртуальных машин на хост
1024
512
512
512
320
320
Виртуальных CPU на хост
4096
4096
2048
2048
512
512
Виртуальных CPU на ядро
32
32
25
25
25
20
Оперативной памяти (RAM) на хост
6 TB
4TB
2TB
2TB
1TB
1TB
Размер LUN
64 TB
64TB
64TB
64TB
2TB
2TB
Raw Device Mapping size (virtual compatibility)
62TB
62TB
2TB
2TB
2TB
2TB
Размер диска Raw Device Mapping в режиме физической совместимости (Physical RDM)
64TB
64TB
64TB
64TB
2TB
2TB
Виртуальных машин в кластере
8000
4000
4000
3000
3000
1280
Пулов ресурсов в кластере
1600
1600
1600
1600
512
512
Хостов на один vCenter Server
1000
1000
1000
1000
1000
200
Число хостов в виртуальном датацентре
500
500
500
500
400
100
Включенных виртуальных машин на один vCenter Server
10000
10000
10000
10000
10000
2000
Зарегистрированных виртуальных машин на один vCenter Server
15000
15000
15000
15000
15000
3000
Число распределенных коммутаторов (Distributed switches, VDS) на один vCenter
128
128
128
32
32
16
Single Sign On (SSO)
Требуется
Требуется
Требуется
Не доступен
Не доступен
Не доступен
Параметры VMware Site Recovery Manager (SRM)
Число защищенных виртуальных машин всего
5000
1000
1000
1000
1000
1000
Число защищенных ВМ в одной protection group
500
500
500
500
500
500
Число Protection groups на один recovery plan
250
250
150
150
150
150
Число Datastore groups
255
255
150
150
150
150
Число одновременно запущенных планов восстановления (recovery plans)
Компания 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" можно по этой ссылке.
Мы как-то писали о технологии 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, код был проверен различными тулзами, а также привлекались сторонние компании для поиска потенциальных уязвимостей.
Интересный пост о технологии 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, требуется знать версию того или иного объекта. Это может быть версия VMTools/vHardware виртуальной машины или версия vSphere хоста ESXi или версия VMFS-датастора (продолжите список сами). И каждый раз вы начинаете судорожно вспоминать, как это делается, где и какой скрипт искать или пускаетесь в поиски по форумам или обращаетесь к доктору Google).
Среди компаний, имеющих в своей производственной среде виртуальную инфраструктуру VMware vSphere или Microsoft Hyper-V, многие применяют для защиты виртуальных сред средство vGate R2 от компании "Код безопасности", позволяющее безопасно настроить инфраструктуру согласно различным требованиям с помощью наборов политик, разграничить доступ администраторов, а также защититься от несанкционированного доступа к виртуальным ресурсам.
Новая версия vGate R2 3.0, прежде всего, отличается расширенными возможностями работы в распределенных инфраструктурах и изменением схемы лицензирования. В результате заказчики vGate смогут получить функционал продукта, в наибольшей степени отвечающий целям и задачам организации. Обновленная версия vGate (vGate R2 и vGate-S R2, релиз 3.0) поддерживает расширенный набор инструментов работы с платформами виртуализации VMware vSphere и Microsoft Hyper-V.
Ниже приведены основные нововведения новой версии vGate 3.0:
В vGate 3.0 реализована полнофункциональная работа на платформе VMware vSphere 6. В качестве сервера управления инфраструктурой виртуализации теперь может выступать vCenter Server Appliance (VCSA), а управление ESXi-хостами может осуществляться посредством ESXi Embedded Host Client.
Обновленный продукт осуществляет поддержку управления инфраструктурой на базе Microsoft Hyper-V через System Center Virtual Machine Manager, а управление кластерами Hyper-V реализовано через Failover Cluster Manager.
Для быстрой настройки привилегий пользователей используется ролевая модель доступа. При создании учетной записи можно ограничить доступ по типам объектов, предоставив его, например, только к виртуальным машинам или сетевым объектам.
У продукта появился ряд новых функций для работы в Enterprise-инфраструктурах. Например, реализована поддержка режима горячего резервирования и автопереключение сервера авторизации (High-Availability cluster). В случае потери работоспособности основного сервера в автоматическом режиме происходят переключение на резервный сервер, замена IP-адреса и оповещение администратора.
Обновленная версия продукта позволяет работать с несколькими площадками виртуализации одновременно (этот функционал доступен только в Enterprise-редакции продукта - он будет очень полезен в крупных инфраструктурах). Механизм подключения агента аутентификации к нескольким серверам авторизации vGate дает возможность взаимодействовать со всей территориально распределенной виртуальной инфраструктурой. Построение леса серверов авторизации позволяет устанавливать групповые политики безопасности, а поддержка функции Cross vCenter vMotion обеспечивает в случае аварий миграцию виртуальных машин между серверами с сохранением политик безопасности.
Помимо этого, в vGate версии 3.0 обновлены наборы политик безопасности, обеспечивающие соответствие приказам ФСТЭК России №17 и №21, стандартам СТО БР ИББС, PCI DSS и другие.
Новые версии vGate R2 и vGate-S R2 применимы для защиты конфиденциальной информации и государственной тайны. Продукты прошли инспекционный контроль ФСТЭК России в подтверждение выданных ранее сертификатов соответствия от 28.03.2011 № 2308 и от 12.07.2011 № 2383.
vGate 3.0 можно приобрести в одной из двух редакций: Standard или Enterprise (для которой доступны все функции работы в крупных инфраструктурах). Ниже приведены основные отличия этих изданий:
Получить дополнительную информацию о технических особенностях vGate и направить запрос на получение демо-ключа можно по e-mail: vgateinfo@securitycode.ru. Более подробная информация о решении представлена на странице продукта vGate R2.
Компания VMware на днях распространила официальную информацию о том, что клиент vSphere Client, написанный на C#, не будет выпущен для следующей версии платформы vSphere (вероятно, седьмой). Вместо него будут использоваться средства управления на базе двух следующих веб-платформ:
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, vSphere, Client, Update, Web Client, HTML5, Blogs
Если вы часто заходите на хост-серверы VMware ESXi по SSH, то вам может оказаться полезным плагин sshAutoConnect для vCenter, который позволяет добавить соответствующий пункт в контекстное меню vSphere Client для хостов ESXi.
Плагин sshAutoConnect состоит из двух файлов - xml, который определяет конфигурацию плагина, и, собственно, dll-библиотека с плагином. Инсталляция плагина проста - нужно положить эти два файла в отдельную папку в папке плагинов vCenter по адресу:
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 для виртуальных машин.
Значение Mem. ShareForceSalting (настройка уровня хоста)
Значение sched.mem.pshare.salt (настройка уровня ВМ)
vc.uuid (свойство ВМ)
Значение соли в настройках ВМ
TPS между виртуальными машинами (Inter-VM)
TPS внутри каждой из ВМ (Intra-VM)
0
Игнорируется
Игнорируется
0
Да, между всеми машинами на хосте
Да
1
Установлено
Игнорируется
Используется sched.mem.pshare.salt
Только между ВМ с одинаковой солью
Да
1
Не установлено
Игнорируется
0
Да, между всеми машинами на хосте
Да
2
Установлено
Игнорируется
sched.mem.pshare.salt
Только между ВМ с одинаковой солью
Да
2
(по умолчанию)
Не установлено (по умолчанию)
Используется
Используется vc.uuid
No inter-VM TPS
Да
2
Не установлено
Отсутствует по какой-либо причине
Используется случайный номер для каждой ВМ
No inter-VM TPS
Да
Для более детальной информации вы можете обратиться к статье KB 2097593.
На прошлой неделе компания 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 можно по этой ссылке.
Интересный пост написал 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, HA, Stretched, Virtual SAN, VSAN, Blogs, vSphere, ESXi
Есть пара интересных постов, на базе которых мы попробуем вкратце описать поведение кластера VMware Virtual SAN в случае, если при развертывании виртуальной машины кластер не способен обеспечить требуемые политики хранилищ (Storage Policies).
1. Обычный кластер Virtual SAN.
Если при развертывании новой ВМ в кластере VSAN невозможно обеспечить требуемые политики хранилищ (например, не хватает места для создания зеркалируемых объектов реплик), а именно:
то виртуальная машина не сможет быть развернута в кластере. Но есть такая настройка 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 так же, как и обычный.
Не так давно мы писали о том, как поддерживает резервное копирования виртуальных машин на томах Virtual Volumes (VVols) главный продукт в индустрии Veeam Backup and Replication. Технически бэкап ВМ на томах VVols ничем не отличается от стандартного бэкапа в VMware vSphere, так как создание снапшота проходит через единый механизм как для обычных виртуальных хранилищ, так и для Virtual Volumes. Достигается это посредством поддержки продуктом для резервного копирования интерфейса vSphere APIs for Data Protection (VADP).
VADP уже достаточно давно поддерживается решениями для резервного копирования виртуальных машин, поэтому вы можете смело использовать их для бэкапа ВМ на томах VVols, начиная со следующих версий:
Для успешного резервного копирования через VADP надо обязательно иметь доступ к vCenter, делать его резервную копию, а также создать бэкап виртуальной машины, реализующей VASA Provider (VP), если он не физически реализован на массиве, а поставляется как ВМ.
Нужно помнить, что VASA Provider (если это ВМ) содержит в себе структуру томов VVols (и маппинги машин к устройствам), и если этот компонент будет потерян, то вы полностью потеряете управление над хранилищами. Надо сказать, что вендоры решений с поддержкой VVols, как правило, сами реализуют отказо- и катастрофоустойчивость своих VP, но необходимо помнить, что это критически важный компонент и неплохо бы делать его резервное копирование.
Важным моментом также является то, что SAN-to-SAN бэкап не работает на томах VVols ни в одном из продуктов для резервного копирования. Причина проста - еще не разработано универсального стабильного API для прямого доступа к томам VVols со стороны медиа-серверов РК.
Важный момент касается снапшотов для томов VVols. Если в традиционных хранилищах не рекомендовалось делать более 2-3 снапшотов (хотя поддерживалось дерево до 32 штук) и хранить их следовало не более 24-72 часов, то для Virtual Volumes все работает несколько иначе:
В среде VVols при снятии снапшота базовый диск остается режиме Read/Write (это все делает массив), то есть контекст записи данных никуда не переключается, и изменения пишутся в базовый диск. В снапшоты (это отдельные тома VVol) пишется только информация об изменениях базового диска (какие дисковые блоки были изменены с момента снятия снапшота).
Ну а при удалении снапшота по окончанию резервного копирования никакой консолидации с базовым диском производить не требуется - так как мы продолжаем с ним работать, просто отбрасывая дельта-диски. Ну а мораль такова: снапшоты с VVols уже не так плохи, как раньше!
Ну и несколько полезных ресурсов о Virtual Volumes:
Только в понедельник мы писали о трех скрытых возможностях в vSphere HTML5 Web Client, а вот буквально вчера VMware выпустила обновление следующего поколения тонкого клиента для управления виртуальной инфраструктурой - vSphere HTML5 Web Client 1.2, где есть одна из этих возможностей уже включенная в GUI клиента. Напомним, что о версии 1.1 h5client мы писали недавно вот тут.
Кстати, недавно также обновился и дизайн проекта VMware Labs (по-моему, стало хуже - будто бы это версия для слабовидящих).
Давате посмотрим, что нового в vSphere HTML5 Web Client 1.2:
Возможность загрузки файла с виртуального хранилища.
Перенаправление URL: ваши старые браузерные закладки для Web Client теперь должны работать, например вот такие ссылки:
https://[h5client ip or domain name]/vsphere-client
https://[h5client ip or domain name]:9443/vsphere-client
Перенаправляют на h5client:
https://[ip or domain name]:9443/ui
Это потребует запустить скрипт "firewall.sh", информация о котором доступна на шаге 5 инструкций по установке. Надо просто выполнить следующую команду:
платформой vSphere - HTML5 Web Client 1.1. Эта версия заменит собой текущий Web Client, который сейчас работает на основе тормозной технологии Adobe Flex.
Оказывается в HTML5 Web Client есть три скрытых возможности, о которых написал Emad Younis, и которые, видимо, еще находятся не в очень стабильном состоянии, поэтому разработчики решили отключить их. Но так как вы используете новый клиент только в целях тестирования - то давайте включим их и посмотрим, что это за фичи.
1. Итак, заходим на vSphere HTML5 Web Client Fling Appliance по SSH.
2. Переходим в папку /etc/vmware/vsphere-client/vsphereFeatures:
# cd /etc/vmware/vsphere-client/vsphereFeatures
3. Находим там файл vsphereFeatures.cfg и открываем его для редактирования в редакторе vi:
# vi vsphereFeatures.cfg
4. Видим там, что некоторые 3 фичи настроены в состояниях disabled. Это:
Datastore File Browser
Add Host Wizard
Network Selector
5. Включим какую-нибудь из них, например, файловый браузер:
6. Перезапустим веб-службы Web Client следующей командой:
# /etc/init.d/vsphere-client restart
7. Теперь зайдем в консоль веб-клиента по адресу:
https://<имя или IP модуля>:9443/ui
И перейдем в раздел Datastore –> Manage –> Files, там мы и увидим файловый браузер:
8. Теперь запустим Add Host Wizard для добавления нового хост-сервера VMware ESXi в кластер:
И попробуем добавить новый хост:
9. Ну а расширенный выбор VM Network находится в настройках виртуальной машины VM –> Network Adapter –> Network drop down –> Show more networks:
Скорее всего, эти 3 фичи появятся в следующей версии HTML5 Web Client, а ждать ее осталось недолго. Но ведь и там будет файлик vsphereFeatures.cfg, в котором можно будет взглянуть на следующие новые возможности нового поколения тонкого клиента VMware vSphere.
Таги: VMware, Web Client, Update, vSphere, ESXi, Обучение, Blogs
Все администраторы знают, как включать и отключать доступ по SSH на хостах ESXi. Однако часто в административных целях требуется перещелкнуть этот сервис не только на одном хост-сервере, а в пределах целого кластера VMware HA/DRS для выполнения комплекса задач на нескольких хостах. В этом случае поможет скрипт PowerCLI, который написал David Ring.
Сначала вводите IP-адрес сервера vCenter, логин и пароль администратора, ну а потом сценарий запросит имя кластера в котором вы хотите включить/отключить доступ к серверам по SSH:
Когда вы закончите проведение необходимых операций в консоли хостов ESXi по SSH, запустите скрипт повторно для отключения SSH в целях безопасности:
Ну и, собственно, сам скрипт PowerCLI:
########### vCenter Connectivity Details ###########
Write-Host “Please enter the vCenter Host IP Address:” -ForegroundColor Yellow -NoNewline
$VMHost = Read-Host
Write-Host “Please enter the vCenter Username:” -ForegroundColor Yellow -NoNewline
$User = Read-Host
Write-Host “Please enter the vCenter Password:” -ForegroundColor Yellow -NoNewline
$Pass = Read-Host
Connect-VIServer -Server $VMHost -User $User -Password $Pass
########### Please Enter the Cluster to Enable SSH ###########
Write-Host “Clusters Associated with this vCenter:” -ForegroundColor Green
$VMcluster = ‘*’
ForEach ($VMcluster in (Get-Cluster -name $VMcluster)| sort)
{
Write-Host $VMcluster
}
Write-Host “Please enter the Cluster to Enable/Disable SSH:” -ForegroundColor Yellow -NoNewline
$VMcluster = Read-Host
########### Enabling SSH ###########
Write-Host “Ready to Enable SSH? “ -ForegroundColor Yellow -NoNewline
Write-Host ” Y/N:” -ForegroundColor Red -NoNewline
$SSHEnable = Read-Host
if ($SSHEnable -eq “y”) {
Write-Host “Enabling SSH on all hosts in your specified cluster:” -ForegroundColor Green
Get-Cluster $VMcluster | Get-VMHost | ForEach {Start-VMHostService -HostService ($_ | Get-VMHostService | Where {$_.Key -eq “TSM-SSH”})}
}
########### Disabling SSH ###########
Write-Host “Ready to Disable SSH? “ -ForegroundColor Yellow -NoNewline
Write-Host ” Y/N:” -ForegroundColor Red -NoNewline
$SSHDisable = Read-Host
if ($SSHDisable -eq “y”) {
Write-Host “Disabling SSH” -ForegroundColor Green
Get-Cluster $VMcluster | Get-VMHost | ForEach {Stop-VMHostService -HostService ($_ | Get-VMHostService | Where {$_.Key -eq “TSM-SSH”}) -Confirm:$FALSE}
}
Скачать скрипт можно по этой ссылке (уберите расширение doc и добавьте .ps1).
Недавно мы писали про превью vSphere HTML5 Web Client, представляющего собой тонкий клиент на основе технологии HTML 5, который вскоре заменит устаревший Web Client на базе Adobe Flex. На днях VMware обновила версию этого продукта до 1.1, которая доступна для загрузки на сайте проекта VMware Labs.
Посмотрим на новые возможности vSphere HTML5 Web Client 1.1:
Добавление нового CD/DVD-привода к новой или существующей виртуальной машине.
Добавление сетевого адаптера к новой или существующей ВМ.
Добавление жесткого диска к новой или существующей ВМ.
Создание виртуальной машины из представления кластера.
Перенос ВМ в кластере за счет vMotion и установление приоритета миграции.
Изменение настроек Agent VM на хост-сервере.
Просмотр настроек Lockdown Mode в разделе Security Profile на хосте.
Просмотр информации о сертификатах на ESXi.
Базовый воркфлоу создания нового кластера.
Удаление кластера.
Дело идет, но до использования продукта в продакшене еще достаточно далеко. Посмотрите хотя бы историю с веб-клиентом ESXi Embedded Host Client, который появился только в vSphere 6.0 Update 2, а шел к этому 7 месяцев с момента релиза первой версии. Поэтому, как минимум полгода еще придется подождать.
Также в новом веб-клиенте кое-что было улучшено:
Операция connect/disconnect сетевого адаптера.
Настройка сетевого адаптера при создании новой виртуальной машины.
Исправлено множество ошибок.
Скачать vSphere HTML5 Web Client 1.1 в виде готового виртуального модуля OVA (Virtual Appliance) можно по этой ссылке. Инструкции по развертыванию и полезные советы приведены тут.
Известный многим из вас блоггер Фрэнк Деннеман (Frank Denneman) на днях анонсировал третье издание книги о проектировании виртуальной инфраструктуры VMware - vSphere Design Pocketbook v3, которая построена на базе материалов авторов, пишущих о виртуализации в своих блогах или на других ресурсах:
Книга представляет собой сборник статей известных блоггеров и специалистов в области построения виртуальной инфраструктуры, которые широко известны в медиа-пространстве. Среди них такие известные ребята, как William Lam, Matt Leibowitz, Frank Denneman и другие.
Книга доступна бесплатно в электронном виде по этой ссылке, а в печатном виде будет распространяться на конференции EMC World. В книге 157 страниц рекомендаций по дизайну инфраструктуры виртуализации в формате блог-записей, в которых авторы стараются быть максимально конкретными и пишут по сути (со скриншотами, графиками и таблицами).
Ниже содержание книги с указанием авторов соответствующих статей, которые объединены в 7 глав, отражающих основные аспекты проектирования виртуальной инфраструктуры VMware vSphere:
Chapter 1 – Host Configuration
Host Design – Scale-Up or Scale-Out? (by Rene van den Bedem)
VMware ESXi – Async Drivers (by Patrick Schulz)
Don’t Forget the Logs (by Steve Wood)
Chapter 2 – Cluster and vCenter Design
VMware Resource Pools (by Eric Shanks)
Tweet Sized Design Recommendation (by Doug Baer)
vCenter is Down – Impact on VMware Infrastructure (by Mariusz Kaczorek)
Tweet Sized Design Recommendation (by Amit Rathod)
Enhanced vMotion Compatibility (EVC) Best Practices (by Dee Abson)
What Does Load Balancing the Platform Services Controller Really Give You? (by William Lam)
Chapter 3 – Storage Configuration
The Ultimate IOPS Cheat Sheet (by Bas van Kaam)
Tweet Sized Design Recommendation (by Doug Behr)
Determine Your vSphere Storage Needs (by Michael Wilmsen)
Tweet Sized Design Recommendation (by Patrick Schulz)
vSphere Replication – Consider These Points Before Using It (by Craig Kilborn)
Know the Minions by Chethan Kumar
Understanding Block Sizes in a Virtualized Environment (by Pete Koehler)
Chapter 4 – Network and Security Design
vSphere 6.0 – Configure VMware Certificate Authority As A Subordinate CA (by Kyle Jenner)
На протяжении нескольких лет от системных администраторов VMware vSphere постоянно поступают жалобы на низкое быстродействие и глючность тонкого клиента управления платформой - vSphere Web Client. Это неудивительно - ведь веб-клиент vSphere построен на базе фреймворка Adobe Flex (пруф), который вобрал в себя все самые "лучшие" стороны флеш-технологии.
Так вот, время флеша похоже истекает - на сайте проекта VMware Labs появилось превью нового клиента vSphere HTML5 Web Client, построенного на базе новых стандартов HTML 5 и Javascript. Напомним, что флеш плох всего лишь в трех аспектах - производительность, стабильность и безопасность, ну а новый клиент призван все это улучшить.
Клиент vSphere HTML5 Web Client пока поддерживается только для VMware vSphere 6 и более поздних версий. Скажем тут на всякий случай, что этот клиент предназначен для управления виртуальной инфраструктурой только через сервисы VMware vCenter. Если вам нужно управлять отдельным хостом, то используйте ESXi Embedded Host Client, который теперь уже поставляется с vSphere 6.0 Update 2 и более поздними версиями платформы виртуализации.
На данный момент технологическое превью умеет делать следующие вещи:
Операции с питанием виртуальных машин (вкл/выкл/приостановка).
Изменение настроек ВМ (CPU, память, виртуальные диски).
Доступ к консоли виртуальных машин.
Страницы информации для хостов и ВМ.
Горячая миграция машин между хостами ESXi (без перемещения хранилищ).
Клонирование машин и создание шаблонов из ВМ.
Создание новой виртуальной машины (пока возможности ограничены).
Различные графики производительности для мониторинга и отслеживания событий (Performance charts, Tasks, Events).
Представления Global Views (последние задачи, алармы и т.п.).
К сожалению, пока в этом клиенте нет функций vSphere Update Manager (напомним, что и в обычном-то vSphere Web Client они появились спустя оочень долгое время).
Скачать VMware vSphere HTML5 Web Client можно в виде готового к развертыванию виртуального модуля OVA по этой ссылке. Для развертывания тонкого клиента понадобится поколдовать с командной строкой (инструкции доступны здесь), ну а в следующих версиях обещают полноценный GUI.
Таги: VMware, vSphere, Labs, Update, Web Client, Performance