Skip navigation
2011

Коллеги, поздравляю вас с наступающим годом Дракона! К слову, на Дальнем Востоке Новый год уже наступил, с чем нас – Дальневосточников и поздравляю! А тем, кому еще только предстоит войти в Новый год, желаю успехов в работе, побольше новых полезных знакомств, интересных проектов и, конечно же, удачи! В общем, УРРРА, товарищи!!!

1.png

Кто хоть как-то связан с VMware vSphere, знают, что самый популярный блог на данную тему - это сайт "Yellow-Bricks.com". Так вот, автор этого блога, Duncan Epping, опубликовал итоговый пост, в котором приводит три свои самые популярные статьи 2011 года. Вот они:


  1. The HA Deepdive
  2. Using vSphere Auto-Deploy in your home lab
  3. esxtop


В принципе, все логично, только я удивлен, что в тройке лидеров нет статьи "The DRS Deepdive". Видимо, новая функция "Auto-Deploy" затмила всем разум :0)

Достаточно интересный документ от "DAVID DAVIS" и "BRAD BONN" при финансовой поддержке компании "VKernel" (проще говоря, спонсора). Вот описание, взятое из данного документа:

When sizing virtual machines a virtualization administrator must select the number of vCPUs, the size of the virtual disk, the number of vNICs, and the amount of memory. Out of all those resources, the amount of memory allocated to each virtual machine (VM) is often the most difficult to determine. This is because memory is the most dynamic and least predictable of those resources.


Virtualization administrators should avoid over-allocating memory to their VMs because doing so can waste expensive server resources and will, therefore, minimize the return on the investment (ROI) in that infrastructure. On the other hand, the business-critical applications running on virtual machines also need to maintain high performance, and the last thing a virtualization administrator wants is to have performance complaints from end users.  

Многое из этого документа мы с вами знаем, но, как говорится, повторение - мать учения. Для вашего удобства к этому посту прикреплена PDF версия данного документа.

Если у вас часто спрашивают, какую версию виртуального железа для ВМ использовать, или какие конкретно функции/возможности появились в той или иной версии VMH (Virtual Machine Hardware), то вы можете смело показывать вот эту небольшую сводную табличку. За её полноту я ручаться не могу, но, по крайней мере, если вы захотите создать свою подобную таблицу, то уже некий набросок у вас будет. Если создадите свою таблицу, не забудьте поделиться ею с комьюнити :0)

Многие блогеры перед самым Новым Годом подводят некие итоги своей деятельности, публикуя в блоге соответствующий итоговый пост. Кто-то пишет, что сделал, чего достиг, а кто-то о том, что нового узнал. Некоторые пытаются строить прогнозы на грядущий новый год. В общем, каждый развлекается, как может. А вот "Eric Sloof", автор весьма популярного блога "www.ntpro.nl", не стал сильно долго заморачиваться и просто опубликовал "10 самых популярных видео", сделанных им за "2011" год. Взгляните, может чего не видели или пропустили.

Deshifrator Hot Shot

Docs: VCP 510 Ressources

Posted by Deshifrator Dec 31, 2011

Буквально одной строкой. Очередная подборка материала, необходимого вам для сдачи экзамена "VCP 510", от Vladan SEGET (VMware vExpert 2011), активного блогера. Его блог вы можете найти, перейдя по следующему адресу: "www.vladan.fr".

Для тех, кто все же решил внедрить у себя на предприятии vSphere Storage Appliance (VSA) даже после прочтения вот этой статьи, думаю будет интересно следующее видео:


Поступила в продажу очередная книжка по VMware vSphere 5: "Administering vSphere 5: Planning, Implementing and Troubleshooting". Описание, взятое с сайта амазона:

ADMINISTERING VSPHERE 5: PLANNING, IMPLEMENTING AND TROUBLESHOOTING focuses on planning, installing, and maintaining vSphere environments. It is not a verbose documentation-style tome, but rather a comprehensive guide based on the tips, tricks, and gotchas gleaned from the authors' years of experience as vSphere consultants and trainers. The book is separated into four discrete sections: planning, implementation, troubleshooting, and security. The structure of the book provides readers with a balanced, deep understanding of vSphere. The authors have incorporated nearly two decades of consulting and training experience in the pages of this book. Real-world experience has been leveraged to help readers avoid the pitfalls that the authors have learned the hard way. Written by trainers, this book presents the material utilizing a practical teaching style. This experience will benefit both the new and veteran administrator alike. While this book does cover the new features found in vSphere 5, it doesn't assume that the reader has extensive experience with the previous versions of vSphere. ADMINISTERING VSPHERE 5: PLANNING, IMPLEMENTING AND TROUBLESHOOTING provides newcomers with a solid foundation in vSphere, while also filling in the gaps for more experienced readers.

К сожалению, электронной версии данной книги нет, и я думаю, что и не планируется. А жаль.

Ранее я уже написал пост про виртуальный модуль "OpenVPN Access Server", в котором рассказал, как легко и быстро его можно развернуть в своей виртуальной инфраструктуре. Но тогда я не упомянул, что кроме виртуального модуля существует уже готовый к использованию специальный программный пакет под различные операционные системы.

oas.jpg

Вы можете меня спросить: "А зачем нам его, в принципе, нужно использовать?". На мой взгляд, на это есть как минимум две причины. Первая - программный пакет, как показало время, обновляется гараздо чаще, чем виртуальный модуль. Вторая - у вас на предприятии используются ОС, которые основаны только на коммерческом Red Hat Enterprise Linux, а виртуальный модуль построен на базе Debian.


Лично я отказался от виртуального модуля в пользу программного пакета.

William Lam в своем блоге "www.virtuallyghetto.com" совсем недавно опубликовал несколько, как мне кажется, интересных скриптов, которые могут кому-нибудь пригодиться в хозяйстве. Вот они:


  1. sessionManagement.pl (подробности на английской языке читайте здесь)
  2. getdvSwitchInfo.pl (подробности на английском языке читайте здесь)


С помощью первого скрипта вы можете получить полный список текущих сессий к "vCenter", и, при необходимости, вы можете также, используя данный скрипт, "убить" простаивающую (idle) сессию. А вот с помощью второго скрипта вы cможете получить всю необходимую для вас информацию о распределенном свиче (dvSwitch). Пользуйтесь.

Иногда случается так, что нужно зайти в BIOS виртуальной машины, например, для того, чтобы поменять устройство, с которого нужно грузиться. Задача, на самом деле, вроде бы и простая, но если вы уже пробовали успеть нажать клавишу "F2" при перезагрузке виртуальной машины, чтобы зайти в её биос, то вы уже знаете, что это не так просто. Там все так быстро меняется, что успеть нажать "F2" непосильная задача, особенно, если все это делать удаленно с некоторой задержкой.


Но выход есть. Можно, так сказать, "притормозить" загрузку виртуальной машины, чтобы все-таки успеть переключиться в её консоль и нажать заветную клавишу "F2". Для этого вам нужно зайти в настройки нужной вам виртуальной машины, перейти на вкладку "Options", затем выбрать "Boot Options" и указать время в миллисекундах, которое необходимо подождать (я поставил 10 000 ms, что равняется 10 секундам - этого вполне хватает):

boot-delay.PNG

Теперь при перезагрузке ВМ вы увидите следующее:

bios-1.PNG

Нажав "F2", вы сразу же попадете в BIOS этой ВМ:

bios-2.PNG

Вот так все достаточно просто. И еще. После того, как вам больше не нужна будет задержка при загрузке, её лучше убрать, установив значение в "0" миллисекунд.

Источник: Could not join domain: the specified domain either does not exist or could not be contacted


Если вам зачем-то понадобилось ввести хост VMware ESXi 5.0 в домен, то вы можете столкнуться с некоторыми трудностями. Если у вас должным образом не настроен фаервол, который появился в ESXi 5.0, то при попытке ввести такой хост ESXi в домен, вы получите примерно такую ошибку:

Could not join <domainname> The specified domain either does not exist or could not be contacted. (я думаю, что в переводе это сообщение об ошибке не нуждается)

А все из-за того, что на ESXi-firewall'е по умолчанию не открыт 53-ий TCP порт. Именно через этот порт посылаются DNS запросы. А так как он закрыт, то вы и получаете соответствующую ошибку. Итак. Для того, чтобы справиться с этой проблемой, вам необходимо, используя "vSphere Client", открыть 53-ий UPD порт. Да-да, именно UDP, не TCP, как написано немного выше. И дело тут вот в чем. Если DNS запрос возвращает пакет, который меньше 512 байт, то все должно работать нормально. Поэтому вам сначала следует с помощью "vSphere Client" настроить соответствующим образом фаервол, открыв на нем 53-ий UDP порт:

ESXi-5.0-firewall.jpg

Если открытие UDP порта не поможет, то есть ошибка будет повторяться, то тогда вам следует временно отключить фаервол (тогда DNS запросы будут посылаться через 53-ий TCP порт). Для этого зайдите на хост VMware ESXi по SSH и выполните следующую команду:

# esxcli network firewall unload

После всего этого хост VMware ESXi 5.0 должен войти в домен, как миленький :0).

В VMware vSphere 5.0 немного преобразился "Video Memory Calculator". В частности, теперь можно указать количество виртуальных дисплеев (это делается с помощью нового параметра - "Number of displays"), ну и, в принципе все. Больше значительных нововведений нет, кроме того, что теперь

Для каких целей нужен параметр "Number of displays" я расскажу немного ниже.

"Video Memory Calculator" открывается в отдельном окне:

esxi5.PNG

В VMware vSphere 4.x, "Video Memory Calculator" выглядел немного по-другому (чуток попроще), но функционал, в принципе, был такой же. На скриншоте ниже это хорошо видно:

esxi-4.jpg

Немного погуглив на тему, зачем все-таки нужен параметр "Number of displays", я понял, что мало кто в курсе, зачем он вообще нужен (в частности, и я до этого момента не знал, для чего он может быть нужен). Поэтому особо не раздумывая, я для своей тестовой виртуальной машины WinXP для параметра "Number of displays" задал значение "2", и вот, что у меня получилось:

display.jpg

Как вы видите, действительно появился второй дисплей. Возможно, кому-то это придется по вкусу. После 15 минут использования мне показалось, что это вполне себе удобно. И еще. Максимальное количество виртуальных дисплеев равняется четырем (4). Но, к сожалению (а, может, и к счастью), мой монитор четыре таких виртуальных дисплея уже не вмещает. А вот два - вполне.

В блоге "Virtual Geek" опубликованы результаты неофициально (это важно) проведенного опроса 1935 респондентов (естественно, в основном, это ИТ специалисты) на тему "VMware Storage". То есть, были вопросы по типу: "А какую СХД вы используете?"; "А какими именно storage-функциями vSphere вы пользуетесь?", ну и тому подобные. Кстати говоря, в блоге "VM Guru" уже существует соответствующая заметка по поводу этого опроса. В этой же заметке, но только в комментариях, romx (специалист по NetApp СХД) высказал свое IMHO по части объективности данного опроса. Но сейчас не об этом.


В данном посте я хотел бы остановиться на том, кто какие протоколы, функции использует в своих средах, исходя из результатов неофициального опроса. И первое, на чем я хотел остановиться - это то, что же народ использует в качестве СХД для среднего и малого бизнеса (скорее всего, для малого бизнеса). И вот как распределились голоса:


  • FreeNAS – 5
  • OpenFiler – 24 (~1%)
  • Iomega – 17 (~1%)
  • QNAP – 36 (~1.5%)
  • Datacore – 20 (~1%)
  • Nexenta – 32(~1.5%)
  • Nimble – 6
  • Nutanix – 2
  • Fusion-IO – 3
  • IBM XIV – 6
  • Sun – 5
  • Whiptail – 4


Лично я удивлен, что FreeNAS набрал так мало голосов. Ну да ладно, не буду долго горевать :0). А теперь давайте уже перейдем к тому, кто какие протоколы использует в своей среде или в среде клиента для доступа к системе хранения данных:

1.png

Как видите, FC до сих пор в лидерах, причем доля его очень высока. Но заметьте, что NFS и iSCSI также активно применяются. Я думаю, что здесь есть достаточно четкая грань. FC выбирают, в основном, в больших организациях, где есть соответствующие денежные средства, и для которых преимущества FC очень важны. Под преимуществами я подразумеваю надежность (хотя, конечно, вы можете поспорить в этом моменте) и меньшую по сравнению с другими протоколами величину задержки при обращении к массиву.


Теперь давайте перейдем к более интересной диаграмме:

2.png

Из приведенной чуть выше диаграммы можно сделать вывод, что в SMB, в основном, используется "iSCSI (1GbE)" и "NFS (1Gb)", что вполне логично. Предприятия покрупнее активно используют "FC (4Gb)". Хотя, казалось бы, почему этим предприятиям не использовать "FC (8Gb)"? Ведь разница в цене на оборудование не сильно большая. Здесь все достаточно просто и весьма банально. Все зависит от СХД. В основном, предприятия, которые крупнее, чем SMB, покупают СХД энтерпрайз уровня, которая поддерживает только "FC (4Gb)", а все потому, что разница в стоимости между СХД, поддерживающей "FC (4Gb)" и СХД, поддерживающей "FC (8Gb)", достаточно велика. Этим можно объяснить преобладание "FC (4Gb)" над "FC (8Gb)".


В заключение я хочу привести последнюю диаграмму, которая меня заинтересовала:

3.png

Как видите, большинство балуется снапшотами. Главное, чтобы в меру и не ради бэкапа. Что еще меня удивило, так это активное использование "Thin Provisioning". Я думаю, что "Thin Provisioning" стоит использовать только в небольших средах, где можно за всем этим добром уследить, либо в тестовых, домашних лабораториях.

Источник: Cool Tool - HD_Speed


Утилита "HD_Speed" позволяет без особых усилий протестировать ваш жесткий и не только диск. Приведу англоязычное описание утилиты "HD_Speed", взятое с официального сайта:

Measures both sustained and burst data transfer rates of your hard disks, cd/dvd-roms, flash cards/sticks, floppys, etc. Realtime graphical display.

Текущая версия (1.7.2.91 от 25 ноября 2011) "HD_Speed" поддерживает операционную систему Windows, начиная с версии "WinNT4" и заканчивая "Win7". Еще очень приятно и то, что в списке поддерживаемых языков присутствует великий и могучий РУССКИЙ ЯЗЫК.

hd_speed.png

Утилита "HD_Speed" достаточно легка в обращении. Выбираете диск, указываете размер блока, выбираете режим (Чтение, Запись, Запись+чтение, Запись+чтение+проверка), задаете в формате (мм:cc) длительность и жмете по кнопке Старт. Только будьте внимательны, когда вы выбираете режим, где есть "Запись" - программа выдает информационное сообщение, в котором сказано, что все данные будут уничтожены. Имейте, пожалуйста, это в виду.

Источник: Does 2008 R2 Failover Clustering require a change to the Notify Switches policy?


В течение достаточно длительного времени компания "VMware" рекомендовала нам использовать multicast режим при настройке NLB (MS’s Network Load Balancing) кластера:

VMware recommends that you use multicast mode, because unicast mode forces the physical switches on the LAN to broadcast all NLB traffic to every machine on the LAN.

В блоге Михаила Коротько "www.vm.pro-it.kz" имеется хорошая статья на данную тему - "VMware vSphere и Microsoft Windows NLB". К ознакомлению рекомендую. Ну, а теперь, давайте вернемся к нашему разговору. Если вы все-таки по каким-либо причинам не хотите использовать multicast, а хотите использовать unicast, то вам нужно будет в настройках соответствующей портгруппы для политики "Notify Switches" установить значение "No":

Notify-Switches.png

С выходом Windows 2008 R2 кое-что изменилось и в работе failover-кластера. В соответствии с этим документом, multicast функционал в Windows 2008 R2 больше не используется. Теперь для обмена информацией внутри кластера используется "UDP unicast":

Multicast functionality has been discontinued in Windows Server 2008 failover clustering, and cluster communications now use User Datagram Protocol (UDP) unicast.

Из комментариев к статье-источнику следует, что теперь, так как каждый хост в кластере будет иметь свой IP и MAC адрес, политику "Notify Switches" можно не менять, то бишь оставить "Yes".

Jonathan Medd (автор блога www.jonathanmedd.net) опубликовал в своем блоге скрипт, с помощью которого без особого труда можно привести группу хостов ESXI в соответствие с рекомендациями вендора системы хранения данных. Так как у автора данного скрипта СХД от компании HP (EVA), данный скрипт заточен именно под эту СХД. Но если у вас другая СХД (а, скорее всего, так оно и есть), то немного переделать скрипт, я думаю, не составит большого труда. Ведь выполняемые команды-то везде одинаковые, отличаться будут, в основном, только передаваемые параметры.

Если кому-то хочется автоматизировать процесс настройки "Multi NIC vMotion" на хостах ESXi, то в блоге www.lucd.info уже имеется соответствующий простой и ничем не перегруженный скриптик, который, в случае чего, можно достаточно легко доработать. Правда, хочу заметить, что данный скриптик может использоваться для автоматической настройки "Multi NIC vMotion" только лишь на стандартом свиче (vSwitch). Имейте это в виду.

Появилась публичная бета версия "Virtual Storage Console (VSC) 4.0". Из нововведений хотелось бы отметить поддержку гипервизора ESXi 5.0. Дополнительную информацию вы можете получить на официальном сайте компании NetApp. Оригинальная новость находится здесь.

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

Англоязычные

Русскоязычные

  • Две статьи (1 и 2) из блога VM Guru


Из последней статьи вы узнаете, что в "VMware vSphere 5" контроллер PVSCSI использует меньше ресурсов процессора и показывает лучшую производительность по сравнению с "LSI Logic SAS" контроллером. Поэтому, если есть такая возможность (существуют соответствующие драйвера для гостевой операционной системы), то используйте PVSCSI.

В блоге "VMware SMB Blog" запостили соответствующее видео. Я думаю, какие-либо комментарии здесь излишни. Кому нужно, просто берите и смотрите, вникайте, экспериментируйте. Если вы еще не знакомы с vSphere - это видео именно для вас. Не упускайте возможность познакомиться с этой очень мощной, гибкой и масштабируемой платформой для виртуализации. И, заметьте, что это не какой-нибудь там рекламный пост, просто я действительно так считаю.

vsphere-5-install.PNG

Вышел очередной патч (Build Number: 515841 | Release Date: 12/15/2011) для VMware ESXi 5.0, в котором много чего поправили, так сказать, залатали дыры. В первую очередь хочется отметить проблему, связанную с "SCSI UNMAP" командой, при выполнении которой наблюдалось резкое падение производительности на таких операциях, как Storage vMotion и объединение снапшотов (snapshot consolidation). Нет, не подумайте, данную проблему пока не исправили. Просто теперь функция возврата дискового пространства (space reclamation feature) отключена по умолчанию. Поэтому тем, кому данная функция очень нужна, придется ждать очередного патча или, в худшем случае, следующей версии вСферы.

patch.jpg

Еще в данном патче исправили проблемы с vMotion и драйвером VMXNET3 (описание проблемы, возникающей с VMXNET3 драйвером приведено немного ниже).

VMXNET 3 driver versions 1.0.25.0-k to 1.1.17.0-k fail to activate the device if the number of vCPUs that you assign to a virtual machine is not a power of two.

Полный список всех изменений вы можете посмотреть здесь. Напомню, что если вам необходимо обновить один-два хоста ESXi, и у вас нет "Update Manager", то вам сюда.

В блоге "VMware Networking Blog" появилась серия статей на тему настройки распределенного свича (vDS) в различных окружениях. Очень много полезных рекомендаций. В общем, "VDS Best Practices". К ознакомлению обязательно.


  1. VDS Best Practices - Design Considerations (Part 1 of 6)
  2. VDS Best Practices - Virtual and Physical Switch Parameters (Part 2 of 6)
  3. VDS Best Practices - Rack Server Deployment with Eight 1 Gigabit adapters (Part 3 of 6)
  4. VDS Best Practices - Rack Server Deployment with Two 10 Gigabit adapters (Part 4 of 6)
  5. VDS Best Practices - Blade Server Deployments (Part 5 of 6)
  6. VDS Best Practices - Operational aspects (Part 6 of 6)

pdficon_large.gifОчередная полезная шпаргалка (текст, выделенный СЕРЫМ ЦВЕТОМ - это то, в чем автор немного сомневается, поэтому, имейте это в виду) от блогера Forbes Guthrie. Для вашего удобства существует PDF версия этой шпаргалки, которую вы можете получить, пройдя вот по этой ссылке, либо кликнув по соответствующей pdf-иконке.

Для начала хочу объявить о том, что появился новый документ касательно VSA: "VMware vSphere Storage Appliance Technical Deep Dive". Документ весьма интересный с технической точки зрения. В нем я нашел весьма и весьма занимательную диаграмму:

vsa-digram.png

На этой диаграмме изображена логика работы VSA. Что с чем взаимодействует, логические связи и т.д. Покажи эту диаграмму системному администратору Linux, я уверен, что он скажет примерно следующее: "Да ептиль, я это соберу за день, а с пивом - так вообще за полдня". И в самом деле, я, как человек, пришедший в мир виртуализации из мира *nix, на этой диаграмме вижу, что все это можно реализовать самостоятельно на основе OpenSource софта. Можно точно так же взять три виртуальные, либо три физические машины, и сделать примерно такое же отказоустойчивое хранилище.


Так за что вы платите, когда покупаете VSA? За поддержку? За графический интерфейс? Лично я сильно сомневаюсь, что среднему и малому бизнесу, по крайней мере, в России это сильно нужно. В заключение всего выше сказанного, хочу выразить свое мнение относительно VSA. Лично мне кажется, что VSA, как продукт - это напрасно потраченные деньги VMware на его разработку и сопровождение. Если уж на то пошло, SMB проще купить себе какую-нибудь дешевую хранилку, например, ту же ИОмегу или самосбор на базе какого-нибудь RAID-контроллера по типу 3ware. И это будет куда лучше, чем VSA. И еще VSA сложноват в сопровождении.

Хорошая статья на тему VSA имеется в блоге vm4.ru: "vSphere Virtual Storage Appliance". Особенно обратите внимание на раздел: "Размышления про применимость". Я думаю, что соответствующие выводы вы сделаете сами, если уже не сделали.

Как вы понимаете, все выше сказанное - это моё личное мнение, ни на что не претендующее. В этом мире, слава Богу, есть выбор, и каждый выбирает сам, куда деньги тратить.

После прочтения вот этой заметки, размещенной в блоге "VM Guru", решил я опробовать на деле бесплатный инструмент "vGate Compliance Checker" от небезызвестной многим нам компании "Код Безопасности", который предназначен для комплексной проверки виртуальной инфраструктуры на соответствие всем необходимым нормам информационной безопасности (ИБ). Обо всем этом вы можете подробно прочитать в заметке, приведенной выше. В этом же посте я хочу остановиться на практической части.


В общем, скачал я данный инструмент, запустил, добавил сервер, указал логин, пароль и IP адрес тестового хоста ESXi 5.0, на котором практически нет ничего (так, пара виртуалок). Затем я нажал на кнопку "Запустить", и буквально уже через пару минут я наблюдал детальный отчет об уровне безопасности данного хоста. Картинка, прямо скажу вам, достаточно печальная. Практически все не соответствует стандартам и рекомендациям! Как страшно жить! Но сейчас не об этом.


Внимательно просматривая отчет, который выдал мне "vGate Compliance Checker", я остановился на следующих двух "Несоответствиях":


  • Запрет использования Managed Object Browser
  • Отключение приветственной страницы (Welcome Web Page) ...

О том, что такое "Managed Object Browser", вы можете прочитать здесь.

Немного погуглив, я нашел статью в KB (1016039), в которой рассказывается о том, как отключить MOB и приветственную web-страницу:

# vim-cmd proxysvc/remove_service "/mob" "httpsWithRedirect"
# vim-cmd proxysvc/remove_service "/" "httpsWithRedirect"

После выполнения этих действий на хосте VMware ESXi, я решил повторить тест с использованием "vGate Compliance Checker", но мне это не удалось - возникла следующая ошибка:

vgate.PNG

Я так понял, что нужно вернуть приветственную web-страницу (Welcome Web Page) на прежнее место, иначе я не смогу повторить тест на отдельно стоящем тестовом сервере. Собственно, что я и сделал. Зайдя на хост ESXi по SSH, я выполнил следующую команду:

# vim-cmd proxysvc/add_tcp_service "/" httpsWithRedirect localhost 8309

В результате "Welcome Web Page (WWP)" снова появилась, и "vGate Compliance Checker" перестал при запуске теста выдавать ошибку (на время своих тестов я оставил WWP включенной).

Вы можете меня спросить, а зачем вообще самому что-то делать. Купил vGate, да и жми на кнопочки, защищай инфраструктуру. На это я вам отвечу следующее: "Лично мне очень важно понять то, как все это работает изнутри. Да, можно купить vGate и тыкать на кнопочки, но перед этим нужно во всем самому разобраться". Безусловно, "vGate R2" очень нужный инструмент, и я его так же, как и Александр Самойленко, рекомендую.

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

Источник: vSphere HA Isolation response when using IP Storage


Если вы в своей виртуальной инфраструктуре используете некую "IP-СХД", взаимодействуя с ней с помощью протокола iSCSI, и при этом в настройках кластера VMware HA для параметра "Isolation Response" у вас установлено значение "Leave Powered On", то в данном случае, когда все-таки произойдет изоляция хоста ESXi 5.0, при которой не будет доступа ни до "Management Network", ни до "iSCSI Network", HA после того, как блокировки, установленные на VMDK, будут сняты,

Так как изолированный хост ESXi не имеет доступа до хранилища, блокировки на VMDK файлы будут через некоторое время автоматически сняты.

перезапустит вышедшие из строя ВМ. Здесь всё, как вы видите, правильно и логично. Но здесь есть одно большое НО.


Изолированный хост не потушит свои ВМ до тех пор, пока не убедится в том, что блокировки на VMDK установил кто-то другой. А проверить он это может только после того, как появится сеть до СХД. Но если появится сеть до СХД, то в большинстве случаев это означает, что появилась и сеть управления, а это, в свою очередь, означает, что теневая ВМ может начать мусорить в сеть своим IP и MAC адресом, что приведет к некоторым проблемам. Конечно, если хост по IP сети доберется до СХД раньше и убедится в том, что блокировки на VMDK уже установлены, то он тут же потушит все свои ВМ. Но ведь может и не успеть добраться раньше, чем ВМ начнут мусорить. В общем, имейте это в виду при проектировании виртуальной инфраструктуры на базе VMware vSphere 5.

Буквально одной строкой. Темой "VMware Auto Deploy" я особо не интересовался, так как не вижу особой выгоды от его использования в моем конкретном случае. Но сейчас не об этом. Я всего лишь хочу сказать, что меня немного удивило, что на данный момент такие продукты, как "vShield App" и "vShield Endpoint", не совместимы с технологией "VMware Auto Deploy". Здесь стоит также отметить, что "vShield Edge" СОВМЕСТИМ с "Auto Deploy".

Об этом я узнал, прочитав эту статью: "vSphere 5 and vShield 5 Critical Considerations".

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


P.S.

Хотел одной строкой, а в итоге получилось вот что.

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

ESXi-Customizer-26-GUI.jpg

Как видите, все предельно просто. Все, что вам нужно, так это:


  • Указать путь до оригинального образа ESXi 5.
  • Указать путь до ранее скаченного драйвера устройства.
  • Указать рабочую директорию.
  • Нажать на кнопку Run!


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

В интернете на данный момент уже существует вполне достаточное количество опубликованных (в основном, англоязычных) статей и видеороликов на тему "Multiple-NIC vMotion". Видеоролики, в основном, все повторяются, да и статьи, в основной массе своей, тоже. Поэтому в данном посте я приведу только то, что я написал/перевел, и еще приведу несколько видеороликов, которые, как мне показалось, являются наиболее интересными, информативными и полезными. Вот, собственно говоря, то, что я уже успел написать/перевести к этому моменту на тему выполнения операции vMotion с использованием нескольких сетевых интерфейсов:


VMware Knowledge Base:

Видео из VMware KB TV про настройку Multiple-NIC vMotion:


Верхний видеоролик демонстрирует нам то, как ПРАВИЛЬНО настроить "Multiple-NIC vMotion" на стандартном свиче (vSwitch), а вот нижнее видео демонстрирует нам то же самое, но только уже для распределенного свича (dvSwitch):


Источник: Multi NIC vMotion, how does it work?


Duncan Epping опубликовал в своем блоге пост (приведен выше как источник), в котором прояснил некоторые темные моменты, касающиеся того, как работает vMotion с использованием нескольких сетевых интерфейсов, и как ведет себя vMotion в смешанной среде, то есть, например, когда на одном хосте только 1x10GbE сетевой интерфейс, а на другом 3x1GbE NIC.


Итак. vCenter перед тем, как начать процесс vMotion между "host-1" и "host-2", проверит каждый хост и определит общую пропускную способность (bandwidth) сети, которая доступна для vMotion на конкретном хосте. Другими словами, если хост имеет 2x1GbE NICs и 1x10GbE NIC, то общая пропускная способность этого хоста будет 12GbE. Что происходит затем, можно легко понять из следующих практических примеров:


  • Если хост-src (хост источник) имеет 1x1GbE NIC, а хост-dest (хост назначения) имеет 1x10GbE NIC, то между этими хостами будет открыто одно соединение.


  • Если хост источник имеет 3x1GbE NICs, а хост назначения 1x10GbE NIC, то будет открыто, в общей сложности, только три (3) соединения (по одному соединению с каждого 1GbE сетевого интерфейса источника) до хоста назначения.


  • Если хост-src имеет 15x1GbE NICs, а хост-dest 1x10GbE NIC и 5x1GbE NICs, то будет открыто десять (10) соединений (по одному соединению с каждого сетевого интерфейса источника) до 10GbE NIC и еще пять (5) соединений между оставшимися 1GbE сетевыми картами на хостах. В общем, получается, будет установлено между хостом-src и хостом-dest 15 соединений.


Стоит отметить тот факт, что если на хосте источнике будет 2x1GbE NICs, а на хосте назначения только 1x1GbE NIC, то будет установлено только одно соединение для осуществления vMotion.

Источник: ESXi – Use the embedded VNC Server


Установить на Windows машину VNC сервер - это проще простого. Грубо говоря, всего несколько кликов мыши - и все завелось. Но кто сталкивался с подобной задачей на Linux, тот знает, что это не так-то просто. Существуют целые многостраничные манулы о том, как правильно установить и настроить VNC сервер в ОС Linux, чтобы он загружался до залогинивания на целевой машине. В общем, суть такова, что в линуксе это трудоемкое занятие.


Но не все так уж плохо, как может показаться на первый взгляд. Оказывается, в VMware ESXi (это относится и к 4-ой и к 5-ой версии гипервизора) есть свой встроенный VNC сервер, который можно легко использовать для доступа к консоли виртуальной машины. Для того, чтобы получить доступ по VNC к консоли ВМ, внесите в её конфигурационный файл следующие строки:

RemoteDisplay.vnc.enabled = true
RemoteDisplay.vnc.port = TCP_port
RemoteDisplay.vnc.password = password

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

Доступ по VNC к консоли ВМ на данный момент реализован в VMware vSphere 4 и 5. Но хочу отметить, что данная возможность официально VMware не поддерживается. И, как мне кажется, очень даже зря.

Я думаю, другие два параметра не нуждаются в каком-либо дополнительном пояснении.

vnc6.PNG

Если вы данную операцию проделали на vSphere 4, то вы можете смело запускать VNC клиент и соединяться с сервером ESXi по порту 5901:

vnc1.jpg

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

vnc3.jpg

Вот так все достаточно просто, но это только для VMware vSphere 4.x. Как вы знаете, в vSphere 5 появился встроенный "ESXi firewall", в котором нужно будет открыть доступ по VNC порту. Как это сделать, хорошо написано здесь: "How to Create Custom Firewall Rules in ESXi 5.0".

Источник: ESXi Performance Graphs – VM Power


Если вы, находясь на уровне хоста VMware ESXi, перейдете на вкладку "Performance" и, в качестве объекта для мониторинга, выберете потребляемую хостом мощность:

vm-power-graph2.PNG

то, как и положено, вы увидите соответствующий график, по которому будет четко видно, когда и, самое главное, сколько электричества ваш ESXi хост "скушал". Правда, НЕ ВСЕГДА вы сможете увидеть нормальные графики. Если эта функция аппаратно не поддерживается на хосте ESXi, то на графике вы ничего не увидите. Везде будут одни только нули. Так вот. Возвращаясь к вопросу мониторинга мощности - её можно мониторить не только на уровне хоста ESXi, но и на уровне отдельно взятой виртуальной машины.

Хочу заметить, что эта функция в VMware vSphere 4 и 5 является экспериментальной.

По умолчанию функция мониторинга мощности на уровне виртуальной машины не активна. Для того, чтобы её включить, необходимо на каждом хосте ESXi для параметра "Power.ChargeVMs", находящегося в "Advanced Settings", изменить значение с "0" на "1". После выполнения данной процедуры на вкладке "Performance" конкретной ВМ вы увидите потребляемую ею мощность. Вот, как это выглядит на практике:

vm-power-graph.png

Как уже выше было сказано, данная функция до сих пор является экспериментальной (что в 4-ой, что в 5-ой версии vSphere), поэтому используйте её с особой осторожностью и не особо доверяйте её показаниям. На данный момент, это просто прикольная "фишечка".

Источник: NetApp Storage Best Practices for VMware vSphere


Если виртуальная машина перемещается в кластере SDRS с одного датастора на другой с целью освободить место на одном из них, то нужно учитывать следующее: если перемещаемая ВМ была дедуплицирована силами СХД NetApp, и, при этом, большинство из её дедуплицированных блоков были расшарены между другими ВМ, расположенными на этом же датасторе, то пространство, высвобождаемое в результате миграции этой ВМ на другой датастор, будет равняться количеству уникальных блоков этой виртуальной машины.

Например, если размер виртуальной машины составляет 100 гигабайт, и, при этом, 60 её гигабайт дедуплицировано и расшарено между другими ВМ на том же датасторе, то при миграции освободится всего лишь 40GB (это именно те уникальные блоки ВМ, которые не удалось дедуплицировать).

И еще. Когда виртуальная машина в Storage DRS кластере перемещается на другой датастор, для которого включена дедупликация, для вновь записанных блоков будет вычисляться хэш, но блоки (и это очень важно) этой ВМ на самом деле будут недедуплицированы до тех пор, пока не будет выполнена следующая запланированная или запущенная вручную дедупликация. И первое время ВМ будет занимать на новом датасторе 100% от своего размера.

Из недавно вышедшего документа: "NetApp Storage Best Practices for VMware vSphere (TR-3749)", хочу привести вам наилучшие практики по использованию кластера "Storage DRS" с системами хранения данных (СХД) от компании NetApp. Вот они:

sdrs.jpg

По-русски эти рекомендации будут звучать следующим образом:


  • Установите для кластера Storage DRS ручной режим (manual mode) работы и просматривайте рекомендации перед их применением.

  • Все датасторы, входящие в кластер, должны быть одинакового типа (SAS, SATA и так далее) и иметь одинаковые настройки репликации и защиты.

  • SDRS будет перемещать виртуальные диски ВМ между датасторами, и любая экономия места, полученная от клонирования или дедупликации срествами СХД NetApp, будет потеряна при перемещении VMDK. Но, вы можете повторно сделать дедупликацию, чтобы вернуть ранее сэкономленное дисковое пространство.


  • После того, как Storage DRS переместит VMDK, рекомендуется пересоздать (recreate) снапшот датастора, на который ранее был перемещен VMDK виртуальной машины.


  • Не используйте Storage DRS с "Thin Provisioning" VMFS датасторами из-за риска возникновения "out-of-space" ситуации, то есть ситуации, когда свободное место на СХД кончилось.


  • Не смешивайте "replicated" и "nonreplicated" датасторы в одном SDRS кластере.
  • Все датасторы в SDRS кластере должны быть либо VMFS, либо NFS типа.
  • Датасторы не могут быть расшарены между двумя различными сайтами (sites).

  • Все хосты, к которым подключены датасторы, входящие в SDRS кластер, должны работать под управлением гипервизора VMware ESXi 5.0.


Как видите, NetApp рекомендует нам именно ручной режим работы кластера SDRS. Возможно, это и правильно, судить не возьмусь, но лично я, будь у меня СХД от NetApp и Storage DRS кластер, я бы прислушался к рекомендациям вендора СХД.

Спешу сообщить вам о том, что обновился очень важный и архиполезный документ от компании NetApp - производителя СХД: "NetApp Storage Best Practices for VMware vSphere (TR-3749)". Теперь в нем есть раздел и про новые "вкусности", появившиеся в VMware vSphere 5, и то, как правильно их готовить с СХД от NetApp. Данный документ будет полезен абсолютно всем, потому что в нем содержится достаточно много общих рекомендаций, которые применимы и к виртуальным средам, построенным на основе СХД другого вендора.

Я думаю, многие из нас, кто настраивал iSCSI Multipathing в VMware vSphere, задавался следующим вопросом: "А можно и, главное, нужно ли использовать "NIC Teaming" для сетевых интерфейсов, выделенных для iSCSI трафика?". Забегая вперед, скажу, что нет, не нужно, но об этом немного ниже. Ну, а сейчас я хочу упомянуть об источниках, которыми я пользовался для написания этой маленькой заметки:


  1. Why can you not use NIC Teaming with iSCSI Binding?
  2. vSphere 5.0 Storage Features Part 12 - iSCSI Multipathing Enhancements
  3. VMware: Creating iSCSI network in vSphere ESXi 5.0


Предположим, что в вашей виртуальной инфраструктуре есть стандартный свич (vSwitch) с двумя подключенными к нему сетевыми интерфейсами (vmnicX), на котором создано две портгруппы с незатейливыми именами: "iSCSI01" и "iSCSI02". Для лучшего понимания, вот вам схема (я думаю, большинство именно так и настраивает iSCSI Multipathing):

iscsi-scheme.png

Если следовать официальной документации, а ей и нужно следовать, то в настройках каждой портгруппы "iSCSI01" и "iSCSI02" на вкладке "NIC Teaming" нужно один сетевой интерфейс поместить в секцию Active, а другой - в секцию Unused. В нашем случае для двух портгрупп это будет выглядеть следующим образом:

iscsi.png

Казалось бы, почему мы не можем поместить второй сетевой интерфейс в каждой портгруппе в секцию Standby, что позволило бы в случае отказа первого сетевого интерфейса перейти на использование второго? В блоге "VMware vSphere Blog" нам дают по этому поводу следующее пояснение:

This requirement prevents the VMkernel port from floating across uplinks in the case of a failure. The reason for this is that if the physical NIC loses connectivity, it should be treated as a storage path failure, not a network failure. We want the Pluggable Storage Architecture (PSA) in the VMkernel to handle this event and failover to an alternate path to stay connected to the storage.

Попробую пояснить то, как я это себе представляю. Если у вас все настроено, как написано в документации, когда один сетевой интерфейс находится в секции Active, а другой - в секции Unused, то в этом случае хост ESXi одновременно установит сразу два соединения до хранилища (фактически, по два соединения на каждый подключенный к хосту LUN), одно соединение через vmk1 iSCSI01 (vmnic4), а другое - через vmk2 iSCSI02 (vmnic5). В этом случае, если выйдет из строя сетевой интерфейс vmnic4, то PSA автоматически и без простоя в работе сменит маршрут до хранилища на альтернативный через vmk2 iSCSI02 (vmnic5). В данном случае все будет работать замечательно и, я еще раз подчеркну - без простоя в работе.


Теперь давайте рассмотрим другой вариант, когда второй интерфейс в каждой потргруппе находится в секции Standby, и внезапно, как оно обычно бывает, выходит из строя сетевой интерфейс vmnic4. Что же произойдет? А произойдет очень страшное: PSA вместо того, чтобы переключиться на альтернативный путь до хранилища через vmk2 iSCSI02, будет пытаться установить новое соединение через vmk1 iSCSI01, но уже через интерфейс vmnic5, который находится в секции Standby. Соответственно, мы получим некоторый простой в работе, хорошо, если виртуальные машины это переживут, а ведь могут и не пережить.

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

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

Источник: Nice vmkfstools feature for Extents


Задача по устранению проблем, возникающих с экстентами (extent), всегда была весьма трудной. Не было простого способа узнать, какой экстент (а, фактически, это физический LUN или диск), входящий в состав VMFS тома, вышел из строя. Но, с выходом vSphere 5.0, ситуация в этом смысле кардинально поменялась. Теперь с помощью стандартной утилиты "vmkfstools" можно запросто вычислить, какой экстент в VMFS томе вышел из строя. Для примера, вот вам VMFS-5 том, который состоит из двух iSCSI LUN:

# vmkfstools -Ph /vmfs/volumes/iscsi_datastore/
VMFS-5.54 file system spanning 2 partitions.
File system label (if any): iscsi_datastore
Mode: public
Capacity 17.5 GB, 16.9 GB available, file block size 8 MB
UUID: 4d810817-2d191ddd-0b4e-0050561902c9
Partitions spanned (on "lvm"):
        naa.6006048c7bc7febbf4db26ae0c3263cb:1
        naa.6006048c13e056de156e0f6d8d98cee2:1
Is Native Snapshot Capable: NO

Теперь, если хотя бы один из экстентов, входящих в состав тома VMFS-5, выйдет из строя, то утилита "vmkfstools" выдаст нам соответствующее предупреждение, из которого будет легко понять, какое конкретно устройство находится в офлайне:

# vmkfstools -Ph /vmfs/volumes/iscsi_datastore/
VMFS-5.54 file system spanning 2 partitions.
File system label (if any): iscsi_datastore
Mode: public
Capacity 17.5 GB, 7.2 GB available, file block size 8 MB
UUID: 4d810817-2d191ddd-0b4e-0050561902c9
Partitions spanned (on "lvm"):
        naa.6006048c7bc7febbf4db26ae0c3263cb:1
        (device naa.6006048c13e056de156e0f6d8d98cee2:1 might be offline)
        (One or more partitions spanned by this volume may be offline)
Is Native Snapshot Capable: NO

Как видите, все достаточно легко и просто. Пользуйтесь.

Источник: SQL Server Rolling Patch Upgrade using Standby VM


Неплохой мануал на тему обновления SQL сервера с помощью запасной ВМ. Алгоритм достаточно простой и, вполне себе, логичный. Итак, вышло новое обновление для SQL сервера, и вам нужно с минимальным простоем в работе его обновить.

Небольшое отступление. В этом примере в качестве SQL сервера выступает виртуальная машина с тремя (3) дисками: "System", "Data" и "Log". Наверное, вы уже догадались, что основные манипуляции будут именно с виртуальными дисками "Data" и "Log".

В статье, а точнее будет сказать, в руководстве, приведенном как источник, чтобы обновить SQL сервер с минимальным простоем в работе, нам предлагают поступить следующим образом (всего 5 шагов и будет счастье):

Шаг 1: Configure standby VM

  • Создаем путем клонирования основной или, с помощью шаблонов, вторую (standby или, проще говоря, запасную) виртуальную машину (точную копию основной) с SQL сервером на борту.
  • Убедитесь в том, что запасной SQL сервер настроен точно так же, как и первый (основной).
sql-1.png

Шаг 2: Patch standby VM

  • Обновляем запасной SQL сервер (применяем все необходимые патчи)
sql-2.png

Шаг 3: Hot remove SQL Server resources from primary

  • На основном SQL сервере отключаем все клиентские подключения к баз(е/ам) данных.

Сбросить все клиентские соединения можно путем отключения сетевого интерфейса.

  • Отсоединяем (detach) все базы данных от основного SQL сервера (sp_detach_db).
  • Переводим виртуальные диски "Data" и "Log" в автономный (offline) режим работы.
  • Используя vSphere Client, удаляем из основного SQL сервера диски "Data" и "Log".

sql-3.png

Шаг 4: Hot add resources to the SQL Server standby VM

  • Используя vSphere Client, добавляем на запасной SQL сервер "Data" и "Log" диски.
  • Используя "Disk Management", делаем диски "online" и монтируем их под нужными буквами.
  • Используя T-SQL команду sp_attach_db, присоединяем к запасному SQL серверу все БД.

sql-4.png

Шаг 5: Switch role

  • На запасном SQL сервере разрешаем сетевой трафик от приложений, путем включения vNIC.
  • Запасной SQL становится основным, и приложения начинают с ним взаимодействовать.
  • Теперь уже бывший основной SQL сервер можно обновить и "потушить" до следующего подобного обновления.

sql-5.png

Простой в работе SQL сервера у вас произойдет с 3-его по 5-ый шаг, но большинство приложений данный незначительный простой должны пережить, попросту переустановив соединение до SQL сервера и повторив ранее невыполненные запросы.

Источник: Leave Some RAM For Filesystem Cache


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


Если у вас достаточно много оперативной памяти на хосте, но при этом совсем слабая дисковая подсистема, то увеличение количества памяти (RAM), выделенной для виртуальных машин, может дать прирост в производительности инфраструктуры в целом, так как большинство I/O запросов к дисковой подсистеме будут закэшированы. Например, автор статьи, чтобы побороть задержки, возникающие при работе с дисковой подсистемой, на одной из своих ВМ увеличил объем RAM в три раза, что позволило закэшировать большинство дисковых I/O запросов и, тем самым, повысить производительность виртуальной машины.


Конечно же, это решение в продакшен средах не особо применимо, но в некоторых средах, например, состоящих из одного хоста ESXi с 16GB RAM и двумя SATA дисками в зеркале, такое решение вполне может сработать.

Источник: [How To] Patch vSphere 5 ESXi Without Update Manager


Для очень маленьких домашних лабораторий, состоящих из одного-двух физических серверов и не имеющих в своем составе VUM сервера, возможно, пригодится нижеследующий мануал о том, как пропатчить ESXi 5.0 без Update Manager:


  1. Для начала скачайте нужный патч со следующего портала: VMware Patch Portal
  2. Активируйте SSH доступ до хоста ESXi
  3. Переведите хост в режим обслуживания (после применения патча потребуется перезагрузка)
  4. Скопируйте соответствующий патч на хост ESXi с помощью SCP
  5. Затем выполните следующую команду:
esxcli software vib install -d /vmfs/volumes/[DATASTORE]/[PATCH_FILE].zip

После того, как команда esxcli завершит все необходимые действия по обновлению системы, вам нужно будет перезагрузить хост VMware ESXi. В результате вы получите пропатченный хост без использования Update Manager.

Буквально вчера на сервере "Dell PowerEdge R510", на котором установлено два блока питания, произошла неприятная ситуация. На первом БП произошел сбой. Конечно, в этой ситуации нет ничего страшного, ведь есть второй, резервный БП. Но вот только одно плохо, что о выходе из строя одного БП на сервере я узнал не от ESXi 4.1 U1, который установлен на этом сервере, а из информационного LCD дисплея, установленного на сервере.


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

pwsup1.PNG

По коду ошибки E1614 в "Dell™ PowerEdge™ R510 Systems Hardware Owner's Manual" мне удалось отыскать следующее описание:

pwsup3.PNG

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


Итак. Возвращаясь к теме оповещения. Как видно выше, возникла какая-то проблема с первым блоком питания. Но все бы ничего, вот только ESXi 4.1 U1 об этом ничего не сообщает. Для него по-прежнему все хорошо, красиво и работоспособно:

pwsup2.PNG

Я так понимаю, что это очередной баг в CIM агенте, что очень печально. Если у кого-нибудь есть возможность протестировать, как ведет себя ESXi 5.0 на сервере "Dell R510" при отключении или возникновении какой-либо ошибки на одном из блоков питания, пожалуйста, отпишитесь об этом в комментариях. Буду благодарен.

Инструмент "VMware Documentation Downloader" от компании Xtravirt позволяет закачать себе на рабочую станцию всю документацию по продуктам VMware (включая, кстати, и vSphere 5.0). Вот, что про него написано на официальном сайте:

GetVMwareDocs is a small DOS batch script that creates and maintains a local copy of all VMware’s product documentation, making it an ideal utility for consultants or administrators that require offline access to these resources, such as when at a customer site without immediate internet access.

То есть, "VMware Documentation Downloader" - это всего лишь небольшой DOS-скрипт, запустив который мы закачаем к себе на локальный компьютер все html-pages и PDF документы, которые располагаются на этой странице: http://www.vmware.com/support/pubs/index.html.

Примечание: Лично я данный инструмент пока не еще не использовал.

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