Skip navigation
2011

Предыдущий мой пост на эту тему: Install ESXi 4.1 on Oracle VM VirtualBox


Воспользовавшись вот этой инструкцией с единственной оговоркой - вместо 1 CPU я назначил 2 - у меня получилось без особых проблем установить ESXi 5.0 на VirtualBox:

vbox-vesxi.PNG

Для того, чтобы "пощупать" новый ESXi, вполне себе годный вариант.

Deshifrator Hot Shot

Boot Device

Posted by Deshifrator Aug 29, 2011

Раньше как-то не замечал вот этой опции:

boot_options1.JPG

которая позволяет изменить загрузочное устройство и перезагрузить хост:

boot_options2.jpg

Мелочь, а приятно.

Источник: vSphere 5.0 Storage Features Part 9 - Snapshot Consolidate


В пятой vSphere появилась новая и достаточно полезная опция в выпадающем меню виртуальной машины - Snapshot > Consolidate. Кто уже работал с vSphere 5, вероятно, это меню уже заметил, а кто еще не работал, вот как это выглядит:

consnap.png

Основная причина появления данной функции очень проста - уменьшить количество обращений пользователей в службу технической поддержки. Дело всё в том, что подобных обращений очень много, потому что в предыдущих версиях vSphere процесс применения и удаления снапшот(а/ов) не был прозрачным для пользователя. Если в процессе применения/удаления снапшота произошел какой-либо сбой, и файл дельты не был объединен с базовым диском ВМ, то такой сбой оказывался для пользователя незаметным до тех пор, пока дельта-файл сильно не разрастался и не заполнял весь том, на котором находится. Большой дельта-файл также может очень негативно повлиять на производительность дисковой подсистемы в целом.


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

warnconsnap.png

Вот теперь V-администратор может воспользоваться новой Snapshot > Consolidate опцией для их объединения.

Источник: vmxnet3 and MTU sizes


После тестирования производительности сети между виртуальными машинами, которые находятся на разных хостах и соединены между собой физической сетью 10GbE, и виртуальными машинами на одном хосте, у меня спросили: "был ли включен Jumbo Frames?". Jumbo Frames включен не был, так как я вообще не думал, что его включение значительно повлияет на конечный результат. Но, как показала практика, я был сильно не прав. В тесте, приведенном ниже, видно, что существует большая разница в значениях пропускной способности между ВМ на одном хосте и ВМ на разных хостах при включенном Jumbo Frames.


Приступим. В своей виртуальной инфраструктуре я изменил значение MTU и, затем, перезапустил тесты. Тест между ВМ на разных хостах через 10GbE, как и ожидалось, оказался немного лучше - 9.75Gbit против 9.05Gbit при выключенном Jumbo Frames. Тест между виртуальными машинами на одном хосте показал намного меньшую пропускную способность. Результат был на 4.5Gbit меньше по сравнению с результатом теста при MTU, равном 1500 байт (значение по умолчанию).


Подобное поведение мне показалось странным. В Twitter прозвучала идея о том, что код VMware лучше оптимизирован для дефолтного размера MTU. Чтобы это проверить, я написал небольшой скрипт, который автоматически устанавливает различные значения MTU и запускает ipref тест для измерения пропускной способности:

MTU graph.png

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

Источник: vSphere 5 Hardware Version 8 & New vCPU Config for Licensing Trickery


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


  1. multicore vCPU
  2. многоядерные виртуальные процессоры, cpuid.coresPerSocket


Проходят те времена! В vSphere 5.0 стало возможным для виртуальной машины в настройках CPU задавать количество сокетов и количество ядер на сокет (главное, чтобы версия железа у ВМ была восьмой). Теперь, если у вас на предприятии интенсивно используется какой-либо софт, который лицензируется только посокетно, то, с выходом VMware vSphere 5.0, у вас появится возможность достаточно неплохо сэкономить на лицензировании этих приложений. Вот как это выглядит на практике:

vcpu01.png

А вот что показывает CPU-Z:

vcpu-02.png

Жить становится проще, жить становится лучше!

Deshifrator Hot Shot

VMFS-5 LUN Sizing

Posted by Deshifrator Aug 18, 2011

Источник: VMFS-5 LUN Sizing


У меня был вопрос по поводу моей старой статьи на тему сайзинга хранилища: "VMFS/LUN size?", которую я написал еще в конце июня 2009 года. Вопрос заключался в следующем: "как, исходя из сегодняшних реалий, применять формулу и производить расчеты, если учесть тот факт, что новая ФС VMFS-5 не за горами". Это очень правильный и нужный вопрос, поэтому я решил взять свою предыдущую статью и переписать её. Ниже представлен список параметров со значениями, с помощью которых и будет выстроена конечная формула и произведен расчет.


Параметры:


  • MinSize = 1.2GB
  • MaxVMs = 40
  • SlackSpace = 20%
  • AvgSizeVMDK = 30GB
  • AvgDisksVMs = 2
  • AvgMemSize = 3GB


Перед тем, как привести конечную формулу, я хочу вам немного рассказать о том, как вычислить значение параметра "MaxVMs". Первым делом, вам нужно выяснить, какое количество операций ввода-вывода в секунду (IOps) способен обработать ваш LUN (дополнительную информацию вы можете получить, прочитав эту статью: О производительности: IOPS vs. MB/s). Помимо количества IOps вы также должны принять во внимание и неожиданный всплеск в потребностях к ресурсам со стороны виртуальных машин, расположенных на данном LUN (например, если все ВМ на данном LUN'е одновременно начнут загружаться). Ну и, конечно, не стоит забывать и про RTO (Recovery Time Objective на Википедии), принятое для этой среды.

MaxVMs = ((IOpsPerLUN – 20%) / AVGIOpsPerVM) 
MaxVMs ≤ (MaxVMsWithinRTO)

Как видно выше, я вычитаю 20%, тем самым резервируя ресурсы на случай их резкой потребности со стороны виртуальных машин. Резервирование 20% не является самой лучшей практикой. Вам следует использовать другое, более оптимальное число, в зависимости от размера вашего LUN и общего количество IOps, которое LUN способен обработать. Например, если вы используете 8 SATA дисков, то 20% - это всего лишь 80 IOps (многое, конечно, зависит от уровня RAID). В случае если вы используете 8 SAS дисков, то 20% - это, примерно, 280 IOps и это огромная разница по сравнению с SATA дисками. В любом случае, вам решать, какое количество ресурсов оставить под резерв. Лично я использовал 20% для резервирования дискового пространства (для снапшотов и swap-файлов) и производительности с целью сильно не усложнять конечные расчеты. Итак, с 20% разобрались, осталось рассмотреть последний, достаточно важный, параметр: MaxVMsWithinRTO. Смысл данного параметра сводится к следующему: убедитесь в том, что вы можете восстановить работоспособность виртуальных машин, расположенных на данном хранилище, в пределах ранее определенного времени восстановления (RTO). Вы же не хотите оказаться в ситуации, когда RTO составляет 4 часа, а по факту общее время восстановления составляет 24 часа.


Наконец, мы и дошли до формулы. Прошу заметить, что я не принимал во внимание традиционные ограничения, такие как "SCSI Reservations Conflicts", поскольку с появлением файловой системы VMFS-5 и VAAI SCSI Locking Offload эти ограничения сняты. Если ваш массив не поддерживает типовую операцию Atomic Test and Set (ATS), то SCSI-блокировку вам следует иметь в виду. Хотя механизм SCSI-блокировок был значительно усовершенствован в последние годы, все же, если у вас много Power-On событий, vMotion событий и так далее, то SCSI-блокировки все еще могут вас ограничить.

(((MaxVMs * AvgDisksVMs) * AvgSizeVMDK) + ( MaxVMs * AvgMemSize)) + 
+ SlackSpace ≥ MinSize

Небольшое отступление: "параметр MinSize определяет минимальный размер хранилища, который необходим для размещения метаданных тома VMFS". Ну, а теперь, используя ранее определенные числа, производим вычисления:

(((40 * 2) * 30GB) + (40 * 3GB)) + 20% = (2400GB + 120GB) * 1.2 = 3024 GB

Надеюсь, что данный материал поможет вам при сайзинге хранилища.

Источник: VMware related acronyms


  • FDM = Fault Domain Manager
  • CSI = Clustering Services Infrastructure
  • PAE = Propero Application Environment
  • ESX = Elastic Sky X
  • GSX = Ground Storm X or Ground Swell X
  • VPX = Virtual Provisioning X
  • VPXA = Virtual Provisioning X Agent
  • VPXD = Virtual Provisioning X Daemon
  • VMX = Virtual Machine eXecutable
  • AAM = Automated Availability Manager
  • VIX = Virtual Infrastructure eXtension
  • VIM = Virtual Infrastructure Management
  • DAS = Distributed Availability Service
  • ccagent = Control Center agent
  • vswif = Virtual Switch Interface


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

Источник: VM with disks in multiple datastore clusters?


На этой неделе Дункану (yellow-bricks.com) задали вопрос касательно Storage DRS (SDRS). Вопрос заключался в следующем: "А возможно ли расположить диски виртуальной машины на нескольких кластерах хранилищ (datastore clusters)?". На что Дункан ответил примерно следующее: "Данная конфигурация является достаточно распространенной, и она поддерживается VMware vSphere 5". Вы можете создать виртуальную машину, у которой, например, системный диск располагается на RAID-5 datastore кластере, а диск с данными (data disk) - на RAID-10 datastore кластере. При этом, если Storage DRS увидит необходимость в миграции одного из дисков ВМ на другой датастор, то будет создана соответствующая рекомендация.

В блоге kendrickcoleman.com  увидел вот эти посты:


  1. Virtual HD Audio Hardware in vSphere 5
  2. New vSphere 5 Distributed vSwitch Settings with Screenshots


Из первого поста вы узнаете о том, что vSphere 5 поддерживает HD Audio, а во втором посте вы увидите скриншоты нового распределенного свича (dvSwitch).

Источник: Testing VM Monitoring on vSphere 5.0


При тестировании системы мониторинга ВМ мне понадобилось вызвать для одной из виртуальных машин "синий экран смерти" (Blue Screen of Death). К сожалению, решение "CrashOnCtrlScroll" не сработало, поэтому мне нужно было другое решение. И вот, наконец, мне удалось его получить, выполнив последовательно нижеследующие действия:


Добавляем следующий ключ в реестр:

reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl" /v NMICrashDump /t REG_DWORD /d 0x1 /f

Чтобы получить "World ID" нужной нам ВМ, выводим список всех запущенных виртуальных машин. Для этого по SSH соединяемся с хостом ESXi 5.0 и выполняем следующую команду:

# esxcli vm process list

Теперь, для того чтобы вызвать "синий экран смерти" (BSOD) для Windows виртуальной машины, отправляем ей NMI запрос. Для этого выполняем следующую команду (замените "<world id vm>" на соответствующий идентификатор вашей ВМ):

# vmdumper <world id vm> nmi

В результате мы получим BSOD с последующей перезагрузкой ВМ и скриншот консоли виртуальной машины до перезагрузки (см. скриншот ниже).

bsod-console-screenshot.jpg

Источник: Realtek 8111E Works With VMware vSphere 5


Для обладателей реалтековских карточек появилась хорошая новость! В приведенном выше посте нам сообщают о том, что сетевые карты фирмы Realtek работают без каких-либо дополнительных хирургических вмешательств. Я думаю, много у кого данные или подобные сетевые карты имеются в наличии. И теперь появилась возможность задействовать их в своей домашней лаборатории.

realtek05.png

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

Источник: ESXi 5: Suppressing the local/remote shell warning


Наверное, все замечали предупреждение, которое появляется в vSphere Client'e после включения локального или удаленного режима технической поддержки (Local/Remote Tech Support Mode):

shell-warning.jpg

Совместно с текстовым предупреждением на соответствующем хосте ESX/ESXi также появляется "предупреждающий треугольник":

host-warn.jpg

Многих (а может и всех) V-администраторов данное предупреждение раздражает (оно и понятно, ведь включение Local/Remote Tech Support Mode не является каким-либо злым деянием, и поэтому постоянно наблюдать эти предупреждение не особо хочется).


В VMware vSphere 4 убрать текстовое предупреждение можно было путем перезагрузки хоста. И вот, с выходом VMware vSphere 5, все изменилось. Теперь не нужны всяческого рода "шАмаНства". Стоит только в "Advanced Settings" для переменной "UserVars.SuppressShellWarning" установить значение "1", и все предупреждения, касающиеся включенного Tech Support Mode, исчезнут:

adv-set.jpg

Источник: Edit MTU settings by GUI in vSphere 5.0


В vSphere 4 для того, чтобы изменить стандартное значение MTU, приходилось лезть в командную строку и там выполнять определенные команды. Как это было, можно прочитать здесь. В vSphere 5 данный процесс решили упростить, и теперь изменить значение MTU можно непосредственно из vSphere Client'а, что, несомненно, очень удобно.


  • vSwitch MTU Advanced Properties:

vswitch.png

  • VMkernel MTU NIC settings:

iscsi.png

Источник: Make-A-File – File Creation Utility


Если по долгу своей работы вы много работаете с системами хранения данных (СХД), производя различные тесты и замеры производительности, то вам может пригодиться такой инструмент, как утилита Make-A-File. Данная Windows-утилита позволяет создавать различные файлы нужного размера вплоть до 18 Эксабайт.

make-a-file.jpg

В использовании данная утилита достаточно проста. Необходимо запустить файл Make-a-File.exe, затем нужно указать несколько конфигурационных параметров, и программа тут же приступит к созданию файла.


ПараметрОписание
FilenameУказываем расположение результирующего файла
SizeЗадаем размер файла (от 1 Байта до 18 Эксабайт)
Random contentЕсли данная опция установлена, то весь файл будет заполнен случайными данными (мусором). Без этой опции файл будет заполнен нулями.
Quick CreateЕсли данная опция установлена то программа создаст "тонкий" файл. Используя указанный ранее размер, утилита Make-a-File просто отметит начало и конец файла. При этом в сам файл никакие данные записаны не будут.



В Unix-Like системах для создания нужного размера файлов можно использовать очень мощный и гибкий инструмент - утилиту dd. Вот пример того, как с помощью dd можно создать и заполнить случайными данными файл размером 50 мегабайт:

# dd if=/dev/random of=file.random bs=1M count=50

/dev/random для FreeBSD, для Linux путь немного другой: /dev/urandom. Если вам нужно заполнить файл нулями, то вместо /dev/random вам нужно использовать /dev/zero:

# dd if=/dev/zero of=file.zero bs=1M count=50

Более полную информацию об утилите dd вы можете получить на Википедии.

 

Пролистывая новости, наткнулся на интересное видео про настройку iSCSI Port Binding. То же самое, но только более детально и в виде статей можно прочитать тут, тут и тут.


Я уже писал ранее о новой команде esxcli вот тут и тут. В дополнение к моим постам, вот еще несколько интересных англоязычных постов на эту тему: