Archive for the ‘VMware’ category

Пароль для ESX 4.1 и ESXi 4.1 не более 8 символов

Июль 29th, 2010

Практически сразу после выхода новой версии ESX и ESXi обнаружилась ошибка в системе аутентификации. Суть ее в том, что при аутентификации воспринимается первые 8 символов пароля, и даже если пароль содержит больше, достаточно будет ввести правильно только первые 8. Официально написано тут – KB 1024500.

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

Для ESX:

Вставить md5 в файл /etc/pam.d/system-auth

  1. Логинемся как root в service console.
  2. Переходим в директорию /etc/pam.d/.
  3. При помощи текстового редактора (например VI) открываем файл system-auth.
  4. Добавляем три символа md5 к строке password sufficient, чтобы получилось так:

    password sufficient /lib/security/$ISA/pam_unix.so use_authtok nullok shadow md5

  5. Меняем пароль. Если пароль не сменить, ESX будет продолжать использовать “усеченный” пароль.

Для ESXi:

Тоже вставить md5 в файл /etc/pam.d/system-auth

  1. Входим в Tech Support Mode, благо это теперь официально поддерживается в новой версии ESXi и о том как включить его отлично написано у Михаила.
  2. Переходим в директорию /etc/pam.d/.
  3. При помощи текстового редактора (например VI) открываем файл system-auth.
  4. Добавляем три символа md5 к строке password sufficient, чтобы получилось так:
  5. password sufficient /lib/security/$ISA/pam_unix.so use_authtok nullok shadow md5

  6. (Опционально) Если хотим чтобы настройка применилась после перезагрузки ESXi, нужно добавить к файлику /etc/rc.local следующую строчку:
  7. sed -e ‘/password.*pam_unix.so.* md5/q’ -e ‘/password.*pam_unix.so/s/$/ md5/’ -i /etc/pam.d/system-auth

  8. Меняем пароль. Если пароль не сменить, ESXi будет продолжать использовать “усеченный” пароль.

 

Выход vSphere 4.1

Июль 14th, 2010

image

Радостной новостью прокатилась информация по всем блогам околовиртуальной среды о выходе обновления vSphere, теперь последняя версия номеруется vSphere 4.1.

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

1. Очень большая работа была проделана в сторону улучшения производительности и оптимизации использования ресурсов хоста. Например скорость взаимодействия между ВМ  в пределах хоста может достигать 19 Гб/c.

 2. Переработан механизм миграции (VMotion) и время миграции сокращено до 50% на тестах в сети 10 GbE.

 3. Добавленная поддержка iSCSI адаптеров:

  • 10Gb iSCSI Broadcom 57711;
  • 1Gb iSCSI Broadcom 5709;

Это позволит снизить нагрузку на процессор при использовании iSCSI для операций чтения и записи боле чем на 80%.

 4. Load-Based Teaming – еще одно улучшение для балансировки сетевой нагрузки, за счет объединения физических адаптеров в vNetwork Distributed Switch.

 5. Появилась возможность нормального развертывания систем ESXi по PXE.

6. Тонкий гипервизор ESXi теперь межет загружаться по SAN (Boot from SAN).

7. Доступ через консоль (Tech Support Mode) и по SSH к ESXi  теперь официально разрешен и поддерживается и его можно включить через клиента или локально на хосте.

8. Была реализована интеграция хостов ESX/ESXi с Active Directory. Теперь к хосту можно подключаться под своей учетной записью, то есть то что было в vCenter.

9. Появилась возможность (очень долгожданная) пробрасывать USB устройства, подключенные к хосту ESX/ESXi в виртуальные машины.

10. Новый vCenter 4.1 поддерживает в ТРИ раза больше виртуальных машин, хостов и подключений vSphere клиентов чем vCenter 4.0

И это далеко не все изменения и нововведения.О том, какие изменения были сделано можно прочитать на официальном сайте – http://www.vmware.com/support/vsphere4/doc/vsp_41_new_feat.html. Так же, коллеги из российской компании VMC сделали отличный документ с описанием изменений, с которым рекомендую ознакомиться – http://www.vmc-company.ru/pdf/vmware_vsphere_41_whats_new_rus.pdf

VMware как всегда радует нас.

Использование паравиртуального SCSI адаптера VMware.

Май 31st, 2010

Используя виртуализацию в производственной среде, у многих возникает вопрос о производительности и ее потере. Многие отмечают, что узким местом при большом коэффициенте виртуализации может стать дисковая подсистема, и не торопятся виртуализировать требовательные к дисковому IO системы, такие как БД. Разработчики гипервизоров уделяют большое внимание оптимизации производительности виртуальных машин, добавляя новые возможности, выпуская новые драйвера и улучшая файловые системы. Одним из таких улучшений была разработка паравиртуального адаптера для VMware ESX (Paravirtual SCSI Adapter). PVSCSI адаптер – высокопроизводительный SCSI адаптер, который может быть подключен к виртуальным машинам с определёнными гостевыми ОС. Он позволяет значительно повысить пропускную способность при больших нагрузках на дисковую систему ВМ, снижая при этом нагрузку на CPU хоста. Адаптер был разработан для работы с высокопроизводительными системами хранения данных на основе SAN и VMware не рекомендует использовать его для DAS (direct-attached storage) систем. ВМ должна быть версии 7 (Version 7). PVSCSI может быть использован для дисков с данными, то есть не для системного раздела ВМ и пока только в следующих гостевых системах:

  • Windows Server 2008 R2
  • Windows Server 2008
  • Windows Server 2003
  • Red Hat Linux (RHEL) 5

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

  • Для Fibre Channel – от 10% доя 30%
  • Для iSCSI – до 25%

Прирост производительности будет заметен, только если сравнивать ВМ при действительно больших нагрузках. То есть при производительности около 2000 IO в секунду разницы заметно не будет, об этом говориться в статье 1017652, КВ VMware:

“The test results show that PVSCSI is better than LSI Logic, except under one condition – the virtual machine is performing less than 2,000 IOPS and issuing greater than 4 outstanding I/Os.”

Но при больших нагрузках, например при 350 000 IO в секунду VMware в своих тестах получили 12% прирост производительности и 18% снижение нагрузки на процессор.

Не получиться использовать PVSCSI при использовании Fault Tolerance или Microsoft Cluster Service (MSCS).

Начать использовать PVSCSI можно как для новых ВМ так и для уже созданных.

Для новых ВМ процесс создание ничем не отличается:

1. При создании ВМ выбираем Custom конфигурацию

clip_image001

2. После ввода названия и выбора хранилища, на шаге Virtual Machine Version необходимо убедиться, что выбрана версия 7.

clip_image002

3. На следующем шаге будет предложено выбрать гостевую ОС а затем тип SCSI контролера. Выбираем VMware Paravirtual. Если выбранная ОС не поддерживает или некорректно работает с PVSCSI то рядом с типом контроллера мы увидим (not recommended for this guest OS).

clip_image003

4. Дальше все как обычно: заканчиваем создание ВМ, подключаем образ диска запускаем установку. После загрузки с установочного диска, например при установке Windows Server 2008 R2, мы увидим что в нашей системе нет установленных дисков.

clip_image004

5. Но это лишь говорит о том что на установочном диске небыло обнаружено подходящего драйвера и его нужно будет загрузить. Для этого подключаем к виртуальному floppy дисководу, главное не удалить его при создании ВМ, образ дискеты. Кликаем на значке дискеты в окне консоли и выбираем пункт Connect to floppy on datastore…

clip_image005

В появившемся окне необходимо выбрать образ из папки vmimages. Выбираем необходимы драйвер и возвращаемся к установке ОС.

clip_image006

6. Нажимаем Load Driver и выбираем папку на floppy диске в соответствии с процессором.

clip_image007

7. После загрузки драйвера Диск в окне отобразиться и можно продолжить привычный процесс установки.

clip_image008

PVSCSI можно добавлять не только при создании ВМ но и к уже работающим. Для этого в гостевой ОС должны быть установлены VMware Tools.

1. Для начала заходим в свойства ВМ (правой клавишей по ВМ и выбираем Edit Settings) и добавляем новое устройство (кнопка Add).

clip_image009

2. В появившемся окне выбираем из списка Hard Drive.

clip_image011

3. После указания размера и расположения диска обязательно потребуется указать к какому SCSI адаптеру (Virtual Device Node) будет подключён новый диск. Необходимо будет учесть, что PVSCSI диск должен быть подключен к тому же адаптеру что и системный диск, который по умолчанию находиться на ноде SCSI 0:0. В нашем случае новый диск подключаем как ноду SCSI (1:0).

clip_image012

4. Как только мы сохраним изменения, в списке устройств ВМ появятся два новых – новый SCSI контроллер и новый диск.

clip_image013

5. Теперь выбираем новый SCSI контроллер и нажимаем кнопку Change Type. В появившемся окне выбираем тип VMware Paravirtual и нажимаем ok.

clip_image014

6. После перезагрузки в управлении дисками (Disk Manager) появиться новый диск.

Общий диск для виртуальных машин на ESX/ESXi

Апрель 20th, 2010

Как создать общий для виртуальных машин диск? Очень просто.

Если еще не установлен vCLI, качаем и устанавливаем его. Запустив, переходим в папку bin.

clip_image002

Используем команду vmkfstools.pl для создания диска:

vmkfstools.pl –server <IP адрес сервера ESX> -c 10G -d eagerzeroedthick /vmfs/volumes/lab/shared.vmdk -a lsilogic

Для каждой ВМ проходим процесс добавления диска:

1. Заходим в “Edit Settings”

2. Кликаем “Add…”

3. Выбираем Hard Disk.

4. Подключаем созданный ранее диск.

5. Меняем значение “virtual device node” в разделе Advanced Options на неиспользуемый порт, Например SCSI (1:1):

clip_image002[5]

6. Возвращаемся в Edit Setting и меняем свойство “SCSI Bus Sharing” нового контроллера на “Physical”:

clip_image002[7]

7. Повторяем те же действия для другой ВМ.

После запуска обоих ВМ можно инициализировать и использовать общий диск.

Настало время объединяться

Март 29th, 2010

Коллеги, настало время объединяться.

И первые шаги в этом направлении уже делает Михаил – первый (по моему мнению) казахстанский блоггер, который пишет о виртуализации. Он создал группу в социальной сети для профессионалов и приглашает подключаться. Те, кто еще не знаком с его блогом, знакомтесь – http://vm.pro-it.kz

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

О поддержке Virtual Infrastructure 3

Февраль 18th, 2010

Для тех, кто использует Virtual Infrastructure 3 будет интересна следующая информация.

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

  • ESX 3.5 versions 3.5 GA, Update 1, Update 2, Update 3 and Update 4
  • ESX 3.0 versions 3.0 GA, 3.0.1, 3.0.2 and 3.0.3
  • ESX 2.x versions 2.5.0 GA, 2.5.1, 2.5.2, 2.1.3, 2.5.3, 2.0.2, 2.1.2 and 2.5.4
  • VirtualCenter 2.5 GA, 2.5 Update 1, 2.5 Update 2, 2.5 Update 3, 2.5 Update 4 and 2.5 Update 5
  • VirtualCenter 2.0

Они будут доступны до мая 2010, так что поторопитесь скачать. Официальное объявление можно причитать тут – www.vmware.com/support/policies/lifecycle/vi.

Так же будет официально прекращена основная (general) поддержка для этих продуктов в этом году. Расширенная (Extended) поддержка будет осуществляться в течении еще 3 лет для следующих продуктов:

  • ESX 3.5 Update 5
  • ESX 3.0.3 Update 1
  • Virtual Center 2.5 Update 6 (ожидается в начале 2010)

Подробнее и удобнее о сроках поддержки для продуктов VI3 в табличке на сайте VMware – http://www.vmware.com/support/policies/lifecycle/vi/eos.html

Так же существует несколько таблиц, по которым можно определить сроки поддержки продуктов VI3.

Например, если у продукта была два минорных релиза, то совокупный срок поддержки будет 9 лет.

  • General Availability – момент выхода основного релиза (пример обозначения ESXi 3.0);
  • Minor Release – дополнения к основному релизу, которое включает незначительные изменение или дополнения функционала. (Например ESXi 3.1);
  • Maintenance Release – релиз с исправлением ошибок. (Например ESXi 3.0.3)

Разница между типами поддержки в таблице ниже.

Автозагрузка VMware View Client на тонких клиентах

Декабрь 29th, 2009

Развертывание VDI решений так или иначе предполагает запуск на стороне клиента приложения для доступа к удаленной машине. Это приложение может быть как MS RDP Client, VMware View Client или клиент Cirtix XenDesktop. Очень часто бывает необходимо органичить пользователей и предоставить доступ только к клиенту VDI, убрав все лишнее. Этого можно добиться путем замены загружаемой оболочки, которой по умолчанию является Explorer.exe. Как это сделать, на примере тонкого клиента HP c установленной XPe и VMware View Client.

  1. Для начала создаем cmd файл, например view.cmd, следующего содержания:

@echo off

:View

«C:\Program Files\VMware\VMware View\Client\bin\wswc.exe»

goto View

2.  Поместить файл в папку, которая по умолчанию доступна пользователю, например в  C:\Documents and Settings\User\Desktop

3.  Теперь в этой же папке создаем новый VBS файл, например view.vbs, следующего содержания:

Set WshShell = CreateObject(«WScript.Shell»)

WshShell.Run chr(34) & » C:\Documents and Settings\User\Desktop\view.cmd» & Chr(34), 0

Set WshShell = Nothing

4.  Открываем REGEDIT, находим в ветке HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon параметр Shell и прописываем туда команду выполнения нашего скрипта:

wscript C:\»Documents and Settings»\User\view.vbs  (Если в названиях папки есть пробелы, возьмите их в кавычки)

Regedit

5.  Если если используете XPe то сохрание изменения во флеш-памяти клиента, в командной строке:

ewfmgr  c: –commit

После перезагрузки на рабочем столе ничего не увидим кроме окошка View Client, или например RDP, но в этом случае просто меняем, догадываетесь какую строчку, в view.cmd на

‘’C:\Windows\System32\mstsc.exe”

VMware View и Smart-Card Logon

Декабрь 29th, 2009

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

Клиент VMware View может пробрасывать USB устройства в том числе и смарт-карты, при этом как в клиентской машине так и в удаленной должны быть установлены драйвера устройства для считывания карты и ПО для работы со смарт-картами. В моём случая это Aladdin eToken PKI Client версии 5.1 и следующие устройства:

  1. HP USB Smart Card Reader
  2. HP USB Keyboard with SMART Card Reader
  3. HASP USB Token

Драйвера устройств и ПО были установлены без проблем как на удаленные так и на клиентские машины, в том числе и на тонкого клиента HP 5730 c WinXP Embeded SP3.

Смею предположить что у вас уже есть домен, Active Directory, Certification Authority  и сертификаты на карточках, если нет то вам сюда: TechNet Microsoft.Com, так как это отдельная, объемная тема.

Как вы знаете, в домене Windows уже есть возможность реализовать Smart Card Logon при помощи групповых политик, зачем же заморачиваться и делать это для VMware View? Это может улучшить безопасность использования удаленных машин. Это может понадобиться в связи с политиками безопасности организации. Это позволит применять Smart Card Logon для машин, где политиками Windows это не установлено. А может быть просто интересно как это работает.

Итак, первое что я сделал, это заменил сертификат, который используется для поднятия SSL соединения между клиентом и View Connection Server. Сертификат может быть выписан на сервер, содержать полное имя и быть в формате .pfx, то есть содержать Private Key. Для того чтобы экспортировать такой сертификат в файл, это должно быть разрешено шаблоном в Certification Authority – в шаблоне сертификатов компьютера должна стоять галочка:

Certificate Template Settings 

После того как файл сертификата есть, нужно положить его в папку:

C:\Program Files\VMware\VMware View\Server\sslgateway\conf

В этой же папке создать файл locked.properties и в нем прописать строчки:

keyfile=<имя файла>.pfx
keypass=<ключевя фраза>

После чего перезапустить службу View Connection Server. Для того чтобы убедиться что служба запущена и используется именно ваш сертификат можно посмотреть лог в папке C:\Documents and Settings\All Users\Application Data\VMware\VDM\logs\

13:57:40,676 INFO <Thread-1> [NetHandler] Using SSL certificate store: <имя файла>.pfx with password of 6 characters

Либо подключиться Internet Explorer к адресу View Connection Server и увидеть значок замка в адресной строке:

View Admin Portal

Теперь SSL соединение строиться с использованием сертификата вашей организации и клиенты ему доверяют.

Далее необходимо будет “сказать” VMware View кому можно доверять при авторизации по сертификатам, то есть по смарт-картам.

Сделать это можно будет следующим образом:

  1. Создать файлик Truststore – хранилище ключей
  2. Разрешить Smart Card Logon в настройках View Connection Server.

Для того чтобы создать файл Truststore, можно воспользоваться утилитой keytool из Java Runtime Environment (JRE), который устанавливается с VMware View, но чтобы было удобно воспользоваться ей из командной строки нужно добавить путь к файлам Java в переменные окружения сервера:

  1. Открываем Properties компьютера.
  2. На вкладке Advanced нажимаем кнопку Environment Variables
  3. В системной переменной Path, в конце строки добавляем следующее:

;%ProgramFiles%\VMware\VMware View\Server\jre\bin

System Variable

Мы готовы создать хранилище ключей но нужно что-то в это хранилище положить, а для этого нам понадобятся файлы сертификатов в формате .cer, которым будет доверять View Connetction Server. Это может корневой сертификат центра сертификации либо пользовательский сертификат, который можно сохранить в файл либо через оснастку certmgr.msc либо следующим образом:

  1. Запустить IE открыть Tools > Internet Options
  2. На вкладке Content кликаем Certificates.
  3. Выбираем сертификат и нажимаем на View
  4. На вкладке Details нажимаем Copy to File.
  5. Сохраняем в удобном месте, можно сразу в папке C:\Program Files\VMware\VMware View\Server\sslgateway\conf

Теперь добавляем сертификат в хранилище ключей нашего View Connection Server:

  1. Открываем cmd.exe
  2. переходим в C:\Program Files\VMware\VMware View\Server\sslgateway\conf
  3. И набираем следующую команду:

keytool -import -alias <Псевдоним_по_желанию> -file <Файл_сертификата>
-keystore <Имя_файла_хранилища>

4.  Далее нас попросят ввести пароль и спросят доверять ли импортируемому сертификату.

5.  Теперь добавляем у уже созданный ранее файл locked.properties следующие строчки:

trustKeyfile=<Имя_файла_хранилища>
trustStoretype=JKS
useCertAuth=true

Теперь включение функции Smart Card Logon в настройках View Connection Server:

  1. Открываем web-консоль администратора View.(/admin">/admin">https://<server_name>/admin).
  2. Идем в Configuration –> Servers, выбираем View сервер и нажимаем Edit.

VMware View позволяет применять три варианта использования смарт-карт:

  • Не использовать :) (Вход только по паролю пользователя)
  • Опционально (По паролю или смарт-карте)
  • Требовать смарт-карту (Вход только по смарт-карте)

 View Smart Card Options

3. Выбираем нужный (для проверки советую поставить 3 вариант) нажимаем OK и перезапускаем службу View Connection Server.

После перезапуска смотрим лог и видим:

<Front> [d] Smart Card/Certificate Authentication enabled at gateway

Теперь можно попробовать как это работает:

Запускаем клиента VMware View и если карта не вставлена а в настройках выбрана 3 опция то видим следующие предупреждение:

Smart Card Warning

Вставляем карту и видим запрос PIN кода нашей карты:

PIN Request

Вводим PIN и можем выбирать доступную нашему пользователю ВМ, после логона в которую, смарт-карта автоматически пробрасывается и уже там мы видим запрос PIN кода:

Windows PIN Request

Ну а дальше все как обычно.

Ну и на на последок хочется сказать что VMware предоставляет нам возможность управлять различными параметрами подключения к ВМ при помощи групповых политик компьютера и пользователя, шаблоны для которых предусмотрительно копируются при установке VMware View в папку:

C:\Program Files\VMware\VMware View\Server\Extras\GroupPolicyFiles

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

Добавить их можно при помощи оснастки gpedit.msc:

clip_image001[5]

По кнопке Add добавляем файлы шаблонов:

clip_image001[7]

clip_image001[9]

Нажимаем Close.

clip_image001[11]

View Policies

Теперь в нашей ВМ появились политики, которые позволяю, например запретить подключаться к ВМ отличным от VMware View клиетом, например MS RDP, и при подключении клиентом MS Remote Desktop Connection к ВМ мы увидим следующее:

clip_image001[13]

Так же есть политики по отключению звука, запрету USB устройств или Хранение PIN-кода карточки для последующей передачи его при входе в Windows, так чтобы для пользователя не приходилось вводить его два раза. Все политики имеют достаточно внятное описание, поэтому советую с ними ознакомиться. На этом пока все и надеюсь кому-то помог.

Отчет о преимуществах виртуализации для SMB от VMware.

Декабрь 21st, 2009

Компания VMware опубликовала отчет с результатами своего опроса 309-и компаний малого и среднего бизнеса (от 1 до 1000 человек) США и Канады. Опрос был направлен на выявление основных преимуществ и потребностей SMB сегмента рынка виртуализации. Приведены как текстовые описания вопросов так и графическое представление результатов, например на вопрос “Какой из перечисленных факторов препятствует продвижению виртуализации в вашей организации?”.

 image

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

Ознакомится с отчетом на английском языке можно скачав с сайта VMware – http://www.vmware.com/files/pdf/VMware-SMB-Survey.pdf

Мониторинг ESX\ESXi по SNMP

Декабрь 10th, 2009

В гипервизорах ESX\ESXi есть SNMP агенты, позволяющие передавать события по сети, например для систем мониторинга. Список таких систем довольно широк, от таких масштабных систем как HP Operations до бесплатных и специализированных на ESX VM Monitor от SolarWinds. Именно о последней в сообществе много писали. Действительно полезная для администраторов VMware инфраструктуры, сидит в трее и показывает различные статусы серверов и виртуальных машин.

image

Есть несколько но:

  • Не поддерживает последнюю, 4-ую версию ESX.
  • Не поддерживает ESXi

Но сегодня я хочу рассказать о том, как настроить и проверить работу SNMP уведомлений на серверах ESX\ESXi 4 версии. Понадобиться командная строка VMware vSphere CLI, которая не так давно вышла в обновленной версии 4.0 Update 1.

После установки, команды vSphere CLI можно запускать в cmd.exe, перейдя в папку bin в каталоге установки, у меня это C:\Program Files\VMware\VMware vSphere CLI\bin. Для управления SNMP агентом нужно воспользоваться командой vicfg-snmp.pl (более подробно с работой командной строки и командами можно ознакомиться в документе vSphere Command-Line Interface Installation and Reference Guide).

Сценарий следующий:

1. Перед использованием агента нужно задать хотя бы одно значение community string, следующей командой:

vicfg-snmp.pl –server <имя хоста> –username <логин> –password <пароль> -c <значение, например public>

2. Теперь нужно настроить адрес, куда агент будет слать свои сообщения:

vicfg-snmp.pl –server <имя хоста> –username <логин> –password <пароль> -t <имя хоста>@<номер порта, по умолчанию 162>/<значение, например public> (пример – vicfg-snmp.pl –server host.example.com –username user –password password -t target.example.com@162/public.)

3. Активировать агент:

vicfg-snmp.pl –server <имя хоста> –username <логин> –password <пароль> -E

Для того чтобы проверить работу SNMP агента можно воспользоваться утилитой Trap Receiver. Ее необходимо установить и запустить на хосте, который был указан как target для агента.

4. Запустить тест:

vicfg-snmp.pl –server <имя хоста> –username <логин> –password <пароль> –T

В результате в окне Trap Receiver получим следующий результат:

Trap 

Теперь, для того чтобы наша ловушка могла интерпретировать snmp события в удобный язык необходимо загрузить MIB файлы и подключить их в следующем порядке:

  • VMWARE-ROOT-MIB.mib
  • VMWARE-TRAPS-MIB.mib
  • VMWARE-PRODUCTS-MIB.mib
  • VMWARE-SYSTEM-MIB.mib
  • VMWARE-ENV-MIB.mib
  • VMWARE-RESOURCES-MIB.mib
  • VMWARE-VMINFO-MIB.mib
  • VMWARE-OBSOLETE-MIB.mib (для версий ESX/ESXi до 4.0)
  • VMWARE-AGENTCAP-MIB.mib
  • VMWARE-VC-EVENT-MIB.mib

Теперь полученные события имеют описание:

TrapwithMIB

В качестве примера в Virtual Center был настроен Alarm на выключение ВМ и отправку SNMP события. Подробнее о настройке Alarm-ов можно прочитать тут – Working with Alarms.