Новости Статьи VMware Veeam StarWind vGate! Microsoft ИТ-ГРАД Citrix Symantec 5nine События Релизы Видео Контакты Авторы RSS
Виртуализация и виртуальные машины

Виртуализация vSphere, Hyper-V, XenServer и Red Hat

Более 3480 заметок о виртуализации и виртуальных машинах VMware, Microsoft, Citrix, Red Hat

VM Guru / Search

Как начать с работать с кластерами хранилищ - документ VMware Virtual SAN 6.0 Proof of Concept Guide.


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

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

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

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

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

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


Таги: VMware, Virtual SAN, Whitepaper, ESXi, vSphere

Интересный и полезный документ "What’s New in VMware vSphere 6 - Performance".


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

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

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

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

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

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


Таги: VMware, vSphere, Performance, ESXi, vCenter, Whitepaper

Как вывести сообщение пользователям VMware ESXi при логине по SSH.


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

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

1. Login banner

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

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

# vi /etc/issue

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

# /etc/init.d/SSH restart

2. Баннер MOTD.

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

# vi /etc/motd

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

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

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


Таги: VMware, ESXi, Security, Blogs, vSphere

Как обнаружить, какая виртуальная машина на VMware ESXi залочила VMDK-файл, и разлочить его.


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

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

Could not power on VM: Lock was not free

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

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

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

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

#cd /bin

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

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

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

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

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

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

Total time taken : 0.27 seconds.

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

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

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

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

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

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

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

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

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

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

# lsof | egrep 'Cartel|vm1.vmdk'

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

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

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

# esxcli vm process list

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

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

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

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

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

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

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

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

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


Таги: VMware, VMDK, Troubleshooting, vSphere, ESXi, Storage, VMachines

Когда происходит "подмораживание" (stun) виртуальной машины в VMware vSphere 6.


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

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

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

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

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

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

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

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

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


Таги: VMware, VMDK, Snapshots, Performance, VMachines, vSphere, ESXi

Вышла финальная версия VMware vSphere 6.0 Security Hardening Guide.


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

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

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

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

vSphere: vSphere 5.1: vSphere 5.5: vSphere 5.5 Update 1: vSphere 6.0: Другие продукты VMware:

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


Таги: VMware, vSphere, Security, Update, vSphere, ESXi

Автоматическая блокировка аккаунта VMware ESXi после неудачных попыток входа.


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

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

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

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

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

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


Таги: VMware, ESXi, Security

Репликация в VMware Site Recovery Manager - чем отличаются Array Based Replication и vSphere Replication.


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

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

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

 Категория Репликация уровня массива (Array-Based Replication) Репликация уровня хоста ESXi (vSphere Replication)
Тип репликации Репликация на уровне массива по выделенному каналу Репликация на уровне хостов ESXi по сети
Минимальная и максимальная потеря данных (требования к контрольной точке восстановления - RPO) От 0 до максимально определенной вендором массива. От 15 минут до 24 часов
Максимальное число ВМ До 5 000 защищенных ВМ и до 2 000 машин, одновременно восстанавливаемых с одного vCenter До 2 000 ВМ (и защищаемых, и одновременно восстанавливаемых) на один vCenter
Порядок записи данных на резервной инфраструктуре (Write order fidelity) Write order fidelity поддерживается для нескольких ВМ в пределах одной consistency group Write order fidelity поддерживается для дисков VMDK одной ВМ. Для нескольких ВМ одной consistency group это не гарантируется.
Уровень репликации Репликация на уровне LUN/VMFS или томов NFS Репликация на уровне виртуальной машины
Метод настройки репликации Репликация настраивается на стороне дискового массива средствами продуктов вендора Репликация настраивается и управляется через vSphere Web Client
Тип дискового массива Необходим массив с поддержкой репликации на обеих площадках (например, EMC RecoverPoint, NetApp vFiler, IBM SVC и т.п.) Любое хранилище, включая локальное хранилище (в случае наличия в списке vSphere HCL)
Тип хранилища и протокол Только для хранилищ с протоколами FC, iSCSI или NFS Поддержка ВМ на локальном хранилище, VSAN, FC, iSCSI или NFS
Стоимость решения Относительно высокая. Нужна лицензия на функции Replication и Snapshot. vSphere Replication включена в издание vSphere Essentials Plus 5.1 и более высокие
Развертывание Необходимо привлечение администраторов хранилищ и, возможно, сетевых администраторов Администратор vSphere может настроить самостоятельно
Консистентность данных на уровне приложений В зависимости от дискового массива и производителя консистентность приложений может поддерживаться средствами агентов в гостевой ОС ВМ Поддержка VSS и Linux file system application consistency
Возможность репликации ВМ, защищенных технологией Fault Tolerance (FT) Можно реплицировать FT ВМ, но при восстановлении FT будет выключена. Также не поддерживаются ВМ с несколькими vCPU. Репликация ВМ с включенной FT не поддерживается
Возможность репликации выключенных ВМ, шаблонов, связанных клонов (Linked clones), ISO-образов Все эти объекты (как и любые другие файлы на виртуальных хранилищах) можно реплицировать на уровне томов VMFS Можно реплицировать только запущенные виртуальные машины.
Поддержка томов RDM Тома RDM в режиме физической и виртуальной совместимости могут быть реплицированы Только тома RDM в режиме виртуальной совместимости (virtual mode)
Поддержка кластеров MSCS Да, машины, являющиеся частью кластера MSCS, можно реплицировать Нет, репликация ВМ в составе MSCS-кластера не поддерживается (нельзя реплицировать диски в режиме записи с нескольких хостов - multi-writer)
Поддержка виртуальных сервисов vApp Да, полностью поддерживается Нет, объекты vApp реплицировать нельзя. Можно реплицировать машины виртуальных сервисов по отдельности, а потом вручную собрать из них vApp на резервной площадке.
Поддержка версий хостов vSphere Поддерживаются версии vSphere 3.5-6.0 Только начиная с vSphere 5.0 и более поздние версии
Несколько точек восстановления (Multiple point in time - MPIT) Снапшоты Multiple point in time и возможность отката к ним поддерживается только отдельными производителями (например, в продукте EMC RecoverPoint) До 24 точек восстановления
Снапшоты Поддержка репликации ВМ со снапшотами в неизменяемом виде Поддержка репликации ВМ со снапшотами, на на целевой площадке они будут удалены (ВМ будет в последнем состоянии, без снапшотов)
Реакция на сбой хоста Не влияет, так как репликация идет независимо на уровне дискового массива При сбое хоста, машина перезапускается на другом ESXi и вызывается полная ресинхронизация ВМ (больше подробностей в vSphere Replication FAQ)

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


Таги: VMware, SRM, Replication, Hardware, vSphere, ESXi, Сравнение

Обновления микрокода Intel и AMD в VMware ESXi - как это работает.


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

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

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

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

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

  • uc_amd.b00
  • uc_intel.b00

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

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

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

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

tar -zxf microcode-*.tgz

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

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

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

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

import sys

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

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

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

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

Для AMD:

cat amd/*.bin > uc_amd
gzip uc_amd

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


Таги: VMware, ESXi, vSphere, Обучение, Hardware

Отличия VMware vSphere 5.x и 6.0 в таблицах.


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

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

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

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


Таги: VMware, vSphere, Сравнение, Update, ESXi, vCenter

Как бороться со снапшотами в VMware vSphere - утилита Snapwatcher Enterprise Edition.


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

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

Что умеет Snapwatcher:

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

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

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


Таги: opvizor, Snapshots, vSphere, VMware, VMachines, ESXi, Troubleshooting

Первый важный патч VMware ESXi 6.0 - апрель 2015 (Build 2615704).


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

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

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

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

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


Таги: VMware, ESXi, Update, vSphere

VMware Tools в виртуальном ESXi в vSphere 6.


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

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


Таги: VMware, Tools, ESXi, Nested, Update

Производительность виртуальных машин с Microsoft SQL Server на платформах vSphere 5.5 и vSphere 6.0.


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

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

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

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

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

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

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

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


Таги: VMware, SQL, Performance, ESXi, Microsoft

Как менялся размер гипервизора ESXi - от версии 3.5 до 6.0.


Florian Grehl в своем блоге провел интересное исследование размера гипервизора ESXi от версии 3.5, вышедшей 7 лет назад, до ESXi 6.0, вошедшей в состав VMware vSphere 6.0 совсем недавно.

Итак, размеры мажорных версий гипервизора ESXi:

  • ESXi 3.5 – 46,01 MB
  • ESXi 4.0 – 59,99 MB
  • ESXi 4.1 – 85,19 MB
  • ESXi 5.0 – 132,75 MB
  • ESXi 5.1 – 125,85 MB
  • ESXi 5.5 – 151,98 MB
  • ESXi 6.0 – 154,90 MB

Как мы видим, за 7 лет размер вырос не катастрофически - всего в три раза. Посмотрите на продукты других вендоров и поймете, что это не так уж и много.

На диаграмме:

Как автор вычислял размер гипервизора? Он сравнил размер следующих пакетов, содержащих в себе компоненты ESXi:

  • Пакет "image" в ESXi 3.5
  • Пакет "firmware" в ESXi 4.x
  • VIB-пакет "esx-base" в ESXi 5.x и 6.x

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

ESXi Size
4.0 57,80 MB
4.0 U1 58,82 MB
4.0 U2 59,11 MB
4.0 U3 59,72 MB
4.0 U4 59,97 MB
4.0 LATEST 59,99 MB
4.1 85,45 MB
4.1 U1 85,89 MB
4.1 U2 85,25 MB
4.1 U3 85,27 MB
4.1 LATEST 85,19 MB
5.0 133,64 MB
5.0 U1 132,32 MB
5.0 U2 132,27 MB
5.0 U3 132,56 MB
5.0 LATEST 132,75 MB
5.1 124,60 MB
5.1 U1 124,88 MB
5.1 U2 125,67 MB
5.1 U3 125,85 MB
5.1 LATEST 125,85 MB
5.5 151,52 MB
5.5 U1 152,24 MB
5.5 U2 151,71 MB
5.5 LATEST 151,98 MB
6.0 154,90 MB

Но почему ISO-образ ESXi 6.0 занимает 344 МБ, а не 155 МБ? Потому что есть еще пакет VMware Tools для различных гостевых ОС (а их поддерживается очень много) плюс драйверы устройств серверов.

Получается вот так:

Package Size
Hypervisor 155 MB (45%)
Drivers 11 MB (3%)
VMware Tools Images 179 MB (52%)

Или картинкой:


Таги: VMware, ESXi, Blogs, vSphere

Некоторые заблуждения относительно новой версии VMware vSphere 6.0.


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

Итак, что есть на самом деле в VMware vSphere 6:

  • Первая ошибка была в документе vSphere 6.0 What's New - там было указано, что в кластере может быть до 6000 виртуальных машин. На самом деле их может быть до 8000.
  • Если раньше толстым клиентом vSphere Client (C#) можно было соединяться только с хостами ESXi, то в релизной версии можно коннектиться и к vCenter Server. Однако помните, что функции, которые появились, начиная с версии vSphere 5.5, доступны только в тонком клиенте vSphere Web Client. Толстым клиентом можно редактировать функции доступные до Virtual Hardware 8 (например, добавить памяти или диск выключенному vCenrer), а вот Virtual Hardware 9, 10 и 11 - уже доступны только для чтения.
  • Fautl Tolerance с несколькими vCPU будет доступна для машин vCenter, но только для некоторых вариантов использования. Информация об этом появится несколько позже.
  • Поддерживаемые БД vCenter для Windows включают в себя Microsoft SQL Server 2008 R2, 2012 и 2014, Oracle 11g и 12c, а также встроенную БД vPostgres. БД vPostgres для Windows имеет ограничение 20 хостов и 200 виртуальных машин. При апгрейдах инфраструктур, где была БД SQL Express, будет установлен vPostgres. vCenter Server Appliance (vCSA) поддерживает встроенную БД vPostgres для 1000 хостов и 10,000 виртуальных машин (то есть, на полноценную конфигурацию). Также для vCSA поддерживаются Oracle 11g и 12c, но их поддержка в скором времени будет прекращена (только для vCSA, само собой).
  • По поводу кластеров vCenter средствами MSCS - да, Cluster Services поддерживаются для vCenter Server 5.5 U3 и 6.0, в дополнение к кластерам БД на бэкэнде.
  • Если для ранних билдов vSphere политику RPO для vSphere Replication можно было понизить до 5 минут, то в релизной версии минимум - 15 минут.
  • По поводу нового компонента Platform Services Controller (PSC), который включает в себя модули Single Sign-On (SSO), Licensing и VMware Certificate Authority (VMCA) - его надо выносить на отдельную машину тогда, когда у вас есть несколько решений, использующих SSO, например vSphere и vRealize Suite. В остальных случаях для малых и средних инфраструктур ставьте вместе с vCenter.
  • В версии vSphere 6.0 все компоненты vSphere Web Client, Inventory Service, Auto-Deploy, Syslog Collector, Network dump collector и некоторые другие ставятся только на один сервер с vCenter Server. Если вы обновляете инфраструктуру vSphere 5.x на 6.x, то конфигурация компонентов будет собрана со всех серверов, где они установлены, но сами компоненты будут поставлены на один сервер.

Таги: VMware, vSphere, vCenter, Обучение, ESXi, Beta, Upgrade, Update

Важная информация по обновлению инфраструктуры на VMware vSphere 6.


Многие из вас уже подумывают об обновлении своей виртуальной инфраструктуры на новую версию платформы VMware vSphere 6 (см. тут о том, стоит ли обновлять). Основное препятствие к обновлению на сегодняшний день - неподдержка средствами резервного копирования новой версии vSphere 6.0 и, в частности: технологии VVols.

Например, компания Veeam, выпускающая продукт номер 1 для резервного копирования виртуальных машин Veeam Backup and Replication, не рекомендует обновляться сейчас и просит подождать до конца апреля, когда будет выпущена версия Veeam Backup & Replication 8.0 Update 2:

Со своей же стороны компания VMware выпустила полезную KB, где перечислены основные моменты по апгрейду компонентов инфраструктуры vSphere 6.0. Поэтому если проблема резервного копирования в ESXi 6.0 вас не пугает - можно стартовать апгрейд, предварительно изучив материалы ниже.

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

Продукт Последовательность обновления
vCenter SSO External
1
vRA
2
VCM
2
ITBM
2
vRAS
3
vCD
3
VCNS
4
NSX Manager
4
NSX Controllers
5
View Composer 5
View Connection Server
6
vCenter Server
7
vRO
8
VR
8
VUM
8
vROPs / vCOPs
8
VDP
8
vCenter Hyperic
8
VIN
8
vCC
9
vRLI
9
BDE
9
SRM
9
ESXi
10
VMware
Tools
11
vShield/ NSX Edge
11
vShield App/ NSX LFw
12

vShield Endpoint/ NSX Guest IDS
12
View Agent / Client 12

Во-вторых, надо бы почитать три следующих полезных статьи, так как архитектура сервисов vCenter изменилась (особенно обратите внимание на первую статью):

  • List of recommended topologies for vSphere 6.0.x (2108548)
  • Unable to find the vCenter Server 6.0 Appliance OVA, OVF, ZIP, or VMDK files on the VMware download page (2110730)
  • Upgrading to vCenter Server 6.0 best practices (2109772)

В-третьих, нужно посмотреть статьи о миграции базы данных vCenter:

  • Migrating the vCenter Server database from SQL Express to full SQL Server (1028601)
  • Upgrading to vCenter Server 6.0 without migrating SQL database to vPostgres (2109321)

В-четвертых, необходимо изучить, как происходит работа с сертификатами в vSphere 6.0:

  • Implementing CA signed SSL certificates in vSphere 6.0 (2111219)

В-пятых, посмотрите рекомендации по отдельным продуктам, если они есть в вашей виртуальной инфраструктуре, например:

vCenter Server (Windows):

  • Upgrading to Windows vCenter Server 6.0 causes python.exe to fail (2110912)
  • Installing or Upgrading to vCenter Server 6.0 fails with the error: Incompatible MSSQL version with vCenter Server 6.0 (2111541)

vCenter Server Appliance:

  • Upgrading the vCenter Server Appliance to vSphere 6.0 with embedded Postgres hangs on Starting VMware vCenter Server (2110080)
  • Installing or upgrading vCenter Server Appliance to vSphere 6.0 fails with the error: Error while configuring vSphere Auto Deploy Waiter firstboot. (2110025)

vRealize Automation:

  • Unable to edit a tenant created in vRealize Automation with the vCenter 5.5 SSO after upgrading from vCenter SSO 5.5 to PSC (Platform Services Controller) 6.0 (Windows-based SSO only) (2109719)
  • Reinstalling the VMware vRealize Automation Identity Appliance or vCenter Server SSO makes tenants inaccessible (2081462)

vRealize Operations Manager and vCenter Operations Manager:

  • The vSphere Web Client 6.0 displays an internal error after upgrading to vSphere 6.0 in a pre-5.8.5 vRealize Operations Manager environment (2111224)

В-шестых, открываете VMware vSphere 6.0 Upgrade Guide - и начинайте, чего тянуть. Вся официальная документация по VMware vSphere 6 размещена тут.

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


Таги: VMware, vSphere, Upgrade, ESXi, vCenter, Обучение, VMachines

Вышло обновление утилиты RVTools 3.7 - новые возможности.


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

Автор утверждает, что скачано уже более 400 тысяч копий утилиты. Давайте посмотрим, что там появилось нового:

  • VI SDK поменяно с версии 5.0 на 5.5.
  • Увеличен таймаут при операции получения данных с 10 до 20 минут для окружений с большим числом хостов.
  • Новое поле VM Folder на вкладках vCPU, vMemory, vDisk, vPartition, vNetwork, vFloppy, vCD, vSnapshot и vTools.
  • На вкладке vDisk появилась информация Storage IO Allocation.
  • На вкладке vHost новые поля: service tag (serial #) и строка OEM-производителя.
  • На вкладке vNic новое поле: имя (distributed) virtual switch.
  • На вкладке vMultipath добавлена информация о доступе по нескольким путям.
  • На вкладке vHealth новая проверка: Multipath operational state (состояние доступа по нескольким путям).
  • Еще одна новая проверка vHealth: Virtual machine consolidation needed (машины, для которых нужно консолидировать снапшоты).
  • На вкладке vInfo новые поля: boot options, firmware и Scheduled Hardware Upgrade.
  • На статус-баре появилась дата и время последнего обновления данных.
  • На вкладке vHealth ошибки поиска датасторов видны как предупреждения.
  • Можно экспортировать csv-файлы через интефейс командной строки (как и xls).
  • Можно установить интервал автообновления данных.
  • Все время и дата отформатированы в формате yyyy/mm/dd hh:mm:ss.
  • Папки со временем и датой также создаются в формате yyyy-mm-dd_hh:mm:ss.
  • Bug fix: на вкладке dvPort теперь отображаются все сети.

Скачать RVTools 3.7 можно по этой ссылке. Документация доступна тут. Молодец автор - столько лет прошло, а утилита продолжает обновляться.


Таги: RVTools, Update, VMware, vSphere, VMachines, ESXi

Платформа VMware vSphere 6 доступна для скачивания.


Компания VMware сделала доступной для скачивания новую версию платформы виртуализации VMware vSphere 6.0. Да, продукты ESXi 6.0 и vCenter 6.0 можно устанавливать прямо сейчас:

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

Вся документация по VMware vSphere 6 доступна по этой ссылке: https://www.vmware.com/support/pubs/vsphere-esxi-vcenter-server-6-pubs.html.

Ссылки на скачивание отдельных продуктов:

В ближайшее время напишем еще что-нибудь интересное про vSphere 6 - stay tuned.


Таги: VMware, vSphere, Update, ESXi, vCenter, vRealize

Поддержка режима vGPU для карт NVIDIA в VMware vSphere 6.


Продолжаем рассказывать о новых возможностях платформы виртуализации VMware vSphere 6, выход которой ожидается в самое ближайшее время. Сегодня мы расскажем о поддержке режима vGPU, который позволяет предоставить ресурсы видеокарты (GPU) напрямую сразу нескольким виртуальным машинам (режим vGPU). Напомним, что эта технология уже довольно давно поддерживается в продуктах Citrix (а также в решении RemoteFX от Microsoft), а ее поддержка в платформах VMware была анонсирована в прошлом году на VMworld 2014.

Технология vGPU от NVIDIA при использовании с продуктами VMware подразумевает использование в качестве платформы VMware vSphere 6, а в качестве средства управления виртуальными ПК - VMware Horizon 6 (для этого выйдет специальное обновление с версией 6.1).

vGPU поддерживается для графических адаптеров NVIDIA GRID K1 и K2, для каждой из которых определены 4 профиля для виртуальных ПК, которые используют ресурсы видеокарты. Вот таблица этих профилей:

Всего есть три типа пользователей:

  • Designer - человек, который использует очень требовательные к графическим ресурсам приложения (не только дизайнеры, но и пользователи CAD-приложений).
  • Power User - человек, использующий подобные приложения время от времени.
  • Knowledge Worker - пользователь со сравнительно небольшой нагрузкой на ресурсы видеокарты.

Важно, что в рамках одного физического GPU видеокарты можно использовать только профили одного типа. Взгляните на картинку - как можно, а как нельзя:

Опишем здесь вкратце процедуру настройки использования vGPU с VMware vSphere 6, которая приведена в vGPU Deployment Guide (документ еще не вышел).

Для настройки vGPU необходимы следующие компоненты:

  • VMware vCenter 6.0
  • VMware ESXi 6.0
  • VMware Horizon View 6.1
  • NVIDIA GRID vGPU Manager

Потребуются также настройки BIOS на серверах (для каждого вендора свои). Вот, например, конфигурация Cisco:

  • CPU Performance: выставить в Enterprise или High Throughput.
  • Energy Performance: выставить в Performance.
  • PCI Configuration: выставить MMCFG BASE в 2 GB и Memory Mapped I/O above 4GB: Disabled.
  • VGA Priority: выставить в Onboard VGA Primary.

Далее нужно развернуть на хостах компонент NVIDIA vGPU Manager, который создает связь между GPU видеокарты и виртуальной машиной. Устанавливается он как обычный VIB-пакет:

[root@ESX60-01:~] esxcli software vib install --no-sig-check -v /vmfs/volumes/ISO/vib/NVIDIA-vgx-VMware-346.27-1OEM.600.0.0.2159203.x86_64.vib
Installation Result:
Message: Operation finished successfully.
Reboot Required: false
VIBs Installed: NVIDIA_bootbank_NVIDIA-vgx-VMware_vSphere_6_Host_Driver_346.27-1OEM.600.0.0.2159203
VIBs Removed:
VIBs Skipped:
[root@IUESX60-01:~] esxcli software vib list | grep -i nvidia
NVIDIA-vgx-VMware_ESXi_6.0_Host_Driver 346.27-1OEM.600.0.0.2159203 NVIDIA VMwareAccepted 2015-02-06

После того, как NVIDIA vGPU Manager настроен на хост-серверах ESXi, нужно подготовить виртуальные машины. Делается это через vSphere Web Client. Выберем аппаратные характеристики ВМ в зависимости от типа рабочей нагрузки:

  • Entry Level Engineer / Design Reviewer: 4GB RAM, 2 vCPU
  • Mid Level Engineer: 8 GB RAM, 2-4 vCPU
  • Advanced Engineer: 16 GB RAM, 4-8 vCPU

Затем в настройках ВМ нужно добавить Shared PCI Device:

Выбираем тип NVIDIA GRID vGPU и профиль в соответствии с таблицей, приведенной в начале статьи:

Обратите внимание, что нужно зарезервировать память для виртуальных машин, иначе их просто нельзя будет запустить. То есть, кнопку "Reserve all memory" нужно нажать обязательно. Кроме того, для машин, использующих vGPU, не поддерживаются такие технологии как vMotion, HA, снапшоты - то есть, машина полностью привязана к хосту ESXi.

После этого в виртуальном ПК можно устанавливать гостевую ОС (поддерживается Windows 7 и более поздние версии). Затем нужно установить NVIDIA GRID driver (после этого неплохо бы сделать из такой машины шаблон для дальнейшего ускоренного развертывания новых десктопов):

Кстати, в диспетчере устройств в гостевой ОС виртуального ПК можно посмотреть на драйвер графического адаптера:

Затем нужно соответствующим образом настроить пул виртуальных ПК в VMware Horizon View. Просто указываем протокол PCoIP и тип 3D-рендера NVIDIA GRID VGPU:

Вот, в принципе, и все. После этого виртуальные машины готовы к работе с vGPU в рамках пула виртуальных ПК.


Таги: VMware, vGPU, vSphere, NVIDIA, ESXi, VMachines, Hardware, VDI

Сжатие данных при передаче (compression) в VMware vSphere Replication 6.0.


Продолжаем рассказывать о новых функциях платформы виртуализации vSphere 6.0 (для этого у нас есть специальная страница). Сегодня у нас на очереди функции сжатия данных в VMware vSphere Replication 6.0. Функция репликации включена во все издания VMware vSphere, начиная с Essentials Plus (то есть, за бортом только Essentials). Кстати, родственная репликации функция резервного копирования VMware Data Protection 6.0 также есть во всех изданиях, начиная с Essentials Plus.

Начнем с того, что vSphere Replication 6.0 полностью совместима с продуктами VMware Virtual SAN 6.0 и vCenter Site Recovery Manager (SRM). Также в vSphere 6.0 появилась функция сжатия данных сетевого трафика при передаче:

Это снижает требования к ширине канала репликации, что особенно актуально при использовании продукта VMware SRM для обеспечения отказоустойчивости на уровне помещений или датацентров. Делается сжатие средствами библиотеки FastLZ, однако сжатие выключено по умолчанию.

При передаче данных репликации пакеты остаются сжатыми до того момента, пока они не отправляются на запись на диск. Но в некоторых случаях, в зависимости от версий ПО и особенностей архитектуры, сжатие может быть не на всем участке пути данных, или его может не быть вовсе. Пример: репликация vSphere 6.0 при соединении с виртуальным модулем vSphere Replication 5.8 - сжатия не будет. Если же, например, данные хоста ESXi 6.0 идут на виртуальный модуль vSphere Replication 6.0, а дальше на хранилище хоста vSphere 5.5, то данные будут разжаты на виртуальном модуле репликации, а дальше пойдут в обычном виде. Отсюда мораль - старайтесь поддерживать актуальные версии своего ПО на всех компонентах инфраструктуры.

В большинстве случаев достигается коэффициент сжатия данных в диапазоне от 1.6 к 1 до 1.8 к 1. Это приводит к уменьшению времени синхронизации и возможности настройки более строгой политики RPO.

Примеры:

1. ВМ с гостевой ОС Windows и диском в 37.5 ГБ при первой репликации без компрессии синхронизируется за 52 минуты. Когда включили компрессию, 20.2 ГБ данных отреплицировалось за 29 минут. Таким образом, эффективное использование канала выросло с 98 Mbps до 177 Mbps.

2. ВМ с гостевой ОС Linux и 4.7 ГБ данных при первичной репликации синхронизировались за 13 минут. После включения компрессии 2,8 ГБ ушли за 8 минут. Эффективное уменьшение ширины канала - с 49 Mbps до 80 Mbps.

Из минусов - компрессия создает нагрузку на процессор, поэтому нужно ее использовать аккуратно, и потому она отключена по умолчанию. Больше информации о технологии репликации от VMware можно найти в документе "VMware vSphere Replication 6.0 Technical Overview".


Таги: VMware, vSphere, Replication, Update, DR, ESXi

Transparent Page Sharing в VMware vSphere 6.0: разламывание больших страниц памяти.


Мы уже немало писали про технологию Transparent Page Sharing (TPS) в VMware vSphere, которая позволяет дедуплицировать страницы оперативной памяти на хост-сервере ESXi при недостатке физической памяти для виртуальных машин. Как мы уже писали тут и тут, в VMware vSphere 5.5 Update 3 и более поздних версиях технология TPS отключена (при дедупликации страниц между машинами), чтобы не нагружать хост понапрасну, поскольку в современных ОС используются большие страницы памяти (Large Memory Pages), вероятность дедупликации которых мала. В то же время, технологию TPS никто из vSphere не убирал, и ее можно в любой момент включить.

Как пишет знаменитый Дункан, В VMware vSphere 5.x есть 4 состояния памяти для хост-сервера относительно параметра minFree:

  • High (100% от minFree)
  • Soft (64% от minFree)
  • Hard (32% от minFree)
  • Low (16% от minFree)

Эти состояния определяют срабатывание определенных триггеров (об этом ниже). Например, если minFree для вашей конфигурации сервера равно 10 ГБ, то при переходе в состояние, когда занято 6,4 ГБ (Soft), произойдет определенное действие с точки зрения техник оптимизации памяти.

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

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

Поэтому в VMware vSphere 6.0 ввели новое состояние Clear (100% от minFree), а состояние High переопределили до значения 300% от minFree. Для чего это сделано? А вот для чего.

При недостатке памяти, хостом ESXi используется техника разламывания больших страниц памяти на обычные страницы, которые затем могут быть дедуплицированы с помощью TPS. Это делается затем, чтобы предотвратить свопирование страниц на диск, что является самым тормозным способом освобождения ресурсов. Так вот эта штука начинает активно работать при наличии свободной памяти в промежутке от High (300%) до Clear (100%), чтобы начать работать на еще не испытывающем острого недостатка ресурсов хосте. Но при этом TPS сразу не запускается.

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

Состояние памяти (State) Пороговое значение (% от minFree) Эффект при переходе в диапазон
High 300% Большие страницы разламываются на обычные, но TPS не запускается и ждет следующего цикла прохода дедупликации (по умолчанию 60 минут, минимально настраиваемое в расширенном параметре Mem.ShareScanTime время равно 10 минут)
Clear 100% Разламывание больших страниц и мгновенный запуск TPS
Soft 64% Включение TPS и техники Memory Ballooning
Hard 32% Включение TPS, Memory Compression и свопирования на диск
Low 16% Memory Compression + свопирование на диск + блокировка использования памяти

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

Но все что касается TPS, актуально только тогда, когда TPS включено. По умолчанию же эта техника выключена, а о том, как включить ее, написано вот тут.


Таги: VMware, vSphere, Memory, Performance, Обучение, ESXi

Возможность пощелкать компоненты VMware vSphere 6 уже сейчас - новые Feature Walkthroughs.


Как все из вас знают, скоро выходит обновленная платформа виртуализации VMware vSphere 6, в которой появилась уйма новых возможностей. О многих из них мы уже писали (см, например, нашу последнюю заметку тут). На днях компания VMware сделала еще одну полезную вещь - выложила пошаговые гайды по некоторым компонентам vSphere 6 на сайте VMware Feature Walkthroughs.

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

Какие гайды доступны уже сейчас:

  • vCenter Server Install - установка компонентов vCenter 6.0. Напомним, что о новых функциях в vCenter мы писали вот тут.
  • vCenter Server Upgrades - процесс обновления со старых версий vCenter Server, включая 5.x, до версии vCenter 6.0.
  • vSphere Data Protection – набор пошаговых гайдов, позволяющих пройти весь процесс резервного копирования виртуальных машин. О новых возможностях VDP 6.0 мы также писали вот тут.
  • vSphere Replication – эти гайды позволят вам самостоятельно настроить репликацию и попробовать повосстанавливать виртуальные машины из реплик.

В ближайшее время ожидаются новые Feature Walkthrough - следите за обновлениями!


Таги: VMware, vSphere, Update, Обучение, ESXi, vCenter, VDP

VMware vSphere Virtual Volumes (vVOLs) - что это такое и чем отличается от VAAI.


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

Сегодня у нас на очереди одна из самых интересных тем в vSphere 6 - технология организации хранилищ VMware vSphere Virtual Volumes (VVOls). Напомним, что ранее мы подробно писали о ней тут. С тех пор появилось некоторое количество новой информации, которую мы постараемся актуализировать и дополнить в этом посте.

Начнем с того, что vVOL - это низкоуровневое хранилище для виртуальных машин, с которым позволены операции на уровне массива по аналогии с теми, которые сегодня доступны для традиционных LUN - например, снапшоты дискового уровня, репликация и прочее. vVOLs - это новый способ организации хранилищ в виде удобном для массива, когда используется не традиционная файловая система VMFS, а массив сам определяет, каким образом решать задачи доступа и организации работы с данными для виртуальных машин.

Тома vVOLs создаются на дисковом массиве при обращении платформы к новой виртуальной машине (создание, клонирование или снапшот). Для каждой виртуальной машины и ее файлов, которые вы сейчас видите в папке с ВМ, создается отдельный vVOL. В итоге же, создаются следующие тома на хранилище:

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

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

Давайте посмотрим на архитектуру VVols:

Здесь мы видим следующие компоненты:

Storage Provider (SP)

Технология vVOLs при взаимодействии с аппаратным хранилищем реализуется компонентом Storage Provider (SP), который также называется VASA Provider (подробнее об интерфейсе VASA - тут). Storage provider - это предоставляемый вендором аппаратного обеспечения слой ПО, который обеспечивает взаимодействие платформы vSphere и, собственно, хранилища с организованными на нем томами vVOLs в виде контейнеров (storage containers). vVOLs используют механизм VASA 2.0, который позволяет управлять объектами виртуальных машин (дискми) прямо на хранилище.  

Protocol EndPoint (PE)

Если раньше каждый хост налаживал в случае необходимости соединение с каждым из vmdk-дисков виртуальных машин и получалось куча связей, то теперь у хранилища есть логическое I/O-устройство, через которое происходит общение с томами vVOL. PE можно считать сущностью, пришедшей на замену LUN, этих PE может быть создано сколько угодно (кстати, длина очереди у PE - 128 по умолчанию, вместо 32 у LUN).

То есть, через PE хост ESXi получает доступ к данным конкретной виртуальной машины. PE совместимы с существующими протоколами  FC, iSCSI и NFS и позволяют использовать уже имеющееся ПО для управления путями в SAN. К отдельному PE через vCenter можно привязать или отвязать тома vVOL отдельных виртуальных машин. Для хранилища не нужно много PE, одно это логическое устройство может обслуживать сотни и тысячи виртуальных томов vVOL.

Storage Container (SC)

Это логическая сущность, которая нужна для объединения томов vVOL по типам в целях выполнения административных задач. Storage Container создается и управляется на стороне дискового массива и предназначен для логической группировки и изоляции виртуальных машин (например, виртуальные машины отдельного клиента в публичном облаке vCloud).

vVOL Datastore

Это хранилище, которое непосредственно создается из vSphere Client. По-сути, это представление Storage Container (SC) для платформы VMware vSphere. Этот тип датастора можно, например, выбрать при создании виртуальной машины:

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

Policy Based Management

Это механизм, который позволяет назначать виртуальным машинам политики, которые определяют ее размещение, а как следствие, и производительность с точки зрения подсистемы ввода-вывода (например, можно задавать необходимые трешхолды по ReadOPs, WriteOPs, ReadLatency и WriteLatency.).

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

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

Об этом более подробнее вы можете прочитать в статье "vSphere Virtual Volumes Interoperability: VAAI APIs vs VVOLs".

Ну и отметим, что ведущие вендоры аппаратного обеспечения уже приступили к реализации vVOL в своем оборудовании. Например, это уже начинает делать HP:

Этим же занимается и Dell. В ближайшее время мы будем рассказывать о практических аспектах использования vVOLs подробнее.


Таги: VMware, vSphere, vVOL, Update, ESXi, Storage

Как работает SSD кеширование средствами гипервизора в облаке VMware.


Компания VMware еще с выходом VMware vSphere 5.1 объявила о нескольких новых начинаниях в сфере хранения данных виртуальных машин, включая возможность использования распределенного кеш на SSD-накопителях локальных дисков серверов ESXi. Данная технология имела рабочее название vFlash и находилась в стадии Tech Preview, превратившись позднее в полноценную функцию vSphere Flash Read Cache (vFRC) платформы VMware vSphere 5.5. И это вполне рабочий инструмент, который можно использовать в задачах различного уровня.


Таги: IT-Grad, VMware, SSD, Performance, vSphere, ESXi

Новое в VMware vSphere Data Protection 6.0 - теперь почти для всех пользователей vSphere.


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

Сегодня мы поговорим об анонсированной новой версии VMware vSphere Data Protection 6.0 (VDP) - продукте для резервного копирования виртуальных машин на серверах ESXi. Если ранее пользователям предлагалось одно из двух изданий - встроенное в платформу и vSphere Data Protection Advanced (с расширенными функциями), то теперь осталось только одно. Теперь VDP включено во все издания VMware vSphere, кроме самого базового (Essentials). То есть, пользователи vSphere 6.0 Essentials Plus и более старших изданий получат VDP в комплекте. Кстати, продукт vSphere Data Protection Advanced будет недоступен для заказа с 1 марта.

Напомним, что VDP построен на базе решения для резервного копирования и дедупликации EMC Avamar, которое развертывается как готовый виртуальный модуль (Virtual Appliance). ПО работает без агентов, использует функциональность Changed Block Tracking и может восстанавливать не только машины целиком, но и отдельные файлы из бэкапов через браузер. Шестая версия VDP поддерживает до 8 ТБ дедуплицированных данных бэкапов.

Итак, что нового появилось в VDP:

1. Агенты для Microsoft SQL Server, Exchange и SharePoint.

Напомним, что это намного раньше появилось в Veeam Backup and Replication, а теперь VMware "заимствует" функциональность у Veeam. Эти агенты позволяют создавать консистентные копии виртуальных машин с данными приложениями, а также восстанавливать отдельные объекты приложений из бэкапов (например, базу данных или электронное письмо). Агенты поддерживают такие функции, как SQL Server Failover, кластеры AlwaysOn и Exchange Database Availability Groups.

2. В VDP появилась интеграция с хранилищем EMC Data Domain с использованием ПО Data Domain Boost.

Теперь за обработку бэкапов может отвечать Data Domain, а модуль VDP просто отвечать за передачу данных. Данная функция также есть у Veeam.

3. Возможность репликации данных между модулями VDP.

Данные, передаваемые между модулями VDP дедуплицируются, поэтому в канал передаются только уникальные блоки данных. Это может оказаться необходимым при отбрасывании резервных копий на резервные хранилища через WAN. При этом поддерживаются различные топологии репликации данных виртуальных модулей - 1:1, N:1 и 1:N.

4. Сжатие данных для vSphere Replication.

Теперь если вы используете VMware SRM для репликации данных между площадками и восстановления машин после сбоев, то при передаче данных включается технология сжатия данных при передаче (end-to-end network compression).

Типичный коэффициент сжатия данных - от 1.6:1 до 1.8:1. Например, если раньше машина размером 37.5 ГБ передавалась за 52 минуты, то теперь она ужимается до 20.2 ГБ и передается за 29 минут.

5. Улучшенная репликация.

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

6. Верификация резервных копий.

Теперь резервные копии VDP можно восстановить на временное хранилище и запустить машины отключенными от сети, чтобы убедиться, что ОС запускается и приложения работают.

7. Поддержка "подмораживания" файловых систем Linux.

Для Windows-систем уже давно есть quiescence-скрипты, которые подмораживают операции с данными ВМ, для которой происходит резервное копирование. Для Linux это появилось в версии VDP 6.0 (функция отключена по умолчанию).

8. Поддержка Storage vMotion и Storage DRS в целевом хранилище.

Ранее при перемещении реплики средствами Storage vMotion требовалась полная ресинхронизация ВМ, а в версии VDP 6.0 перемещение машин между серверами и хранилищами отслеживается, и процесс полной синхронизации не запускается.

Больше подробностей о возможностях vSphere Data Protection 6.0 можно узнать из вот этого документа.


Таги: VMware, VDP, Update, ESXi, vSphere, Backup

Вышли фиксы багов с некорректной обработкой Changed Block Tracking (невосстановимые копии бэкапов) для VMware vSphere 5.x.


Некоторое время назад мы писали про серьезный баг в механизме Changed Block Tracking (CBT), который используют практически все средства для резервного копирования виртуальных машин на уровне хоста ESXi, например, Veeam Backup and Replication.

Суть бага заключалась в том, что при увеличении виртуальных дисков машин с включенной технологией Changed Block Tracking (CBT), если их результирующий размер перешагивает 128 ГБ (а также 256, 512, 1024 и т.д.) - их резервные копии оказываются невалидными и не подлежащими восстановлению.

Проблема была обнаружена в начале ноября прошлого года, но только сейчас компания VMware пофиксила этот баг. Описание проблемы и решений можно найти в KB 2090639.

Патчи можно скачать по следующим ссылкам:

Zip-файлы патчей можно импортировать через VMware Update Manager:

/p>

Напомним, что для решения проблемы без патчей, надо "перещелкнуть" Changed Block Tracking на хосте ESXi (как это сделать - тут и в KB). Старые бэкапы, понятное дело, останутся невалидными. Следующий бэкап после повторного включения CBT всегда будет полным.

Интересно, что для VMware vSphere 4.x никаких патчей на эту тему выпущено не было (Currently, there is no resolution for ESXi 4.x.).

Отметим также, что компания Veeam уже давно выпустила решение этой проблемы. Пользователям Veeam Backup and Replication 8 вообще ничего делать не нужно - там эта проблема уже решена.


Таги: VMware, vSphere, Bug, Bugs, ESXi, Backup, Veeam

vMaxGuide - информация о максимальных конфигурациях VMware vSphere в приложении для Android.


На многим из вас известном сайте VMware Labs появилось интересное мобильное приложение для смартфонов на базе Android - vMaxGuide. Оно позволяет посмотреть информацию о максимальных конфигурациях различных компонентов виртуальной инфраструктуры VMware vSphere.

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

  • VMware vSphere 5.5
  • VMware vSphere 5.1
  • VMware vSphere 5.0

Также в сравнениях участвуют различные версии виртуального аппаратного обеспечения (Virtual Hardware). Там где максимумы могут быть достигнуты только при определенных условиях, соответствующие пункты помечены символом "*".

Инсталляция и использование vMaxGuide:

Кстати, эта штучка может быть хорошей шпаргалкой на экзамене по VMware VCP!)


Таги: VMware, vSphere, Labs, ESXi, VMachines

Отключенный Transparent Page Sharing на хосте VMware ESXi - сколько можно сэкономить, если включить его?


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

Технологию TPS было решено прекратить использовать по двум причинам:

  • Использование в современных ОС больших страниц памяти (large memory pages) размером в 2 МБ делает намного менее вероятным появление дубликатов.
  • Использование одной копии страницы памяти несколькими ВМ создает потенциальные проблемы безопасности.

На данный момент статус отключенности TPS по умолчанию на хостах VMware ESXi таков:

  • В ESXi 5.5 U2d, запланированном на первый квартал 2015 года, TPS будет отключен.
  • В ESXi 5.1 U3, выпущенном 4 декабря 2014 года, TPS уже отключен.
  • В ESXi 5.0 U3d, запланированном на первый квартал 2015 года, TPS будет отключен.

Однако не стоит сбрасывать TPS со счетов - возможно, если вы используете старые ОС (Windows 2003) и инфраструктуру VDI на базе старых клиентских ОС, TPS сможет сэкономить вам какое-то количество памяти (если безопасность TPS вас не особенно заботит). Ну и напомним, что TPS отключена только для межмашинного взаимодействия и продолжает работать для внутримашинного.

Для этого в VMware сделали скрипт Host Memory Assessment Tool.ps1, который показывает количество памяти на хостах, которую можно сэкономить с помощью TPS.

Вот что он делает:

  • Соединяется с vCenter и определяет хосты ESXi
  • Позволяет включить SSH на хостах
  • Генерирует отчет об обследовании на экономию по TPS
  • Можно экспортировать результаты в CSV
  • Можно снова включить SSH, если нужно

Пока скрипт позволяет указать только одну пару логин-пароль на хостах ESXi, но надеемся это будет исправлено в следующих версиях.

Здесь вот какие значения в колонках:

  • Total Host Memory – объем физической памяти хоста (доступной vmkernel).
  • Host Mem Saved via TPS – объем памяти, которая сэкономлена TPS.
  • Host Mem Saved via TPS Zero Pages – объем памяти, которая экономится на нулевых страницах. Фактически такая экономия не актуальна для большинства случаев, так как сэкономленные нули означают, что недостатка ресурсов не наблюдается.
  • Potential Host Mem Savings Lost – а вот эта экономия уже на реально используемых страницах. Объем, указанный тут, показывает сколько можно потерять, отключив TPS на хосте.
  • Host Free Mem – объем свободной оперативной памяти (по данным vmkernel). Если свободной памяти меньше, чем значение в предыдущей колонке, то при отключении TPS будет своппинг.

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

После запуска скрипта вам может потребоваться отключить или включить Transparent Page Sharing на хосте ESXi. В этом случае вам пригодится KB 2097593.


Таги: VMware, TPS, Memory, ESXi, vSphere

Как создать задачу крон (планировщика) в VMware vSphere Management Assistant (vMA).


Как знают многие администраторы VMware vSphere, есть такое удобное средство vSphere Management Assistant (vMA), которое представляет собой виртуальный модуль (готовую виртуальную машину), средствами которой очень удобно управлять скриптами, исполняемыми на нескольких хостах VMware ESXi через интерфейс ESXCLI или Perl.

При выполнении различных сценариев на Linux-машине vMA иногда требуется создать задачу планировщика (крон-таску), чтобы запустить скрипт в назначенное время. Ниже мы опишем, как это нужно делать.

1. Чтобы запускать скрипты без аутентификации, нужно добавить хосты ESXi в vi-fastpass. Вы можете добавить только хосты ESXi, либо хост vCenter Server (или всех их). Используйте команду vifp addserver в интерактивном режиме (конфигурация сохраняется при перезагрузках):

vi-admin@vma:~> vifp addserver esx1.virten.local --username root --password 'vmware'
vi-admin@vma:~> vifp addserver esx2.virten.local --username root --password 'vmware'
vi-admin@vma:~> vifp addserver esx3.virten.local --username root --password 'vmware'
vi-admin@vma:~> vifp addserver vcsa.virten.local --username root --password 'vmware'

Используйте команду vifp listservers для того, чтобы посмотреть список сконфигурированных хостов для быстрого доступа:

vi-admin@vma:~> vifp listservers
esx1.virten.local ESXi
esx2.virten.local ESXi
esx3.virten.local ESXi
vcsa.virten.local vCenter

2. Используйте механизм vi-fastpass внутри скрипта. Это делается вот так (сценарий размещайте, где написано #do something):

#!/usr/bin/perl -w

use VMware::VIRuntime;
use VMware::VmaTargetLib;

my $service_content;
my @targets = VmaTargetLib::enumerate_targets();
foreach my $target(@targets) {
$target->login();
$service_content = Vim::get_service_content();
#do something
$target->logout();
}

Также примеры скриптов можно найти в папке /opt/vmware/vma/samples/perl:

vi-admin@vma:~> ls -l /opt/vmware/vma/samples/perl
total 24
-r--r--r-- 1 root root 2660 Jul 15 2013 README
-r-xr-xr-x 1 root root 9023 Jul 15 2013 bulkAddServers.pl
-r-xr-xr-x 1 root root 1282 Jul 15 2013 listTargets.pl
-r-xr-xr-x 1 root root 2452 Jul 15 2013 mcli.pl

Для примера также посмотрите скрипты отсюда (можете на них и поэкспериментировать, например, с esxcfg-perf.pl).

3. Создаем таску в кроне (cron job).

Синтаксис команды прост:

* * * * * command
| | | | |
| | | | ----- Day of week (0 - 7) (Sunday=0 or 7)
| | | ------- Month (1 - 12)
| | --------- Day of month (1 - 31)
| ----------- Hour (0 - 23)
------------- Minute (0 - 59)

Открываем крон в режиме редактирования:

vi-admin@vma:~> crontab -e

Нажмите <i>, чтобы перейти в режим вставки в crontab, после чего добавьте нужный путь к библиотеке и команду:

LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/vmware/vma/lib64:/opt/vmware/vma/lib
*/5 * * * * /home/vi-admin/scripts/esxi-perf.pl

Затем выходим из режима редактирования, нажав <ESC> : w q <ENTER>

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

vi-admin@vma:~> crontab -e
-bash: /usr/bin/crontab: Permission denied

То вам нужно предварительно выполнить sudo (юзер vi-admin в vMA 5.5 не имеет пермиссий на crontab):

vi-admin@vma:~> ll /usr/bin/crontab
-rwsr-x--- 1 root trusted 40432 Apr 2 2013 /usr/bin/crontab
vi-admin@vma:~> sudo chmod +rx /usr/bin/crontab
vi-admin@vma:~> ll /usr/bin/crontab
-rwsr-xr-x 1 root trusted 40432 Apr 2 2013 /usr/bin/crontab

4. Если крон-таска упадет, то вывод ошибок будет направляться сюда:

/var/mail/vi-admin

Вывод ошибки может быть таким:

Can’t load ‘/usr/lib/perl5/site_perl/5.10.0/libvmatargetlib_perl.so’ for module vmatargetlib_perl: libtypes.so: cannot open shared object file: No such file or directory at /usr/lib/perl5/5.10.0/x86_64-linux-thread-multi/DynaLoader.pm line 203.
at /usr/lib/perl5/site_perl/5.10.0/VMware/VmaTargetLib.pm line 10
Compilation failed in require at /usr/lib/perl5/site_perl/5.10.0/VMware/VIFPLib.pm line 9.
BEGIN failed–compilation aborted at /usr/lib/perl5/site_perl/5.10.0/VMware/VIFPLib.pm line 9.
Compilation failed in require at /home/vi-admin/graphite/esxi-perf-graphite.pl line 5.
BEGIN failed–compilation aborted at /home/vi-admin/graphite/esxi-perf-graphite.pl line 5.

Это значит вы некорректно добавили путь к библиотеке (/opt/vmware/vma/lib64:/opt/vmware/vma/lib).

Если же вы получаете вот такую ошибку:

“Server version unavailable at ‘https://[host]:443/sdk/vimService.wsdl’ at /usr/lib/perl5/5.10.0/VMware/VICommon.pm line 545.”

Это из-за непрошедшей SSL-аутентификации. Если у вас нет валидных SSL-сертификатов, отключите авторизацию через SSL в вашем скрипте:

# Disable SSL Verification
export PERL_LWP_SSL_VERIFY_HOSTNAME=0


Таги: VMware, vMA, vSphere, Management, VMachines, ESXi

1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17    >   >>
Поиск по сайту:
Реклама


Advertisement






Зал Славы Рекламодателя
Ближайшие события в области виртуализации:

10/09/2015:  Облачные технологии 2015: антикризисный рост
12/11/2015:  CNews Forum 2015

Быстрый переход:
VMware Veeam StarWind IT-Grad 5nine Security Code Citrix Nutanix vRealize VirtualBox Symantec Gartner Softline EMC Microsoft Login VSI Oracle Offtopic RVTools Xen Enterprise Teradici Red Hat vGate Amazon NetApp VDI Linux Hyper-V IBM Cisco NVIDIA Google Parallels VMTurbo VSI HP Security Windows vCenter VMachines Storage Cloud Webinar View VKernel Events Hardware Windows 7 Caravan Apple TPS Hyper9 Nicira Blogs Sun VMC Xtravirt Novell vSphere IntelVT Сравнение VirtualIron XenServer CitrixXen ESXi ESX ThinApp VMFS Books P2V vCSA Virtual SAN VMworld V2V Backup Labs VMDK IaaS XenDesktop Horizon Mirage Video Event PowerShell Log Insight Operations Whitepaper SRM vCloud SaaS Converter SC VMM Workstation HA Snapshots Certification Tools SQL DR Update SSD VDP Sponsorship Fault Tolerance Partners PCoIP Azure RHEV Performance Manager Award Network Обучение AWS USB Replication Licensing PowerCLI Logs esxtop iSCSI Web Client Server XenApp Demo Fusion Visio Intel vCHS MP SMB NSX Calculator Бесплатно VSAN XenClient vExpert Client Beta VCP SAN Exchange Support Virtual Appliance MAP ONE DaaS VSA Desktop Networking vNetwork Monitoring VPLEX UCS Poster VSPP SDRS Mobile vMotion VDI-in-a-Box RDM Deduplication Forum Reporter vShield DRS ACE Cloud Computing Go nworks iPad XCP Data Recovery Sizing Pricing VMotion Snapshot FlexPod VMsafe Enteprise Monitor KVM vStorage Essentials Live Migration SCVMM TCO Studio AMD-V VirtualCenter NFS ThinPrint Troubleshooting Director VAAI Air Upgrade Memory Bug Chargeback Heartbeat Android MSCS Connector SSH Ports SVMotion Storage DRS CLI Bugs Composer DPM Mac
Интересные плакаты:

Постер о VMware vSphere 5.1 CLI:

Постер о vSphere 5.1 PowerCLI

Постер VMware vCloud Networking:

Порты и соединения VMware vSphere 5:

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

Составляющие решения VMware vCloud:

Популярные статьи:
Как установить VMware ESXi. Инструкция по установке сервера ESXi 4 из состава vSphere.

Включение поддержки технологии Intel VT на ноутбуках Sony VAIO, Toshiba, Lenovo и других.

Как настроить запуск виртуальных машин VMware Workstation и Server при старте Windows

Что такое и как работает виртуальная машина Windows XP Mode в Windows 7.

Как работают виртуальные сети VLAN на хостах VMware ESX / ESXi.

Инфраструктура виртуальных десктопов VMware View 3 (VDI)

Бесплатные утилиты для виртуальных машин на базе VMware ESX / ESXi.

Проектирование инфраструктуры виртуализации VMware vSphere 4.

Как поднять программный iSCSI Target на Windows 2003 Server для ESX

Отличия VMware ESXi 4 free (бесплатного), ESXi 4 и ESX 4 в составе VMware vSphere.

Новые возможности VMware vSphere 5.0 - официально.

Бесплатные программы для VMware ESX / ESXi в среде Virtual Infrastructure / vSphere (часть 2).

Как использовать возможности VMware vSphere Management Assistant (vMA).

Типы виртуальных дисков vmdk виртуальных машин на VMware vSphere / ESX 4.

Windows 7 в виртуальной машине VMware Workstation 6.5.2 и Virtual XP Mode.

Все ресурсы о виртуализации:
Интервью:

Alessandro Perilli
virtualization.info
Основатель

Ратмир Тимашев
Veeam Software
Президент


Купить:

VMware vSphere 5.5


Veeam Backup 8


Полезные ресурсы:


Видео компании VMware

Видео про Citrix Xen

Видео о виртуализации Microsoft

Утилиты для виртуальных машин Microsoft.

Книги на английском языке

Блоги на английском языке

Блоги на русском языке

Агрегация статей в твиттере VMC:


Copyright VM Guru 2006 - 2015, Александр Самойленко. Правила перепечатки материалов.