Время от времени мы пишем о графических материалах, позволяющих пользователям и партнерам VMware документировать виртуальную инфраструктуру VMware vSphere, VMware View, VMware SRM и прочее. Мы писали о наборе картинок для VMware vSphere 5 тут и тут, вот об этом наборе иконок, картинок и диаграмм, об этом, а также и об этом неофициальном наборе стенсилов Visio.
Последний как раз вчера и обновился в составе третьей части, которая теперь включает в себя картинки, графику и стенсилы для следующих компонентов:
Обратите внимание, что VMware настаивает на включении в документы, которые содержат эти картинки, какого-то бредового текста, который вы увидите в начале данных презентаций.
В инфраструктуре VMware vSphere для диагностики сетевых неполадок иногда приходится в сервисной консоли серверов VMware ESXi тестировать различные соединения. В этой заметке мы вкратце опишем, как это делается.
Прежде всего, обычный пинг через стандартный Management-интерфейс:
# ping <IP хоста>
Пинг через порт VMkernel (в ESXi это тот же самый интерфейс, а в ESX - другой):
# vmkping 192.168.48.133
PING 192.168.48.133 (192.168.48.133): 56 data bytes
64 bytes from 192.168.48.133: icmp_seq=0 ttl=64 time=0.978 ms
64 bytes from 192.168.48.133: icmp_seq=1 ttl=64 time=1.009 ms
Для проверки соединения сервера VMware ESXi с хостом по какому-нибудь порту используется утилита netcat (nc). Telnet есть только на ESX. Формат использования netcat:
# nc -z <IP хоста> <порт хоста>
Например:
# nc -z 192.168.48.133 80
Connection to 192.168.48.133 80 port [tcp/http] succeeded!
С помощью netcat можно проверять только TCP-соединения, для UDP (флаг -uz) всегда будет статус succeeded (даже если порт заблокирован или закрыт), так как соединения по UDP не устанавливается. Для того, чтобы тестировать UDP-соединения можно воспользоваться утилитой tcpdump-uw.
Команда nc может быть использована для сканирования диапазона портов (будьте осторожны со сканированием, чтобы не навлечь гнев безопасников):
# nc -w 1 -z 192.168.48.133 20-81
Connection to 192.168.48.133 22 port [tcp/ssh] succeeded!
...
Connection to 192.168.48.133 80 port [tcp/http] succeeded!
Опция -w определяет таймаут между соединениями.
Для траблшутинга SSL-соединений может быть использована следующая команда:
Как многие из вас знают, в VMware vSphere 5.1 была введена возможность обновления пакета VMware Tools "без перезагрузки" гостевой ОС. Многие пользователи были удивлены - как же так, после обновления драйверов не нужно перезагружать сервер? На самом деле это небольшой маркетинговый обман - перезагружать ОС в некоторых случаях, все-таки, придется - чудес не бывает.
Просто исторически (до vSphere 5.1) обновление VMware Tools в любом из компонентов этого пакета требовало перезагрузки. При этом для Windows-систем ее можно было отложить используя опции установщика, например, такие (или так):
setup.exe /S /v"/qn REBOOT=R"
или
setup.exe /S /v"/qn REBOOTPROMPT=S"
Для ОС Unix/Linux драйверы и модули ядра отправлялись на стейджинг и активировались в системе после перезагрузки сервера.
Теперь же, в vSphere 5.1 обновление не всех компонентов VMware Tools требует перезагрузки, однако это применимо только к ОС Windows, для Linux все осталось по-прежнему. Перезагрузка требуется при обновлении следующих компонентов, входящих в состав пакета VMware Tools:
Драйвер видеоадаптера VMware SVGA II. Он используется для ОС младше Windows Vista, однако может использоваться в некоторых случаях и для других ОС. Если в системе установлен драйвер VMware SVGA 3D, то его обновление, скорее всего, не потребует перезагрузки. Однако в KB 2015163 указано, что перезагрузка произойти, все-таки, может.
Драйвер VMware Pointing DeviceDriver (PS/2). Этот драйвер используется по умолчанию для всех версий Windows, но обновляется крайне редко. В VMware vSphere 5.1 появился VMware USB Pointing Device driver, который не требует перезагрузки. Если это критично - можно использовать его.
Драйверы VMware VMSCSI Controller и VMware PVSCSI Controller Driver. Обновление этих драйверов, скорее всего, потребует перезагрузки, но только в случае, если один из этих драйверов используется для системного диска (с папкой C:\Windows), либо для устройства, файловая система которого используется на момент установки. В других случаях (например, у вас нет дисков на контроллере PVSCSI) - перезагрузка не требуется.
Опциональные компоненты. К ним относятся HGFS (функции shared folders) и ThinPrint, которые могут потребовать перезагрузки.
Какие особенности есть у процесса обновления VMware Tools без перезагрузки в VMware vSphere:
Работает это для Windows Vista и выше.
Работает только для ОС Windows.
Для виртуальной машины требуется Virtual Hardware 9 или более поздней версии.
Также стоит прочитать статью о том, следует ли обновлять VMware Tools при апгрейде хостов VMware vSphere.
Многие из вас, кто использует кластеризацию MSCS в виртуальных машинах на платформе VMware vSphere, возможно, замечали, что когда используется кластер Across Boxes (т.е. между ВМ на разных хостах), то перезагрузка хоста VMware ESXi занимает весьма продолжительное время (иногда - до получаса).
Дело здесь в том, что поскольку узлы кластера виртуальных машин используют диск RDM, который напрямую пробрасывается в виртуальную машину и для него используются SCSI reservations, то хост ESXi тратит много времени на обнаружение параметров устройства.
Избежать этого очень просто. Для этого:
В ESX / ESXi 4.0 нужно выставить минимальное значение на число повторов операций при обнаружении конфликтов SCSI-резерваций (в Advanced Settings хостов):
Scsi.UWConflictRetries = 80
Для ESXi 4.1 появилась дополнительная опция, которая уменьшает таймаут при загрузке в случае обнаружения конфликта. Это значение необходимо выставить в:
Scsi.CRTimeoutDuringBoot = 1
Начиная с ESXi 5.0, опция Scsi.CRTimeoutDuringBoot больше не действует. Теперь нужно использовать команды множества esxcli storage. Для этого:
Сначала надо найти NAA-идентификатор устройства (физического LUN, на котором используется RDM). Для этого нужно зайти в управление путями до устройства (Manage Paths) и посмотреть на строчку, начинающуюся с naa...... - это и есть naa id.
Далее в консоли сервера ESXi нужно выполнить следующую команду (она пометит LUN как изначально зарезервированный):
У компании VMware есть специализированное ПО для моделиирования рабочей нагрузки в VDI-среде - VMware View Planner 2.0. К сожалению, это средство доступно только партнерам VMware, однако умной голове не составит труда раздобыть его. Также, напомним, что мы уже писали о средствах тестирования VDI-нагрузок: VDI Sizing Tool и Login VSI.
View Planner поставляется в виде виртуального модуля (Virtual Appliance) в формате OVF, построенного на базе дистрибутива Linux Centos 5.x и требующего 2 GB памяти и один vCPU на виртуальную машину.
View Planner предназначен для генерации различных сценариев рабочей нагрузки виртуальных ПК, включая управление состояниями виртуальных машин, пользователями Active Directory, построение отчетов и прочее. Все это управляется через веб-интерфейс, присутствующий у виртуального модуля, включая службы Active Directory и конфигурации View Connection servers, контролируемые средствами развертываемых на них агентов.
Архитектурно решение VMware View Planner состоит из следующих компонентов:
Виртуальные ПК на хостах VMware ESXi.
Несколько клиентских виртуальных машин на хостах ESXi - используются для удаленного режима или пассивных тестов, т.е. те, откуда происходит доступ к виртуальным ПК.
View Planner можно запускать в трех различных режимах:
Remote mode - в этом случае для каждой тестируемой ВМ будет своя клиентская машина. Это самый затратный с точки зрения необходимых ресурсов способ тестирования, однако самый адекватный.
Passive Client mode - в этом режиме клиентских машин требуется меньше и они только пассивно принимают результаты вывода тестируемых машин, а последние генерируют нагрузку. Это позволяет снизить требования к нужным для тестирования ресурсам.
Local mode - в этом случае тесты исполняются только на десктопах, без клиентов. Это не учитывает сетевой трафик между ними, поэтому менее репрезентативно, зато и менее затратно.
Вот, например, как работает тест в режиме Remote mode:
Все данные о тестировании нагрузок хранятся в базе данных MySQL.
Модель нагрузки задается в виде блоков, каждый из которых создается под свою задачу для виртуальных ПК:
Пример рабочей нагрузки, генерируемой View Planner:
В качестве результатов работы View Planner вы получите следующие полезные параметры:
Время отклика в виртуальном ПК (Responce Time) - показатель QoS для пользователей
Статистики использования ресурсов (Resource stats)
Запускаем тест, получаем примерное число виртуальных ПК (пользователей), которые выдержит наша виртуальная инфраструктура с заданным показателем QoS (в данном случае время отклика - 1,5 секунды):
Из таблицы видно, что при заданной модели нагрузки наша VDI-инфраструктура с приемлемым показателем качества обслуживания будет выдерживать максимум ~130 пользователей. Не такого ли ответа на вопрос ожидают те из вас, кто планирует VDI-инфраструктуру у себя в организации?
Чтобы продолжить изучение полезного продукта VMware View Planner, рекомендую обратиться по следующим ссылкам:
Администраторы VMware vSphere знают, что для виртуальных машин, работающих на серверах VMware ESXi, есть операция Suspend, которая позволяет поставить виртуальную машину "на паузу", что означает сохранение памяти ВМ на диск. Когда машину потребуется "продолжить" (Resume), ее память с диска будет загружена в физическую RAM и она продолжит исполнять инструкции.
В платформе Microsoft Hyper-V есть такая операция Save, которая работает аналогично операции Suspend в ESXi, однако есть и операция Pause, которая работает несколько иначе: виртуальная машина прекращает исполнять инструкции, но память ее продолжает оставаться загруженной в оперативную память сервера. Вследствие этого, такая ВМ может быть быстро продолжена, так как не требуется загружать память с диска.
Есть ли такая операция в VMware vSphere? Как пишет Вильям Лам, оказывается, есть. Для этого можно поступить с VMX-процессом виртуальной машины так же, как и с любым другим процессом в случае его "замораживания" в Unix-системе.
Итак, чтобы поставить ВМ на такую "паузу", идентифицируем ее PID (Process ID). Для этого выполним команду:
# esxcli vm process list
PID виртуальной машины приведен в секции "VMX Cartel ID" результатов вывода команды:
В качестве альтернативы можно использовать также команду ps:
# ps -c | grep -v grep | grep [vmname]
Ну и, собственно, ставим ВМ на паузу:
# kill -STOP [pid]
Чтобы снять машину с паузы, выполняем команду для продолжения VMX-процесса:
# kill -CONT [pid]
Машинка продолжит возвращать пинги:
Надо отметить, что эта штука не работает с виртуальными машинами, для которых включена функция VM monitoring, поскольку этот механизм ничего не знает о такой возможности по приостановке виртуальных машин.
Ну и, само собой, несмотря на то, что эта штука вполне себе работает, она не поддерживается со стороны VMware.
Иногда бывает так, что VMware ESXi может начать вести себя странно, но симптомы могут быть совершенно разными, например:
Не работает vMotion - отваливается на 13% с ошибкой "A general system error occurred: Timed out waiting for vpxa to start" или зависает вовсе
Не работает консоль виртуальной машины (Unable to contact the MKS)
Не зайти на хост VMware ESXi по SSH
Хост ругается на отсутствие свободного места, хотя оно есть на разделах ESXi (No free space left on device)
и прочие неприятности
При этом иногда сходу и не скажешь, что произошло. А проблема вот в чем: у файловых систем ОС Unix есть объекты inode - структуры данных, где хранится метаинформация о стандартных файлах, каталогах или других объектах файловой системы, кроме непосредственно данных и имени. Так вот, этих inode - ограниченное количество, и при большом количестве файлов они могут просто закончиться.
Чтобы проверить количество доступных inodes надо выполнить следующую команду на VMware ESXi (подробнее в KB 1007638):
Вот тут мы видим, что из 640 тысяч айнодов свободно 580 тысяч, то есть все в порядке.
Откуда может взяться так много файлов? Оказывается это случается, когда включен демон SNMPD на VMware ESXi 5.1. Каталог /var/spool/snmp начинает быстро засираться файлами SNMP-трапов. Если у вас включен SNMP и в этом каталоге более 2000 файлов - вероятность возникновения описанного выше поведения высока.
Выход - почистить папку и сделать так, как написано в статье KB 2040707.
Если у вас или вашего руководства возникают вопросы о том, поддерживается ли то или иное приложение на платформе VMware vSphere, то теперь вы можете получить достоверный ответ на сайте Business Applications on the VMware Platform. На данный момент в базе данных 3707 приложений и список постоянно пополняется:
Что означает этот список? Он означает полную поддержку работоспособности данного ПО в виртуальной машине именно со стороны производителя данного бизнес-приложения, а не VMware. То есть, VMware обращается к вендору этого ПО (в том числе по запросам пользователей), а он, в свою очередь, публикует support statement, который также появляется на этом сайте.
Вот, например, заметка про поддержку IBM WebSphere на VMware vSphere:
Идем по ссылке и внизу страницы находим официальную информацию про поддержку VMware vSphere:
Каждый пользователь может самостоятельно составить запрос к вендору того или иного приложения, для этого нужно зарегистрироваться.
В документе рассмотрены различные варианты подключения дисковых массивов NFS, их преимущества и недостатки, а также совместная работа с такими технологиями как Storage I/O Control, VAAI, Network I/O Control, Storage DRS и прочими. Также администраторам будет интересно прочитать про расширенные настройки VMware vSphere, относящиеся к хранилищам NFS.
Если вы заглянете в папку с работающей виртуальной машиной в VMware ESXi 5.1 из консоли, то увидите, что там находятся 2 конфигурационных файла VMX:
Не стоит думать, что файл vmx~ - это lock-файл вроде тех, которые бывают для виртуальных дисков VMDK (lck). На самом деле, это так называемый "edit file", который нужен для того, чтобы вносимые в конфигурацию виртуальной машины изменения сначала сохранялись в нем, а затем эти два файла меняются местами.
Таким образом, этот файл вам пригодится, если оригинальный vmx-файл будет поврежден или потерян, так как vmx~ является точной копией его последнего рабочего состояния.
Поэтому не стоить вносить правки в файлы vmx вручную, а стоит воспользоваться интерфейсом vSphere Client:
Можно также внести правки в расширенные настройки виртуальной машины через интерфейсы удаленного администрирования, например, как описано в этой статье.
Таги: VMware, vSphere, VMachines, ESXi, Blogs, Обучение
Если заглянуть в секцию Network утилиты esxtop, то там (начиная с ESXi 5.1) можно увидеть объекты Shadow of vmnic1 и т.п.:
На самом деле, эти штуки созданы для обеспечения работы функций VDS Network Health Check, которые появились в VMware vSphere 5.1. Для каждого физического интерфейса создается shadow port, через который посылаются пакеты Health Check, связанные с состоянием этого порта. Эти виртуальные интерфейсы можно мониторить на предмет работоспособности означенной функциональности.
Если эти штуки вам мешают, то можно убрать их, отключив модули хоста ESXi, связанные с хэлсчеком (заодно и в целях безопасности). Для этого нужно выполнить следующую последовательность команд для выгрузки ненужных модулей:
Помните, что после перезагрузки эти изменения не сохранятся - модули снова будут загружены автоматически.
Кстати, не по теме, но хозяйке на заметку: если вы видите, что в esxtop какой-либо счетчик принимает только значения 0 или 100 - знайте, что это просто означает работает эта штука в данный момент времени или нет. Так, например, происходит с SIOC. Просто нет еще в esxtop булевых метрик.
Интересная статья обнаружилась у Кормака, касающаяся того, как работает LUN Discovery на хостах VMware ESXi. Оказывается все новые LUN, висящие на одном таргете обнаруживаются сервером ESXi автоматически по заданному таймауту.
То есть мы сначала делаем Rescan, чтобы добавить новый таргет (порт массива), например, T2 с LUN ID=10:
Дальше на этом таргете создаем новый LUN ID=20, и через какое-то время он автоматически появляется в списках устройств:
Все это потому, что по умолчанию каждые 5 минут вызывается проба (SCSI-команды REPORT_LUN и/или INQUIRY), целью которой является обнаружение новых устройств и путей на известных хосту таргетах. Настраивается это время (в секундах) в следующей расширенной настройке (по умолчанию 300 секунд):
Disk.DeviceReclaimTime
Кроме того, все это отрабатывает и тогда, когда происходят операции добавления (Rescan) или удаления таргета.
Если вам по каким-либо причинам понадобилось подключить флэшку или другое USB-устройство к VMware ESXi, например, в целях сбора диагностических данных или интеграции сторонних пакетов (или драйверов) в гипервизор, то сделать это можно способом, описанным ниже. Прежде всего отметим, что монтирование USB-хранилищ в консоль ESXi поддерживается только для файловой системы FAT16.
1. Сначала нужно отключить службу USB Arbitrator service, которая отвечает за проброс USB-девайсов в виртуальные машины хост-сервера. Для этого выполняем команду:
# /etc/init.d/usbarbitrator stop
2. Далее подключаем носитель к ESXi и проверяем девайс командой:
# esxcli storage core device list | grep -i usb
или смотрим список смонтированных файловых систем:
# esxcli storage filesystem list
После этого вы можете работать с USB-устройством через папку /vmfs/volumes/NO NAME/. Например, можно установить бандл ESXi с флешки:
Как многие помнят, ранее в настройках VMware Tools можно было настраивать синхронизацию времени гостевой ОС со временем хост-сервера VMware ESXi. Доступно это было при двойном клике на иконку VMware Tools в гостевой системе:
Теперь же, начиная с vSphere 5.1, при двойном клике на иконку VMware Tools вы увидите следующее:
То есть тут, по-сути, доступна только информация о версии пакета. Это правильно, так как пользователю виртуальной машины не должно быть доступно никаких действий и настроек, относящихся к слою виртуализации.
Вместо этого, различные настройки, в том числе синхронизации времени, были вынесены в категорию VMware Tools опций виртуальной машины (Virtual Machine –> Edit Settings –> Options –> VMware Tools):
Теперь администраторам VMware vSphere не требуется полномочий в гостевой ОС, чтобы регулировать настройки VMware Tools.
Написана она на PowerCLI человеком по имени Sean Duffy и обновлялась совсем недавно - 29 декабря прошлого года.
Для резервного копирования и восстановления конфигурации VMware ESXi используются командлеты PowerCLI Get-VMHostFirmware и Set-VMHostFirmware. Утилита была протестирована для ESXi 5.0 и 5.1, графический интерфейс позволяет производить резервное копирование на локальный диск компьютера, где она запущена. Убедитесь, кстати, что в вашей инфраструктуре работает служба DNS, так как утилита обращается к хост-серверам по именам.
Из интересных особенностей - возможность восстановить конфигурацию на другой хост ESXi (на скриншоте подчеркнуто красным). В последней версии также добавлена валидация хоста на возможность резервного копирования и восстановления (т.е., что он не находится в maintenance mode и вообще работает).
Скачать ESXi Host Backup & Restore GUI Utility можно по этой ссылке. Для запуска утилиты вам потребуется установленный PowerShell / PowerCLI.
Если вы попробуете импортировать виртуальную машину (или Virtual Appliance), которая была создана для настольных платформ виртуализации (например, VMware Workstation в формате 2gbsparse), в VMware vSphere 5.1 с помощью утилиты vmkfstools, то у вас это не выйдет. Вы получите подобное сообщение:
Failed to open 'VM-name.vmdk': The system cannot find the file specified (25).
Ошибка может быть и такой:
File [VMFS volume]\VM-name.vmdk was not found.
И такой:
Error Stack:
An error was received from the ESX host while powering on VM VM-name
Cannot open the disk '/vmfs/volumes/Datastore/VM-name/VM-name.vmdk' or one of the snapshot disks it depends on.
The system cannot find the file specified.
VMware ESX cannot find the virtual disk '/vmfs/volumes/Datastore/VM-name/VM-name.vmdk'. Verify the path is valid and try again.
Все это из-за одного и того же - в VMware vSphere 5.1 убрали автоматическую загрузку модуля multiextent, который и отвечает как раз за конверсию виртуальных дисков с hosted-платформ VMware в формат VMFS. Чтобы загрузить этот модуль нужно выполнить простую команду:
# vmkload_mod multiextent
Ну а чтобы выгрузить:
# vmkload_mod -u multiextent
Делать это можно смело, так как этот модуль отвечает только за работу с Non-VMFS дисками ВМ.
Так вот для тех из вас, кто решил встать на нелегкий путь сертификации VCAP (экзамены действительно сложные), вышло руководство VCAP5-DCA Study Guide, основанное на официальном Blueprint и насчитывающее 349 страниц (!). В нем, как это часто бывает, много ботвы, но и по существу есть немало полезного.
Для администраторов VMware vSphere в руководстве также найдется много интересного. Руководство снабжено картинками, командами CLI и, что самое нужное при подготовке к экзамену VCAP, отсылками к конкретным документам VMware (и их главам) по каждой теме. Штука местами очень классная - рекомендую.
Теперь, на основе статьи Франка, мы обобщим и актуализуем информацию по миграциям vMotion и Storage vMotion в разных контекстах - на уровне хранилищ, сети и хост-серверов VMware ESX.
Как и в прошлой статье, здесь будем пользоваться понятием стоимости миграции в единицах (cost) и максимального значения костов в тех же единицах (max cost), которое отображает предельно допустимое значение. Сумма костов операций vMotion и SVMotion не должна превышать max cost для соответствующего объекта (datastore, NIC и хост ESXi).
Теперь взглянем на таблички (в них есть не только vMotion, но и SVMotion):
Хост ESXi
Operation
Config Key
Cost
vMotion Cost
costPerVmotionESX41
1
Storage vMotion Cost
costPerSVmotionESX41
4
Maximum Cost
maxCostPerEsx41Host
8
Сеть
Operation
Config Key
Cost
vMotion Cost
networkCostPerVmotion
1
Storage vMotion Cost
networkCostPerSVmotion
0
Maximum Cost
maxCostPerNic
2
maxCostPer1GNic
4
maxCostPer10GNic
8
Хранилище (Datastore)
Operation
Config Key
Cost
vMotion Cost
CostPerEsx41Vmotion
1
Storage vMotion Cost
CostPerEsx41SVmotion
16
Maximum Cost
maxCostPerEsx41Ds
128
Читать эти таблички просто - например, для хоста ESXi стоимость миграции vMotion равна 1, а поскольку max cost равно 8, то всего на хост может быть 8 одновременных миграций в конфигурации по умолчанию. Либо допустимы одновременно: 1 миграция SVMotion (4 очка) и 4 штуки vMotion (по одному очку каждая), т.е. суммировать надо по костам: 4+1+1+1+1=8.
Для хранилища (Datastore) также есть ограничения vMotion, поскольку передаются страницы файла подкачки (если он не шаренный между хостами), а также производится передача владения VMX-файлом и другими файлами ВМ на хранилище. Но поскольку влияние это мало, то стоимость vMotion для хранилища всего 1 при максимальной емкости одновременных операций 128 (а вот SVMotion, требующая значительных ресурсов хранилища, "кушает" 16 единиц). Таким образом 1 операция vMotion съест 1 единицу коста, поэтому в этот момент для хранилища будет доступно только 7 миграций SVMotion, т.е. (128-1) div 16 = 7.
Соответственно, редактирование параметра Config Key для соответствующей операции позволяет изменять количество одновременных операций vMotion/SVMotion. Для редактирования параметра Config Key нужно отредактировать конфигурационный файл vpxd.cfg на сервере VMware vCenter, который находится в папке:
Если соответствующей секции нет, то ее можно просто добавить. Уменьшать максимальные косты точно можно, а увеличение работает не всегда. То есть гарантированно вы сможете только уменьшить число одновременных миграций vMotion или SVMotion, а вот увеличить - не факт. Ограничение можно делать двумя способами - повышением обычных костов или понижением максимальных костов.
Теперь самое интересное - это динамический параметр max cost для сетевых адаптеров. Как видно из таблицы, его действующее значение зависит от типа сетевого адаптера на хосте - 1G или 10G. Но, на самом деле, и не только от типа. Точнее - от скорости соединения для трафика vMotion между хостами ESXi, которую обнаруживает VMkernel. Таким образом:
Если VMkernel обнаруживает соединение на скорости 1Gbit/s - Maximum Cost выставляется в значение 4 (это верно и для случая соединения 1G<->10G).
Если VMkernel обнаруживает соединение на скорости 10Gbit/s - Maximum Cost выставляется в значение 8.
Если VMkernel обнаруживает соединение на скорости ниже 1Gbit/s - Maximum Cost выставляется в значение 2.
Таким образом, для адаптера возможны либо 2, либо 4, либо 8 одновременных миграций vMotion, в зависимости от действующей скорости соединения. Операция Storage vMotion, как видно из таблицы, костов сети не кушает.
Если ограничение для сети жестче (например, 4 миграции vMotion), чем ограничение для хоста (8 миграций vMotion) - то для машин этого хоста действует ограничение сети.
Начиная с версии VMware vSphere 4.0, компания VMware сделала замечательную вещь - все выпускаемые ей в комплекте с платформой виртуализации пакеты VMware Tools обратно совместимы со всеми прошлыми версиями хостов VMware ESXi:
Соответственно, на VMware ESX 4.0 можно использовать VMware Tools от vSphere 5.1, но как сделать это, не обновляя платформу виртуализации? Оказывается есть простой метод, опубликованный на v-front.de и основанный на информации из KB 2004018.
Там будет один или два файла с расширением .vib. Если их два, то тот, что с меньшим номером билда - это тулзы, содержащие только обновления безопасности, а тот, что с большим - включает и эти обновления, и багофиксы. Берем тот, что с большим номером (609), кликаем на нем 2 раза и проваливаемся дальше в архив, где виден репозиторий VMware Tools:
Эти три папки вы уже когда-то видели на Datastore в ESXi (во время установки тулзов). Создаем папку с именем vmware-tools на локальном хранилище ESX / ESXi и заливаем туда три извлеченные из vib'а папки, чтобы получилось вот так:
Теперь нужно настроить хост ESXi для использования данного репозитория VMware Tools. Для этого идем в Advanced Settings хоста ESXi и настраиваем параметр UserVars.ProductLockerLocation, где прописана версия тулзов в формате:
/locker/packages/<ESXi-Version> (ESXi-Version = 5.1.0, 5.0.0, 4.1.0 or 4.0.0)
В нашем случае она выглядит так:
/locker/packages/5.1.0
Меняем ее на путь к репозиторию: /vmfs/volumes/<имя Datastore>/vmware-tools.
После этого нужно перезагрузить хост, и изменения вступят в силу. Если перезагружать ESXi не хочется, то можно в корне файловой системы пересоздать символьную ссылку /productLocker:
Можно также вызвать команды, которые вызываются хостом для пересоздания символьных ссылок:
/sbin/configLocker - для ESX / ESXi 4.x
jumpstart --plugin=libconfigure-locker.so - для ESXi 5.x
Теперь остается только выбрать пункт Install/Upgrade VMware Tools в консоли vSphere Client при подключении к консоли ВМ для обновления компонентов пакета.
С приходом Нового года в продукте VMware vCenter, входящем в состав vSphere 5.1, была обнаружена ошибка, следствием которой является отображение за прошедший год статистик производительности (Performance history) только за последние 30 дней (декабрь).
Данная ошибка является следствием недоработок в хранимых процедурах БД vCenter Server, что приводит к удалению (purge) объектов базы данных, касающихся производительности. Исправления ошибки и никакого workaround'а пока нет.
С одной стороны, эти данные не являются критичными и, зачастую, не используются администраторами, однако различные продукты, которые используют исторические данные для анализа и планирования мощностей инфраструктуры виртуализации (Capacity Planning), не смогут уже выполнять свои функции адекватно.
Для получения информации об исправлении ошибки можно подписаться на KB 2042164.
Зачастую администраторам VMware vSphere требуется снять скриншот консоли виртуальной машины, который появляется вследствие различных ошибок или при установке ОС в ВМ. Делают они это, как правило, нажимая принтскрин в ОС, где установлен vSphere Client. Однако этот способ не очень красивый и не особо универсальный - ниже мы покажем, как правильно делать скриншот консоли ВМ.
Для этой операции мы снова задействуем MOB (Managed Object Browser), о котором мы уже писали тут и тут. Сначала нам надо получить MoRef ID виртуальной машины на определенном хосте VMware ESXi. Вкратце: MoRef ID присваивается виртуальной машине (и другим объектам) сервером vCenter для различных операций с ней, в том числе через MOB (он также используется в vCloud Director и других продуктах). MoRef ID уникален в пределах одного сервера vCenter.
Для получения MoRef ID воспользуйтесь статьей KB 1017126 - в ней все понятно расписано по шагам. Можно также воспользоваться скриптом vSphere MoRef ID Finder, который написал Вильям Лам.
Далее в адресной строке браузера наберите:
https://<IP хоста ESXi>/screen?id=vm-171
где vm-171 - это MoRef ID виртуальной машины. После авторизации пользователя (у которого должна быть привилегия VirtualMachine.Interact.ConsoleInteract) скриншот консоли ВМ будет выведен прямо в браузер.
При получении скриншота ВМ можно использовать еще несколько GET-параметров:
w = ширина получаемой картинки h = высота получаемой картинки x0 = координата X левого угла для снятия скриншота региона y0 = координата Y левого угла для снятия скриншота региона x1 = координата X правого угла для снятия скриншота региона y1 = координата Y правого угла для снятия скриншота региона
Примеры отработки MOB для получения скриншотов ВМ с различными параметрами:
Соответственно, нужно начинать отучать пользователей ходить через vSphere Client и приучать использовать веб. Проблема в том, что штатного способа сделать это нет. Если у пользователя есть доступ - то и клиент он всегда сможет скачать и использовать.
Поэтому William Lam придумал простой способ борьбы с этим. Надо открыть файл version.txt на сервере vCenter, который находится вот тут:
Дальше в значение версии клиента (exactVersion) нужно вписать несуществующую версию, например, 9.0.0. После этого, при логине через vSphere Client, пользователям будет предложено скачать версию клиента, которой не существует, что приведет к зацикливанию процесса:
Однако это приведет к желаемому результату - через vSphere Client пользователи не смогут залогиниться.
На сервере VMware ESXi это тоже можно применить, однако там нужно поправить файл clients.xml, размещенный по адресу:
/usr/lib/vmware/hostd/docroot/client
Так что пора уже переводить своих пользователей на браузер.
Таги: VMware, vSphere, Web Client, Обучение, ESXi, vCenter
Отличный пост про симулятор сервера vCenter написал William Lam. Изложим здесь его вкратце. Когда-то два человека, Zhelong Pan и Kinshuk Govil, написали утилиту vcsim, которая позволяет эмулировать сервер VMware vCenter в котором запущены тысячи виртуальных машин, при этом такие объекты потребляют минимум ресурсов и работают на минимальной конфигурации VMware vCSA (vCenter Server Appliance). Утилита входит в состав vCSA, но отсутствует в обычной инсталляции vCenter.
Помимо собственно построения виртуального Inventory сервера vCenter из виртуальных машин и хост-серверов, утилита vcsim поддерживает простейшие операции с фейковыми объектами, например, Power On ненастоящих машин, а также различные метрики производительности. Кроме того, с помощью этой утилиты можно и добавлять настоящие серверы VMware ESXi и виртуальные машины, создавая гибридную конфигурацию, так как vcsim - это, все же, настоящий vCenter Server.
Теперь приведем ситуации, когда такая конфигурация может оказаться полезной:
При изучении vSphere API для исследования функций навигации по иерархии.
Возможность создать "виртуальное" окружение для тестирования различных скриптов.
Разработка утилит, отслеживающих производительность
Разработка плагинов к vSphere Web Client
Для начала работы с vcsim нужно внести изменения в файл /etc/vmware-vpx/vpxd.cfg, поместив туда следующее между тэгами </vpxd> и </config>:
Кстати, шаблон конфигурации vcsim представлен в файле:
/etc/vmware-vpx/vcsim/model/vcsim.cfg.template
После этого нужно перезапустить сервис vCenter:
service vmware-vpxd restart
Такой перзапуск сервиса можно делать только один раз (даже если он был не успешен), дальше будут использоваться другие команды, приведенные ниже.
После рестарта сервиса мы можем увидеть окружение с сотнями хост-серверов и десятью тысячами виртуальных машин, как в веб-клиенте:
\
так и в "толстом" клиенте:
Теперь мы можем менять параметры окружения в файле:
/etc/vmware-vpx/vcsim/model/initInventory.cfg
В нем можно настраивать следующие объекты:
Datacenter
Hosts per Datacenter
VM per Host
Powered On VM per Host
Cluster per Datacenter
Host Per Cluster
Resource Pool per Cluster
VM per Resource Pool
Powered On VM
vCPU for a VM
vMEM for a VM
После того, как вы сохранили внесенные в конфигурацию изменения, нужно выполнить команду vpxd -b, чтобы пересоздать базу симулируемого vCenter. Поэтому выполняем следующую последовательность для рестарта сервиса:
service vmware-vpxd stop vpxd -b
service vmware-vpxd start
Кроме того, vcsim использует следующие конфигурационные файлы:
vcsim/model/metricMetadata.cfg (симулируемые Performance Metrics - по умолчанию их нет)
vcsim/model/vcModules.cfg (симулируемые модули vCenter, например, DRS)
vcsim/model/OperationDelay.cfg (задержки выполнения операций)
Так что теперь можно испытывать эту штуку и экспериментировать в свободное время. Ну и, само собой, все это никак не поддерживается со стороны VMware.
Таги: VMware, vCenter, vcsim, Blogs, ESXi, VMachines, Обучение
Для начала обратите внимание, что обновление вышло не для ESXi 5.1 (последней версии гипервизора), а для ESXi 5.0 - его предыдущей версии. Так что это обновление актуально только для тех, кто еще не успел переехать со старой версии платформы.
Помимо VMware ESXi 5.0 Update 2, вышел и VMware vCenter 5.0 Update 2. Новые возможности обновлений:
Официальная поддержка работы vCenter 5.0 на Windows Server 2012.
Официальная поддержка новых гостевых ОС: Oracle Solaris 11, Solaris 11.1, а также Mac OS X Server Lion 10.7.5.
Поддержка сервером vCenter механизма Guest Operating System Customization для следующих гостевых ОС: Windows 8, Windows Server 2012, Ubuntu 12.04, RHEL 6.2, RHEL 6.3.
В vSphere Web Client эти типы трафика можно просто назначить интерфейсу vmk (VMkernel):
Но можно ли управлять этими настройками с помощью интерфейса ESXCLI? Оказывается, что, начиная с версии vSphere 5.1, это делается очень просто. Интерфейс vmk можно "тэгировать" различными типами трафика, что означает, что он будет их пропускать. В командной строки ESXCLI администратору доступно множество команд tag в следующем пространстве имен:
esxcli network ip interface
Как и с многими другими объектами, с тэгами можно совершать операции get, add и remove:
vi-admin@vMA51:~> esxcli –server vcenter51 –vihost pod23-esx-01a.pml.local –username root network ip interface tag
Usage: esxcli network ip interface tag {cmd} [cmd options]
Available Commands:
add Adds a tag on a given VMkernel network interface.
get Gets the tags set on the given VMkernel network interface.
remove Removes a tag on a given VMkernel network interface.
Как вы знаете, в VMware vSphere можно получить информацию о текущих лицензиях для хостов ESXi и vCenter как через "толстый" vSphere Client, так и через "тонкий" vSphere Web Client:
Иногда эту информацию хочется получить через API, например, чтобы иметь всегда актуальный отчет о лицензировании или в целях инвентаризации ключей. Для этого в иерархии объектов vSphere есть объект LicenseManager, который имеет методы для добавления, удаления и просмотра лицензий на хостах VMware vCenter / ESXi.
Для просмотра всех доступных лицензий в системе используется свойство licenses, которое содержит весьма подробную информацию о лицензиях, включая, собственно, сами лицензионные ключи и лицензированные фичи. Есть также свойства expirationDate, expirationMinutes и expirationHours, позволяющие узнать, когда лицензии закончатся.
Известный многим William Lam написал скрипт getLicenseInfo.pl, который использует LicenseManager для получения нужной информации о лицензировании (туда включена также информация не только о vSphere, но и о других продуктах семейства vCenter):
Скрипт может быть использован как для отдельных хостов ESXi, так и для централизованного сбора ключей через vCenter. Для отображения лицензионных ключей открытым текстом нужно вызывать скрипт с параметром –hide_keyfalse.
Кроме того, не так давно были воплощены в жизнь такие полезные службы vSphere для работы с SSD-накопителями, как SSD Monitoring (реализуется демоном smartd) и Swap to SSD (использование локальных дисков для файлов подкачки виртуальных машин). Однако функции кэширования на SSD реализованы пока совсем в базовом варианте, поэтому сегодня вам будет интересно узнать о новой технологии Virtual Flash (vFlash) для SSD-накопителей в VMware vSphere, которая была анонсирована совсем недавно.
Эта технология, находящаяся в стадии Tech Preview, направлена на дальнейшую интеграцию SSD-накопителей и других flash-устройств в инфраструктуру хранения VMware vSphere. Прежде всего, vFlash - это средство, позволяющее объединить SSD-ресурсы хост-серверов VMware ESXi в единый пул, используемый для задач кэширования, чтобы повысить быстродействие виртуальных машин. vFlash - это фреймворк, позволяющий сторонним вендорам SSD-накопителей и кэш-устройств использовать собственные алгоритмы для создания модулей обработки кэшей виртуальных машин (плагины vFlash Cache Modules). Будет реализован и собственный базовый алгоритм VMware для работы с кэшем.
Основная мысль VMware - предоставить партнерам некий API для их flash-устройств, за счет которого виртуальные машины будут "умно" использовать алгоритмы кэширования. Для этого можно будет использовать 2 подхода к кэшированию: VM-aware caching и VM-transparent caching:
VM-aware Caching (vFlash Memory)
В этом режиме обработки кэширования флэш-ресурс доступен напрямую для виртуальной машины, которая может использовать его на уровне блоков. В этом случае на уровне виртуального аппаратного обеспечения у виртуальной машины есть ресурс vFlash Memory определенного объема, который она может использовать как обычный диск в гостевой ОС. То есть, приложение или операционная система должны сами думать, как этот высокопроизводительный ресурс использовать. Можно вообще использовать его не как кэш, а как обычный диск, хотя идея, конечно же, не в этом.
VM-transparent Caching (vFlash Cache)
В этом случае виртуальная машина и ее гостевая ОС не знают, что на пути команд ввода-вывода находится прослойка в виде flash-устройств, оптимизирующих производительность за счет кэширования. В этом случае задача специализированного ПО (в том числе от партнеров) - предоставить оптимальный алгоритм кэширования. В этом случае будет доступна настройка следующих параметров кэша:
Гарантированный объем (Reservation size)
Выбор программного модуля-обработчика (vFlash Cache Module)
Размер блока (настраивается в зависимости от гостевой ОС)
Что делать с кэшем при перемещении виртуальной машины посредством vMotion (перенести вместе с ней или удалить)
При vMotion сервер vCenter будет проверять наличие необходимых ресурсов кэширования для виртуальной машины на целевом хосте ESXi. Для совместимости с технологией VMware HA, виртуальная машина должна будет иметь доступные vFlash-ресурсы на хранилищах хостов в случае сбоя (соответственно, потребуется эти ресурсы гарантировать).
В целом vFlash в VMware vSphere обещает быть очень перспективной технологией, что особенно актуально на волне роста потребления SSD-накопителей, постепенно дешевеющих и входящих в повсеместное употребление.
Компания HP обновила Firmware для своих серверов HP ProLiant, доступное для гипервизора VMware ESXi 5.0 и более поздних версий. Обновление доступно по этой ссылке.
Процесс обновления Firmware проходит из сервисной консоли серверов VMware ESXi, при этом предварительными требованиями является наличие следующих компонентов:
Мы уже писали о некоторых функциях утилиты esxcli в VMware vSphere, которая работает с различными пространствами имен, такими как network, storage, hardware и прочими. Сегодня мы хотим остановиться на новых функциях по управлению устройствами ввода-вывода I/O Device Management (IODM), пространство имен для которых появилось в VMware vSphere 5.1. Цель этих новых инструментов - дать администратору инструменты для понимания уровня, на котором происходят проблемы с хранилищем в сети SAN (см. тут).
Это новое пространство имен выглядит вот так:
esxcli storage san
Например, мы хотим сделать Reset для FC-адаптера:
esxcli storage san fc reset -A vmhba3
А потом посмотреть его лог, который включает в себя информацию о таких событиях, как разрыв соединения:
esxcli storage san fc events get
Можно собрать статистику по iscsi-адаптеру командой:
esxcli storage san iscsi stats get
Кроме того, в VMware vSphere 5.1 появились функции мониторинга твердотельных накопителей - SSD Monitoring, реализуемые метриками, которые собирает каждые полчаса демон S.M.A.R.T. (Self-Monitoring, Analysis and Reporting Technology). Находятся стандартные плагины в /usr/lib/VMware/smart_plugins (кстати, вендоры дисковых устройств могут добавлять туда свои плагины вместо имеющихся generic-плагинов). Надо также отметить, что эти метрики не передаются в vCenter и доступны только через esxcli.
Посмотреть статистики SSD-дисков можно командой:
esxcli storage core device smart get -d naa.xxxxxx
Жирным выделены метрики, которые могут оказаться полезными. Параметр Reallocated Sector Count не должен сильно увеличиваться со временем для исправных дисков. Когда дисковая подсистема получает ошибку read/write/verification для сектора, она перемещает его данные в специально зарезервированную область (spare area), а данный счетчик увеличивается.
Media Wearout Indicator - это уровень "жизни" вашего SSD-диска (для новых дисков он должен отображаться как 100). По мере прохождения циклов перезаписи диск "изнашивается" и данный счетчик уменьшается, соответственно, когда он перейдет в значение 0 - его жизнь формально закончится, исходя из рассчитанного для него ресурса. Кстати, этот счетчик может временно уменьшаться при интенсивных нагрузках диска, а потом восстанавливаться со временем, если средняя нагрузка на диск снизилась.
RSS
\
