Skip navigation
2011

В vSphere Client'е для VMkernel интерфейса вы можете задать только один шлюз, на который ESXi и будет пересылать все пакеты, направленные в удаленные сети. Но что, если нужно сделать какое-либо исключение и добавить нестандартный маршрут? В гипервизоре ESX это достаточно легко сделать, так как в нем есть Service Console (SC). А как же быть с ESXi, в котором SC просто нет? Ответ простой - нужно использовать служебную команду esxcfg-route. Собственно, перейдем к её рассмотрению. Чуть ниже приведены различные примеры её использования.


Просматриваем текущую таблицу маршрутизации:

# esxcfg-route --list
VMkernel Routes:
Network          Netmask          Gateway          Interface
192.168.33.0     255.255.255.0    Local Subnet     vmk0
default          0.0.0.0          192.168.33.1     vmk0

Добавляем нестандартный маршрут до подсети 192.168.100.x через шлюз 192.168.33.17:

# esxcfg-route -a 192.168.100.0/24 192.168.33.17

А так можно переназначить шлюз по умолчанию:

# esxcfg-route -a default 192.168.33.17

Если при добавлении маршрута вы допустили ошибку, указав не тот шлюз или не ту подсесть, или вам просто ранее добавленный маршрут больше не нужен, то удалить его можно быстро и легко, выполнив следующую команду:

# esxcfg-route -d 192.168.100.0/24 192.168.33.17

Выше приведенные примеры команд подходят только для работы с IPv4 таблицей маршрутизации. Посмотреть примеры (синтаксис) команд для работы с IPv6 таблицей маршрутизации вы можете, вызвав справку для этой команды:

# esxcfg-route --help

Для тех, у кого нет под рукой терминала, приведу скриншот, на котором изображены различные примеры команд для работы с IPv6 таблицей маршрутизации:

ipv6-route-table.jpg

Источник: KB Article: 2000130


Если в целях отладки вам нужно просмотреть ARP (для IPv4 сетей) или Neighbor Discovery (для IPv6 сетей) кэш, то на хосте ESX/ESXi вам нужно выполнить следующую команду:

# esxcli network neighbor list

На своем сервере я получил следующее:

Neighbor       Mac Address        vmknic  Expiry(sec)  State
192.168.0.6    00:19:cb:8b:d5:30  vmk0    922
192.168.0.15   00:1b:78:04:71:7e  vmk0    1176
192.168.0.16   00:0c:29:6d:c8:99  vmk0    1169
192.168.0.30   00:13:72:62:4d:64  vmk0    1197
192.168.0.240  00:18:8b:e7:52:68  vmk0    1199
192.168.0.249  00:15:17:c9:63:17  vmk0    1146

Более подробную информацию о протоколе ARP и Neighbor Discovery можно получить, прочитав вот эти статьи: IPv6 и ARP.

Andy Grant (один из авторов блога по виртуализации www.vladan.fr) опубликовал пост, в котором представлена достаточно интересная диаграмма:

Adv-Disk-Parameters-Visual.jpg

До этого то же самое, только на словах, описал Duncan Epping (автор блога www.yellow-bricks.com) в своем посте. Лично мне диаграмма пришлась по вкусу, прояснив для меня некоторые непонятные до этого моменты.


 

UPD.: (6/29/2011)
В блоге vmgu.ru появился хороший русскоязычный пост на эту тему:


Русскоязычные Блоги, Сайты и Документы

blog.vadmin.ru


itband.ru


vm4.ru


vmgu.ru


vsphere.ru


vforv.me


Статьи на Хабрахабре


VMUG: Russia VMware User Group


Англоязычные Блоги, Сайты и Документы

vpivot.com


vmguru.com


vreference.com


vmnomad.blogspot.com

petri.co.il


VMware Documents


vladan.fr


yellow-bricks.com


hypervizor.com


frankdenneman.nl


deinoscloud.wordpress.com


virtualinsanity.com


jpaul.me


PDF Documents


alistg.wordpress.com


van-lieshout.com


ntpro.nl


mikes.eu


gabesvirtualworld.com


searchvmware.techtarget.com


wikipedia.org


kingston.com


boche.net


vsential.com


blog.peacon.co.uk


kb.vmware.com


VMware vSphere Advanced Troubleshooting

PDF документ: AdvancedTroubleshooting.pdf и тоже самое только в слайдах (с 14 по 27 слайд).

VVAT.jpg

Автор блога deinoscloud.wordpress.com опубликовал занятное видео, в котором наглядно показал, как можно ограничить количество операций ввода/вывода в секунду для конкретной виртуальной машины. Рекомендую к просмотру (только после просмотра обязательно прочитайте комментарии к данному посту). Кстати говоря, у данного автора есть еще один пост на данную тематику:



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

Ранее сделанные мною посты на данную тему: пост1, пост2


После многочисленных статей (написанных другими авторами) и обсуждений, сотрудник VMware Duncan Epping опубликовал в своем блоге наинтереснейшую статью:


тем самым подводя некий итог. Вот, что пишет Duncan в заключении своей статьи:

To conclude, now that the coin has finally dropped on Disk.SchedNumReqOutstanding I strongly feel that the advanced settings should not be changed unless specifically requested by VMware GSS. Changing these values can impact fairness within your environment and could lead to unexpected behavior from a performance perspective.

Как можно было предположить, менять advanced settings не рекомендуется, так как это может очень негативно повлиять на производительность в целом. Но самое главное в этой статье не итог, а логика того, как это все работает. Поэтому не поленитесь, прочитайте на досуге.

Источник: KB Article: 2001123


Иногда бывает так, что агенты управления на хосте ESX не реагируют на различные команды и, в том числе, на команды выключения или перезагрузки хоста. Так что делать, если данный хост все же нужно перезагрузить, но при этом у вас нет возможности подойти и физически выключить его или подцепиться к нему через IP-KVM, iLO или iDRAC (за их отсутствием). В этом случае вы можете перезагрузить хост ESX удаленно, выполнив в SSH-терминале следующие команды:

# echo 1 > /proc/sys/kernel/sysrq
# echo u > /proc/sysrq-trigger
# echo s > /proc/sysrq-trigger
# echo b > /proc/sysrq-trigger

Примечание: Данный метод работает, только если ядро Service Console по-прежнему отвечает, то бишь не зависло.

Ниже показана таблица, в которой отображено, зачем нужна каждая конкретная команда:


CommandExplanation
echo 1 > /proc/sys/kernel/sysrqEnables the use of the commands
echo u > /proc/sysrq-triggerForces all disks to remount read only
echo s > /proc/sysrq-triggerSyncs all unwritten disk activity to disk
echo b > /proc/sysrq-triggerReboots the server

Jason Boche в своем личном блоге (www.boche.net) опубликовал интересную "приколюху" о том, как можно изменить стандартный вид DCUI на хосте ESXi. Изменив стандартный вид DCUI, мы тем самым можем повысить безопасность хоста ESXi в целом. По крайней мере, теперь, подцепившись напрямую к Console, нельзя будет увидеть как имя хоста, так и его IP адрес. Вот так, примерно, это всё будет выглядеть:

dcui-deshifrator.jpg

В одном из своих постов я уже писал о теме, которую поднял Jason Boche в своем посте. Затем эту тему подхватил и начал развивать Andy Grant, опубликовав два поста:



И вот, спустя некоторое время, Andy Grant опубликовал очередной (третий по счету) пост на эту тему с результатами своих экспериментов:



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

Источник: KB Article: 1011170


Если в вашей виртуальной инфраструктуре существует ВМ, в которой присутствует толстый (Thick) жесткий диск, и вам понадобилось узнать, какого он формата (zeroedthick или eagerzeroedthick), то, для получения этой информации, вам необходимо выполнить команды, представленные чуть ниже.

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

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

# vim-cmd /vmsvc/getallvms

vmid у моей тестовой виртуальной машины равен 16. Далее выполняем команду, которая выведет нам детальную информацию о жестком диске (я вывожу информацию для первого жесткого диска "Hard Disk 1" виртуальной машины Win2003-3, у которой vmid равен 16):

# vim-cmd /vmsvc/device.getdevices 16 | grep -i "Hard Disk 1" -A 14

Если в полученном (при помощи выше приведенной команды) описании жесткого диска вы увидите вот такую строку: "eagerlyScrub = true", то это значит, что данный жесткий диск пригоден как для кластерных приложений (clustered applications), так и для VMware Fault Tolerance. А это, в свою очередь, означает, что данный Thick диск имеет eagerzeroedthick формат:

getdevices.jpg

Существуют и другие методы определения формата Thick диска. Все эти методы описаны в статье, приведенной выше, взятой из VMware KB.








Deshifrator Hot Shot

VMware vSphere Homelab

Posted by Deshifrator Jun 19, 2011

Vladan Seget в своем блоге (www.vladan.fr) опубликовал пост, в котором рассказывает о том, как устроена его домашняя VMware vSphere лаборатория (VMware vSphere Homelab). Также в блоге (www.vladan.fr) существует раздел Lab, в котором подробно расписано о том, какие компоненты использовались для построения данной лаборатории. В общем, для тех, кто только собирается собрать свою домашнюю лабораторию для тестирования VMware vSphere, рекомендую данный пост к прочтению.

My-VMware-vSphere-HomeLAB.jpg

Изначально рассуждения на тему влияния параметра VMKernel Disk.SchedNumReqOutstanding на глубину очереди начал Jason Boche (boche.net). Затем эту тему подхватил и развил Andy Grant (один из авторов блога www.vladan.fr). Andy Grant провел ряд экспериментов (исследуя то, как параметр Disk.SchedNumReqOutstanding влияет на глубину очереди) и вот, что у него получилось:

Question: SIOC dynamically changes LUN queue depth (DQLEN) depending on load, how does this effect Disk.SchedNumReqOutstanding?

Answer: SIOC ignores the Disk.SchedNumReqOutstanding parameter.

Question: the adaptive queue depth algorithm dynamically changes DQLEN, how does this effect Disk.SchedNumReqOutstanding?

Answer: the adaptive queue depth algorithm uses Disk.SchedNumReqOutstanding as the lowest bound threshold for DQLEN.

Правда, не со всеми результатами согласен Duncan Epping:

I have read the article 3 times and still don’t get it… I have never seen SIOC bumping the DQLEN above the given Queuedepth up on an array so I expect your results are due to the fact that you were using it on an unsupported configuration.

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



Источник: Script - Automate VAAI Configurations in vSphere 4.1 (vaaiHWAccelerationMgmt.pl)


В продолжение темы VAAI. В англоязычном блоге virtuallyGhetto.com увидел скрипт, который умеет включать, выключать и отображать поддержку VAAI для группы серверов ESX/ESXi. Работает скрипт достаточно просто. Нужно только указать параметры, необходимые для подключения к vCenter, тип операции (query|enable|disable) и имя файла, в котором перечислены ESX(i) сервера. После этого скрипт, запросив пароль для доступа к vCenter, выполнит необходимую операцию, либо выведет соответствующее сообщение об ошибке. Данный скрипт также умеет напрямую подключаться к хостам ESX(i) в обход vCenter. Вот, например, как будет выглядеть вывод скрипта для двух хостов ESXi, если тип операции установлен "query":

query.png

Источник: KB Article: 1025757


На тот случай, когда нам нужно отключить запущенный CIM агент на хосте ESXi (например, если мы установили ESXi не на брэндовое железо, а на "самосбор", то CIM агент нам, в принципе, не нужен, только память зазря съедает да в лог мусорит), выполняем следующие команды:

# chkconfig sfcbd-watchdog off
# chkconfig sfcbd off
# /etc/init.d/sfcbd-watchdog stop

Для того, чтобы обратно включить CIM агент на хосте ESXi, в приведенных выше командах меняем ("off" на "on") ("stop" на "start") и заново выполняем данные команды.

Если вам понадобилось провести детальную инвентаризацию парка серверов ESX(i), в которой присутствует такой пункт, как NIC Firmware, или вам просто нужно посмотреть текущую версию firmware сетевого адаптера (NIC) на хосте ESX/ESXi, то вы легко можете это сделать, выполнив следующую команду:

# ethtool -i vmnic0

ethtool-1.jpg


P.S.

Если на хосте ESX/ESXi выполнить команду:

# ethtool -p vmnic0 15

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


P.P.S.

VAAI - vStorage APIs for Array Integration

Ссылки:

vmgu.ru


vmlab.ge


vm4.ru


virtualgeek.typepad.com


thelowercasew.com


blog.fosketts.net


yellow-bricks.com


vstorage.wordpress.com


virtu-al.net


vperformance.org


kb.vmware.com


На заметку:

Get the value:

# esxcfg-advcfg -g /DataMover/HardwareAcceleratedMove
# esxcfg-advcfg -g /DataMover/HardwareAcceleratedInit
# esxcfg-advcfg -g /VMFS3/HardwareAcceleratedLocking

Enable[1] / Disable[0] VAAI:

# esxcfg-advcfg -s 1 /DataMover/HardwareAcceleratedMove
# esxcfg-advcfg -s 1 /DataMover/HardwareAcceleratedInit
# esxcfg-advcfg -s 1 /VMFS3/HardwareAcceleratedLocking
VAAI Status:
# esxcfg-scsidevs -l | egrep "Display Name:|VAAI Status:"

Источник: KB Article: 1038241


Все мы, наверное, наслышаны о том, что в VMware vSphere 4.1 появилась такая замечательная технология, как Storage I/O Control (SIOC). Если вы еще не знаете, что такое SIOC и зачем он нужен, то вам прямая дорога к прочтению следующих статей: 1 2 3. Так вот, SIOC - это конечно хорошо, но эта технология становится доступной, только если у вас имеется в наличии лицензия Enterprise Plus, а она (в смысле лицензия) имеется далеко не у каждого. Так что делать, если лицензии Enterprise Plus нет, а задать, например, ограничение на количество вырабатываемых IOps для конкретной виртуальной машины, необходимо. Как оказалось, решение существует. И оно достаточно простое. Всего лишь нужно добавить одну строчку в конфигурационный файл ВМ. Какую строчку и как добавить, показано чуть ниже.


Переходим в папку c нужной нам ВМ:

# cd /vmfs/volumes/ESXi-01-Local/Debian/

и добавляем (виртуальная машина к этому моменту должна находиться в выключенном состоянии) в конфигурационный файл ВМ строчку, которая ограничит количество операций ввода/вывода в секунду для данной ВМ до 50:

# echo "sched.scsi0:0.throughputCap = 50IOps" >> Debian.vmx

Если нам нужно ограничить не количество IOps, генерируемых данной ВМ, а полосу пропускания, то в конфигурационный файл данной ВМ добавляем следующую строку:

# echo "sched.scsi0:0.bandwidthCap = 10KBps" >> Debian.vmx

Вместо 10KBps вам нужно подставить своё, более подходящее значение.


Практикум

Первым делом на тестовом сервере под управлением ESXi я остановил все запущенные на нем виртуальные машины. Затем я запустил только одну ВМ (ей оказалась Debian) и посмотрел, сколько IOps она генерирует без каких-либо явным образом заданных ограничений. Затем я остановил ВМ и задал для нее ограничение на количество IOps, равное пятидесяти (50). Далее я снова запустил эту виртуальную машину. И вот, что я увидел на графике:

disk-iops-limit-1.jpg

Как видно на графике, виртуальная машина без каких-либо установленных ограничений может генерировать до трёхсот (300) IOps (примерное время на графике c 14:11 по 14:12). При этом ВМ с установленным ограничением (примерное время на графике: c 14:27 по 14:31), как и положено, в среднем, генерирует около 50 IOps. Точнее будет сказать, что ВМ генерирует больше IOps, но установленное ранее ограничение не дает выйти ВМ за рамки дозволенного. А это значит, что ограничение, как таковое, работает, что и требовалось доказать/подтвердить.

После долгих и нудных уговоров, лекций о здоровом образе жизни и преимуществе в плане быстрого передвижения по городу, я, наконец, "сдался" (нужно же было понабивать цену:))) и согласился! Обсчитали бюджет, объездили кучу магазинов, перелопатили массу информации с вело-блогов, изучили кучу отзывов о различных марках (заняло не один день) и отправились в магазин. Зашли, остановились возле выбранной дистанционно модели велика согласно формуле цена = качество, озадаченно на нее попялились пару минут (оказалась не той расцветки, какой видели в инете, что-то такое глянцево-серое, вычурное и на глаз неприятное), переглянулись и отвернулись... И тут увидели их, Merida Matts 40V-N2:

merida-40V-N2.jpg

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

И вот теперь мы счастливые обладатели замечательных транспортных средств, радующих как глаз, так и душу! Особенно радуют прогулки по ночному городу Хабаровску, когда достаточно тихо, немноголюдно и красиво!!!

А вот, собственно, и довольные мы:

Liza.JPG

Deshifrator.JPG

Deshifrator Hot Shot

Free Tools

Posted by Deshifrator Jun 9, 2011

В блоге по виртуализации vsphere-land.com увидел достаточно интересную подборку различных бесплатных (Free) инструментов от различных производителей (VMware, Veeam, vKernel, HP и еще много кого). Также присутствуют и OpenSource инструменты. Подборка выполнена в виде таблицы с возможностью сортировки по различным столбцам, что лично для меня оказалось чрезвычайно удобным. В общем, обязательно посмотрите данную подборку. Может, чего интересного для себя найдете.

Free-Tools.jpg

В гипервизоре VMware ESX/ESXi есть такая замечательная функция, как "Автоматический запуск виртуальных машин". Если у вас на хосте ESX/ESXi находятся, допустим, 10 или более виртуальных машин, и если у вас корректно настроен автоматический запуск данных ВМ, то, после очередной перезагрузки хоста ESX/ESXi, все эти виртуальные машины будут автоматически запущены без какого-либо участия администратора. Согласитесь, что это достаточно удобно, особенно если у вас много ВМ на одном хосте.


От слов к делу. Для того, чтобы настроить автоматический запуск виртуальных машин, нужно в vSphere Client'e выбрать хост ESX/ESXi, затем перейти на вкладку Configuration -> Virtual Machine Startup/Shutdown и нажать на ссылку Properties:

vmss-1.jpg

После нажатия на ссылку "Properties" откроется окно настроек, в котором необходимо установить галочку напротив "Allow virtual machines to start and stop automatically with the system":

vmss-1-1.jpg

после чего нам станут доступны различные настройки:

vmss-2.jpg

Ну, а теперь по порядку пробежимся по настройкам:


  • Default Startup Delay - время, заданное в секундах, которое должно пройти после запуска одной виртуальной машины до запуска другой ВМ. Отсчет времени происходит сразу же после запуска виртуальной машины. Именно после запуска, а не после того, как завершится загрузка операционной системы в этой ВМ.

  • Continue immediately if the VMware Tools start - запускать следующую виртуальную машину сразу же после того, как запустится пакет VMware Tools. При этом время Default Startup Delay игнорируется. Чтобы было более понятно, приведу небольшой пример. Как видно на рисунке выше, в секции Automatic Startup находятся три виртуальные машины. На всех трех ВМ стоит VMware Tools. Так вот, если галочка напротив Continue immediately if the VMware Tools start НЕ установлена, то виртуальные машины после перезагрузки хоста ESX/ESXi будут стартовать в следующeм порядке: первой запустится ВМ FreeBSD, через 120 секунд запустится ВМ WinXP, еще через 120 секунд запустится ВМ WinXP-2. То есть весь процесс запуска трех ВМ займет четыре с небольшим минуты. Но если напротив Continue immediately if the VMware Tools start УСТАНОВЛЕНА галочка, то сценарий будет другим: как обычно первой запустится виртуальная машина FreeBSD. Спустя 30 секунд операционная система в виртуальной машине FreeBSD полностью загрузится, и в ней запустятся утилиты из пакета VMware Tools, а так как напротив пункта Continue immediately if the VMware Tools start установлена галочка, то, не дожидаясь окончания 120 секунд, будет запущена следующая ВМ - WinXP. Спустя 30 секунд в ВМ WinXP так же запустится VMware Tools, и тут же будет инициирован процесс запуска следующей ВМ - WinXP-2. То есть весь процесс запуска трех виртуальных машин займет чуть больше минуты. Если в какой-нибудь ВМ не установлен пакет утилит VMware Tools, то ничего страшного нет. Просто следующая ВМ запустится по истечении 120 секунд с момента запуска предыдущей ВМ, где нет вообще, или по какой-либо причине не запустился, VMware Tools.


  • Default Shutdown Delay - это время, заданное в секундах, которое отводится определенной виртуальной машине для завершения своей работы. Немного поясню, что это значит. Когда вы перезагружаете или выключаете хост ESX/ESXi путем выбора соответствующего меню "Reboot" или "Shut Down", то гипервизор начинает поочередно выключать запущенные на нем виртуальные машины. Причем гипервизор не просто выключает ВМ, он еще и ждет, пока гостевая ОС, установленная на этой ВМ, корректно завершит свою работу. И только после этого переходит к выключению следующей ВМ. Следовательно, если операционная система в ВМ зависла до или во время завершения работы, то гипервизор не перейдет к выключению следующей ВМ, что не есть хорошо. И вот на этот случай и существует Default Shutdown Delay, то есть время, в течение которого гипервизор пытается корректно выключить ВМ, и, если ему этого не удается, переходит к выключению следующей ВМ. Если ВМ по требованию завершает свою работу раньше отведенного ей времени, то гипервизор сразу же переходит к выключению другой ВМ. Всё выше написанное для Default Shutdown Delay справедливо, если Shutdown Action для группы ВМ установлен в Guest Shutdown, и если в данных ВМ установлен и запущен VMware Tools. Однако Default Shutdown Delay, может пригодиться и для Shutdown Action: Power Off или Suspend. Ведь нельзя на 100% гарантировать, что задача Power Off или Suspend для виртуальной машины не зависнет.

  • Shutdown Action - выбираем то, как будут выключаться виртуальные машины:


    1. Power Off - "жесткое" выключение виртуальных машин
    2. Guest Shutdown - "мягкое" выключение с использованием утилит из пакета VMware Tools. Если в виртуальной машине не установлен набор утилит VMware Tools, то она НЕ БУДЕТ выключена (это равносильно тому, если бы у хоста ESX/ESXi внезапно пропало бы питание).
    3. Suspend - приостановить виртуальные машины


  • Startup Order: Automatic Startup - виртуальные машины, которые находятся в данной секции, будут первыми, в отличие от других ВМ (которые расположены в других секциях), поочередно запускаться в соответствии с ранее определенными настройками (см. Default Startup Delay и Continue immediately if the VMware Tools start).

  • Startup Order: Any Order - виртуальные машины, которые находятся в данной секции, начнут запускаться только после того, как в секции Automatic Startup запустится последняя ВМ, и пройдет 120 секунд, либо запустится VMware Tools. Очередность запуска виртуальных машин в данной секции каждый раз меняется. Если посмотреть на рисунок выше, то мы увидим, что в секции Any Order у нас располагаются две ВМ - Debian и Xangati-VA. Если перезагрузить хост ESX/ESXi, то мы можем увидеть, что первой запускается ВМ Xangati-VA. Перезагрузив еще раз хост, мы можем увидеть, что первой запускается другая ВМ - Debian. А может случиться и так, что, перезагружая раза два-три подряд хост ESX/ESXi, первой запускается ВМ Xangati-VA, а перезагрузив хост в третий-четвертый раз, первой запускается ВМ Debian. В общем randomize рулит для этой секции.

  • Startup Order: Manual Startup - виртуальные машины, которые находятся в данной секции, не будут автоматически запускаться после того, как хост ESX/ESXi будет перезагружен.


Итак, с настройками мы разобрались. Осталось только непонятно то, как для одной определенной ВМ изменить какой-либо параметр. Например, как можно изменить Shutdown Action на другой, не тот, что задан глобально. К счастью, здесь всё достаточно просто. Для этих целей существует так называемое "окно индивидуальных AutoStart настроек" для ВМ. В этом окне настройки все те же самые, что и в основном (глобальном) окне, за тем исключением, что этих настроек меньше, и они применяются только для определенной, ранее выбранной ВМ.


Чтобы открыть "окно индивидуальных AutoStart настроек" для ВМ, выделяем её в основном окне и нажимаем на кнопку Edit. Откроется следующее окно:

vmss-3.jpg

На этом я закончу рассмотрение различных настроек. В заключение приведу своё окно настроек, а чуть ниже приведу небольшое описание:

vmss-4.jpg

Опираясь на скриншот, приведенный выше, опишу хронологию запуска моих ВМ в тестовой среде (во всех ВМ установлен VMware Tools). Поехали. После перезагрузки хоста (в данном случае ESXi), первой запустится виртуальная машина FreeBSD. Спустя где-то минуту, операционная система в этой ВМ полностью загрузится, и в ней запустятся утилиты из пакета VMware Tools. После запуска VMware Tools сразу же начнется процесс запуска следующей по порядку ВМ - WinXP. И так вплоть до последней виртуальной машины в секции Automatic Startup. После того, как в секции Automatic Startup произойдет запуск последней ВМ, гипервизор начнет запускать в произвольном порядке виртуальные машины из секции Any Order. При этом логика запуска ВМ будет точно такой же, что и в секции Automatic Startup.


Вот, в принципе, и все. Дельные предложения и замечания в комментариях приветствуются.



P.S.

Источник: KB Article: 1003762


Если у вас не получается запустить виртуальную машину, или вы не можете создать виртуальный диск (на самом деле проблем может быть намного больше, чем описано здесь), то одной из причин такого поведения может являться ограничение на максимальное количество файлов, которое существует в ESX/ESXi для тома VMFS-3. Дело всё в том, что максимально возможное количество файлов, которые могут одновременно находиться на томе VMFS-3, составляет 30720. Если данный лимит достигнут, то у вас будут проявляться проблемы, описанные чуть выше.


Чтобы посмотреть, достигнут ли лимит на максимальное количество файлов для определенного VMFS-3 тома, выполняем следующую команду:

# vmkfstools -P -v 10 /vmfs/volumes/ESXi-01-Local/

vmkfstools-red.JPG

Строка Files (max/free) - это как раз то, что нам нужно. Стоит только от max (30720) отнять free (30643), и мы получим количество файлов, расположенных на данном vmfs томе. Если полученное значение меньше 30720, то значит всё в порядке. Стоит отметить тот факт, что если разница между max и free незначительна, то скорее всего на vmfs томе присутствует что-то лишнее, и поэтому следует провести аудит данного тома.



P.S.

Честно говоря, я не знаю, как можно достигнуть максимального лимита по количеству файлов на одном VMFS-3 томе. Это же нужно разместить на данном vmfs томе примерно 1536 виртуальных машин, если учитывать, что одна ВМ состоит, в среднем, из 20 файлов. Хотя, если в системе присутствует самописный скрипт, который периодически выполняется посредством крона, и при этом работает "не совсем правильно", то, вполне возможно, что данных скрипт замусорит vmfs том различными маленькими файлами (так сказать, остатками жизнедеятельности). Как мне кажется, это больше походит на правду, чем 1536 ВМ на одном томе. Поэтому очень тщательно тестируйте свои скрипты, прежде чем запускать их в продакшен среде.

Источник: KB Article: 1007566


Когда вы удаляете большой снапшот или делаете удаление всех многочисленных снапшотов для конкретной виртуальной машины, то может случиться так, что "процентная" строка состояния для задачи "Remove all snapshots" или "Remove snapshot" в vSphere Client'е зависает на скольки-то процентах, и нам кажется, что задача повисла:

remove-sanp.jpg

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


Используя SSH, залогиниваемся на хосте ESXi и переходим в каталог с нужной нам ВМ:

# cd /vmfs/volumes/ESXi-01-Local/FreeBSD

Далее выполняем команду, которая будет выводить каждые 2 секунды список всех vmdk файлов с указанием их размеров и времени последнего доступа к ним:

# watch -n 2 "date; ls -luh *.vmdk"
  • -n интервал повтора, заданный в секундах
  • -l использовать длинный (long) формат отображения
  • -u отображать время доступа (access time)
  • -h выводить размеры в удобном для чтении формате (1K 234M 2G)

    snap-monitor-cmd.jpg

    Если вы видите, что у группы или у определенного vmdk файла периодически изменяется "access time" или размер (size), то это значит, что процесс удаления снапшот(а/ов) не завис. Он просто очень медленно выполняется из-за причин, описанных выше.

    Deshifrator Hot Shot

    New Mind Map: VDR

    Posted by Deshifrator Jun 4, 2011

    Скачать можно здесь.

    new-mind-map.jpg

    В блоге vmware.progm.ru углядел интересное руководство: "Миграция с ESX на ESXi". Вот его содержание:


    1. Сравнение гипервизоров ESX и ESXi
    2. План миграции
    3. Наличие выделенного хранилища
    4. Настройка iSCSI хранилища
    5. Наличие комплектации VSphere
    6. Перемещение
      1. Перемещение с помощью Veeam B&R
      2. Перемещение с помощью Storage vMotion
    7. Сохранение профилей
    8. Снятие ВМ нагрузки с ESX хоста
    9. Установка ESXi
    10. Восстановление профилей
    11. Возврат ВМ нагрузки на ESXi хост


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

    map.png

    В общем, всем рекомендую к прочтению данное руководство. Лишним уж точно не будет.

    Источник: KB Article: 1000607


    Иногда бывает, что syslog в ESXi самопроизвольно останавливается, и, соответственно, перестают вестись логи, а это очень плохо. Одной из причин остановки syslog'а может быть недоступность удаленного сервера журналирования, куда локальный syslog отправляет свои лог-сообщения (как настроить логирование на удаленный syslog сервер, написано здесь). Если такое произошло, то вы можете вручную запустить локальный syslog сервер, выполнив следующую команду (при этом желательно убедиться, что удаленный сервер журналирования уже доступен):

    # syslogd -s 1024 -b 8 -S
    

    Список доступных опций для syslog:

    syslog.jpg


    P.S.