На днях компания VMware обновила свое средство для управления виртуальной инфраструктурой на базе технологии HTML5 - на сайте проекта VMware Labs появился VMware vSphere Client версии 3.36.

Напомним, что о версии 3.34 этого продукта мы писали в середине февраля вот тут, поэтому давайте взглянем на новые функции и улучшения последних двух версий клиентов - VMware vSphere Client 3.36 и 3.35:

• Кастомизация дополнительных устройств и опций при создании виртуальной машины или ее клонировании:
• Host USB device
• SCSI controller
• USB controller
• SATA controller
• CPU > CPUID Mask > Advanced
• VM Options > VMRC options
• VM Options > VMware Tools > Power Operations
• VM Options > Power Management > Wake up on LAN
• VM Options > Advanced Configuration Parameters
• VM Options > Fibre Channel NPIV
• Оповещение перед тем, как происходит операция над шаблоном ВМ, который в данный момент управляется клиентом.
• Улучшения интерфейса для быстрого поиска (Quick search).
• Улучшения в панели управления дисками ВМ - теперь они объединяются в группы в разделе VM Summary->Edit Settings (если их больше 4 штук).
• Несколько исправлений багов и мелких улучшений.

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

На сайте nolabnoparty.com появилась отличная статья о том, как нужно выключать и включать кластер отказоустойчивых хранилищ VMware vSAN таким образом, чтобы не повредить данных, и включить его потом без особых проблем. Инструкция может оказаться полезной тем администраторам, которым необходимо остановить кластер vSAN целиком в целях обслуживания оборудования (серверы, коммутаторы, стойка и т.п.).

Выключение кластера vSAN

1. Для начала вам нужно выключить все виртуальные машины, кроме сервера VMware vCenter (неважно, обычный это VC или vCSA):

2. Мигрируем с помощью vMotion сервер vCenter на хост ESXi01 (тот хост, который вы считаете своим первым хостом в виртуальной инфраструктуре):

Также на первый хост ESXi настоятельно рекомендуется перевести контроллер домена Active Directory.

3. Теперь надо убедиться, что в данный момент в кластере vSAN нет процессов ресинхронизации (Resyncing Components). Для этого надо зайти в соответствующий раздел на вкладке Monitor:

На этом скриншоте видно, что никаких процессов ресинхронизации сейчас не идет. Если они у вас есть, то следует дождаться их завершения.

4. Переводим все хосты VMware ESXi (кроме ESXi01) в режим обслуживания (Maintenance Mode):

В настройках режима обслуживания уберите галку с варианта переместить машины (Move powered-off and suspended virtual machines...), а также выберите вариант не перемещать данные кластера vSAN (No data evacuation):

5. Выключите гостевую ОС виртуальной машины c VMware vCenter. Для этого в контекстном меню vCenter или vCSA выберите пункт Shut Down Guest OS:

После этого у вас, само собой, отпадет соединение с VMware vSphere Web Client:

6. Зайдите на хост ESXi через ESXi Host Client (ссылка https://<ip esxi>/ui) и переведите сервер в режим обслуживания, выбрав из контекстного меню пункт Enter maintenance mode:

Аналогично укажите, что не нужно переносить данные кластера vSAN:

Также это можно сделать следующей командой esxcli в консоли сервера:

# esxcli system maintenanceMode set -e true -m noAction

Включение кластера VMware vSAN

1. Сначала последовательно выводим хосты ESXi из режима обслуживания, начав с первого:

Сделать это также можно командой esxcli:

# esxcli system maintenanceMode set -e false

2. Включаем на хосте ESXi01 сервер vCenter и контроллер домена Active Directory:

3. Идем на вкладку Monitor и там в разделе Health убеждаемся, что все узлы в порядке и кластер vSAN прошел все проверки:

4. Только после этого включаем все виртуальные машины:

Если вы зайдете на страницу поддерживаемых устройств ввода-вывода (I/O Devices) в списке VMware Hardware Compatibility List (HCL), то в правой колонке увидите там следующие параметры:

• VID (Vendor ID)
• DID (Device ID)
• SVID (Sub-Vendor ID)
• SSID (Sub-Device ID)

Все эти категории там не просто так - это очень удобный способ проверить совместимость вашего устройства ввода-вывода (сетевая карта, HBA-адаптер, SCSI-контроллер, USB-контроллер, и т.п.) с платформой VMware vSphere / ESXi и другими продуктами.

Например, если вы хотите узнать эти параметры для сетевой карты, то можно вывести список PCI-устройств командой vmkchdev, отфильтровав их с помощью grep по свойству vmnic (сетевой адаптер):

vmkchdev -l | grep vmnic

Далее вы увидите подобный вывод:

[dpasek@esx01:~] vmkchdev -l | grep vmnic

0000:02:00.0 14e4:1657 103c:22be vmkernel vmnic0

0000:02:00.1 14e4:1657 103c:22be vmkernel vmnic1

0000:02:00.2 14e4:1657 103c:22be vmkernel vmnic2

0000:02:00.3 14e4:1657 103c:22be vmkernel vmnic3

0000:05:00.0 14e4:168e 103c:339d vmkernel vmnic4

0000:05:00.1 14e4:168e 103c:339d vmkernel vmnic5

0000:88:00.0 14e4:168e 103c:339d vmkernel vmnic6

0000:88:00.1 14e4:168e 103c:339d vmkernel vmnic7

Здесь вот этот участок - 14e4:1657 103c:22be - для адаптера vmnic0 позволяет разложить его на 4 приведенных выше параметра:

• VID = 14e4
• DID = 1657
• SVID = 103c
• SSID = 22be

После этого вы просто вбиваете эти параметры в VMware HCL для I/O-устройств в правую колонку и смотрите, совместима ли данная сетевая карта с данной версией VMware ESXi.

Если вы отфильтруете вывод по строчке vmhba, то можете получить локальные SCSI-контроллеры или HBA-адаптеры, которые также можно проверить аналогичным образом.

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

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

Приведем данный список ниже:

Бизнес-задачи и проблемы

• Какие основные задачи стоят при внедрении?
• Какие проблемы заказчика предполагается решить?

Варианты использования платформы

• Какие варианты использования инфраструктуры VMware предполагает сам заказчик?

Требования/Ограничения/Допущения

• Каковы основные требования, какие ограничения учесть, о какие допущениях и неочевидных моментах нужно проинформировать заказчика.

Риски

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

A. Управление виртуальным датацентром

Решения в области логической архитектуры

• Общий объем объединяемых в пул ресурсов (вычислительные мощности, сети и хранилища).
• Какие сервисы будет предоставлять инфраструктура.
• Необходимый уровень доступности для систем управления платформой виртуализации.
• Интеграция со сторонними решениями: IT Service Management, Infrastructure Management systems, Enterprise services (DNS, LDAP, NTP, PKI, Syslog, SNMP Traps), сбор данных агентами систем различных вендоров.
• Необходимы ли расширенные операции, не предоставляемые из коробки?
• Механизмы защиты рабочих нагрузок гипервизора (vMotion, HA и другое).
• Механизмы балансировки нагрузки на гипервизор (DRS).

Решения в области физической инфраструктуры

• Гипервизор: версии ESXi.
• Нужен ли отдельный кластер управления?
• Серверы vCenter в режиме Standalone или Linked-Mode?
• Версия vCenter Server и тип установки (под Windows или в виде виртуального модуля).
• База данных vCenter Server - встроенная или внешняя?
• Механизмы защиты vCenter Server.
• Дизайн инфраструктуры Platform Services Controller (PSC). Будет ли один домен SSO?
• Нужна ли инфраструктура шифрования (PKI)? Какие требования к SSL?
• Какие компоненты vSphere будут использоваться?
• Нужна ли функциональность Host profiles?
• Вопросы управления обновлениями ESXi, версиями VM Hardware и версиями VMware Tools.
• Интеграция с антивирусами и решениями vShield/NSX.
• Нужен ли пакет vRealize Suite для расширенных операций и управления частным облаком?
• Нужен ли продукт vRealize Orchestrator для управления рабочими процессами операций? Нужен ли PowerCLI для сценариев автоматизации?
• Нужно ли интегрировать виртуальную инфраструктуру с другими средствами управления (Enterprise Management)?
• Automated vendor support mechanisms? How will VMware Skyline be used?
• Нужно ли организовывать интеграцию с системами Service Desk или Change Management?
• Каковы требования к механизмам vSphere HA и vSphere DRS?
• Если будет использоваться HCI (Hyper-Converged Infrastructure), то какие решения будут использоваться для управления, и как это будет совместимо с vSphere?
• Вопросы интеграции со службами DNS и NTP.
• Ролевая модель доступа (Role Based Access Control) и интеграция с LDAP.
• Какой интерфейс vCenter Server будет использоваться для администрирования и ежедневных операций (vSphere Client / Web Client).
• Модель лицензирования vCenter.
• Вопросы лицензирования стороннего ПО в виртуальных машинах (на хост, на виртуальный процессор vCPU и т.п.).

B. Вычислительные ресурсы

Решения в области логической архитектуры

• Традиционная архитектура, технология Server-Side Flash Cache Acceleration, конвергентная или гиперконвергентная инфраструктура (связано с хранилищами).
• Минимальное число хостов в кластере.
• Тип сайзинга хостов в кластерах: вертикальный (Scale Up) или горизонтальный (Scale Out)?
• Гомогенные или гетерогенные узлы?
• Число физических процессоров на хост.
• Резервирование уровня хостов в рамках доменов отказа (Failure Domains).
• Необходимая емкость по CPU.
• Необходимая емкость по RAM.

Решения в области физической инфраструктуры

• Вендор серверов.
• Тип процессоров серверов.
• Фичи CPU: VT-x, Hyper-threading, Turbo Boost, включена ли NUMA?
• Конфигурация серверного оборудования.
• Число сокетов CPU на узел.
• Модель процессора, частота и число ядер.
• Нужен ли GPU?
• Физическое размещение хостов.
• Тип размещения: Single Rack или Multi-Rack с шарингом ресурсов?
• Требования к доступности кластеров.
• Нужно ли обеспечить согласованность доступности хостов с доступностью хранилищ.
• Будущее расширение вычислительных ресурсов.

C. Хранилища

Решения в области логической архитектуры

• Традиционные хранилища, технология Server-Side Flash Cache Acceleration, конвергентная или гиперконвергентная инфраструктура (связано с вычислительными ресурсами).
• Блочные или IP-хранилища?
• Средства автоматизированного управления хранилищами.
• Допустимо ли использование RDM?
• Метод загрузки хоста ESXi - с локального диска (DAS), LUN или PXE.
• Толстые или тонкие диски для виртуальных машин?
• Необходимые ресурсы хранения.
• Репликация хранилищ.

Решения в области физической инфраструктуры

• Вендор систем хранения.
• Расчет используемой емкости хранилищ с учетом пулов хранения, затрат на репликацию и бэкап. Каковы численные требования к емкости и производительности хранилищ?
• Число дисков SSD и HDD в каждой из систем хранения.
• Использование дедупликации, сжатия данных, технологии Erasure Coding и Storage APIs. Нужно ли держать процент хранилищ всегда свободным?
• Какой активный Working Set (рабочий объем данных) необходим?
• Трешхолды для автоматизированного ярусного хранения данных (разнесения по ярусам).
• Использование шифрованных дисков и сервер KMS.
• Сеть хранения данных и ее организация.
• Механизм загрузки хстов ESXi.
• Технологии VM DirectPath I/O и SR-IOV.
• Число датасторов на кластер.
• Будут ли использоваться DRS и SIOC?
• Будут ли применяться VMDK shares на уровне виртуальных дисков?
• Будет ли использоваться технология VAAI?
• Использование VASA и профилей хранилищ (storage profiles).
• Будут ли использоваться синхронные или асинхронные DR-решения?
• Планирование расширения хранилищ.

D. Сетевая инфраструктура

Решения в области логической архитектуры

• Технология Legacy 3-Tier Switch, Collapsed Core или Clos-type Leaf/Spine?
• Кластеризованные физические или отдельные коммутаторы EoR/ToR?
• Растянутые логические VLAN или на уровне стойки?
• Трафик будет функционально разделяться на уровне виртуальных коммутаторов или отдельных VLAN?
• Будут ли использоваться Jumbo Frames?
• Требования Quality of Service (QoS).
• Балансировка нагрузки в сети (Load Balancing).
• Версия протокола IP.
• Соединения Inter-Data Center, включая RTT.
• Требуемая емкость и пропускная способность сети.
• Какие ВМ разрешены - с одним или несколькими vNIC?

Решения в области физической инфраструктуры

• Выбор вендора решения Clos-type Leaf/Spine для больших инсталляций. Либо использование архитектуры Core/Agg/Dist/Access switch.
• Фабрика коммутаторов типа Blocking или non-blocking?
• Если blocking, какое уровень переподписки (over-subscription ratio)?
• Каков путь трафика типа North/South и East/West?
• Где находятся шлюзы Layer 3 для каждой из подсетей?
• Требования к динамической маршрутизации (Dynamic Routing)?
• Нужен ли мультикаст?
• Будут ли использоваться End-to-End Jumbo Frames?
• Интерфейсы хостов ESXi: 1GbE и/или 10GbE? Сколько их будет на каждом хосте?
• Интерфейсы на хостах - LAG или unbonded?
• Слой управления для KVM и iLO/iDRAC/IPMI.
• Производительность физической сети LAN.
• Матрица связности хостов по сети передачи данных.
• Нужно ли Metro Ethernet между датацентрами?
• Использование QoS, Network Control и vSphere Network I/O Control.
• Будет ли использоваться Edge QoS или End-to-End QoS?
• Система vSphere NIOC и User-Defined Network Resource Pools.
• vMotion через несколько физических адаптеров одновременно.
• Использование VLAN Pruning.
• Использование Spanning Tree.
• Технологии VM DirectPath I/O и SR-IOV.
• Будет ли включена TCP Offload?
• Будут ли использованы стандартные vSwitch (VSS) или распределенные Distributed Switch (VDS).
• Разные vSwitches на кластер или общие?
• Использование технологий Teaming и Load Balancing.
• Порты VMkernel.
• Группы портов для виртуальных машин.
• Нужно ли решение VMware NSX-v?
• Планирование расширения сети по числу портов.

E. Защита данных

Решения в области логической архитектуры

• Частота резервного копирования большинства ВМ.
• Настройки бэкапов уровня Application Consistent и Database Consistent.
• Требования ко времени восстановления.
• Физическое разделение актуальных данных и бэкапов.
• Необходимые решения для бэкапа.
• Требования к производительности процесса резервного копирования.

Решения в области физической инфраструктуры

• Будет ли использоваться решение на базе VADP (например, Veeam Backup and Replication).
• Критерии для выбора решения по бэкапу.
• Требования к механизму резервного копирования и восстановления.
• Снапшоты уровня ВМ.
• Нужна ли асинхронная репликация снапшотов ВМ в удаленный кластер или публичное облако.
• Частота резервного копирования.
• Политика хранения резервных копий.
• Выделяемые емкости под хранение бэкапов и производительность процесса.
• Быстрое восстановление средств управления кластером на хосте ESXi.
• Рост объема хранения бэкапов и ресурсы для его обслуживания.

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

Решения в области логической архитектуры

• Стандартные размеры ВМ (по уровням настроек - виртуальный диск, память, сеть, опции).
• Какие механизмы для CPU и RAM будут использоваться (например, Memory Ballooning)?
• Размещение файлов ВМ.
• Стандартизация гостевых ОС.
• Выбор между 64 и 32-битными системами.
• Использование шаблонов.

Решения в области физической инфраструктуры

• Стандартные размеры виртуальных машин и ресурсы для них.
• Планирование виртуальных сервисов vApps и пулов ресурсов.
• Размещение виртуальных машин на общих хранилищах.
• Стандартные настройки виртуальных дисков машин.
• Будут ли использоваться тонкие диски?
• Допустимы ли аппаратные снапшоты на уровне хранилищ или снапшоты vSphere?
• Будет ли включен Changed Block Tracking (CBT)?
• 32/64-битные версии гостевых систем.
• Адаптеры vSCSI.
• Виртуальные сетевые адаптеры vNIC.
• Версия виртуального аппаратного обеспечения (VM Hardware).
• Будут ли установлены VMware Tools и какой версии?
• Прочие стандартные настройки ВМ.
• Какие шаблоны ВМ будут использоваться?
• Настройки репозиториев шаблонов ВМ.
• Предложения по работе виртуальных машин с приложениями уровней Mission-Critical/Business-Critical.

G. Безопасность

Решения в области логической архитектуры

• Зоны и трасты.
• Нужна ли Defence-in-Depth?
• Будет ли решение мультивендоным?
• Физическое разделение сегментов сети.
• Стандарты, которые нужно соблюсти.
• Требования к защите инфраструктуры виртуализации и виртуальным машинам.
• Необходимый объем защиты сетевой инфраструктуры.

Решения в области физической инфраструктуры

• Физическое и виртуальное зонирование сетей.
• Сетевые экраны уровня приложений и уровня сетей.
• Системы IDS и IPS.
• SSL и сети IP-Sec VPN.
• Комплексная защита от сетевых угроз (Unified Threat Management)?
• Выбор вендора в сфере решений ИТ-безопасности.
• Нужно ли решение VMware NSX-v/T?
• Защита конечных устройств и выбор антивирусов.
• Производительность решений для сеNetwork Security Performance?
• Системы Security Information & Event Management (SIEM).
• Будет ли использоваться инфраструктура шифрования (Public Key Infrastructure, PKI)?
• Будет ли использоваться технология vSphere Cluster security? STIG?
• Технологии защиты хоста ESXi.
• Технологии защиты сетевого взаимодействия.
• Технологии защиты хранилищ.
• Технологии защиты резервных копий.
• Технологии защиты виртуальных машин.
• Будет ли будущее расширение инфраструктуры и какие дополнительные средства могут понадобиться?

H. Непрерывность бизнеса / восстановление после аварий (BC/DR)

Решения в области логической архитектуры

• Какие механизмы защиты будут использоваться?
• Ручные или автоматические сценарии восстановления? Регламент ручных действий.
• Политики RPO, RTO, WRT и MTD для приложений различной степени критичности (Mission-Critical, Business-Critical и Non-Critical).
• Как использовать глобальные балансировщики (Global Site Load Balancers).
• Параметры DNS TTL для клиентов.

Решения в области физической инфраструктуры

• Нужны ли решения по катастрофоустойчивости?
• Нужен ли продукт VMware SRM или Veeam Availability Suite?
• Нужно ли решение GSLB?
• Использование внутренних и внешних DNS-серверов.
• Уровень катастрофоустойчивости - нужна ли синхронная репликация на географически удаленные кластеры?
• Репликация на несколько площадок, репликация баз данных и Message Queue clustering/replication.

Многие из вас хотя бы раз задумывались о том, сколько виртуальных машин должно в среднем приходиться на один хост, а кроме того, в частности, сколько виртуальных процессоров (vCPU) могут исполняться на физических процессорах (pCPU) хост-сервера VMware ESXi.

На этот счет системные архитекторы часто дают следующие рекомендации (в соответствии с критичностью нагрузок в кластере):

• Tier 1 cluster (mission-critical приложения) - соотношение 1:1 vCPU / pCPU.
• Tier 2 cluster (business-critical приложения) - соотношение 3:1 vCPU / pCPU.
• Tier 3 cluster (инфраструктурные и обеспечивающие приложения) - соотношение 5:1 vCPU / pCPU.
• Tier 4 cluster (виртуальные десктопы) - соотношение 10:1 vCPU / pCPU.

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

Для того, чтобы регулировать это соотношение со стороны кластера балансировки нагрузки VMware DRS есть 2 специальные расширенные настройки:

• MaxVcpusPerClusterPct - регулирует соотношение vCPU/pCPU на уровне всего кластера, не привязываясь к конкретным хостам ESXi (то есть сумма vCPU всех машин делится на сумму pCPU всех хостов).
• MaxVCPUsPerCore - регулирует соотношение vCPU/pCPU на уровне каждого из хостов ESXi, то есть ни на одном из них это соотношение не может быть превышено.

Указываются эти расширенные настройки в разделе Configuration Parameters в vSphere Web Client при настройке DRS-кластера:

Также их можно задать и в HTML5-клиенте vSphere Client:

Но самое интересное - это то, что в vSpher Web Client эта настройка есть в GUI и регулирует параметр MaxVcpusPerClusterPct на уровне всего кластера (можно задать процент от 0 до 500, но разумно задавать значения от 100 до 500, если задать 500 - число vCPU может быть больше pCPU в пять раз):

А вот в vSphere Client - эта настройка уже MaxVCPUsPerCore, то есть задание CPU Overcommitment на уровне каждого из хостов ESXi, о чем и написано в интерфейсе:

Кстати, выставить эту настройку можно в диапазоне от 0 до 32.

На днях мы писали о том, что компания VMware выпустила обновления VMware vCenter и ESXi, закрывающие потенциальную угрозу безопасности Spectre (она же Hypervisor-Assisted Guest Mitigation - CVE-2017-5715), которая недавно была обнаружена в процессорах Intel. Для закрытия уязвимости нужно обновить не только серверы ESXi и vCenter, но и микрокод (BIOS/Firmware) серверов (более подробная информация также приведена в KB 52085).

На днях наш читатель Сергей прислал ссылку на скрипт от Вильяма Лама, который позволяет провести проверку компонентов виртуальной инфраструктуры VMware vSphere на данную уязвимость. Этот PowerCLI-скрипт содержит две функции:

• Verify-ESXiMicrocodePatchAndVM
• Verify-ESXiMicrocodePatch

Первая функция позволяет проверить хосты ESXi и виртуальные машины и сгенерировать отчет в разрезе виртуальных машин. Если в колонке Affected стоит значение False - значит обновления и микрокода сервера, и хоста ESXi были применены, а сами ВМ и хост-сервер не подвержены уязвимости Spectre.

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

Функция Verify-ESXiMicrocodePatchAndVM может быть запущена тремя способами:

• Без параметров - проверяется все окружение VMware vSphere и все виртуальные машины в нем.
• С параметром - ClusterName - проверяется конкретный кластер и всего его хосты и ВМ.
• С параметром - VMName - проверяется только конкретная ВМ и ее хост, соответственно.

У функции Verify-ESXiMicrocodePatch также есть три способа вызова:

• Без параметров - проверяются все хост-сервера в инфраструктуре vCenter.
• С параметром - ClusterName - проверяется конкретный кластер и всего его хосты.
• С параметром - VMHostName - проверяется конкретный хост-сервер ESXi.

Скачать этот PowerCLI-сценарий можно по этой ссылке: VerifyESXiMicrocodePatch.ps1.

Кстати говоря, этот скрипт был добавлен в полезный скрипт vCheck, который перед Новым годом обновился до версии 6.25, скачать его можно вот тут - https://github.com/alanrenouf/vCheck-vSphere.

Мы часто пишем о виртуальном модуле VMware vCenter Server Appliance (vCSA), который представляет собой готовую виртуальную машину для управления виртуальной инфраструктурой VMware vSphere (напомним, что это полноценная замена vCenter for Windows).

Сегодня мы покажем несколько интересных утилит командной строки vCSA, которые могут помочь вам в ежедневной эксплуатации этого управляющего сервиса.

1. Просмотр журнала Cron.

vCSA имел раньше проблемы со сжатием фалов журнала (логов), что приводило к тому, что дисковые разделы быстро заполнялись. Поэтому следующей командой можно посмотреть, когда в последний раз выполнялись запланированные задачи Cron:

ls -l /var/spool/cron/lastrun/

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

vc:~ # date

Mon Dec 4 12:55:39 CET 2017

vc:~ # ls -l /var/spool/cron/lastrun/

total 0

-rw------- 1 root root 0 Dec 3 20:00 cron.daily

-rw------- 1 root root 0 Dec 4 12:15 cron.hourly

-rw------- 1 root root 0 Dec 1 20:00 cron.weekly

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

grep "Authentication token is no longer valid; new one required" /var/log/messages.0.log | head

Если в выводе этой команды будет что-то вроде этого:

<timestamp> vcenter /usr/sbin/cron[<ID>]: Authentication token is no longer valid; new one required

значит пароль root устарел.

2. Смена устаревшего пароля root.

Если ваш пароль root устарел, и крон-таски vCSA не запускаются, то сменить его проще всего будет следующей командой (обратите внимание, что это НЕ слово change):

chage -l root

У вас запросят старый пароль и попросят задать новый:

Password change requested. Choose a new password.

Old Password:

New password:

После этого можно снова вывести срок действия пароля с помощью chage (тут видно, что он устареет через 99999 дней, то есть 274 года):

vc:~ # chage -l root

Minimum: 0

Maximum: 99999

Warning: 7

Inactive: -1

Last Change: Dec 27, 2016

Password Expires: Never

Password Inactive: Never

Account Expires: Never

3. Перезапуск служб vCSA.

Если вы хотите поправить странное поведение vCSA, которое может быть связано с некорректным поведением сервисов Linux внутри виртуального модуля, то можно перезапустить все службы:

service-control --stop --all

service-control --start --all

Можно перезапустить, например, только vSphere Client:

service-control --stop vsphere-client

Список запущенных служб узнается так:

service-control --list

А вот так узнается статус того или иного сервиса:

service-control --status

4. Работа с LVM

Если вам надо увеличить виртуальные диски VMDK, а потом расширить тома LVM, то можете прочитать вот эту нашу статью. Чтобы не использовать API Explorer или PowerCLI, можно выполнить следующую команду для просмотра томов LVM:

lsblk

Далее вы получите примерно следующее:

vc:~ # lsblk

NAME MAJ:MIN RM SIZE RO MOUNTPOINT

sda 8:0 0 20G 0

??sda1 8:1 0 132M 0 /boot

??sda2 8:2 0 1G 0 [SWAP]

??sda3 8:3 0 10.9G 0 /

sdb 8:16 0 1.4G 0

sdc 8:32 0 25G 0

??swap_vg-swap1 (dm-8) 253:8 0 25G 0 [SWAP]

sdd 8:48 0 50G 0

??core_vg-core (dm-7) 253:7 0 50G 0 /storage/core

sde 8:64 0 10G 0

??log_vg-log (dm-6) 253:6 0 10G 0 /storage/log

sdf 8:80 0 10G 0

??db_vg-db (dm-5) 253:5 0 10G 0 /storage/db

sdg 8:96 0 5G 0

??dblog_vg-dblog (dm-4) 253:4 0 5G 0 /storage/dblog

sdh 8:112 0 25G 0

??seat_vg-seat (dm-3) 253:3 0 25G 0 /storage/seat

sdi 8:128 0 1G 0

??netdump_vg-netdump (dm-2) 253:2 0 1016M 0 /storage/netdump

sdj 8:144 0 10G 0

??autodeploy_vg-autodeploy (dm-1) 253:1 0 10G 0 /storage/autodeploy

sdk 8:160 0 10G 0

??invsvc_vg-invsvc (dm-0) 253:0 0 10G 0 /storage/invsvc

fd0 2:0 1 4K 0

sr0 11:0 1 1024M 0

Для идентификации дисковых устройств и их типов можно выполнить следующее:

lsscsi

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

vc:~ # lsscsi

[0:0:0:0] disk VMware Virtual disk 1.0 /dev/sda

[0:0:1:0] disk VMware Virtual disk 1.0 /dev/sdb

[0:0:2:0] disk VMware Virtual disk 1.0 /dev/sdc

[0:0:3:0] disk VMware Virtual disk 1.0 /dev/sdd

[0:0:4:0] disk VMware Virtual disk 1.0 /dev/sde

[0:0:5:0] disk VMware Virtual disk 1.0 /dev/sdf

[0:0:6:0] disk VMware Virtual disk 1.0 /dev/sdg

[0:0:8:0] disk VMware Virtual disk 1.0 /dev/sdh

[0:0:10:0] disk VMware Virtual disk 1.0 /dev/sdi

[0:0:12:0] disk VMware Virtual disk 1.0 /dev/sdj

[0:0:14:0] disk VMware Virtual disk 1.0 /dev/sdk

[1:0:0:0] cd/dvd NECVMWar VMware IDE CDR00 1.00 /dev/sr0

Когда вы поймете, какой том нужно увеличить, выполните команду:

vpxd_servicecfg storage lvm autogrow

Надо помнить, что это сработает только для томов под управлением LVM (например, для disk 1 (sda) с разделом / - не сработает).

5. Поиск "загрязняющих" файлов.

Чтобы найти логи, которые могут засорить корневой раздел или раздел /storage/log, выполните одну из следующих команд:

du -a /var | sort -n -r | head -n 10
du -a /storage/log | sort -n -r | head -n 10

6. Изменение режима ротации логов (Log Rotation).

Сначала перейдем в папку с логами:

cd /etc/logrotate.d

Далее сделаем бэкап настроек:

cp dnsmasq ./dnsmasq.old

Затем откроем настройки:

vi dnsmasq

И поменяем слово "weekly" (еженедельно) на "daily" (ежедневно), например:

/var/log/dnsmasq.log {

daily

missingok

notifempty

delaycompress

sharedscripts

postrotate

[ ! -f /var/run/dnsmasq.pid ] || kill -USR2 cat /var/run/dnsmasq.pid

endscript

create 0640 dnsmasq dnsmasq

После этого можно удалить старый большой лог следующими командами:

cd /var/log

rm dnsmasq.log

7. Удаление файлов, которые не удалились.

Бывает так, что вы удалили большой файл, а дисковое пространство не высвободилось - и это видно командой df -h. Это происходит потому, что какой-то из процессов в памяти еще держит файл (при этом не обязательно использует его). Чтобы узнать, что это за процесс выполняем команду:

lsof | grep deleted

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

postgres 8860 vpostgres 10u REG 253,4 16777216 16395 /storage/dblog/vpostgres/pg_xlog/000000010000011900000041 (deleted)

Видим, что это Postgres держит файл, поэтому если он нам сейчас не нужен, убиваем процесс:

kill -9 <PID>

После этого вы увидите, что свободного дискового пространства на сервере vCSA стало больше.

Автор известного технического блога о платформе VMware vSphere, Frank Denneman, совместно с одним из коллег выпустил весьма интересную книгу "vSphere 6.5 Host Resources Deep Dive".

В рамках 570-страничного талмуда авторы рассказывают все технические детали управления ресурсами на уровне хоста ESXi, такими как память, процессор, стек работы с хранилищами и сетевая архитектура. Довольно много содержимого книги посвящено архитектуре NUMA-узлов и оперативной памяти, механикам работы CPU и ядра VMkernel, а также прочим самым глубоким моментам программных и аппаратных компонентов хоста ESXi.

По уверению авторов книга покрывает, например, следующие технические вопросы:

• Оптимизация рабочих нагрузок для систем Non-Uniform Memory Access (NUMA).
• Объяснение того, как именно работает механика vSphere Balanced Power Management, чтобы получить преимущества функциональности CPU Turbo Boost.
• Как настроить компоненты VMkernel для оптимизации производительности трафика VXLAN и окружений NFV.

В общем, книга очень крутая и мудрая. Скачать ее можно по этой ссылке.

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

Например, если сертификат vCenter устареет, то при попытке выполнить горячую миграцию vMotion, вы получите сообщение о невозможности соединения с демоном vpxd и ошибкой "server certificate chain not verified" в консоли vSphere Client. Если при этом посмотреть вот в этот лог-файл:

/var/log/vmware/vmware-sps/sps.log

то можно увидеть там подобные сообщения:

com.vmware.vim.vmomi.client.exception.SslException: com.vmware.vim.vmomi.core.exception.
CertificateValidationException: Server certificate chain not verified

Чтобы посмотреть сроки действия текущих сертификатов, нужно воспользоваться следующими командами на хосте vCSA (vCenter Server Appliance):

/usr/lib/vmware-vmafd/bin/vecs-cli entry list –store MACHINE_SSL_CERT –text |less

/usr/lib/vmware-vmafd/bin/vecs-cli entry list –store machine –text |less

По умолчанию сервер vCenter предупреждает администратора об истечении срока действия сертификатов за 30 дней. О том, как заменить сертификаты хорошо рассказано вот тут.

Этот срок можно поменять, для этого:

• Зайдите в vSphere Web Client.
• Выберите vCenter Server, перейдите на вкладку Manage и далее в подвкладку Settings.
• Нажмите Advanced Settings, далее Edit и введите в фильтр слово "threshold".
• Измените значение ключа vpxd.cert.threshold на нужное количество дней.

Ну а чтобы аларм об истечении сертификатов точно сработал, нужно зайти в Alarm settings –> Certificate Status и убедиться, что установлена галка Enable this alarm.

Источник.

Некоторое время мы писали о портале WhatMatrix, где можно посмотреть относительно свежие сравнения платформ виртуализации, а также некоторых других технологий и решений. Хотим напомнить об этом интересном средстве, особенно в контексте последних изменений - на сайте было добавлено много новых категорий сравнений, а скоро будет добавлено еще больше (не только глобальные продукты, но и нишевые решения):

Сравнения представлены в различных категориях:

• Application Delivery Controllers - это так называемые контроллеры доставки приложений, то есть ПО, которое оптимизирует трафик на входящем/исходящем канале на уровне датацентра, балансирует нагрузку и выполняет прочие служебные задачи.
• DR for Virtual Environments - это решения для обеспечения катастрофоустойчивости виртуальных машин и сервисов на уровне датацентра.
• Cloud Management Platforms - это решения для управления онпремизной и публичной облачной инфраструктурой.
• SDS and HCI - различные решения для хранения данных в виртуальной среде и гиперконвергентные платформы управления виртуальной инфраструктурой.
• Virtualization - это, собственно, платформы виртуализации, наиболее интересная часть.
• Cloud Storage Gateways - средства транислирования облачных API-запросов к хранилищам на блочный уровень.
• UDM (Unified Device Management) - комплексные решения для управления пользовательскими устройствами.
• Backups for Virtual Environments - средства резервного копирования виртуальных машин.

В ближайшем будущем также появится сравнение публичных облаков (Public Cloud Comparison), что для многих суперактуальная штука сегодня:

Разработчики портала утверждают, что в ближайшее время также будет добавлено около 170 значительных изменений, что превратит ресурс в главный источник знаний о различиях в корпоративном софте для датацентров. Будет даже добавлен обзор Blockchain-решений. Также обещают кастомизацию сравнений и результатов под конкретные требования пользователя, чтобы не ставить его перед выбором, какие продукты подставлять в сравнения и как между собой сравнивать их результаты.

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

В общем, заходите на WhatMatrix.com и решайте сами - адекватно там все или нет.

Некоторые из вас помнят, что в VMware vSphere 6.5 одной из новых возможностей гипервизора ESXi 6.5 стала функция его безопасной загрузки (Secure Boot). Об этом мы уже упоминали в посте с видеороликами о новых возможностях vSphere 6.5:

Суть механизма безопасной загрузки в vSphere 6.5 заключается в том, что загрузка подписанного кода гипервизора ESXi контролируется со стороны UEFI firmware, а также не разрешается исполнение неподписанных пакетов.

UEFI (Unified Extensible Firmware Interface) - это замена традиционному BIOS в серверах и настольных ПК. Механизм Secure Boot - это один из "протоколов" UEFI, который предоставляет возможности контроля загрузки подписанного кода за счет хранения цифровых сертификатов, которые хранятся в микрокоде (firmware) компьютера (signature database). Это все позволяет убедиться в том, что некий root kit не будет присутствовать в составе загружаемых компонентов и не предоставит доступ злоумышленнику на самом низком уровне.

Большинство UEFI содержит набор сертификатов по умолчанию типа x509 Microsoft UEFI Public CA, а также позволяет устанавливать собственные сертификаты дополнительно. Надо отметить, что эти сертификаты поставляются производителем серверов и обновляются вместе с его микрокодом.

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

• Загрузчик ESXi (boot loader) - он убеждается в том, что цифровая сигнатура кода не была изменена. Загрузчик подписан сертификатом Microsoft UEFI Public CA. Он также содержит VMware public key, с помощью которого проверяются компоненты VM Kernel, Secure Boot Verifier, а также пакеты VIB.
• Ядро VM Kernel - это также подписанная часть кода. Первое, что делает VM Kernel, это запускает Secure Boot Verifier.
• Secure Boot Verifier - он также хранит VMware public key и проверяет аутентичность всех VIB-пакетов, которые загружаются во время загрузки ESXi.
• VIB-пакеты (vSphere Installation Bundles) - эти пакеты, помимо реализуемых ими сервисов, содержат файл XML descriptor и файл цифровой подписи (digital signature file). Во время загрузки ESXi в памяти создается "карта" содержимого каждого из VIB-пакетов, соответственно не требуется проверять каждый из его файлов, а достаточно проверить подпись пакета целиком (это быстрее работает).

Вот как выглядит процесс загрузки хоста ESXi с точки зрения Secure Boot:

• Включение питания.
• UEFI Firmware валидирует загрузчик ESXi Boot Loader на предмет соответствия сертификату Microsoft внутри микрокода UEFI.
• ESXi Boot Loader валидирует компонент VM Kernel на предмет соответствия сертификату в Boot Loader.
• VM Kernel запускает компонент Secure Boot Verifier.
• Secure Boot Verifier валидирует каждый VIB-пакет на соответствие сертификату VMware, который находится в хранилище Secure Boot Verifier.
• Запускаются необходимые сервисы управления (DCUI, hostd и т.п.).

При апгрейде VMware ESXi прошлых версий с помощью ESXCLI происходит обновление сигнатур VIB-пакетов, но Boot Loader остается прежним, поэтому когда вы включите Secure Boot - возникнет ошибка. Как следствие - нужно будет переустановить ESXi.

Если вы обновляете ESXi из ISO-образа, то для некоторых старых VIB-пакетов сигнатуры могут не обновиться (например, кастомные драйвера, которые вы устанавливали отдельно), что приведет к неудаче при безопасной загрузке. То есть для нормального обновления из ISO нужно, чтобы все VIB-пакеты в этом образе обновили все предыдущие VIB. Надо отметить, что VIB-пакеты уровня Community supported не поддерживаются для безопасной загрузки (так как они не подписаны).

В составе VMware vSphere 6.5 есть специальный скрипт, который проверяет возможность безопасного апгрейда прошлой версии платформы.

Сначала надо проверить, что серверы поддерживают UEFI secure boot. Далее надо убедиться, что все ваши VIB-пакеты имеют хотя бы уровень Partner Supported, и у вас нет Community Supported пакетов.

Если вы обновили хост на ESXi 6.5, то можно выполнить следующий скрипт для проверки возможности включения Secure Boot:

/usr/lib/vmware/secureboot/bin/secureBoot.py -c

Результатом будет строчка "Secure Boot can be enabled" или "Secure boot CANNOT be enabled".

Если вы включите Secure Boot в микрокоде сервера, но у вас есть неподписанные пакеты, то при загрузке сервера вы увидите розовый экран и сообщение о том, что нельзя проверить подписи VIB-пакетов:

Чтобы выйти из этой ситуации, надо выключить безопасную загрузку, удалить неподписанные VIB-пакеты и снова включить ее.

Еще одна фишка включенной функции Secure Boot - это то, что вы не сможете установить неподписанные VIB-пакеты с опцией force подобным образом:

"esxcli install software –d /drive/badvib.zip –force –<b>no</b>-sig-check"

Если говорить о модуле TPM, то он тут не участвует, и мало того - TPM 2.0 вообще не поддерживается со стороны VMware vSphere 6.5.

Ну и последнее. Если вы хотите использовать Secure Boot вместе с механизмом vSphere Auto Deploy, то вы должны добавить сертификат VMware в список UEFI firmware whitelist (DB). Это требуется потому, что только ESXi Boot Loader подписан сертификатом Microsoft, а часть кода PXE-загрузчика, которая грузится до Boot Loader, подписана сертификатом VMware. Более подробно об этом написано в KB 2148532.

Интересный пост написал Cormac Hogan, касающийся конфигурации растянутых кластеров VMware vSphere Stretched Clusters и размещения компонентов Witness VM для них. Если у вас есть 2 площадки и два растянутых кластера VMware vSAN между ними, то сама собой напрашивается следующая конфигурация:

Но так делать, конечно же, нельзя - и вот почему. Допустим у вас отказал сайт 2, на котором не было Witness-машин. Только в этом случае у вас будет все хорошо - для каждого из кластеров будет кворум (Witness VM+узел), и они продолжат нормальную работу.

Но если у вас откажет сайт 1, то вы лишитесь сразу двух Witness VM (и WA, и WB), узлы на площадке 2 окажутся изолированными, и все виртуальные машины на них будут недоступны (нет кворума):

А что для случая, если машины Witness VM разместить на разных площадках?

Да тоже ничего хорошего - откажет сайт 1, вследствие чего виртуальные машины выжившего сайта 2 кластера A будут недоступны (не будет кворума, ведь WA, присматривающий за эти узлом умер на первой площадке). Ну а поскольку WB является как раз виртуальной машиной, данного узла кластера A ставшего недоступным, то и у выжившего узла кластера B также не будет кворума. В итоге и виртуальные машины кластера B при данном сбое будут недоступны.

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

Начиная с VMware vSphere 6.0, компания VMware предлагает администраторам очень удобный механизм для назначения прав доступа на самом высоком уровне при наличии нескольких серверов VMware vCenter - глобальные пермиссии (global permissions).

Для тех, кто использует режим vCenter Enhanced Linked Mode (ELM) с несколькими географически разделенными площадками и разнородными инфраструктурами, глобальные пермиссии - это отличное решение, так как они создаются один раз, после чего распространяются и (что самое главное) поддерживаются в согласованном состоянии на всех серверах vCenter связанной инфраструктуры в рамках одного домена Single Sign-On (SSO).

Вильям Лам, известный своими сценариями для автоматизации инфраструктуры vSphere, написал удобный скрипт GlobalPermissions.ps1, позволяющий добавлять и удалять глобальные пермиссии. Он содержит методы New-GlobalPermission и Remove-GlobalPermission, для которых можно задавать следующие параметры:

• vc_server - хост сервера vCenter
• vc_username - имя пользователя vCenter
• vc_password - пароль пользователя vCenter
• vc_user - пользователь vCenter, которому будут назначаться пермиссии
• vc_role_id - идентификатор Role ID, который связан с ролью vSphere на данном vCenter Server
• propagate - значение true или false для распространения пермиссий вниз по уровням иерархии

Чтобы получить параметр vc_role_id, нужно соединиться с vCenter Server и указать имя роли, выполнив сниппет ниже. В данном примере мы получаем ID административной роли с именем Admin:

(Get-VIRole -Name Admin).ExtensionData.RoleId

Вот пример создания новой глобальной пермиссии для одного из пользователей:

$vc_server = "192.168.1.51"

$vc_username = "administrator@vsphere.local"

$vc_password = "VMware1!"

$vc_role_id = "-1"

$vc_user = "VGHETTO\lamw"

$propagate = "true"

New-GlobalPermission -vc_server $vc_server -vc_username $vc_username -vc_password $vc_password -vc_user $vc_user -vc_role_id $vc_role_id -propagate $propagate

А вот появление соответствующей пермиссии в интерфейсе vSphere Web Client как результат работы сценария выше:

Ну а вот так удаляется глобальная пермиссия:

Remove-GlobalPermission -vc_server $vc_server -vc_username $vc_username -vc_password $vc_password -vc_user $vc_user

Посмотреть и загрузить сценарий GlobalPermissions.ps1 можно по этой ссылке.

Как знают все администраторы vSphere, в инфраструктуре виртуализации есть основной пароль компонента Single Sign-On (SSO), являющегося частью служб Platform Service Controller (PSC). SSO отвечает за предоставление токена авторизации пользователю, который соединяется с vCenter и использует остальные решения, которые с ним интегрированы.

Если вы забыли пароль SSO, то никак не сможете администрировать основные службы PSC и vCenter. Также вы не сможете никаким способом повысить одного из пользователей с любой ролью до администратора SSO.

Но есть способ восстановить/сбросить пароль Single Sign-On, если вы используете vCenter Server Appliance (vCSA). Для этого нужно зайти на vCSA под пользователем root (его же вы не забыли, правда?):

После чего ввести команду для доступа к шеллу:

shell.set --enabled true

После этого напишите shell и нажмите Enter:

Далее запустите VDC админ-тул, и вы увидите вот такой результат:

Нажмите клавишу <3>, после чего у вас попросят ввести аккаунт (Account UPN), для которого будет сгенерирован временный пароль. Введите administrator@vsphere.local:

После этого с данным паролем войдите в vCenter Single Sign-On:

Ну а там уже перейдите в Administration>Single Sign On > Users и выберите Edit для пользователя Administrator. Там можно сменить пароль:

Это, кстати, говорит о том, что пароль root для vCenter Server Appliance нужно хранить особенно внимательно и не забывать.

Мы уже писали о том, что у компании StarWind есть замечательный блог о технологиях виртуализации, а сегодня хотим напомнить про него еще раз)

Фишка этого блога в том, что там пишут вовсе не о продуктах StarWind (хотя они и очень полезные), а о различных технологиях, тем или иным образом имеющих отношение к виртуализации. Вот, например, некоторые из тем:

• How to Deploy and Manage Software-Defined Networking using SCVMM 2016
• VMware vSphere 6.5 – What to be aware of before upgrade?
• Azure Security and Compliance: Virtual Cloud Defense (VCD) Released to General Availability
• vCenter Server High Availability Review
• VMware Clarity – Why should you care

Читайте! Там много полезного)

Компания VMware сделала доступным весьма полезный ресурс StorageHub, который будет интересен всем тем, кто хочет узнать все об использовании виртуальных и физических хранилищ под виртуальные машины на базе платформы VMware vSphere. Также на StorageHub есть документы и об инструментах обеспечивающих доступность виртуальных сервисов (например, VMware Site Recovery Manager):

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

• VMware Virtual SAN
• Site Recovery Manager
• Virtual Volumes
• vSphere Replication
• vSphere Core Storage (это не продукт, а раздел о фундаментальных технологиях экосистемы хранилищ VMware)

Мы уже немало писали о платформе виртуализации VMware vSphere 6.5, которая стала доступна для загрузки недавно. Оказывается известный блоггер Вильям Лам регулярно создает и поддерживает готовый виртуальный модуль на базе ESXi, а недавно он обновил его до последней версии платформы - VMware ESXi 6.5 Virtual Appliance.

Этот виртуальный модуль в формате OVA создан для того, чтобы развернуть хост-серверы ESXi в виде виртуальных машин на платформе vSphere в целях обучения и тестирования. Помните, что VMware не поддерживает вложенную (nested) виртуализацию в производственной среде.

Вот конфигурация виртуального модуля:

• GuestType: ESXi 6.5[новое]
• Virtual Hardware 11 [новое]
• 2 vCPU
• 6 GB памяти
• 2 x VMXNET vNIC
• 1 x PVSCSI Adapter [новое]
• 1 x 2GB HDD (под установку самого ESXi)
• 1 x 4GB SSD (для использования с vSAN, по умолчанию пустой)
• 1 x 8GB SSD (для использования с vSAN, по умолчанию пустой)
• Добавлены параметр VHV (подробнее)
• Добавлены параметры dvFilter Mac Learn в VMX-файл (подробнее)
• Добавлены параметр disk.enableUUID в VMX-файл
• VSAN-трафик тэгируется на интерфейсе vmk0
• Отключенный VSAN device monitoring для целей тестирования (подробнее)
• При создании нового тома VMFS будет использоваться новая версия VMFS 6 [новое]
• Включенный sparse swap (подробнее) [новое]

Для запуска виртуального ESXi 6.5 вам потребуется как минимум VMware vSphere 6.0 Update 2. Кстати, а вот какие улучшения появились для виртуального ESXi, которые можно опробовать в версии 6.5:

• Поддержка Paravirtual SCSI (PVSCSI)
• GuestOS Customization
• Поддержка ESXi 6.5 со стороны vSphere 6.0 Update 2
• Поддержка Virtual NVMe

Скачать виртуальный модуль VMware ESXi 6.5 Virtual Appliance можно по этой ссылке.

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

А недавно на сайте blog.igics.com появился интересный и полезный PowerCLI-сценарий, который позволит вам вывести в одном гриде (или в файл) все виртуальные машины и версии VMware Tools в них. Вы, конечно же, можете посмотреть версии VMware Tools в vSphere Client, но если у вас большая инфраструктура, да еще и несколько серверов vCenter, то следить за версиями тулзов во всех виртуальных машинах через клиент будет затруднительно.

И тут на помощь вам придет следующий скрипт:

###################################################################################################################################### 

# Author: David Pasek 

# E-mail: david.pasek@gmail.com 

# Twitter: david_pasek 

# Creation Date: 2016-11-25 

# 

# Use case: 

#  Key use case of this script is to report VMtools from all VMs in vCenter 

# 

# Disclaimer: 

#  Use it on your own risk. Author is not responsible for any impacts caused by this script. 

###################################################################################################################################### 

# 

# CHANGE FOLLOWING VARIABLES BASED ON YOUR SPECIFIC REQUIREMENTS 

# vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv 

# 

# Report type - table, grid, file, csv-file 

$REPORT_TYPE = "csv-file" 

# Report file name without file extension. Extension is automatically added. File is created in current working directory. 

$REPORT_FILE_NAME = "report-vmtools" 

###################################################################################################################################### 

Clear-Host 

# We need VMware PowerCLI snapin 

$o = Add-PSSnapin VMware.VimAutomation.Core 

$o = Set-PowerCLIConfiguration -InvalidCertificateAction Ignore -Confirm:$false 

# Connect to vCenter 

Write-Host "Connecting to vCenter ..." 

$VC = Read-Host "Enter one vCentre Server or multiple vCenter servers delimited by comma." 

Write-Host "Enter vCenter credentials ..." 

$CRED = Get-Credential 

Connect-VIServer -Server $VC -Credential $CRED -ErrorAction Stop | Out-Null 

# Add new property (ToolsVersion) to VM 

New-VIProperty -Name ToolsVersion -ObjectType VirtualMachine -ValueFromExtensionProperty 'Config.tools.ToolsVersion' -Force | Out-Null 

# Initalize report 

$Report = @() 

foreach ($vm in Get-VM) { 

# Numbers mapping is from https://packages.vmware.com/tools/versions 

Switch ($vm.ToolsVersion) { 

7302 {$GuestToolsVersion = "7.4.6"} 

7303 {$GuestToolsVersion = "7.4.7"} 

7304 {$GuestToolsVersion = "7.4.8"} 

8192 {$GuestToolsVersion = "8.0.0"} 

8194 {$GuestToolsVersion = "8.0.2"} 

8195 {$GuestToolsVersion = "8.0.3"} 

8196 {$GuestToolsVersion = "8.0.4"} 

8197 {$GuestToolsVersion = "8.0.5"} 

8198 {$GuestToolsVersion = "8.0.6"} 

8199 {$GuestToolsVersion = "8.0.7"} 

8290 {$GuestToolsVersion = "8.3.2"} 

8295 {$GuestToolsVersion = "8.3.7"} 

8300 {$GuestToolsVersion = "8.3.12"} 

8305 {$GuestToolsVersion = "8.3.17"} 

8306 {$GuestToolsVersion = "8.3.18"} 

8307 {$GuestToolsVersion = "8.3.19"} 

8384 {$GuestToolsVersion = "8.6.0"} 

8389 {$GuestToolsVersion = "8.6.5"} 

8394 {$GuestToolsVersion = "8.6.10"} 

8395 {$GuestToolsVersion = "8.6.11"} 

8396 {$GuestToolsVersion = "8.6.12"} 

8397 {$GuestToolsVersion = "8.6.13"} 

8398 {$GuestToolsVersion = "8.6.14"} 

8399 {$GuestToolsVersion = "8.6.15"} 

8400 {$GuestToolsVersion = "8.6.16"} 

8401 {$GuestToolsVersion = "8.6.17"} 

9216 {$GuestToolsVersion = "9.0.0"} 

9217 {$GuestToolsVersion = "9.0.1"} 

9221 {$GuestToolsVersion = "9.0.5"} 

9226 {$GuestToolsVersion = "9.0.10"} 

9227 {$GuestToolsVersion = "9.0.11"} 

9228 {$GuestToolsVersion = "9.0.12"} 

9229 {$GuestToolsVersion = "9.0.13"} 

9231 {$GuestToolsVersion = "9.0.15"} 

9232 {$GuestToolsVersion = "9.0.16"} 

9233 {$GuestToolsVersion = "9.0.17"} 

9344 {$GuestToolsVersion = "9.4.0"} 

9349 {$GuestToolsVersion = "9.4.5"} 

9350 {$GuestToolsVersion = "9.4.6"} 

9354 {$GuestToolsVersion = "9.4.10"} 

9355 {$GuestToolsVersion = "9.4.11"} 

9356 {$GuestToolsVersion = "9.4.12"} 

9359 {$GuestToolsVersion = "9.4.15"} 

9536 {$GuestToolsVersion = "9.10.0"} 

9537 {$GuestToolsVersion = "9.10.1"} 

9541 {$GuestToolsVersion = "9.10.5"} 

10240 {$GuestToolsVersion = "10.0.0"} 

10245 {$GuestToolsVersion = "10.0.5"} 

10246 {$GuestToolsVersion = "10.0.6"} 

10247 {$GuestToolsVersion = "10.0.8"} 

10249 {$GuestToolsVersion = "10.0.9"} 

10252 {$GuestToolsVersion = "10.0.12"} 

10272 {$GuestToolsVersion = "10.1.0"} 

0   {$GuestToolsVersion = "Not installed"} 

2147483647 {$GuestToolsVersion = "3rd party - guest managed"} 

default {$GuestToolsVersion = "Unknown"} 

} 

$vminfo = New-Object -Type PSObject -Property @{ 

Name = $vm.Name 

VMhardwareVersion = $vm.Version 

ToolsVersion = $vm.ToolsVersion 

GuestToolsVersion = $GuestToolsVersion 

} 

$Report += $vminfo 

} 

# Show report 

Switch ($REPORT_TYPE) { 

"grid"   { $Report | select Name,VMhardwareVersion,ToolsVersion,GuestToolsVersion | Out-GridView } 

"file"   { $Report | select Name,VMhardwareVersion,ToolsVersion,GuestToolsVersion | Out-File -FilePath "$REPORT_FILE_NAME.txt" } 

"csv-file" { $Report | select Name,VMhardwareVersion,ToolsVersion,GuestToolsVersion | export-csv "$REPORT_FILE_NAME.csv" } 

default  { $Report | select Name,VMhardwareVersion,ToolsVersion,GuestToolsVersion | Format-Table } 

} 

Disconnect-VIserver -Server $VC -Force -Confirm:$false

Форму отчета можно редактировать в переменной $REPORT_TYPE, которая задает одно из следующих представлений:

• Стандартный вывод таблицы PowerShell в терминале (значение table)
• Представление PowerShell GridView (grid)
• Текстовый файл, содержащий таблицу (file)
• Файл Comma separated values (csv-file)

Прогнав скрипт, мы получим вот такой результат, из которого можно сделать вывод о том, в каких виртуальных машинах нужно обновить VMware Tools (показывается еще и Virtual Hardware Version):

Как многие из вас знают, совсем недавно компания VMware сделала доступной для скачивания новую версию серверной платформы виртуализации VMware vSphere 6.5. Традиционно, с каждой новой версией происходит увеличение максимумов конфигурации различных компонентов платформы. Приведем их сравнение ниже:

Хосты VMware ESXi 6.5 и виртуальные машины:

Серверы vCenter:

И познавательная инфографика максимальных конфигураций платформы виртуализации ESX/ESXi от первой версии до 6.5 от virten.net (кликабельно):

Ну и, конечно, полезно посмотреть документ "Configuration Maximums vSphere 6.5", который был также обновлен с выходом новой версии платформы.

Как мы уже писали, в новой версии VMware vSphere 6.5 компания VMware существенно улучшила функции виртуального модуля VMware vCenter Server Appliance (vCSA). В частности, в него был добавлен VMware Update Manager (VUM), который по традиции также идет отдельным разделом и диском VMDK, как и остальные сервисы. Расскажем ниже об увеличении раздела диска vCSA, которое описано в статье Вильяма Лама.

Давайте взглянем на таблицу разделов vCSA 6.5, каждому из которых соответствует диск VMDK, в сравнении с vSphere 6.0:

Как мы видим, кое-где изменились размеры стандартных разделов, для Image Builder поменялась точка монтирования, а также добавился отдельный раздел VUM на 100 гигабайт, которого не было раньше.

Размер каждого из разделов можно менять на горячую в настройках ВМ, ну а потом нужно из гостевой ОС vCSA расширить раздел на образовавшееся свободное пространство диска. Вот какие изменения произошли в версии vSphere 6.5 на эту тему:

• Теперь вместо команды vpxd_servicecfg для расширения логического тома нужно использовать следующий скрипт:
  /usr/lib/applmgmt/support/scripts/autogrow.sh
• Помимо расширения раздела из SSH, это можно сделать через интерфейс Virtual Appliance Management Interface (VAMI) REST API, который можно вызвать удаленно методом POST /appliance/system/storage/resize.

Посмотрим на расширение раздела с Net Dumper (VMDK9) с помощью нового VAMI API.

Выполним команду df -h, чтобы вывести таблицу разделов на vCSA:

Теперь в vSphere Client идем в настройки виртуальной машины vCSA и переходим в раздел управления дисками, где увеличиваем размер девятого виртуального диска с 1 ГБ до 5 ГБ:

Затем идем в браузере по адресу https://[VCSA-HOSTNAME]/apiexplorer, где выбираем пункт "appliance" в разделе Select API и нажимаем кнопку Login, после чего вводим логин/пароль от vCenter Server:

Скроллим до операции POST /appliance/system/storage/resize и раскрываем ее, чтобы увидеть детали:

Теперь нажимаем кнопку "Try it out!" и, в случае успешного выполнения, код ответа (Response Code) будет 200. Также эту же операцию можно выполнить и через PowerCLI:

Connect-CisServer -Server 192.168.1.150 -User administrator@vghetto.local -Password VMware1!

$diskResize = Get-CisService -Name 'com.vmware.appliance.system.storage'

$diskResize.resize()

В итоге, результат будет виден в выводе команды df: раздел, как и виртуальный диск VMDK, увеличился до 5 ГБ:

Представляем очередной гостевой пост компании ИТ-ГРАД, посвященный инфраструктуре VMware vCloud Director. Как часто вы сталкиваетесь с проблемами в облачном окружении, устранить которые можно обходными путями по причине отсутствия конечного решения? Одна из таких проблем – потеря сетевого подключения у виртуальных машин на базе ОС Windows Server 2012/R2 с сетевыми адаптерами E1000/E1000e в облаке IaaS.

Многие из вас пользуются продуктом StarWind Virtual SAN для создания надежной и отказоустойчивой инфраструктуры хранилищ под виртуализацию VMware vSphere и Microsoft Hyper-V. С помощью этого продукта можно построить недорогую инфраструктуру небольшого офиса или филиала, начиная с двух серверов VMware ESXi или Hyper-V.

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

Но сегодня мы хотим рассказать о главной полезности - блоге о технологиях виртуализации StarWind.

Большой плюс этого блога - он не привязан к продуктам StarWind и даже к сфере виртуальных хранилищ. Если вы посмотрите на правую колонку авторов (да, автор VM Guru там тоже есть), то увидите там нескольких популярных блоггеров в сфере виртуализации. Пишут они на самые разные темы, последняя статья, как вы видите, о развертывании SQL Server 2016 на Windows Server Core.

Поэтому подписывайтесь и следите за обновлениями - https://www.starwindsoftware.com/blog/.

Там реально много интересного и полезного! Обновляется блог в последнее время почти каждый день.

Представляю вам функцию Compare-VMHost из моего PowerCLI модуля Vi-Module, которая позволяет сравнивать один или группу хостов ESXi с эталонным хостом. Что именно будет сравниваться, регулируется параметром –Compare. На данный момент функция умеет сравнивать по следующим критериям...

Сразу после конференции VMworld 2016 (напоним наши последние новости тут и тут), компания VMware открыла запись на бета-программу новой версии решения Virtual SAN.

Дункан Эппинг уже рассказал о трех новых возможностях обновленной версии VSAN:

• Программное шифрование неиспользуемых данных (Data at rest).
• Технология Nested Fault Domains (FDs), которая обеспечивает двухуровневую защиту "растянутых" кластеров (stretched clusters) - локально и между сайтами. Получается RAID 1 между сайтами, а внутри сайта можно организовать RAID 1, 5 или 6.
• Новые улучшения с точки зрения средств управления виртуальной инфраструктурой - интеграция со средством vReealize Automation, отправка состояния жизнедеятельности на vCenter (healthchecks), мониторинг сетевой активности кластеров хранилищ и другое.

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

Некто Kim Bottu в своем блоге опубликовал интересный калькулятор, предназначенный для определения того, сколько хостов, хранилища, физических/виртуальных процессоров, памяти и кэша вам потребуется, чтобы поддерживать кластеры VMware Virtual SAN для вашей инфраструктуры виртуальных хранилищ.

VMware VSAN 6.2 Online resource calculator представляет собой Excel-таблицу, размещенную в облаке Microsoft OneDrive, в которой показаны только редактируемые поля для ввода данных, влияющие на результат (а параметры, которые используются в качестве исходных данных, можно посмотреть в таблице, начиная с ячейки EO:1660).

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

В синей (верхней) области таблицы данные параметры рассчитываются для All-Flash архитектуры кластера Virtual SAN, а зеленая часть предназначена для расчетов гибридной архитектуры (обычные HDD-диски для данных, а SSD-носители - для кэша).

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

Калькулятор весьма интересный, доступ к нему можно получить по этой ссылке. Кроме того, напомним, что мы писали еще об одном калькуляторе для VMware Virtual SAN от компании VMware, который также помогает вам проводить сайзинг инфраструктуры VSAN и считать совокупную стоимость владения такой инфраструктурой (TCO - total cost of ownership). В принципе, ничто вам не мешает воспользоваться обоими калькуляторами и сравнить результаты, которые должны, по идее, более-менее сходиться.

Очень часто мне, как и любому администратору виртуальной инфраструктуры VMware, требуется знать версию того или иного объекта. Это может быть версия VMTools/vHardware виртуальной машины или версия vSphere хоста ESXi или версия VMFS-датастора (продолжите список сами). И каждый раз вы начинаете судорожно вспоминать, как это делается, где и какой скрипт искать или пускаетесь в поиски по форумам или обращаетесь к доктору Google).

Вильям Лам написал интересный пост об изменении приветственного экрана физической консоли VMware ESXi. Некоторые из вас знают, что внешний вид DCUI-консоли ESXi можно менять в файле /etc/vmware/welcome.

Но руками залезать в него не нужно, вместо этого можно использовать расширенную настройку ESXi Advanced Setting, которая называется Annotations.WelcomeMessage. Ее можно изменить с помощью сценария PowerCLI / PowerShell.

Часто администраторам нужно узнать, на каком из хостов находится виртуальная машина, например, это сервер vCenter, который выключен по тем или иным причинам. В этом случае поможет вывод имен виртуальных машин прямо в физическую DCUI консоль сервера ESXi, к которой можно получить доступ напрямую с сервера или по SSH.

Ниже приведен PowerCLI-скрипта для описанного сценария, в котором все просто и понятно относительно того, как устанавливается рассмотренная выше расширенная настройка для вывода количества и списка виртуальных машин:

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.

Многие из вас используют решение для резервного копирования виртуальных сред - Veeam Backup and Replication, о котором мы часто пишем. Многие, да не все. Те некоторые из вас, кто еще сомневается, подойдет ли это решение для вашей виртуальной инфраструктуры, могут покликать интерактивное демо консоли продукта, где представлены все его основные возможности:

Чтобы начать самостоятельно изучать функциональность консоли, просто выберите одну из понравившихся возможностей, например, кликнем на Verified Protection и выберем функцию SureBackup, которая позволяет убеждаться в том, что резервные копии, которые вы сделали, могут быть восстановлены в производственной среде:

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

Ходим по шагам мастера создания задачи New SureBackup Job и смотрим попутно на возможные настройки и интеграции:

Самое интересное в бэкапе - это восстановление. Например, в разделе High Speed Recovery можно увидеть, как восстанавливаются отдельные файлы виртуальных машин с гостевой ОС Linux:

Какие-то фичи показывают из восьмой версии Veeam Backup and Replication, а какие-то из девятой (с обновленной и более современной консолью продукта). Например, вот мастер восстановления объектов для Oracle:

В общем, очень полезная штука, чтобы понять, какие возможности на деле предоставляет продукт Veeam B&R. Кликайте!

Зачастую в тестовом окружении вам нужно создать несколько томов 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 хостов не работает.