На проходящей сейчас в Сан-Франциско конференции VMworld 2014 компания VMware представила несколько интересных анонсов, которые (как всегда) открывают много возможностей для ИТ-инфраструктур различного масштаба. Одним из таких анонсов стал выпуск решения VMware EVO:RAIL, предназначенного для построения конвергентной инфраструктры.

Почти три года назад мы писали про средство VMware I/O Analyzer, предназначенное для генерации нагрузки и анализа статистики ввода-вывода хостов VMware ESXi, доступное на сайте проекта VMware Labs. Не так давно вышло обновление этого средства, которое, как оказалось, живет и развивается.

VMware I/O Analyzer поставляется в виде виртуального модуля (готовой ВМ), предоставляющего администраторам следующие возможности:

• Интегрированный фрейворк для тестирования производительности хранилищ средствами генераторов нагрузки.
• Готовый к развертыванию виртуальный модуль (управляющая ВМ и "воркеры" - генераторы нагрузки).
• Прост в настройке и возможность исполнения тестов на одном или нескольких хостах ESX/ESXi.
• Возможность просмотра результатов производительности как на уровне хоста, так и на уровне гостевой ОС.
• Возможность экспорта данных для последующего анализа.
• Средства "повторения" нагрузки на хранилища путем ее воспроизведения из трейса ввода-вывода.
• Возможность загрузки трейсов ввода-вывода для автоматического извлечения необходимых метрик.
• Графическая визуализация метрик и результатов анализа производительности.

В обновленном VMware I/O Analyzer 1.6.x появились следующие возможности:

• Улучшенный планировщик заданий ввода-вывода.
• Сам виртуальный модуль теперь на платформе SLES 64-bit, а сервер на Tomcat 6.
• Экспериментальная поддержка статистик клиента NFS.
• Возможность использования непостоянной (non-persistent) конфигурации (без сохранения настроек).
• Сама ВМ с I/O Analyzer теперь версии 7, что позволяет запускать и использовать ее в ESX/ESXi 4.x.
• Улучшения на бэкэнде, позволяющие поддерживать до 240 и более генераторов нагрузки.

На самом деле с 2011 года много что изменилось в этом продукте, поэтому ознакомьтесь с юзер-гайдом, в котором есть история добавления фичей по версиям.

Скачать VMware I/O Analyzer можно по этой ссылке. Очень хорошо, что подобные утилиты не ограничиваются одним релизом, а развиваются и обрастают функционалом.

Если вы хотите, чтобы никто не делал vMotion конкретной виртуальной машины с конкретного сервера VMware ESXi, то нужно просто разослать письмо администраторам vSphere с просьбой этого не делать. Но есть еще один способ, который поведал нам Frank Denneman - хотя он тоже имеет ограниченные условия применения. Ну и не забываем, что есть способ путем задания правил механизма балансировки VMware DRS (однако, не у всех по лицензии DRS есть).

В этом способе есть один существенный минус - в то время, как он не позволяет пользователю двинуть виртуальную машину через vMotion вручную, смигрировать машину можно будет через перевод хоста ESXi в Maintenance mode, так как делается это не под аккаунтом пользователя, а под системной учетной записью (System). Но режим обслуживания используется редко, и хотя бы для ручных операций это можно будет сделать. Ну и имейте в виду, что механизм VMware HA также может перезапустить машину на другом хосте в случае сбоя, наплевав на все.

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

Итак, добавляем роль No-vMotion в vSphere Web Client:

1. Заходим в vCenter как administrator.
2. Идем на домашний экран и переходим в Roles на экране Administration.
3. Выбираем действие создать роль (зеленый плюс).
4. Выбираем "All Priveleges", скроллимся до категории "Resource" и отчекиваем следующие привилегии,

• Migrate powered off virtual machine
• Migrate powered on virtual machine
• Query vMotion

Далее добавляем пермиссию для виртуальной машины для нужного администратора/группы:

1. Выбираем "Host and Clusters" и находим нужную ВМ на вкладке Manage.
2. Выбираем пункт "Permissions" и кликаем на добавление пермиссии (зеленый плюс).
3. Нажимаем "Add" и выбираем пользователя или группу, которым мы хотим запретить vMotion этой виртуальной машины.
4. В правой части экрана выбираем роль "No-vMotion" и нажимаем "Ok".

Убеждаемся, что роль применена для данного пользователя к данному объекту (на остальные пермиссии это не повлияет):

Попробуем смигрировать эту виртуальную машину пользователем FrankD - видим, что опция "Migrate" загреена:

Но вот возможность перевода в Maintenance mode, к сожалению, по-прежнему активна:

Кто-нибудь знает более простой и надежный способ?

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

В VMware vSphere 5.0 компания VMware обновила свою кластерную файловую систему до версии VMFS 5. При этом в vSphere 5.x тома VMFS-3 поддерживаются, а также доступен апгрейд с третьей версии на пятую (напомним, что в пятой версии появилась поддержка дисков в 64 ТБ). Более подробная информация об апгрейде VMFS приведена в документе "VMware vSphere VMFS-5 Upgrade Considerations".

Так вот, апгрейженный том VMFS-5 имеет ограниченную функциональность в отличие от созданного заново тома, а именно:

• Апгрейженный том продолжает использовать исходный размер блока (в новой версии VMFS 5.x размер блока унифицирован - 1 МБ). Это иногда может привести к чрезмерному потреблению места на диске (если много мелких файлов), но что самое неприятное - к падению производительности Storage vMotion.
• Апгрейженный том не имеет таких возможностей как Sub-Block Size, увеличенное число файлов на хранилище и разметка GPT.
• Обновленный том VMFS-5 продолжает иметь раздел, начинающийся с сектора 128, это может вызвать некоторые проблемы с выравниванием блоков. Новый раздел VMFS 5 начинается с сектора 2048.

Таким образом, получается, что лучше создать новый том VMFS-5, чем обновлять существующие тома VMFS-3. Но это все было давно, ну а вдруг у вас остались такие вот обновленные VMFS, из-за которых у вас иногда что-то работает не так?

Проверить, какой у вас том, можно в vSphere Client или vSphere Web Client. Смотрим размер блока:

Если он не 1 МБ - то это точно апгрейженный том, и его неплохо бы пересоздать. А вот если 1 МБ, то вовсе не факт, что это новый том (как раньше, так и сейчас был такой размер блока). В этом случае вам поможет вот этот скрипт, который выводит список всех томов VMFS и показывает, новый это том или апгрейженный.

Запустить этот скрипт можно таким образом:

1. Загружаем его и переименовываем его в check_vmfs.sh, убрав расширение .doc.

2. Копируем скрипт на виртуальный модуль vMA. Можно также запускать скрипт локально на сервере ESXi - для этого его туда надо загрузить через Veeam FastSCP или WinSCP.

3. Включаем демон SSH на хостах ESXi, где вы будете выполнять скрипт. (в vSphere Client нужно зайти в Configuration \ Software \ Security profile \ Services \ SSH).

4. Удаленно выполнить скрипт на серверах через SSH можно с помощью команды:

ssh root@<ESXi IP> 'ash -s' < ./check_vmfs.sh

Далее попросят пароль и будет выведен результат работы скрипта.

Здесь нужно смотреть на значение Sub Blocks, если Sub Blocks = 3968, то это апгрейженный VMFS-5, и его неплохо бы пересоздать. У нормального VMFS-5 значение Sub Blocks равно 32000.

Такое вот работающее правило "лучше переставлять, чем обновлять". Любители PowerShell могут также посмотреть вот эту статью.

Компании VMware и Intel в партнерстве выпустили новый документ "Intel Data Plane Development Kit with VMware vSphere" (DPDK), который описывает работу с данной библиотекой приложений Linux User Space. Она позволяет на высоком уровне работать с подсистемой ввода-вывода и сетевого взаимодействия и на программном уровне обрабатывать то, что ранее необходимо было делать только на аппаратном для высоконагруженных систем, например, Application-specific integrated circuits (ASICs) и Field programmable gate arrays (FPGAs).

Данный DPDK с использованием техник паравиртуализации позволяет напрямую обращаться к аппаратным функциям оборудования или виртуальных устройств VMware vSphere.

Решение DPDK with VMware vSphere может быть использовано для миграции систем (обычно в сфере телекома и какого-то необычного сетевого взаимодействия), которые раньше были жестко завязаны на аппаратные функции "железа", на платформу VMware vSphere.

При использовании DPDK можно взаимодействовать со следующими механизмами VMware vSphere:

• Виртуальный сетевой адаптер VMXNET3
• Коммутаторы vSwitch и Virtual Distributed Switch
• Прямой проброс устройств через VMware vSphere DirectPath I/O или технологию SR-IOV

Стандартная реализация паравиртуализационного взаимодействия гостевой ОС через vSwitch и VDS выглядит так:

Если речь идет о пробросе устройств напрямую в ОС, то схема выглядит следующим образом:

Больше интересных подробностей можно узнать в самом документе.

Вильям Лам описал интересный способ по запуску виртуальных машин с Mac OS X на борту в виртуальном же VMware ESXi, который установлен на платформе VMware Fusion в хостовой Mac OS X. Напомним, что этот вариант запуска виртуальной машины не противоречит лицензионному соглашению Apple, предписывающему запускать Mac OS только на собственном железе.

Для того, чтобы убедиться в том, что гостевая ОС выполняется на оборудовании Apple, сервер ESXi использует механизм Apple SMC (System Management Controller).

В конфигурации, приведенной выше, ESXi по умолчанию не пробрасывает функции SMC в гостевую ОС, но это можно исправить, добавив специальные инструкции в Advanced VM Settings настроек виртуальной машины (или напрямую в VMX-файл):

smc.present = "TRUE"
smbios.reflectHost = "TRUE"

Проверить, что настройки эти зафиксировались можно через MOB (Managed Object Browser). Для этого перейдем по ссылке:

https://<ESXI_IP>/mob/?moid=ha-host&doPath=hardware

и увидим вот такую картинку (в противном случае настройка будет установлена в false):

После этого спокойно можно запускать Mac OS X в виртуальной машине на ESXi через VMware Fusion:

За что вот пользователи любят VMware, так это за то, что она вот такие экзотические штуки предусматривает.

Многие администраторы, которым требуется создание пользователей VMware vSphere на хостах ESXi используют vSphere Client.

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

Надо использовать команду adduser, которая исключена из окружения командной строки (раньше она была на ESX), но по-прежнему доступна через busybox.

Добавляем нового пользователя так:

# /usr/lib/vmware/busybox/bin/busybox adduser -s /bin/sh -G root -h / steve

здесь:

• -G - группа пользователя (добавляем рута)
• -h - его домашняя директория
• steve - понятное дело, имя пользователя

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

Есть команда, которая не предлагает ввести пароль, но создает пользователя без пароля:

# /usr/lib/vmware/busybox/bin/busybox adduser -s /bin/sh -G root -h / -D steve

Однако создавать пользователя без пароля - моветон. Поэтому следующей командой в скрипте можно задать ему нужный пароль:

# echo testpass | passwd steve --stdin

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

Как знают те из вас, кто следит за развитием технологий VMware, есть такой механизм как vFRC (vSphere Flash Read Cache), представляющий собой распределенный кэш на SSD-накопителях локальных дисков серверов ESXi (ранее он имел рабочее название vFlash). Не так давно мы писали про обзорный документ "What’s New in VMware vSphere Flash Read Cache", а на днях вышел более глубокий технический документ "Performance of vSphere Flash Read Cache in VMware vSphere 5.5", посвященный производительности vFRC.

Помимо всего прочего, в документе рассматривается способ получения информации о структуре и содержимом кэша vFRC. Сделать это можно с помощью команды:

~ # esxcli storage vflash cache list

Эта команда выведет список идентификаторов кэша для VMDK-дисков, для которых включена vFRC. Далее с помощью следующей команды можно узнать детали конкретного ID кэша:

 # esxcli storage vflash cache get –c <cache-identifier>

Несколько больше информации (включая объем закэшированных данных) можно почерпнуть из команд, приведенных ниже. Для этого потребуется создать переменную CacheID:

~ # cacheID='vsish -e ls /vmkModules/vflash/module/vfc/cache/'
~ # vsish -e get /vmkModules/vflash/module/vfc/cache/${cacheID}stats

В результате будет выведено что-то подобное:

vFlash per cache instance statistics {
cacheBlockSize:8192
numBlocks:1270976
numBlocksCurrentlyCached:222255
numFailedPrimaryIOs:0
numFailedCacheIOs:0
avgNumBlocksOnCache:172494
read:vFlash per I/O type Statistics {
numIOs:168016
avgNumIOPs:61
maxNumIOPs:1969
avgNumKBs:42143
maxNumKBs:227891
avgLatencyUS:16201
maxLatencyUS:41070
numPrimaryIOs:11442
numCacheIOs:156574
avgCacheLatencyUS:17130
avgPrimaryLatencyUS:239961
cacheHitPercentage:94
}
write:vFlash per I/O type Statistics {
numIOs:102264
avgNumIOPs:307
maxNumIOPs:3982
avgNumKBs:10424
maxNumKBs:12106
avgLatencyUS:3248
maxLatencyUS:31798
numPrimaryIOs:102264
numCacheIOs:0
avgCacheLatencyUS:0
avgPrimaryLatencyUS:3248
cacheHitPercentage:0
}
rwTotal:vFlash per I/O type Statistics {
numIOs:270280
avgNumIOPs:88
maxNumIOPs:2027
avgNumKBs:52568
maxNumKBs:233584
avgLatencyUS:11300
maxLatencyUS:40029
numPrimaryIOs:113706
numCacheIOs:156574
avgCacheLatencyUS:17130
avgPrimaryLatencyUS:27068
cacheHitPercentage:58
}
flush:vFlash per operation type statistics {
lastOpTimeUS:0
numBlocksLastOp:0
nextOpTimeUS:0
numBlocksNextOp:0
avgNumBlocksPerOp:0
}
evict:vFlash per operation type statistics {
lastOpTimeUS:0
numBlocksLastOp:0
nextOpTimeUS:0
numBlocksNextOp:0
avgNumBlocksPerOp:0
}
}

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

Как известно, огромное количество системных администраторов используют бесплатную платформу виртуализации VMware ESXi Free (он же vSphere Hypervisor). Почти все они интересуются вопросом, как организовать надежное хранилище для виртуальных машин, не покупая дорогостоящие аппаратные СХД.

Как раз таким ИТ-специалистам будет интересно послушать бесплатный вебинар "Hardware agnostic Virtual SAN for VMware ESXi Free", который пройдет 7 августа в 22-00 по московскому времени.

На мероприятии будет рассказано о технических аспектах решения номер 1 на рынке для создания программных iSCSI-хранилищ под VMware vSphere - StarWind Virtual SAN (мы писали о нем вот тут), а также об экономических составляющих решения. Напомним, что у продукта есть бесплатное издание с возможностями отказоустойчивости узлов хранилищ (ограничение только по объему хранения), что является беспрецедентным предложением на рынке.

Ну и пришедшим на вебинар - невероятный бонус: будет разыгран один бесплатный билет на конференцию VMware VMworld 2014 US, а также пять бесплатных билетов на выставку VMworld US 2014 (expo passes). Победитель будет выбран случайным образом в конце мероприятия.

ЗАРЕГИСТРИРОВАТЬСЯ

Многие начинающие администраторы VMware vSphere задаются вопросом, как правильно установить время на хосте VMware ESXi. Те из них, кто привык делать это в ОС Linux, могут попробовать выполнить команду:

Однако будет вот такой результат:

date: option requires an argument -- s  
BusyBox v1.19.0 (2012-02-29 14:20:08 PST) multi-call binary.     
Usage: date [OPTIONS] [+FMT] [TIME]     
Display time (using +FMT), or set time             

[-s,--set] TIME Set time to TIME          
-u,--utc        Work in UTC (don't convert to local time)          
-R,--rfc-2822   Output RFC-2822 compliant date string          
-I[SPEC]        Output ISO-8601 compliant date string                          
				 SPEC='date' (default) for date only,                          
				 'hours', 'minutes', or 'seconds' for date and                          
				 time to the indicated precision          
-r,--reference FILE     Display last modification time of FILE          
-d,--date TIME  Display TIME, not 'now'          
-D FMT          Use FMT for -d TIME conversion     

Recognized TIME formats:          
				 hh:mm[:ss]          
				 [YYYY.]MM.DD-hh:mm[:ss]          
				 YYYY-MM-DD hh:mm[:ss]          
				 [[[[[YY]YY]MM]DD]hh]mm[.ss]     

~ # date -s 2014-07-12 12:00:00  
date: Setting date not supported; use <esxcli system time set>

Обратим внимание на последнюю строчку, которая говорит нам о том, что команда date не поддерживается для установки даты и времени, вместо нее нужно использовать утилиту esxcli. Выполняем указанную команду:

~ # esxcli system time set
You must specify one of year, month, day, hour, minute or second

Вызовем помощь:

~ # esxcli system time set --help
Usage: esxcli system time set [cmd options]  

Description:
set Set the system clock time. Any missing parameters will default to the current time  

Cmd options:
-d|--day=<long> Day
-H|--hour=<long> Hour
-m|--min=<long> Minute
-M|--month=<long> Month
-s|--sec=<long> Second
-y|--year=<long> Year

Теперь все стало ясно: чтобы установить, например, октябрь месяц, вызываем команду с параметром "-M 10", то есть:

~ # esxcli system time set -M 10

Проверяем, что октябрь установился:

~ # date
Mon Oct 12 10:43:52 UTC 2014

Аналогично устанавливаем год, день, часы и минуты, используя параметры -y, -d, -H, -m, соответственно.

Ну а проверить можно не только с помощью date, но и через esxcli, заменив set на get:

~ # esxcli system time get
2014-07-12T10:59:14Z

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

Ниже приведен способ, как обновить триал VMware vSphere снова до 60 дней. Общая процедура такова:

• Отсоединяем хост ESXi от vCenter
• Заходим на ESXi через DCUI или по SSH
• Удаляем файлы /etc/vmware/vmware.lic и /etc/vmware/license.cfg
• Перезагружаем сервер
• Присоединяем хост к vCenter

После этого вы получите вот такую картинку - хост затриалится еще на 60 дней:

Команды удаления указанных файлов и перезагрузки следующие:

rm -f /etc/vmware/vmware.lic /etc/vmware/license.cfg
reboot

Для VMware vSphere 5.1 и 5.5 эти файлы надо удалять после каждой перезагрузки. Делается это так:

rm -f /etc/vmware/vmware.lic /etc/vmware/license.cfg
reboot ; while true ; do
rm -f /etc/vmware/vmware.lic /etc/vmware/license.cfg
done

Для ESXi 5.1 есть альтернативный метод без перезагрузки:

rm -r /etc/vmware/license.cfg
cp /etc/vmware/.#license.cfg /etc/vmware/license.cfg
/etc/init.d/vpxa restart

Для ESXi 5.0 это тоже делается без ребута:

rm -f /etc/vmware/vmware.lic /etc/vmware/license.cfg
services.sh restart

Ну а если у вас вдруг истек триал, а вы не успели прописать лицензию на хост, то сделать это очень просто. Надо открыть файл /etc/vmware/vmware.lic (зайдя по SSH):

~# vi /etc/vmware/vmware.lic

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

Для vCenter тоже есть способ сброса триала, но не факт, что он сейчас работает:

• Создаем новый DSN к локальной базе SQL Express, где хранятся данные vCenter
• Удаляем vCenter
• Ставим vCenter заново, указав созданный DSN и убедившись, что не выбран режим overwrite

Как мы писали недавно, в новой версии платформы VMware vSphere 6, которая сейчас находится в стадии публичной беты, появились возможности использования томов VVols (о которых мы писали здесь). Сейчас эта функциональность также находится в бете и доступна для загрузки вот тут. 

Концепция VVol (она же VM Volumes) увеличивает уровень гранулярности работы хост-сервера с хранилищем за счет непосредственных операций с виртуальной машиной, минуя сущности "LUN->том VMFS->Datastore". Тома VVol является неким аналогом существующих сегодня LUN, но с меньшим уровнем гранулярности операций по сравнению с томами VMFS (последние, как правило, создаются из одного LUN). Таким образом, ВМ находится на одном VVol как всадник на лошади.

Чтобы виртуальные машины можно было создавать на томах VVols и производить с ними различные операции, нужно чтобы дисковый массив поддерживал такой интерфейс как vSphere APIs for Storage Awareness (VASA). Через этот API возможна передача функций, обычно выполняемых хостом ESXi, на сторону аппаратного хранилища. Кроме того, есть также интерфейс vSphere Storage API – Array Integration (VAAI), который также используется для offloading'а операций на сторону массива, особенно когда дело касается операций миграции и клонирования ВМ.

Давайте посмотрим, как эти два API (VASA и VAAI) работают с хранилищем при операциях клонирования виртуальных машин, которые часто нужны в инфраструктуре виртуальных ПК на базе VMware Horizon View.

Сценарий 1 - клонирование ВМ в рамках одного контейнера VVol

В этом случае через API VASA вызывается функция cloneVirtualVolume, которая полностью передает на сторону дискового массива операцию клонирования ВМ:

Сценарий 2 - клонирование ВМ в рамках разных VVol

В этом случае все зависит от того, на каких хранилищах находятся данные VVol. Если VVol-a и VVol-b находятся на двух массивах одного вендора, настроенных единообразно, и управляются одним VASA Provider, то в этом случае используется API VASA и вызывается функция cloneVirtualVolume.

Если же VVol-a и VVol-b находятся на одном массиве и настроены по-разному, либо хранилища VVol-a и VVol-b находятся на двух массивах разных вендоров или моделей, то операция через VASA API может не пройти. Тогда происходит переключение на VAAI API, который использует датамувер ESXi (vmkernel data mover) и примитивы VAAI для клонирования виртуальной машины. При этом в случае неудачи передачи операций клонирования на сторону массива датамувер может начать перемещать данные через хост ESXi (подробнее - тут):

Конечно же, предпочтительнее делать все через VASA API - такая операция пройдет быстрее, поскольку в ней не будет задействован хост ESXi. Поэтому тут важна унификация конфигурации хранилищ и дисковых массивов в инфраструктуре. Ну и надо, конечно же, смотреть, чтобы закупаемые массивы в полной мере поддерживали VASA и VAAI.

Сценарий 3 - клонирование ВМ с тома VMFS на VVol

Если получается так, что ВМ надо склонировать с тома VMFS на хранилище VVol, то тут будет работать только операция XCOPY / WRITE_SAME интерфейса VAAI.

При этом работает это только для операции в направлении VMFS->VVol, при обратном клонировании этот API использован не будет.

Узнать больше о томах VVol и позадавать вопросы на эту тему вы можете на специальной странице Virtual Volumes beta community.

Как многие из вас знают, в платформе виртуализации VMware vSphere есть множество удобных средств работы с хранилищами, включая средства позволяющие расширить том VMFS прямо из GUI клиента vSphere Client - достаточно лишь сделать Rescan HBA-адаптеров. Однако если необходимо расширить локальный том (Local VMFS), то тут встроенных средств уже нет, и все нужно аккуратно делать самому, как это описано в KB 2002461. Приведем здесь этот процесс, проиллюстрировав его скриншотами.

Бывает такое, что пользователь системы жалуется администратору виртуальной инфраструктуры VMware vSphere, что у него пропал сетевой адаптер в виртуальной машине, и она больше недоступна из внешней сети. Администратор смотрит в лог виртуальной машины (vmware-##.log) и видит там вот такое:

Mar 15 03:13:37.463: vmx| Powering off Ethernet1 
Mar 15 03:13:37.463: vmx| Hot removal done.

Это, как вы уже догадались, означает, что кто-то тыкнул на иконку "Safely Remove Hardware" в гостевой ОС и выбрал там сетевой адаптер ВМ:

Либо это было сделано случайно в vSphere Client или Web Client. Поправить это легко - надо отключить функции Hot Add для виртуальной машины.

Для этого:

• Соединяемся с хостом ESXi/ESX напрямую или через vCenter Server посредством vSphere Client.
• Выключаем виртуальную машину.
• Выбираем для нее Edit Settings и переходим на вкладку Options.
• Выбираем General > Configuration Parameters > Add Row.
• Добавляем строчку с именем devices.hotplug и значением false.
• Включаем виртуальную машину.

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

Если же вы не хотите запрещать Hot Add для всех устройств, а хотите просто спрятать возможность удаления сетевой карты из Safely Remove Hardware, то нужно сделать следующее:

• Запустить редактор реестра как Local System. Для этого можно использовать утилиту psexec Tool.
• Выполняем psexec -i -s regedit.exe.
• Идем в ветку HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum ищем наш драйвер NIC (в его названии есть VMXNET3, E1000 и т.п.).
• Установите значение ключа Capabilities на 4 единицы ниже.

Например, вот тут мы видим значение ключа 16:

Устанавливаем его на 4 меньше, то есть в значение 12:

После этого сетевой адаптер исчезнет из безопасного удаления устройств:

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

Во-первых, мы уже писали о том, что  в VMware vSphere 5.5 Update 1 был баг - если использовать NFS-хранилища, то они периодически отваливаются, переходя в состояние APD (All paths down). Это касается и VSA-хранилищ. В логах при этом наблюдается что-то вроде такого:

2014-04-01T14:35:08.074Z: [APDCorrelator] 9413898746us: [vob.storage.apd.start] Device or filesystem with identifier [12345678-abcdefg0] has entered the All Paths Down state.
2014-04-01T14:35:08.075Z: [APDCorrelator] 9414268686us: [esx.problem.storage.apd.start] Device or filesystem with identifier [12345678-abcdefg0] has entered the All Paths Down state.
2014-04-01T14:36:55.274Z: No correlator for vob.vmfs.nfs.server.disconnect
2014-04-01T14:36:55.274Z: [vmfsCorrelator] 9521467867us: [esx.problem.vmfs.nfs.server.disconnect] 192.168.1.1/NFS-DS1 12345678-abcdefg0-0000-000000000000 NFS-DS1
2014-04-01T14:37:28.081Z: [APDCorrelator] 9553899639us: [vob.storage.apd.timeout] Device or filesystem with identifier [12345678-abcdefg0] has entered the All Paths Down Timeout state after being in the All Paths Down state for 140 seconds. I/Os will now be fast failed.
2014-04-01T14:37:28.081Z: [APDCorrelator] 9554275221us: [esx.problem.storage.apd.timeout] Device or filesystem with identifier [12345678-abcdefg0] has entered the All Paths Down Timeout state after being in the All Paths Down state for 140 seconds. I/Os will now be fast failed.

В выпущенном обновлении эта ошибка была исправлена.

Во-вторых, была также исправлена ошибка безопасности в OpenSSL, которая может оказаться даже серьезнее, чем исправленный ранее баг OpenSSL Heartbleed. В ESXi существует вероятность атаки типа MiM (Man in the Middle), о которой подробнее рассказано вот тут. Этот баг в приведенном выше обновлении был также зафикшен. Кстати, в своем блоге компания VMware объявила о том, что ее команда безопасности расследует новые возможные уязвимости OpenSSL, и вот тут приведены результаты ее работы.

Чтобы скачать патч, идем на VMware Patch Portal, выбираем там продукт "ESXi Embedded & Installable", версию релиза 5.5.0 и дату - 10 июня. Получаем ссылку на патч:

Применить этот патч можно и не скачивая его с сайта VMware, а просто с помощью следующей последовательности команд:

# открываем фаервол для http

esxcli network firewall ruleset set -e true -r httpClient

# устанавливаем образ ESXi-5.5.0-20140604001-standard из хранилища VMware Online depot

esxcli software profile update -d https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml -p ESXi-5.5.0-20140604001-standard

# перезагружаем хост ESXi

reboot

Также на днях компания VMware выпустила обновления продукта vCenter Server 5.5 Update 1b:

и vCloud Director 5.5.1.2:

Оба этих исправления прежде всего несут в себе фиксы в плане безопасности протокола OpenSSL, однако там есть и другие мелкие улучшения. Рекомендуется их установить.

Надо отметить, что VMware vCenter Server Appliance не подвержен багу OpenSSL, поэтому и исправлений для него нет.

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

Доступен также лог изменений с момента прошлого документа:

В новой версии руководства есть следующие важные изменения:

• enable-VGA-Only-Mode - эта рекомендация должна быть применена для виртуальных серверов, которым не нужен графический режим (обычно он используется для VDI-инфраструктуры). То есть для веб-серверов, серверов Windows Core и т.п. нужно этот режим включить, чтобы уменьшить поверхность возможной атаки.
• disable-non-essential-3D-features - аналогично, отключаем 3D-графику для виртуальных машин, которым это не нужно.
• use-unique-roles - если у вас несколько сервисных аккаунтов, то им не нужно назначать одну роль на всех, а нужно создавать для каждого отдельную с необходимым набором привилегий для решения нужной задачи.
• change-sso-admin-password - это рекомендация сменить пароль для аккаунта administrator@vsphere.local, когда вы используете виртуальный модуль VMware vCSA (готовая ВМ с vCenter). Для обычного vCenter этот пароль просят сменить при установке. Удивительно, но этой рекомендации раньше не было.

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

Как многие знают, с выходом средства для создания отказоустойчивых кластеров хранилищ VMware Virtual SAN, строящихся на базе локальных дисков серверов ESXi, стало известно, что этот механизм интегрирован со средством серверной отказоустойчивости VMware HA.

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

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

Например, на картинке представлено разделение кластеров VMware HA и Virtual SAN на два частично пересекающихся сегмента:

Это, конечно же, плохо. Поэтому в VMware vSphere 5.5 были сделаны изменения, которые автоматически переносят сеть хартбитов кластера VMware HA в подсеть VMware Virtual SAN. Это позволяет в случае разделения сети иметь два непересекающихся в плане обоих технологий сегмента:

Вот тут и возникает 3 основных вопроса:

• Какие хранилища нужно использовать в качестве datastore heartbeat?
• Как адрес в случае изоляции хоста (isolation address) нужно использовать, чтобы надежно отличать изоляцию хоста от разделения сети на сегменты (network partitioning)?
• Какие действия в случае изоляции хостов ESXi от остальной сети (isolation responses) нужно использовать?

Ну а в статье на блогах VMware даются вот такие ответы:

1. В качестве хранилищ, использующих datastore heartbeat в данной конфигурации, предлагается использовать датасторы, прицепленные к хостам ESXi, не входящим в кластер Virtual SAN. Объясняется это тем, что в случае разделения сети VSAN, механизм VMware HA сможет координировать восстановление виртуальных машин на хостах через эти хранилища.

2. По поводу isolation address есть следующие рекомендации:

• При совместном использовании Virtual SAN и vSphere HA настройте такой isolation address, который позволит определить рабочее состояние хоста в случае отключения его от сети (сетей) VSAN. Например, можно использовать шлюз VSAN и несколько дополнительных адресов, которые задаются через расширенную настройку das.isolationAddressX (подробнее об этом - тут).
• Настройте HA так, чтобы не использовать дефолтный шлюз management network (если эта не та же сеть, что и Virtual SAN network). Делается это через настройку das.useDefaultIsolationAddress=false.
• Ну и общая рекомендация - если вы понимаете, как может быть разделен кластер с точки зрения сети, то найдите такие адреса, которые будут доступны с любого хоста при этом сценарии.

3. Ну и самое главное - действие isolation response, которое необходимо выполнить в случае, когда хост посчитал себя изолированным от других. На эту тему уже много чего писалось, но VMware объединила это вот в такие таблички:

А теперь, собственно, таблица ниже, которая объясняет от чего зависят последние 2 пункта:

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

Мы довольно часто пишем о "вложенной" виртуализации, которая позволяет запускать гипервизор VMware ESXi в виртуальной машине поверх ESXi, установленного уже на физическом сервере (nested virtualization). Для таких виртуальных ESXi есть даже свои VMware Tools. Однако, отметим сразу, что такое использование виртуализации официально не поддерживается со стороны VMware (в производственной среде), хотя и активно применяется в частном порядке ее сотрудниками, партнерами и заказчиками.

Так вот у многих администраторов есть закономерный вопрос - а надо ли лицензировать такие виртуальные ESXi? Ведь они все равно, кроме как для тестов, ни на что не годятся. Ответ прост - лицензировать надо. Об этом прямо написано в KB 2009916:

• VMware ESXi/ESX running in VMware Workstation or VMware Fusion
• VMware ESXi/ESX running in VMware ESXi/ESX
• VMware ESXi/ESX running in other third-party hypervisor solutions

Для тех, кто не хочет платить или хочет заплатить поменьше, есть 2 варианта:

• Постоянно переустанавливать ESXi в составе vSphere с триалом на 60 дней.
• Использовать бесплатный vSphere Hypervisor (он же Free ESXi) - но без vCenter.
• Использовать виртуальный ESXi, но с одним vCPU и, как следствие, платить только за одну лицензию. При этом можно поставить несколько виртуальных ядер на этот vCPU, и производительность будет почти та же, что и при нескольких процессорах. Как раз для этих целей VMware и был придуман параметр cpuid.coresPerSocket.

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

Для этого есть специальная утилита с графическим интерфейсом VSAN Observer, которая позволяет через веб-интерфейс наблюдать за кластером VSAN. По умолчанию на сервере VMware vCenter она отключена.

Чтобы включить ее, делаем следующее:

1. Если вы используете VMware vCenter Virtual Appliance, то нужно запустить Ruby-консоль следующей командой:

rvc username@localhost

Здесь вводим логин и пароль администратора vCenter.

Если вы используете vCenter Server для Windows, то эту консоль можно запустить следующим bat-файлом (логин-пароль аналогичны предыдущему пункту):

%PROGRAMFILES%\VMware\Infrastructure\VirtualCenter Server\support\rvc\rvc.bat

2. Используем команды cd и ls, чтобы перейти в рабочий каталог VSAN:

cd localhost

cd VSAN

3. Запускаем веб-сервер VSAN Observer командой:

vsan.observer ~/computers/VSAN --run-webserver --force

4. После этого запускаем консоль VSAN Observer, перейдя по ссылке:

http://<vCenter Server>:8010

На первой вкладке мы видим дэшборд с различными характеристиками хост-серверов VMware ESXi, входящих в состав кластера Virtual SAN:

На вкладке VSAN Disks (per-host) мы видим уже графики на уровне отдельных физических дисков хостов:

На вкладке VSAN Disks (deep-dive) мы смотрим детальные параметры дисков на уровне отдельного хоста ESXi, включая кэширующий SSD-диск и HDD-диски с данными.

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

На вкладке PCPU можно отслеживать параметры загрузки процессоров хост-серверов, обслуживающих кластер VSAN:

То же самое, но касательно памяти:

На вкладке Distribution можно смотреть информацию относительно баланса кластера - равномерно ли загружены его ресурсы:

Вкладка DOM Owner похожа на первую вкладку - говорят она для техподдержки VMware:

А вот вкладка VMs - полезная штука. Тут можно смотреть за производительностью на уровне отдельных виртуальных дисков конкретных ВМ, использующих ресурсы хранения кластера VSAN.

Также тут можно узнать, на каких хостах находятся реплики виртуальных дисков VMDK конкретной ВМ:

Ну а если вы хотите использовать VSAN Observer на сервере VMware vCenter под Windows, то команда ниже позволит вам добавить соответствующее правило в его сетевой экран:

netsh advfirewall firewall add rule name = "VMware RVC VSAN Observer" dir = in protocol = tcp action = allow localport = 8010 remoteip = localsubnet profile = DOMAIN

Некоторое время назад мы писали о том, как запускать вложенный гипервизор и виртуальные машины (nested VMs) на платформе VMware vSphere. В статье по ссылке показано, что можно запустить как вложенную платформу VMware ESXi, так и вложенный сервер с ролью Hyper-V, при этом можно запускать виртуальные машины в этих ВМ.

А как обстоят дела с вложением Hyper-V в Hyper-V? При попытке поставить роль Hyper-V в виртуальной машине Windows Server 2012 R2 вы получите вот такие сообщения об ошибках:

Hyper-V cannot be installed: A hypervisor is already running.

Если попробуем включить роль через PowerShell получим аналогичную ошибку:

Но саму роль Hyper-V в виртуальной машине на Windows Server включить можно. Делается это средствами утилиты по обслуживанию образов DISM.exe. Если вы используете Windows 8 как гипервизор, то потребуется скачать еще и пакет Windows Assessment and Deployment Kit (ADK) for Windows 8.

Выполняем следующие команды в консоли:

DISM /Online /Enable-Feature /FeatureName: Microsoft-Hyper-V
DISM /Online /Enable-Feature /FeatureName: Microsoft-Hyper-V-Management-Clients

Далее роль встанет, и можно запустить консоль управления виртуальными машинами.

Но при попытке запустить виртуальную машину будет выведена ошибка:

VM failed to start. Failed to start the virtual machine because one of the Hyper-V components is not running.

Для этой проблемы пока решения нет. Виртуальную машину вы не сможете запустить на Hyper-V никак. Хотя на VMware vSphere 5.x все будет прекрасно работать.

Здесь же вы только сможете сделать такие вложенные ВМ узлами Failover Cluster для целей тестирования или снятия скриншотов:

Все это происходит из-за того, что Microsoft не хочет предоставлять виртуальным машинам средства эмуляции техник аппаратной виртуализации Intel VT и AMD-V, хотя многие пользователи и спрашивают об этом. По мнению сотрудников Microsoft, которых можно встретить на форумах technet, "это не нужно".

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

На днях компания VMware выпустила очень полезный, а глвное бесплатный, онлайн-курс VMware Virtual SAN Fundamentals [V5.5], посвященный базовым принципам работы продукта и его администрирования.

Курс состоит из четырех модулей:

Module 1: Introduction to Virtual SAN

• Software-Defined Storage
• The Benefits of Virtual SAN
• Advantages of Virtual SAN over Traditional Storage and VSA.’

Module 2: Software-Defined Data Center

• Use Cases
• Virtual Desktop Infrastructure (VDI)
• Test and development
• Disaster recovery
• Management cluster storage
• DMZ
• Remote office/branch office
• POC Pre-Qualification Checklist

Module 3: Virtual SAN Architecture

• Virtual SAN Architecture
• Virtual SAN Objects and Components
• Virtual SAN prerequisites
• Virtual SAN cluster sizing requirements

Module 4: Configuring Virtual SAN (Optional)

• Enable Virtual SAN on a cluster
• Create disk group
• Storage policies
• Expand Virtual SAN cluster

Пару недель назад мы писали об уязвимости OpenSSL HeartBleed, которая коснулась виртуальной инфраструктуры VMware vSphere, а также других продуктов компании VMware. Напомним, что эта уязвимость позволяла злоумышленнику получить доступ к памяти сервера, где могут храниться логины/пароли и другая информация пользователей.

На прошлой неделе компания VMware выпустила фиксы для этого бага в виде обновлений VMware vSphere 5.5 Update 1a и VMware vSphere 5.5c, подробнее о которых написано в специальной статье KB 2076665.

Но тут, как часто бывает, вышла оказия. Нашелся еще один баг в VMware vSphere 5.5 Update 1 - оказывается, если для этого билда использовать NFS-хранилища, то они периодически отваливаются, то есть переходят в состояние APD (All paths down). Это касается и VSA-хранилищ. В логах при этом наблюдается что-то вроде такого:

2014-04-01T14:35:08.074Z: [APDCorrelator] 9413898746us: [vob.storage.apd.start] Device or filesystem with identifier [12345678-abcdefg0] has entered the All Paths Down state.
2014-04-01T14:35:08.075Z: [APDCorrelator] 9414268686us: [esx.problem.storage.apd.start] Device or filesystem with identifier [12345678-abcdefg0] has entered the All Paths Down state.
2014-04-01T14:36:55.274Z: No correlator for vob.vmfs.nfs.server.disconnect
2014-04-01T14:36:55.274Z: [vmfsCorrelator] 9521467867us: [esx.problem.vmfs.nfs.server.disconnect] 192.168.1.1/NFS-DS1 12345678-abcdefg0-0000-000000000000 NFS-DS1
2014-04-01T14:37:28.081Z: [APDCorrelator] 9553899639us: [vob.storage.apd.timeout] Device or filesystem with identifier [12345678-abcdefg0] has entered the All Paths Down Timeout state after being in the All Paths Down state for 140 seconds. I/Os will now be fast failed.
2014-04-01T14:37:28.081Z: [APDCorrelator] 9554275221us: [esx.problem.storage.apd.timeout] Device or filesystem with identifier [12345678-abcdefg0] has entered the All Paths Down Timeout state after being in the All Paths Down state for 140 seconds. I/Os will now be fast failed.

Решения для этой проблемы пока нет, поэтому рекомендуется просто откатиться на VMware vSphere 5.5 (без Update 1), если вы используете NFS-хранилища или модуль VSA.

Так вот, поэтому vSphere 5.5 Update 1 и просто vSphere 5.5 надо обновлять разными патчами для устранения уязвимости OpenSSL HeartBleed (чтобы на 5.5 не накатилась проблема с APD):

VMware ESXi 5.5, Patch Release ESXi550-201404001
Это патч только для фикса хостов ESXi 5.5 Update 1

VMware ESXi 5.5, Patch Release ESXi550-201404020
А этот патч для фикса хостов разных версий 5.5 за исключением ESXi 5.5 Update 1, а именно:
ESXi 5.5.0 hosts
ESXi 5.5.0 hosts patched with ESXi550-201312101-SG bulletin
ESXi 5.5.0 hosts patched with ESXi550-201312401-BG bulletin
ESXi 5.5.0 hosts patched with ESXi550-201403101-SG bulletin
ESXi 5.5.0 hosts patched with ESXi-5.5.0-20131201001s-standard image profile
ESXi 5.5.0 hosts patched with ESXi-5.5.0-20131201001s-no-tools image profile
ESXi 5.5.0 hosts patched with ESXi-5.5.0-20131204001-standard image profile
ESXi 5.5.0 hosts patched with ESXi-5.5.0-20131204001-no-tools image profile
ESXi 5.5.0 hosts patched with ESXi-5.5.0-20140301001s-standard image profile
ESXi 5.5.0 hosts patched with ESXi-5.5.0-20140301001s-no-tools image profile

Для серверов vCenter есть также соответствующие патчи:

• VMware vCenter Server 5.5 U1a
• VCVA 5.5 U1a
• VMware vCenter Server 5.5c
• VCVA 5.5c

VMware рекомендует сначала обновить серверы vCenter, а потом уже обновлять хосты ESXi. Сама процедура обновления описана в KB 2076692.

После обновления, на хостах ESXi надо перегенерить сертификаты и сменить пароли root. Делается это так:

cd /etc/vmware/ssl
/sbin/generate-certificates
chmod +t rui.crt
chmod +t rui.key
passwd root

Ну и надо отметить, что для всех остальных продуктов VMware также вышли фиксы уязвимости OpenSSL HeartBleed. Информация о них доступна по этой ссылке: http://www.vmware.com/security/advisories/VMSA-2014-0004.html.

В конце прошлой недели компания VMware сделала анонс долгожданного мажорного обновления своих продуктов для виртуализации ПК предприятия - VMware Horizon 6. С момента релиза VMware Horizon View 5.3 прошло всего 5 месяцев, а компания VMware вновь идет на штурм рынка VDI, делая очень серьезную заявку на победу над Citrix. Итак, давайте разбираться, что к чему.

На днях ИТ-сообщество переполошилось из-за очень неприятного факта - уязвимости OpenSSL HeartBleed, которая была обнаружена в версии защищенного протокола OpenSSL 1.0.1 и 1.0.2-beta. Уязвимость получилась из-за того, что отсутствует необходимая проверка границ в одной из процедур расширения Heartbeat (RFC6520) для протокола TLS/DTLS.

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

Как пишет Хабр, 1 января 2012 года, Robin Seggelmann отправил, а steve проверил commit, который добавлял HeartBeat в OpenSSL. Именно этот коммит и привнес уязвимость, которую назвали Heartbleed. То есть, пару лет любой желающий мог вылавливать данные из памяти где-то 2/3 всех защищенных серверов мира. Эта версия OpenSSL используется в веб-серверах Nginx и Apache, в почтовых серверах, IM-системах, VPN, а также еще очень-очень много где. Сертификаты скомпрометированы, логины/пароли, возможно, утекли к посторонним людям. Кошмар, бардак, ядерная война.

Например, уязвимость есть вот в этих Linux-дистрибутивах:

• Debian Wheezy (стабильная), OpenSSL 1.0.1e-2+deb7u4)
• Ubuntu 12.04.4 LTS, OpenSSL 1.0.1-4ubuntu5.11)
• CentOS 6.5, OpenSSL 1.0.1e-15)
• Fedora 18, OpenSSL 1.0.1e-4
• OpenBSD 5.3 (OpenSSL 1.0.1c) и 5.4 (OpenSSL 1.0.1c)
• FreeBSD 8.4 (OpenSSL 1.0.1e) и 9.1 (OpenSSL 1.0.1c)
• NetBSD 5.0.2 (OpenSSL 1.0.1e)
• OpenSUSE 12.2 (OpenSSL 1.0.1c)

Ну и, конечно же, серверы VMware ESXi 5.5 (build 1331820) и ESXi 5.5 Update 1 (build 1623387) также имеют эту уязвимость. Проверить это просто - выполняем команду:

# vmware -vl

VMware ESXi 5.5.0 build-1331820
VMware ESXi 5.5.0 GA

# openssl version -a

OpenSSL 1.0.1e 11 Feb 2013
built on: Tue Feb 26 16:34:26 PST 2013

Видим, что здесь версия 1.0.1e, которая подвержена уязвимости.

А вот для пользователей VMware ESXi 5.1 бонус - уязвимости тут нет, так как используется другой бранч OpenSSL (0.9.8y):

# vmware -vl

VMware ESXi 5.1.0 build-1612806
VMware ESXi 5.1.0 Update 2

# openssl version -a

OpenSSL 0.9.8y 5 Feb 2013
built on: Wed Mar 20 20:44:08 PDT 2013

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

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

Подробное описание уязвимости можно прочитать на специальном сайте: http://heartbleed.com/.

Проверить свой публичный сайт на наличие уязвимой версии протокола можно вот тут: http://filippo.io/Heartbleed/.

Интересную особенность тут обнаружил один из читателей Дукана Эппинга: оказывается в VMware vSphere 5.5 Update 1 при перезапуске/выключении хоста VMware ESXi через консоль DCUI рестарта его виртуальных машин посредством механизма VMware HA не происходит.

Ну то есть, если выключение ESXi делать по клавише <F12> в консоли сервера:

Действительно, в этом случае в логе FDM можно увидеть вот такую запись:

2014-04-04T11:41:54.882Z [688C2B70 info 'Invt' opID=SWI-24c018b] [VmStateChange::SavePowerChange] 
vm /vmfs/volumes/4ece24c4-3f1ca80e-9cd8-984be1047b14/New Virtual Machine/New Virtual Machine.vmx 
curPwrState=unknown curPowerOnCount=0 newPwrState=powered off clnPwrOff=true hostReporting=host-113

Это означает, что VMware vSphere считает, что виртуальные машины были выключены корректно (администратором/хостом), а значит их перезапуск механизмом VMware HA не требуется (параметр clnPwrOff=true).

Совсем другая картина, если мы делаем ребут или выключение VMware ESXi из VMware vSphere Client или vSphere Web Client:

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

2014-04-04T12:12:06.515Z [68040B70 info 'Invt' opID=SWI-1aad525b] [VmStateChange::SavePowerChange] 
vm /vmfs/volumes/4ece24c4-3f1ca80e-9cd8-984be1047b14/New Virtual Machine/New Virtual Machine.vmx 
curPwrState=unknown curPowerOnCount=0 newPwrState=powered on clnPwrOff=false hostReporting=host-113

Здесь уже мы видим, что clnPwrOff=false, а значит vSphere полагает, что что-то пошло не так и VMware HA перезапустит виртуальные машины "отказавшего" хоста.

Это поведение актуально для VMware vSphere 5.5 Update 1, но пользователи в комментариях к статье Дункана отмечают, что подобное поведение наблюдается и для vSphere 5.0. Поэтому будет не лишним знать об этом всем тем, кто после настройки отказоустойчивого кластера VMware HA тестирует его работоспособность путем перезагрузки хостов ESXi.

Недавно компания VMware начала серию статей про совместимость ее решения для организации кластеров хранилищ Virtual SAN с различными продуктами (например, с vCloud Automation Center и решением для резервного копирования vSphere Data Protection). Но многих пользователей интересует юзкейс использования VSAN для катастрофоустойчивой инфраструктуры, управляемой VMware Site Recovery Manager. А именно, с точки зрения экономии, наиболее интересным вариантом является создание резервной инфраструктуры на базе хранилищ локальных дисков серверов VMware ESXi, бэкэнд которых обеспечивается кластером хранилищ VSAN:

Такая схема полностью поддерживается со стороны VMware, как для решения vSphere Replication, обеспечивающего репликацию виртуальных машин на резервный сайт и его VSAN-хранилища, так и для vCenter Site Recovery Manager, обеспечивающего оркестрацию процесса.

Естественно, на данный момент поддерживается совместимость SRM+VSAN только на базе технологии асинхронной репликации vSphere Replication, поэтому такой сценарий не подойдет тем, кто хочет обеспечить RPO=0 для сервисов виртуальных машин в случае массового сбоя или катастрофы на основной площадке. Но для сценариев с RPO=15 минут такая схема вполне подойдет.

Зато такая схема не требует больших вложений в резервную инфраструктуру - не нужно покупать дорогостоящие FC-хранилища, SAN-коммутаторы и прочее. Для организации такой схемы резервирования можно использовать как только механизм vSphere Replication (но тогда потребуются регулярные ручные операции + ручное сопровождение в случае сбоя), так и автоматизировать процесс с помощью vCenter SRM.

При этом SRM может обеспечить следующие возможности:

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

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

Не все администраторы VMware vSphere знают о том, что в версии vSphere 5.5, компания VMware сделала специальную настройку для виртуальных машин - Latency Sensitivity. Она позволяет снизить издержки на виртуализацию для виртуальной машины в случае, когда требуется ее производительность близкая к нативной (то есть почти без потерь на нужды слоя виртуализации).

Найти ее можно в vSphere Web Client, если выбрать нужную ВМ, перейти на вкладку Manage, далее выбрать Settings->VM Options и в разделе Advanced Settings перейти на опцию Latency Sensitivity:

Там можно выбрать значения Low, High, Medium и Normal, однако значения Medium и Normal в vSphere 5.5 являются экспериментальными, поэтому пока можно использовать только Low (по умолчанию) и High (режим высокой производительности для чувствительных нагрузок).

Детально о том, что конкретно делает этот режим, можно почитать в документе "Deploying Extremely Latency-Sensitive Applications in VMware vSphere 5.5", мы же здесь приведем основные моменты.

Итак, если вы ставите Latency Sensivity для виртуальной машины в значение High, происходит следующее:

Виртуальная машина получает эксклюзивный доступ к физическим ресурсам хоста

• Планировщик CPU хоста ESXi определяет возможность того, может ли быть предоставлен эксклюзивный доступ виртуального процессора vCPU к физическому процессору (ядру) сервера pCPU, учитывая реальное состояние процессора (нагруженность, over-commit и прочее). При возможности происходит резервирование pCPU для виртуального процессора на 100%. В этом случае никакие другие vCPU и трэды не могут быть исполнены на этом pCPU (включая VMkernel I/O threads).
• Возможность latency-sensitivity требует от пользователя установки резервирования памяти (Memory Reservation), чтобы выделенная виртуальной машине память не была ненароком отдана другой машине средствами Memory Ballooning. Это позволит дать гарантию, что машина всегда будет иметь в своем распоряжении четко выделенный сегмент физической оперативной памяти хоста ESXi, даже в случае недостатка ресурсов на хосте.

Обход слоя виртуализации

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

Тюнинг механизмов виртуализации на хосте

• Когда в качестве виртуального сетевого адаптера (VMNIC) виртуальной машины используется устройство VMXNET3, то функция Interrupt coalescing и поддержка LRO отключаются, чтобы уменьшить время отклика и джиттер. Если виртуальной машине не нужны такие функции, как vMotion, NetIOC и Fault tolerance, то можно и нужно использовать механизмы проброса сетевого устройства напрямую в виртуальную машину (pass-through) через механизм Single-root I/O virtualization (SR-IOV). Поддержка этого механизма появилась еще в VMware vSphere 5.1, но была существенно доработана в версии 5.5.

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

Как знают все те, кто интересуется решением для создания отказоустойчивых хранилищ StarWind iSCSI SAN, совсем недавно вышла обновленная версия StarWind V8 RC, которая пришла на смену StarWind V8 Beta 3.

Совсем скоро появится релизная восьмая версия продукта, в которой будет масса нововведений, в том числе обновленное средство для деплоя ПО StarWind на серверы VMware ESXi - StarWind VSA Builder.

При установке этот компонент называется VSAN Deployment Tools:

Для начала процесса развертывания ПО StarWind нужно нажать на иконку Deploy VSAN в Management Console:

Указываем параметры сервера VMware ESXi:

Указываем путь к ISO-образу с установкой Windows Server или скачиваем его:

Далее указываем исошник к инсталляции StarWind или также скачиваем:

После чего указываем хранилище хоста VMware ESXi, где будет размещена виртуальная машина:

Далее указываем параметры виртуального диска StarWind - то есть, непосредственного хранилища виртуальных машин на диске полученной машины:

Ну и после всего этого начнется развертывание виртуальной машины с ПО StarWind внутри:

По окончанию процесса установки, вы сможете открыть в полученной ВМ StarWind Management Console и управлять виртуальными хранилищами, создать отказоустойчивый кластер и многое другое. Саму эту виртуальную машину можно использовать как шаблон для развертывания новых узлов кластера StarWind.

Скачать StarWind iSCSI SAN V8 Release Candidate можно по этой ссылке.

Как многие знают, в VMware vSphere 5.5 был полностью переписан движок сервисов аутентификации Single-Sign-On (SSO), так как раньше VMware использовала стороннее решение. Теперь же нет старой базы RSA, а контроллеры доменов Active Directory не нужно указывать напрямую. Механизм аутентификации стал проще, но при этом эффективнее.

Итак, например, у вас такая задача - есть домен, в который вы заводите серверы VMware ESXi и vCenter, и администраторы которого будут рулить виртуальной инфраструктурой. Но у вас есть и второй трастовый домен, пользователей которого вы бы также хотели наделять полномочиями по управлению своей частью инфраструктуры. Тут надо отметить, что полноценная поддержка односторонних и двусторонних AD-трастов появилась только в vSphere 5.5, поэтому в более ранних версиях платформы сделать этого по-нормальному не получится.

Итак, как мы помним, завести серверы VMware ESXi в домен AD можно в раздеде Configuration-> Authentication Services

Тут можно добавить основной домен, но в строчке Trusted Domain Controllers мы увидим пустоту, так как настраивать это нужно не через "толстый" vSphere Client, который скоро перестанет поддерживаться, а через "тонкий" vSphere Web Client, в котором возможности добавления источников аутентификации для сервера SSO весьма обширны.

Итак:

• Открываем Sphere Web Client по ссылке https://<адрес сервера vCenter>:9443/vsphere-client
• Заходим обязательно как administrator@vsphere.local. Именно под этим пользователем - обычный админ не прокатит - раздел SSO будет скрыт.
• Идем в раздел Administration > Single Sign-On > Configuration

Если этого раздела в vSphere Web Client вы не видите, значит вы зашли не под administrator@vsphere.local.

Далее идем в раздел Identity Sources и там нажимаем "+":

Добавляем новый источник:

Добавляем источник именно как "Active Directory as a LDAP Server", так как основной источник Active Directory (первый вариант) может быть добавлен только один.

Вот пример заполнения данных по домену:

Тут не заполнены только обязательные поля "Base DN for users" и "Base DN for groups". Если вы хотите искать пользователей во всем каталоге домена, то укажите в обоих этих полях просто подобное значение (из примера):

DC=virten,DC=local

Далее нужно протестировать соединение (Test Connection).

После того, как новый домен будет добавлен как Identity Source, его можно будет увидеть при добавлении любого разрешения на вкладке Permissions:

Вот так все и просто. Добавляете пользователя и даете ему права на различные объекты виртуальной инфраструктуры VMware vSphere.

Как многие уже слышали, совсем недавно вышла первая версия продукта VMware VSAN, который был выпущен одновременно с релизом обновленной платформы VMware vSphere 5.5 Update 1. Многие уже принялись тестировать это решение, которое (что похвально) теперь работает производительнее своей же бета-версии и в то же время линейно масштабируется по количеству узлов ESXi с точки зрения производительности...