Новости Статьи VMware Veeam StarWind Microsoft ИТ-ГРАД Citrix Symantec 5nine События Релизы Видео Контакты Авторы RSS
Виртуализация и виртуальные машины

Виртуализация vSphere, Hyper-V, XenServer и Red Hat

Более 4510 заметок о виртуализации и виртуальных машинах VMware, Microsoft, Citrix, Red Hat

VM Guru | Ссылка дня: Вышел VMware vCenter 6.7a - пофикшены проблемы апгрейда

Ошибка при обновлении VMware ESXi - No space left on device.


У некоторых пользователей VMware vSphere при обновлении серверов VMware ESXi возникает проблема - при выполнении команды "esxcli software vib update" в ответ возникает ошибка "No space left on device", хотя с дисками все в порядке, и на них много свободного места, в чем можно убедиться с помощью команды df -h.

Например, появляется вот такой вывод при попытке обновления:

[InstallationError]
[Errno 28] No space left on device
vibs = VMware_bootbank_esx-base_6.5.0-1.41.7967591
Please refer to the log file for more details.

В то же время вывод df -h говорит, что места на всех разделах достаточно:

Очень редко причина такого поведения оказывается проста - на хосте не хватает файловых объектов inodes, как описано в KB 1007638. Это объекты файловой системы, которых может быть до 640 тысяч на одном томе VMFS. Их используемое количество зависит от числа файлов в файловой системе в данный момент.

Проверить наличие свободных inodes можно командой stat -f /:

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

Например, можно найти лог-файлы и прочие файлы на хосте ESXi размером более 50 МБ, которые находятся НЕ на томах VMFS (чтобы не задеть логи ВМ), можно следующей командой:

find / -path "/vmfs" -prune -o -type f -size +50000k -exec ls -l '{}' \;

По итогу будет сгенерирован список преимущественно локальных файлов, который будет содержать ISO-образы, большие лог-файлы и т.п., которые уже скорее всего не нужны, и их можно удалить (а лучше переместить на какое-нибудь хранилище в целях архивирования). Также рекомендуем почитать KB 1008643, которая как раз посвящена удалению файлов в целях высвобождения объектов inodes.

Между тем, в случае появления приведенной в начале статьи ошибки о недостатке свободного места очень вероятно, что хост ESXi не может аллоцировать достаточно оперативной памяти (RAM) для проведения обновления. В этом случае вам просто надо включить ESXi system swap, который будет размещен на одном из датасторов, куда будут сбрасываться страницы оперативной памяти при недостатке памяти во время обновления.

Сделать это можно, зайдя в раздел Manage > Settings > System Swap, после чего нажав Edit...:

Выберите датастор и нажмите Ok. Также это можно сделать с помощью функционала Host Profiles:

После выбора датастора для системного свопа обновите хост ESXi и перезагрузите его.


Таги: VMware, vSphere, ESXi, Troubleshooting, Memory, Storage, Update

Ограничение виртуальных дисков по IOPS в среде VMware vSphere.


Блогер David Pasek опубликовал интересный пост, касающийся ограничения виртуальных машин и их виртуальных дисков по числу операций ввода-вывода. Смысл его в том, что автор, являющийся ярым сторонником обеспечения QoS на уровне виртуальных дисков, настоятельно рекомендует применять ограничения IOPS limit к виртуальным дискам машин, которые потенциально могут выесть много полосы ввода-вывода.

Сейчас ограничивать виртуальные машины по IOPS можно как на уровне виртуальных дисков на томах VMFS/RDM/NFS, так и на уровне томов VVols. Многие системы хранения оперирует понятием логического тома LUN, на котором размещается один том VMFS. Как правило, LUN - это логический том, что значит, что несколько LUN могут размещаться на одной физической группе дисков:

Таким образом, виртуальные машины, потребляющие много IOPS от хранилища (он называет их "noisy neighbor") могут существенно замедлить работу других производственных систем.

Поэтому для таких машин требуется создавать ограничения IOPS limit, которые можно задать для виртуального диска в опциях машин, либо привязать к VMDK диску политику с ограничениями по IOPS.

Например, в vSphere Web Client создаем новую VM Storage Policy с ограничениями IOPS limit for object:

А далее привязываем эту политику к диску VMDK в настройках ВМ:

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

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

Ну и в заключение несколько аспектов данного рода ограничений:

  • Команды ввода-вывода (IO) нормализуются к блоку 32 КБ, то есть команда в 128 КБ будет преобразована в 4 IO.
  • IOPS limit не влияет на операции SVmotion (миграция хранилища), XVmotion (миграция машин без общего хранилища) и клонирование ВМ.
  • IOPS limit применяется только ко вводу-выводу гостевой ОС и не затрагивает операции с самим диском VMDK и его swap-файлами.
  • Если у машины несколько лимитов по IOPS для дисков на одном датасторе, то эти лимиты складывают и применяются для всей ВМ на этом датасторе в целом. Если же диски находятся на разных хранилищах, то тут уже действуют правила для каждого из групп дисков.
    • Например, если у каждой из 4 дисков машины на одном датасторе стоит лимит 100 IOPS, то для всей машины будет совокупный лимит 400. То есть, если три VMDK едят по 10 IOPS каждый, то четвертый диск сможет съесть максимум 370 IOPS.
    • А вот для NFS-хранилищ все работает несколько иначе - если у каждого из 4 дисков на одном датасторе стоит лимит 100 IOPS, то сколько бы ни потребляли остальные диски, для каждого из дисков будет применен максимальный лимит 100.
  • Полная информация об ограничении ввода-вывода для виртуальных машин приведена в KB 1038241.

Также рекомендуем почитать нашу статью "VMware Storage I/O Control (SIOC) - как это работает на практическом примере".


Таги: VMware, vSphere, Storage, Performance, VMDK, VMFS, NFS

Как VMware DRS работает с памятью при балансировке кластера - Active, Consumed и Configured Memory.


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

Давайте посмотрим как Distributed Resource Scheduler работает с оперативной памятью. В кластере DRS есть такая настройка "Memory Metric for Load Balancing", которая отключена по умолчанию, и если почитать к ней описание, то становится понятно, что DRS по умолчанию руководствуется параметром Active memory для балансировки.

У машины есть три основных параметра памяти, учитываемых DRS - это Active, Consumed и Configured Memory:

  • Configured - это память, указанная в настройках виртуальной машины, то есть ее максимальное значение.
  • Consumed - это память, которая использовалась виртуальной машиной с момента ее загрузки (а вы знаете, что при загрузке операционная система обращается к большему объему памяти, чем затем ее использует).
  • Active - это активные страницы памяти (RAM), которые сейчас используются гостевой ОС.

На картинке ниже показан пример - у машины 16 ГБ памяти, при этом при загрузке она наинициализировала страниц памяти на 12 ГБ, а активно использует только 5734 МБ.

Для того чтобы подчитывать используемую память, планировщик DRS подсчитывает working set из страниц Active Memory и прибавляет к нему 25% от разницы между Consumed и Active (это называется Idle Consumed Memory) на незапланированные резкие изменения нагрузки - и это число использует в своих вычислениях балансировки кластера:

В данном случае будет использоваться значение 5734+0,25*(12288-5734) = 7372,5 МБ (на картинке 7373 МБ). Кстати, это еще не все - к машине с памятью в 16 ГБ прибавляются накладные расходы (Overhead) в размере 90 МБ, поэтому DRS в своих вычислениях будет использовать значение 7373+90 = 7463 МБ.

Если же включить настройку DRS-кластера, упомянутую выше, то DRS в своих вычислениях будет использовать Consumed Memory и также прибавлять Memory Overhead:

В обновлении vSphere 6.5 update 1d клиент позволяет вам просматривать как метрику Active Memory, так и Consumed Memory.

Вот так выглядит картинка для сбалансированного кластера DRS (рекомендаций и ошибок нет):

Кстати, если вы посмотрите на Active Memory сбалансированного кластера, то там вполне может быть дисбаланс:

В этом нет ничего страшного, так как машины используют менее 20% active memory от памяти хоста, всем памяти хватает, и DRS решает, что балансировать машины в таком случае - это только тратить ресурсы CPU и сети на vMotion.

Переключимся теперь на Consumed memory:

Тут мы видим большой дисбаланс и разница между хостами более 20% от значений Consumed memory на них. Поэтому если мы включим настройку "Memory Metric for Load Balancing", то кластер DRS начнет работу по миграции виртуальных машин между хост-серверами. Итогом будет вот такая картина:

Вывод тут вот какой. Если у вас кластер работает без оверкомита (non-overcommitted) и есть большой запас по RAM на хостах, то, возможно, вам и следует поставить настройку "Memory Metric for Load Balancing", чтобы DRS балансировал хосты по consumed memory, а сами рекомендации по миграциям, например, можно применять в ручном режиме, чтобы контролировать ситуацию.


Таги: VMware, vSphere, DRS, Memory

Некоторые полезные команды CLI для работы с консолью VMware vCenter Server Appliance (vCSA).


Мы часто пишем о виртуальном модуле VMware vCenter Server Appliance (vCSA), который представляет собой готовую виртуальную машину для управления виртуальной инфраструктурой VMware vSphere (напомним, что это полноценная замена vCenter for Windows).

Сегодня мы покажем несколько интересных утилит командной строки vCSA, которые могут помочь вам в ежедневной эксплуатации этого управляющего сервиса.

1. Просмотр журнала Cron.

vCSA имел раньше проблемы со сжатием фалов журнала (логов), что приводило к тому, что дисковые разделы быстро заполнялись. Поэтому следующей командой можно посмотреть, когда в последний раз выполнялись запланированные задачи Cron:

ls -l /var/spool/cron/lastrun/

Для сравнения ниже приведен вывод этой команды совместно с выводом текущей даты:

vc:~ # date
Mon Dec 4 12:55:39 CET 2017
vc:~ # ls -l /var/spool/cron/lastrun/
total 0
-rw------- 1 root root 0 Dec 3 20:00 cron.daily
-rw------- 1 root root 0 Dec 4 12:15 cron.hourly
-rw------- 1 root root 0 Dec 1 20:00 cron.weekly

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

grep "Authentication token is no longer valid; new one required" /var/log/messages.0.log | head

Если в выводе этой команды будет что-то вроде этого:

<timestamp> vcenter /usr/sbin/cron[<ID>]: Authentication token is no longer valid; new one required

значит пароль root устарел.

2. Смена устаревшего пароля root.

Если ваш пароль root устарел, и крон-таски vCSA не запускаются, то сменить его проще всего будет следующей командой (обратите внимание, что это НЕ слово change):

chage -l root

У вас запросят старый пароль и попросят задать новый:

Password change requested. Choose a new password.
Old Password:
New password:

После этого можно снова вывести срок действия пароля с помощью chage (тут видно, что он устареет через 99999 дней, то есть 274 года):

vc:~ # chage -l root
Minimum: 0
Maximum: 99999
Warning: 7
Inactive: -1
Last Change: Dec 27, 2016
Password Expires: Never
Password Inactive: Never
Account Expires: Never

3. Перезапуск служб vCSA.

Если вы хотите поправить странное поведение vCSA, которое может быть связано с некорректным поведением сервисов Linux внутри виртуального модуля, то можно перезапустить все службы:

service-control --stop --all
service-control --start --all

Можно перезапустить, например, только vSphere Client:

service-control --stop vsphere-client

Список запущенных служб узнается так:

service-control --list

А вот так узнается статус того или иного сервиса:

service-control --status

4. Работа с LVM

Если вам надо увеличить виртуальные диски VMDK, а потом расширить тома LVM, то можете прочитать вот эту нашу статью. Чтобы не использовать API Explorer или PowerCLI, можно выполнить следующую команду для просмотра томов LVM:

lsblk

Далее вы получите примерно следующее:

vc:~ # lsblk
NAME MAJ:MIN RM SIZE RO MOUNTPOINT
sda 8:0 0 20G 0
??sda1 8:1 0 132M 0 /boot
??sda2 8:2 0 1G 0 [SWAP]
??sda3 8:3 0 10.9G 0 /
sdb 8:16 0 1.4G 0
sdc 8:32 0 25G 0
??swap_vg-swap1 (dm-8) 253:8 0 25G 0 [SWAP]
sdd 8:48 0 50G 0
??core_vg-core (dm-7) 253:7 0 50G 0 /storage/core
sde 8:64 0 10G 0
??log_vg-log (dm-6) 253:6 0 10G 0 /storage/log
sdf 8:80 0 10G 0
??db_vg-db (dm-5) 253:5 0 10G 0 /storage/db
sdg 8:96 0 5G 0
??dblog_vg-dblog (dm-4) 253:4 0 5G 0 /storage/dblog
sdh 8:112 0 25G 0
??seat_vg-seat (dm-3) 253:3 0 25G 0 /storage/seat
sdi 8:128 0 1G 0
??netdump_vg-netdump (dm-2) 253:2 0 1016M 0 /storage/netdump
sdj 8:144 0 10G 0
??autodeploy_vg-autodeploy (dm-1) 253:1 0 10G 0 /storage/autodeploy
sdk 8:160 0 10G 0
??invsvc_vg-invsvc (dm-0) 253:0 0 10G 0 /storage/invsvc
fd0 2:0 1 4K 0
sr0 11:0 1 1024M 0

Для идентификации дисковых устройств и их типов можно выполнить следующее:

lsscsi

Вывод будет примерно таков:

vc:~ # lsscsi
[0:0:0:0] disk VMware Virtual disk 1.0 /dev/sda
[0:0:1:0] disk VMware Virtual disk 1.0 /dev/sdb
[0:0:2:0] disk VMware Virtual disk 1.0 /dev/sdc
[0:0:3:0] disk VMware Virtual disk 1.0 /dev/sdd
[0:0:4:0] disk VMware Virtual disk 1.0 /dev/sde
[0:0:5:0] disk VMware Virtual disk 1.0 /dev/sdf
[0:0:6:0] disk VMware Virtual disk 1.0 /dev/sdg
[0:0:8:0] disk VMware Virtual disk 1.0 /dev/sdh
[0:0:10:0] disk VMware Virtual disk 1.0 /dev/sdi
[0:0:12:0] disk VMware Virtual disk 1.0 /dev/sdj
[0:0:14:0] disk VMware Virtual disk 1.0 /dev/sdk
[1:0:0:0] cd/dvd NECVMWar VMware IDE CDR00 1.00 /dev/sr0

Когда вы поймете, какой том нужно увеличить, выполните команду:

vpxd_servicecfg storage lvm autogrow

Надо помнить, что это сработает только для томов под управлением LVM (например, для disk 1 (sda) с разделом / - не сработает).

5. Поиск "загрязняющих" файлов.

Чтобы найти логи, которые могут засорить корневой раздел или раздел /storage/log, выполните одну из следующих команд:

du -a /var | sort -n -r | head -n 10
du -a /storage/log | sort -n -r | head -n 10

6. Изменение режима ротации логов (Log Rotation).

Сначала перейдем в папку с логами:

cd /etc/logrotate.d

Далее сделаем бэкап настроек:

cp dnsmasq ./dnsmasq.old

Затем откроем настройки:

vi dnsmasq

И поменяем слово "weekly" (еженедельно) на "daily" (ежедневно), например:

/var/log/dnsmasq.log {
daily
missingok
notifempty
delaycompress
sharedscripts
postrotate
[ ! -f /var/run/dnsmasq.pid ] || kill -USR2 cat /var/run/dnsmasq.pid
endscript
create 0640 dnsmasq dnsmasq

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

cd /var/log
rm dnsmasq.log

7. Удаление файлов, которые не удалились.

Бывает так, что вы удалили большой файл, а дисковое пространство не высвободилось - и это видно командой df -h. Это происходит потому, что какой-то из процессов в памяти еще держит файл (при этом не обязательно использует его). Чтобы узнать, что это за процесс выполняем команду:

lsof | grep deleted

Вывод будет примерно таким:

postgres 8860 vpostgres 10u REG 253,4 16777216 16395 /storage/dblog/vpostgres/pg_xlog/000000010000011900000041 (deleted)

Видим, что это Postgres держит файл, поэтому если он нам сейчас не нужен, убиваем процесс:

kill -9 <PID>

После этого вы увидите, что свободного дискового пространства на сервере vCSA стало больше.


Таги: VMware, vCenter, vCSA, Linux, Blogs

Несколько советов по дедупликации, компрессии и экономии дискового пространства в кластере VMware vSAN.


John Nicholson написал интересный пост с советами по экономии дискового пространства в кластере VMware vSAN, а также некоторыми рекомендациями по использованию техник дедупликации и сжатия данных.

Вот каким моментам следует уделить внимание:

1. Посмотрите на параметр политики хранения object space reservation (OSR) - если он установлен в 0, то виртуальные диски машин будут тонкими. Если же он будет больше 0, то пространство под диски будет резервироваться и vSAN не сможет эффективно использовать дедупликацию, так как будет вынужден поддерживать фиксированные резервы дискового пространства под ВМ.

2. Помните, что параметр резервирования свопа установлен в 100%, но это можно поменять, как мы писали в этой статье. Уменьшение параметра резервирования свопа оправдано, когда вы не собираетесь использовать memory overcommitment (то есть, ресурсов у вас с запасом), а значит виртуальным машинами не потребуется активно сбрасывать страницы в своп в случае недостатка физической памяти.

3. Помните, что отдельно развертываемые виртуальные машины c дисками типа "thick" или "Eager Zero Thick" (например, со старых клиентов vSphere Client или через консоль) могут перекрывать настройку политики OSR. Чтобы пофиксить это, вы можете переприменить политику хранения (storage policy) на эти хранилища. William Lam написал несколько скриптов, которые позволяют найти такие ВМ и накатить политики по-новой.

4. Убедитесь, что данные записываются на capacity tier - только там они будут дедуплицироваться и сжиматься. Если вы развернули всего 3-4 машины, они могут остаться в буффере (write buffer). Механизмы vSAN не тратят ресурсы на дедупликацию и сжатие объектов, которые долго не живут (то есть, находятся в буффере на запись). Например, 10 машин по 8 ГБ диска каждая тоже могут остаться на стейджинге и, пока не переместятся в постоянное хранилище, не будут дедуплицированы.

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

Ну и вот что Джон рекомендует в плане тестирования дедупликации и компрессии:

  • Самый простой способ организовать тестирование - запустить клонирование 200+ виртуальных машин, они сразу пойдут в capacity tier, и механизм дедупликации включится.
  • Надо помнить, что тестирование этих механизмов и реальное их применение дадут разные результаты, так как при тестировании вы последовательно пишете данные на хранилище и избегаете узких мест, связанных с дестэйджингом из кэша во время размеренного использования кластера vSAN в продакшене.
  • Тестирование алгоритма сжатия на данных, которые плохо сжимаются - плохая идея, так как в этом случае vSAN не будет тратить ресурсы на их сжатие, чтобы записать на хранилище. Это позволит быстрее читать их, а экономия с точки зрения диска будет небольшой (к тому же, алгоритм сжатия LZ4 не такой быстрый, как хотелось бы).
  • При резких всплесках объема записываемых данных и IOPS, которые не помещаются в кэш, видно, что механизмы сжатия и дедупликации приостанавливаются и теряют эффективность. Это связано с тем, что vSAN прежде всего должен обеспечить хороший показатель latency (то есть уровня сервиса), а уже во вторую очередь эффективность механизмов дедупликации и компрессии.

Ну и в довершение, интереснейший документ от VMware - "vSAN Space Efficiency Technologies".


Таги: VMware, Storage, vSAN

Переделка "толстых" файлов подкачки виртуальных машин в кластере VMware vSAN на "тонкие".


Некоторые из вас знают, что, начиная с версии vSAN 6.2, стало возможно создание "тонких" (thin) файлов подкачки. В более ранних версиях vSAN было возможно создавать только reserved своп-файлы, что требовало довольно больших объемов дисковой памяти. То есть, если у машины 16 ГБ оперативной памяти, то в два раза больше будет занято и на диске под своп (32 ГБ), так как при FTT=1 (failures to tolerate) дисковые объекты дублируются в рамках кластера.

Поэтому для сред, в которых достаточно памяти у хостов, и отсутствует Memory Overcommitment, сделали параметр в настройках кластера SwapThickProvisionDisabled, позволяющий виртуальным машинам создавать тонкие файлы подкачки.

Чтобы выставить эту настройку, есть специальный скрипт PowerCLI, который применяет ее ко всем хостам ESXi кластера vSAN.

Однако выставить настройку недостаточно - ведь, чтобы файлы подкачки стали тонкими, то есть пересоздались, надо перезагрузить (выключить и включить) виртуальные машины с толстыми swap-файлами. Найти такие машины позволит вот этот Python-сценарий. Ну а дальше уже перезагрузите машины по списку - это позволит вам сэкономить значительный объем дискового пространства кластера.


Таги: VMware, vSAN, Storage, ESXi, VMachines

Резервное копирование виртуальных машин в облако средствами NAKIVO Backup & Replication.


Многие из вас уже знают продукт NAKIVO Backup & Replication, представляющий собой недорогое решение для резервного копирования и репликации виртуальных машин VMware vSphere, Microsoft Hyper-V и Amazon EC2. Недавно мы писали о бета-версии NAKIVO Backup & Replication 7.2, в которой появилось много новых возможностей. Ну а сегодня мы хотим рассказать о функциях для бэкапа виртуальных машин в облако с помощью решения NAKIVO
Таги: NAKIVO, Backup, Cloud, Amazon, Azure

Новое на VMware Labs - утилита DRS Lens для более глубокого понимания механизма балансировки нагрузки.


На сайте проекта VMware Labs появилась очередная заслуживающая внимания утилита DRS Lens, поставляемая в виде виртуального модуля (Virtual Appliance). Она позволяет администраторам виртуальных инфраструктур получить больше информации о работе механизма балансировки нагрузки на хост-серверы VMware vSphere DRS.

Полученная информация располагается на 5 дэшбордах, которые дают представление о различных аспектах DRS.

Summary

Это вкладка с общей информацией. Тут агрегируются данные с других разделов в удобное представление для администратора.

Cluster Balance

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

VM Happiness

На этом дэшборде впервые можно увидеть метрику VM happiness в графическом интерфейсе. Здесь представлена диаграмма, показывающая число ВМ, которые "счастливы" в кластере (то есть работают под нормальной нагрузкой) и число тех, которые "несчастны" (работают в стрессовых условиях при недостатке ресурсов). Пользователь может выбирать отдельные ВМ для просмотра метрик производительности, которые влияют на VM happiness, такие как %CPU ready, memory swapped и т.п.

vMotions

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

Operations

На этом дэшборде можно отслеживать различные операции (задачи на стороне vCenter Server), которые выполнялись с течением времени. Администраторы могут сопоставлять информацию о задачах с этого дэшборда с данными других вкладок.

Все эти вещи позволят более детально ответить на вопрос - а что же именно и когда механизм DRS делает с виртуальными машинами при перемещении между хост-серверами ESXi.

Скачать VMware DRS Lens можно по этой ссылке. После развертывания виртуального модуля утилитой можно пользоваться по следующим адресам:

https://<appliance-ip>/drs/app

http://<appliance-ip>:8080/drs/app


Таги: VMware, Labs, DRS, vSphere, VMachines, Virtual Appliance

VMware vSphere VMkernel Observations (VOBs) - как создавать кастомные алармы для различных событий (alarms).


В VMware vSphere есть механизм для создания и анализа кастомных алармов - VMkernel Observations (VOBs). VOB'ы - это системные события, которые можно использовать для пользовательских алармов в целях отладки различных аспектов виртуальной инфраструктуры (сетевого взаимодействия, кластеров vSAN, производительности и т.п.).

Чтобы добавить такой аларм, нужно знать его уникальный идентификатор (ID), ассоциированный с конкретным типом события. Эти события и их ID можно посмотреть в следующем файле на хосте ESXi:

/usr/lib/vmware/hostd/extensions/hostdiag/locale/en/event.vmsg

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

/var/log/vobd.log

Для того, чтобы создать кастомный аларм на основе VOB, нужно при создании нового аларма выбрать пункт "specific event occuring on this object":

И далее добавить соответствующий идентификатор, например, такой:

esx.problem.vob.vsan.pdl.offline

Событий, для которых можно создать кастомные алармы, очень много. Вот некоторые из них:

VOB ID VOB Description
esx.audit.vsan.clustering.enabled VSAN clustering services have been enabled.
esx.clear.vob.vsan.pdl.online VSAN device has come online.
esx.clear.vsan.clustering.enabled VSAN clustering services have now been enabled.
esx.clear.vsan.vsan.network.available VSAN now has at least one active network configuration.
esx.clear.vsan.vsan.vmknic.ready A previously reported vmknic now has a valid IP.
esx.problem.vob.vsan.lsom.componentthreshold VSAN Node: Near node component count limit.
esx.problem.vob.vsan.lsom.diskerror VSAN device is under permanent error.
esx.problem.vob.vsan.lsom.diskgrouplimit Failed to create a new disk group.
esx.problem.vob.vsan.lsom.disklimit Failed to add disk to disk group.
esx.problem.vob.vsan.pdl.offline VSAN device has gone offline.
esx.problem.vsan.clustering.disabled VSAN clustering services have been disabled.
esx.problem.vsan.lsom.congestionthreshold VSAN device Memory/SSD congestion has changed.
esx.problem.vsan.net.not.ready A vmknic added to VSAN network configuration doesn't have valid IP. Network is not ready.
esx.problem.vsan.net.redundancy.lost VSAN doesn't haven any redundancy in its network configuration.
esx.problem.vsan.net.redundancy.reduced VSAN is operating on reduced network redundancy.
esx.problem.vsan.no.network.connectivity VSAN doesn't have any networking configuration for use.
esx.problem.vsan.vmknic.not.ready A vmknic added to VSAN network configuration doesn't have valid IP. It will not be in use.
ad.event.ImportCertEvent Import certificate success
ad.event.ImportCertFailedEvent Import certificate failure
ad.event.JoinDomainEvent Join domain success
ad.event.JoinDomainFailedEvent Join domain failure
ad.event.LeaveDomainEvent Leave domain success
ad.event.LeaveDomainFailedEvent Leave domain failure
com.vmware.vc.HA.CreateConfigVvolFailedEvent vSphere HA failed to create a configuration vVol for this datastore and so will not be able to protect virtual machines on the datastore until the problem is resolved. Error: {fault}
com.vmware.vc.HA.CreateConfigVvolSucceededEvent vSphere HA successfully created a configuration vVol after the previous failure
com.vmware.vc.HA.DasHostCompleteDatastoreFailureEvent Host complete datastore failure
com.vmware.vc.HA.DasHostCompleteNetworkFailureEvent Host complete network failure
com.vmware.vc.VmCloneFailedInvalidDestinationEvent Cannot complete virtual machine clone.
com.vmware.vc.VmCloneToResourcePoolFailedEvent Cannot complete virtual machine clone.
com.vmware.vc.VmDiskConsolidatedEvent Virtual machine disks consolidation succeeded.
com.vmware.vc.VmDiskConsolidationNeeded Virtual machine disks consolidation needed.
com.vmware.vc.VmDiskConsolidationNoLongerNeeded Virtual machine disks consolidation no longer needed.
com.vmware.vc.VmDiskFailedToConsolidateEvent Virtual machine disks consolidation failed.
com.vmware.vc.datastore.UpdateVmFilesFailedEvent Failed to update VM files
com.vmware.vc.datastore.UpdatedVmFilesEvent Updated VM files
com.vmware.vc.datastore.UpdatingVmFilesEvent Updating VM Files
com.vmware.vc.ft.VmAffectedByDasDisabledEvent Fault Tolerance VM restart disabled
com.vmware.vc.guestOperations.GuestOperation Guest operation
com.vmware.vc.guestOperations.GuestOperationAuthFailure Guest operation authentication failure
com.vmware.vc.host.clear.vFlashResource.inaccessible Host's virtual flash resource is accessible.
com.vmware.vc.host.clear.vFlashResource.reachthreshold Host's virtual flash resource usage dropped below the threshold.
com.vmware.vc.host.problem.vFlashResource.inaccessible Host's virtual flash resource is inaccessible.
com.vmware.vc.host.problem.vFlashResource.reachthreshold Host's virtual flash resource usage exceeds the threshold.
com.vmware.vc.host.vFlash.VFlashResourceCapacityExtendedEvent Virtual flash resource capacity is extended
com.vmware.vc.host.vFlash.VFlashResourceConfiguredEvent Virtual flash resource is configured on the host
com.vmware.vc.host.vFlash.VFlashResourceRemovedEvent Virtual flash resource is removed from the host
com.vmware.vc.host.vFlash.defaultModuleChangedEvent Default virtual flash module is changed to {vFlashModule} on the host
com.vmware.vc.host.vFlash.modulesLoadedEvent Virtual flash modules are loaded or reloaded on the host
com.vmware.vc.npt.VmAdapterEnteredPassthroughEvent Virtual NIC entered passthrough mode
com.vmware.vc.npt.VmAdapterExitedPassthroughEvent Virtual NIC exited passthrough mode
com.vmware.vc.vcp.FtDisabledVmTreatAsNonFtEvent FT Disabled VM protected as non-FT VM
com.vmware.vc.vcp.FtFailoverEvent Failover FT VM due to component failure
com.vmware.vc.vcp.FtFailoverFailedEvent FT VM failover failed
com.vmware.vc.vcp.FtSecondaryRestartEvent Restarting FT secondary due to component failure
com.vmware.vc.vcp.FtSecondaryRestartFailedEvent FT secondary VM restart failed
com.vmware.vc.vcp.NeedSecondaryFtVmTreatAsNonFtEvent Need secondary VM protected as non-FT VM
com.vmware.vc.vcp.TestEndEvent VM Component Protection test ends
com.vmware.vc.vcp.TestStartEvent VM Component Protection test starts
com.vmware.vc.vcp.VcpNoActionEvent No action on VM
com.vmware.vc.vcp.VmDatastoreFailedEvent Virtual machine lost datastore access
com.vmware.vc.vcp.VmNetworkFailedEvent Virtual machine lost VM network accessibility
com.vmware.vc.vcp.VmPowerOffHangEvent VM power off hang
com.vmware.vc.vcp.VmRestartEvent Restarting VM due to component failure
com.vmware.vc.vcp.VmRestartFailedEvent Virtual machine affected by component failure failed to restart
com.vmware.vc.vcp.VmWaitForCandidateHostEvent No candidate host to restart
com.vmware.vc.vm.VmStateFailedToRevertToSnapshot Failed to revert the virtual machine state to a snapshot
com.vmware.vc.vm.VmStateRevertedToSnapshot The virtual machine state has been reverted to a snapshot
com.vmware.vc.vmam.AppMonitoringNotSupported Application Monitoring Is Not Supported
com.vmware.vc.vmam.VmAppHealthMonitoringStateChangedEvent vSphere HA detected application heartbeat status change
com.vmware.vc.vmam.VmAppHealthStateChangedEvent vSphere HA detected application state change
com.vmware.vc.vmam.VmDasAppHeartbeatFailedEvent vSphere HA detected application heartbeat failure
esx.audit.agent.hostd.started VMware Host Agent started
esx.audit.agent.hostd.stopped VMware Host Agent stopped
esx.audit.dcui.defaults.factoryrestore Restoring factory defaults through DCUI.
esx.audit.dcui.disabled The DCUI has been disabled.
esx.audit.dcui.enabled The DCUI has been enabled.
esx.audit.dcui.host.reboot Rebooting host through DCUI.
esx.audit.dcui.host.shutdown Shutting down host through DCUI.
esx.audit.dcui.hostagents.restart Restarting host agents through DCUI.
esx.audit.dcui.login.failed Login authentication on DCUI failed
esx.audit.dcui.login.passwd.changed DCUI login password changed.
esx.audit.dcui.network.factoryrestore Factory network settings restored through DCUI.
esx.audit.dcui.network.restart Restarting network through DCUI.
esx.audit.esxcli.host.poweroff Powering off host through esxcli
esx.audit.esxcli.host.reboot Rebooting host through esxcli
esx.audit.esximage.hostacceptance.changed Host acceptance level changed
esx.audit.esximage.install.novalidation Attempting to install an image profile with validation disabled.
esx.audit.esximage.install.securityalert SECURITY ALERT: Installing image profile.
esx.audit.esximage.profile.install.successful Successfully installed image profile.
esx.audit.esximage.profile.update.successful Successfully updated host to new image profile.
esx.audit.esximage.vib.install.successful Successfully installed VIBs.
esx.audit.esximage.vib.remove.successful Successfully removed VIBs
esx.audit.host.boot Host has booted.
esx.audit.host.maxRegisteredVMsExceeded The number of virtual machines registered on the host exceeded limit.
esx.audit.host.stop.reboot Host is rebooting.
esx.audit.host.stop.shutdown Host is shutting down.
esx.audit.lockdownmode.disabled Administrator access to the host has been enabled.
esx.audit.lockdownmode.enabled Administrator access to the host has been disabled.
esx.audit.maintenancemode.canceled The host has canceled entering maintenance mode.
esx.audit.maintenancemode.entered The host has entered maintenance mode.
esx.audit.maintenancemode.entering The host has begun entering maintenance mode.
esx.audit.maintenancemode.exited The host has exited maintenance mode.
esx.audit.net.firewall.config.changed Firewall configuration has changed.
esx.audit.net.firewall.disabled Firewall has been disabled.
esx.audit.net.firewall.enabled Firewall has been enabled for port.
esx.audit.net.firewall.port.hooked Port is now protected by Firewall.
esx.audit.net.firewall.port.removed Port is no longer protected with Firewall.
esx.audit.net.lacp.disable LACP disabled
esx.audit.net.lacp.enable LACP eabled
esx.audit.net.lacp.uplink.connected uplink is connected
esx.audit.shell.disabled The ESXi command line shell has been disabled.
esx.audit.shell.enabled The ESXi command line shell has been enabled.
esx.audit.ssh.disabled SSH access has been disabled.
esx.audit.ssh.enabled SSH access has been enabled.
esx.audit.usb.config.changed USB configuration has changed.
esx.audit.uw.secpolicy.alldomains.level.changed Enforcement level changed for all security domains.
esx.audit.uw.secpolicy.domain.level.changed Enforcement level changed for security domain.
esx.audit.vmfs.lvm.device.discovered LVM device discovered.
esx.audit.vmfs.volume.mounted File system mounted.
esx.audit.vmfs.volume.umounted LVM volume un-mounted.
esx.clear.coredump.configured A vmkcore disk partition is available and/or a network coredump server has been configured.  Host core dumps will be saved.
esx.clear.coredump.configured2 At least one coredump target has been configured. Host core dumps will be saved.
esx.clear.net.connectivity.restored Restored network connectivity to portgroups
esx.clear.net.dvport.connectivity.restored Restored Network Connectivity to DVPorts
esx.clear.net.dvport.redundancy.restored Restored Network Redundancy to DVPorts
esx.clear.net.lacp.lag.transition.up lag transition up
esx.clear.net.lacp.uplink.transition.up uplink transition up
esx.clear.net.lacp.uplink.unblocked uplink is unblocked
esx.clear.net.redundancy.restored Restored uplink redundancy to portgroups
esx.clear.net.vmnic.linkstate.up Link state up
esx.clear.scsi.device.io.latency.improved Scsi Device I/O Latency has improved
esx.clear.scsi.device.state.on Device has been turned on administratively.
esx.clear.scsi.device.state.permanentloss.deviceonline Device that was permanently inaccessible is now online.
esx.clear.storage.apd.exit Exited the All Paths Down state
esx.clear.storage.connectivity.restored Restored connectivity to storage device
esx.clear.storage.redundancy.restored Restored path redundancy to storage device
esx.problem.3rdParty.error A 3rd party component on ESXi has reported an error.
esx.problem.3rdParty.information A 3rd party component on ESXi has reported an informational event.
esx.problem.3rdParty.warning A 3rd party component on ESXi has reported a warning.
esx.problem.apei.bert.memory.error.corrected A corrected memory error occurred
esx.problem.apei.bert.memory.error.fatal A fatal memory error occurred
esx.problem.apei.bert.memory.error.recoverable A recoverable memory error occurred
esx.problem.apei.bert.pcie.error.corrected A corrected PCIe error occurred
esx.problem.apei.bert.pcie.error.fatal A fatal PCIe error occurred
esx.problem.apei.bert.pcie.error.recoverable A recoverable PCIe error occurred
esx.problem.application.core.dumped An application running on ESXi host has crashed and a core file was created.
esx.problem.boot.filesystem.down Lost connectivity to the device backing the boot filesystem
esx.problem.coredump.capacity.insufficient The storage capacity of the coredump targets is insufficient to capture a complete coredump.
esx.problem.coredump.unconfigured No vmkcore disk partition is available and no network coredump server has been configured.  Host core dumps cannot be saved.
esx.problem.coredump.unconfigured2 No coredump target has been configured. Host core dumps cannot be saved.
esx.problem.cpu.amd.mce.dram.disabled DRAM ECC not enabled. Please enable it in BIOS.
esx.problem.cpu.intel.ioapic.listing.error Not all IO-APICs are listed in the DMAR. Not enabling interrupt remapping on this platform.
esx.problem.cpu.mce.invalid MCE monitoring will be disabled as an unsupported CPU was detected. Please consult the ESX HCL for information on supported hardware.
esx.problem.cpu.smp.ht.invalid Disabling HyperThreading due to invalid configuration: Number of threads: {1} Number of PCPUs: {2}.
esx.problem.cpu.smp.ht.numpcpus.max Found {1} PCPUs but only using {2} of them due to specified limit.
esx.problem.cpu.smp.ht.partner.missing Disabling HyperThreading due to invalid configuration: HT partner {1} is missing from PCPU {2}.
esx.problem.dhclient.lease.none Unable to obtain a DHCP lease.
esx.problem.dhclient.lease.offered.noexpiry No expiry time on offered DHCP lease.
esx.problem.esximage.install.error Could not install image profile.
esx.problem.esximage.install.invalidhardware Host doesn't meet image profile hardware requirements.
esx.problem.esximage.install.stage.error Could not stage image profile.
esx.problem.hardware.acpi.interrupt.routing.device.invalid Skipping interrupt routing entry with bad device number: {1}. This is a BIOS bug.
esx.problem.hardware.acpi.interrupt.routing.pin.invalid Skipping interrupt routing entry with bad device pin: {1}. This is a BIOS bug.
esx.problem.hardware.ioapic.missing IOAPIC Num {1} is missing. Please check BIOS settings to enable this IOAPIC.
esx.problem.host.coredump An unread host kernel core dump has been found.
esx.problem.hostd.core.dumped Hostd crashed and a core file was created.
esx.problem.iorm.badversion Storage I/O Control version mismatch
esx.problem.iorm.nonviworkload Unmanaged workload detected on SIOC-enabled datastore
esx.problem.migrate.vmotion.default.heap.create.failed Failed to create default migration heap
esx.problem.migrate.vmotion.server.pending.cnx.listen.socket.shutdown Error with migration listen socket
esx.problem.net.connectivity.lost Lost Network Connectivity
esx.problem.net.dvport.connectivity.lost Lost Network Connectivity to DVPorts
esx.problem.net.dvport.redundancy.degraded Network Redundancy Degraded on DVPorts
esx.problem.net.dvport.redundancy.lost Lost Network Redundancy on DVPorts
esx.problem.net.e1000.tso6.notsupported No IPv6 TSO support
esx.problem.net.fence.port.badfenceid Invalid fenceId configuration on dvPort
esx.problem.net.fence.resource.limited Maximum number of fence networks or ports
esx.problem.net.fence.switch.unavailable Switch fence property is not set
esx.problem.net.firewall.config.failed Firewall configuration operation failed. The changes were not applied.
esx.problem.net.firewall.port.hookfailed Adding port to Firewall failed.
esx.problem.net.gateway.set.failed Failed to set gateway
esx.problem.net.heap.belowthreshold Network memory pool threshold
esx.problem.net.lacp.lag.transition.down lag transition down
esx.problem.net.lacp.peer.noresponse No peer response
esx.problem.net.lacp.policy.incompatible Current teaming policy is incompatible
esx.problem.net.lacp.policy.linkstatus Current teaming policy is incompatible
esx.problem.net.lacp.uplink.blocked uplink is blocked
esx.problem.net.lacp.uplink.disconnected uplink is disconnected
esx.problem.net.lacp.uplink.fail.duplex uplink duplex mode is different
esx.problem.net.lacp.uplink.fail.speed uplink speed is different
esx.problem.net.lacp.uplink.inactive All uplinks must be active
esx.problem.net.lacp.uplink.transition.down uplink transition down
esx.problem.net.migrate.bindtovmk Invalid vmknic specified in /Migrate/Vmknic
esx.problem.net.migrate.unsupported.latency Unsupported vMotion network latency detected
esx.problem.net.portset.port.full Failed to apply for free ports
esx.problem.net.portset.port.vlan.invalidid Vlan ID of the port is invalid
esx.problem.net.proxyswitch.port.unavailable Virtual NIC connection to switch failed
esx.problem.net.redundancy.degraded Network Redundancy Degraded
esx.problem.net.redundancy.lost Lost Network Redundancy
esx.problem.net.uplink.mtu.failed Failed to set MTU on an uplink
esx.problem.net.vmknic.ip.duplicate A duplicate IP address was detected on a vmknic interface
esx.problem.net.vmnic.linkstate.down Link state down
esx.problem.net.vmnic.linkstate.flapping Link state unstable
esx.problem.net.vmnic.watchdog.reset Nic Watchdog Reset
esx.problem.ntpd.clock.correction.error NTP daemon stopped.  Time correction out of bounds.
esx.problem.pageretire.platform.retire.request Memory page retirement requested by platform firmware.
esx.problem.pageretire.selectedmpnthreshold.host.exceeded Number of host physical memory pages selected for retirement exceeds threshold.
esx.problem.scratch.partition.size.small Size of scratch partition is too small.
esx.problem.scratch.partition.unconfigured No scratch partition has been configured.
esx.problem.scsi.apd.event.descriptor.alloc.failed No memory to allocate APD Event
esx.problem.scsi.device.close.failed Scsi Device close failed.
esx.problem.scsi.device.detach.failed Device detach failed
esx.problem.scsi.device.filter.attach.failed Failed to attach filter to device.
esx.problem.scsi.device.io.bad.plugin.type Plugin trying to issue command to device does not have a valid storage plugin type.
esx.problem.scsi.device.io.inquiry.failed Failed to obtain INQUIRY data from the device
esx.problem.scsi.device.io.invalid.disk.qfull.value Scsi device queue parameters incorrectly set.
esx.problem.scsi.device.io.latency.high Scsi Device I/O Latency going high
esx.problem.scsi.device.io.qerr.change.config QErr cannot be changed on device. Please change it manually on the device if possible.
esx.problem.scsi.device.io.qerr.changed Scsi Device QErr setting changed
esx.problem.scsi.device.is.local.failed Plugin's isLocal entry point failed
esx.problem.scsi.device.is.pseudo.failed Plugin's isPseudo entry point failed
esx.problem.scsi.device.is.ssd.failed Plugin's isSSD entry point failed
esx.problem.scsi.device.limitreached Maximum number of storage devices
esx.problem.scsi.device.state.off Device has been turned off administratively.
esx.problem.scsi.device.state.permanentloss Device has been removed or is permanently inaccessible.
esx.problem.scsi.device.state.permanentloss.noopens Permanently inaccessible device has no more opens.
esx.problem.scsi.device.state.permanentloss.pluggedback Device has been plugged back in after being marked permanently inaccessible.
esx.problem.scsi.device.state.permanentloss.withreservationheld Device has been removed or is permanently inaccessible.
esx.problem.scsi.device.thinprov.atquota Thin Provisioned Device Nearing Capacity
esx.problem.scsi.scsipath.badpath.unreachpe vVol PE path going out of vVol-incapable adapter
esx.problem.scsi.scsipath.badpath.unsafepe Cannot safely determine vVol PE
esx.problem.scsi.scsipath.limitreached Maximum number of storage paths
esx.problem.scsi.unsupported.plugin.type Storage plugin of unsupported type tried to register.
esx.problem.storage.apd.start All paths are down
esx.problem.storage.apd.timeout All Paths Down timed out, I/Os will be fast failed
esx.problem.storage.connectivity.devicepor Frequent PowerOn Reset Unit Attention of Storage Path
esx.problem.storage.connectivity.lost Lost Storage Connectivity
esx.problem.storage.connectivity.pathpor Frequent PowerOn Reset Unit Attention of Storage Path
esx.problem.storage.connectivity.pathstatechanges Frequent State Changes of Storage Path
esx.problem.storage.iscsi.discovery.connect.error iSCSI discovery target login connection problem
esx.problem.storage.iscsi.discovery.login.error iSCSI Discovery target login error
esx.problem.storage.iscsi.isns.discovery.error iSCSI iSns Discovery error
esx.problem.storage.iscsi.target.connect.error iSCSI Target login connection problem
esx.problem.storage.iscsi.target.login.error iSCSI Target login error
esx.problem.storage.iscsi.target.permanently.lost iSCSI target permanently removed
esx.problem.storage.redundancy.degraded Degraded Storage Path Redundancy
esx.problem.storage.redundancy.lost Lost Storage Path Redundancy
esx.problem.syslog.config System logging is not configured.
esx.problem.syslog.nonpersistent System logs are stored on non-persistent storage.
esx.problem.vfat.filesystem.full.other A VFAT filesystem is full.
esx.problem.vfat.filesystem.full.scratch A VFAT filesystem, being used as the host's scratch partition, is full.
esx.problem.visorfs.failure An operation on the root filesystem has failed.
esx.problem.visorfs.inodetable.full The root filesystem's file table is full.
esx.problem.visorfs.ramdisk.full A ramdisk is full.
esx.problem.visorfs.ramdisk.inodetable.full A ramdisk's file table is full.
esx.problem.vm.kill.unexpected.fault.failure A VM could not fault in the a page. The VM is terminated as further progress is impossible.
esx.problem.vm.kill.unexpected.forcefulPageRetire A VM did not respond to swap actions and is forcefully powered off to prevent system instability.
esx.problem.vm.kill.unexpected.noSwapResponse A VM did not respond to swap actions and is forcefully powered off to prevent system instability.
esx.problem.vm.kill.unexpected.vmtrack A VM is allocating too many pages while system is critically low in free memory. It is forcefully terminated to prevent system instability.
esx.problem.vmfs.ats.support.lost Device Backing VMFS has lost ATS Support
esx.problem.vmfs.error.volume.is.locked VMFS Locked By Remote Host
esx.problem.vmfs.extent.offline Device backing an extent of a file system is offline.
esx.problem.vmfs.extent.online Device backing an extent of a file system came online
esx.problem.vmfs.heartbeat.recovered VMFS Volume Connectivity Restored
esx.problem.vmfs.heartbeat.timedout VMFS Volume Connectivity Degraded
esx.problem.vmfs.heartbeat.unrecoverable VMFS Volume Connectivity Lost
esx.problem.vmfs.journal.createfailed No Space To Create VMFS Journal
esx.problem.vmfs.lock.corruptondisk VMFS Lock Corruption Detected
esx.problem.vmfs.lock.corruptondisk.v2 VMFS Lock Corruption Detected
esx.problem.vmfs.nfs.mount.connect.failed Unable to connect to NFS server
esx.problem.vmfs.nfs.mount.limit.exceeded NFS has reached the maximum number of supported volumes
esx.problem.vmfs.nfs.server.disconnect Lost connection to NFS server
esx.problem.vmfs.nfs.server.restored Restored connection to NFS server
esx.problem.vmfs.resource.corruptondisk VMFS Resource Corruption Detected
esx.problem.vmsyslogd.remote.failure Remote logging host has become unreachable.
esx.problem.vmsyslogd.storage.failure Logging to storage has failed.
esx.problem.vmsyslogd.storage.logdir.invalid The configured log directory cannot be used.  The default directory will be used instead.
esx.problem.vmsyslogd.unexpected Log daemon has failed for an unexpected reason.
esx.problem.vpxa.core.dumped Vpxa crashed and a core file was created.
hbr.primary.AppQuiescedDeltaCompletedEvent Application consistent delta completed.
hbr.primary.ConnectionRestoredToHbrServerEvent Connection to VR Server restored.
hbr.primary.DeltaAbortedEvent Delta aborted.
hbr.primary.DeltaCompletedEvent Delta completed.
hbr.primary.DeltaStartedEvent Delta started.
hbr.primary.FSQuiescedDeltaCompletedEvent File system consistent delta completed.
hbr.primary.FSQuiescedSnapshot Application quiescing failed during replication.
hbr.primary.FailedToStartDeltaEvent Failed to start delta.
hbr.primary.FailedToStartSyncEvent Failed to start full sync.
hbr.primary.HostLicenseFailedEvent vSphere Replication is not licensed replication is disabled.
hbr.primary.InvalidDiskReplicationConfigurationEvent Disk replication configuration is invalid.
hbr.primary.InvalidVmReplicationConfigurationEvent Virtual machine replication configuration is invalid.
hbr.primary.NoConnectionToHbrServerEvent No connection to VR Server.
hbr.primary.NoProgressWithHbrServerEvent VR Server error: {reason.@enum.hbr.primary.ReasonForNoServerProgress}
hbr.primary.QuiesceNotSupported Quiescing is not supported for this virtual machine.
hbr.primary.SyncCompletedEvent Full sync completed.
hbr.primary.SyncStartedEvent Full sync started.
hbr.primary.SystemPausedReplication System has paused replication.
hbr.primary.UnquiescedDeltaCompletedEvent Delta completed.
hbr.primary.UnquiescedSnapshot Unable to quiesce the guest.
hbr.primary.VmLicenseFailedEvent vSphere Replication is not licensed replication is disabled.
hbr.primary.VmReplicationConfigurationChangedEvent Replication configuration changed.
vim.event.LicenseDowngradedEvent License downgrade
vim.event.SystemSwapInaccessible System swap inaccessible
vim.event.UnsupportedHardwareVersionEvent This virtual machine uses hardware version {version} which is no longer supported. Upgrade is recommended.
vprob.net.connectivity.lost Lost Network Connectivity
vprob.net.e1000.tso6.notsupported No IPv6 TSO support
vprob.net.migrate.bindtovmk Invalid vmknic specified in /Migrate/Vmknic
vprob.net.proxyswitch.port.unavailable Virtual NIC connection to switch failed
vprob.net.redundancy.degraded Network Redundancy Degraded
vprob.net.redundancy.lost Lost Network Redundancy
vprob.scsi.device.thinprov.atquota Thin Provisioned Device Nearing Capacity
vprob.storage.connectivity.lost Lost Storage Connectivity
vprob.storage.redundancy.degraded Degraded Storage Path Redundancy
vprob.storage.redundancy.lost Lost Storage Path Redundancy
vprob.vmfs.error.volume.is.locked VMFS Locked By Remote Host
vprob.vmfs.extent.offline Device backing an extent of a file system is offline.
vprob.vmfs.extent.online Device backing an extent of a file system is online.
vprob.vmfs.heartbeat.recovered VMFS Volume Connectivity Restored
vprob.vmfs.heartbeat.timedout VMFS Volume Connectivity Degraded
vprob.vmfs.heartbeat.unrecoverable VMFS Volume Connectivity Lost
vprob.vmfs.journal.createfailed No Space To Create VMFS Journal
vprob.vmfs.lock.corruptondisk VMFS Lock Corruption Detected
vprob.vmfs.nfs.server.disconnect Lost connection to NFS server
vprob.vmfs.nfs.server.restored Restored connection to NFS server
vprob.vmfs.resource.corruptondisk VMFS Resource Corruption Detected

Ну а вот так вот будет выглядеть сработавший кастомный аларм в интерфейсе VMware vSphere Web Client:


Таги: VMware, vSphere, Troubleshooting, ESXi

Вышел VMware vSAN 6.6 - что нового? Да много всего!


Осенью прошлого года компания VMware на конференции VMworld Europe 2016 представила новую версию продукта VMware Virtual SAN 6.5, которая была приведена в соответствие с версией vSphere 6.5. На днях, спустя полгода после этого релиза, была представлена обновленная версия этого продукта для создания кластеров хранилищ - VMware vSAN 6.6 (обратите внимание, что он теперь называется не Virtual SAN, а vSAN).

Несмотря на малое продвижение версии, в VMware vSAN 6.6 появилось весьма много новых возможностей:

1. Шифрование.

В vSAN 6.6 появился механизм DARE – Data At Rest Encryption. Несмотря на то, что для ВМ на платформе vSphere 6.5 есть собственное шифрование, ранее для такого сценария не были доступны дедупликация и компрессия. Теперь за счет того, что шифрование vSAN работает на более позднем уровне - эти механизмы экономии дискового пространства теперь поддерживаются.

Кроме того, эта возможность использует механизм AESNI (Advanced Encryption Standard Native Instruction), который есть во всех современных процессорах, что увеличивает производительность. Также появились новые healthchecks касающиеся того, что сервер KMS доступен (не забудьте обеспечить его резервирование), а также хосты поддерживают AESNI.

2. Механизм локальной защиты для растянутых кластеров (vSAN Stretched Clusters).

Теперь средствами политик можно определить уровень защиты как на уровне локального сайта, так и на уровне межсайтового кластера. Для этого теперь есть 2 политики: Primary level of failures to tolerate (PFTT) и Secondary level of failures to tolerate (SFTT). Для растянутого кластера PFTT определяет защиту между площадками, реализуемую по схеме RAID-1. А политика SFTT для растянутого кластера определяет защиту на уровне локального сайта, которая может быть реализована по схеме RAID-1, RAID-5 или RAID-6.

Это, кстати, означает, что при полном отказе одного из сайтов растянутого кластера, виртуальные машины выжившего сайта все еще будут защищены на уровне отдельных хостов или виртуальных дисков. Единственное, что для этого компонент Witness должен быть доступен.

Надо отметить, что администратор не может контролировать, где будут размещаться дисковые объекты ВМ в пределах сайта (то есть не получится обеспечить распределение дублированных копий объектов на уровне серверных стоек одной площадки).

3. Возможность Site Affinity для растянутых кластеров.

Теперь машину можно привязать к определенной площадке для растянутого кластера, но только в том случае, если у нее установлено Primary level of failures to tolerate в значение 0 (то есть она не защищена на уровне кластера vSAN, а администратор сам заботится о средствах ее защиты).

4. Режим Unicast Mode.

Теперь вместо мультикаста используется юникаст для коммуникации между узлами кластера. Как только вы обновите все хосты кластера vSAN да версии 6.6 - он сам переключится на режим Unicast:

Вот этой командой можно проверить режим Ubnicast на узлах кластера:

[root@esxi-dell-j:~] esxcli vsan cluster unicastagent list
NodeUuid IsWitness Supports Unicast IP Address Port Iface Name
------------------------------------ --------- ---------------- ------------ ----- ----------
58d29c9e-e01d-eeea-ac6b-246e962f4ab0 0 true 172.4.0.121 12321
58d8ef12-bda6-e864-9400-246e962c23f0 0 true 172.3.0.123 12321
58d8ef61-a37d-4590-db1d-246e962f4978 0 true 172.3.0.124 12321
00000000-0000-0000-0000-000000000000 1 true 147.80.0.222 12321
[root@esxi-dell-j:~]

5. Больше информации об объектах в интерфейсе.

Если раньше можно было просматривать только объекты VMDK и VM Home, то теперь добавился Swap и объекты дельта-дисков ВМ для снапшотов (см., например, диск с именем Hard disk 9 -vcsa-06.rainpole.com_8.vmdk):

6. Возможности Smart Rebuilds.

В прошлых версиях vSAN никогда не использовал старый компонент, если начиналась процедура ребилда нового. То есть, если хост выходил из строя, например на больше чем 60 минут, то его компоненты уже не могли быть использованы.

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

Также при высоком заполнении дискового пространства (более 80%) дисковые объекты могут разбиваться на более мелкие чанки, чтобы можно было отбалансировать распределение этих кусочков по хостам кластера в целях более эффективного использования дискового пространства.

7. Механизм Partial Repairs.

В прошлых релизах vSAN, если все компоненты объекта не могли быть восстановлены в результате сбоя, то vSAN не начинал процедуру восстановления (Repair). Теперь же процедура восстановления начнется, даже если компоненты объекта доступны лишь частично - это позволяет частично защититься от дальнейших сбоев в кластере, так как часть восстановленных компонентов будет снова задублирована.

8. Функция Resync Throttling.

Это давно ожидаемая фича - она позволяет задать ширину канала для ресинхронизации в Mbps:

Кроме того, был улучшен сам механизм ресинхронизации - раньше он мог начинаться сначала, если был прерван до завершения. Теперь же он всегда продолжается с последнего прерванного момента.

9. Новые пречеки для режима обслуживания.

Теперь перед переводом кластера в режим обслуживания vSAN делает предпроверки на доступную емкость, чтобы не попасть в ситуацию нарушения политик на время обслуживания:

10. Новые пречеки для удаления дисковых групп и дисков.

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

Такая же штука доступна для отдельных дисков. Это можно оказаться очень полезным при апгрейде хранилищ на хостах ESXi:

11. Новый помощник установки и развертывания.

Теперь процедура развертывания кластера vSAN стала значительно проще благодаря улучшенному установщику:

А для проверки конфигурации кластера vSAN появилась утилита "Configuration Assist", которая позволяет убедиться, что все настроено правильно:

12. Средства для проактивного предупреждения ошибок.

Теперь за счет механизма CEIP (Customer Experience Improvement Program) информация о кластере vSAN посылается в VMware, облачные системы которой могут выдавать предварительные предупреждения о возможных проблемах в инфраструктуре хранилищ и рекомендации по их настройке.

13. Интеграция с HTML5 Host Client.

Теперь для кластера vSAN появилась интеграция с клиентом для управления серверами ESXi, где можно, среди прочего, посмотреть состояние различных компонентов узла vSAN:

Также, например, можно прямо из клиента HTML5 управлять средствами дедупликации vSAN.

14. Новые команды ESXCLI.

Были добавлены следующие пространства команд для управления кластером vSAN и его новыми фичами:

  • esxcli vsan debug
  • esxcli vsan health cluster
  • esxcli vsan resync bandwidth
  • esxcli vsan resync throttle

15. Возможность заменить компонент Witness прямо из GUI.

Теперь в интерфейсе для этого появилась специальная кнопка:

Скачать VMware vSAN 6.6 можно по этой ссылке.


Таги: VMware, vSAN, Update

Вышел VMware vCenter Server 6.5b - новый vSphere Client.


Компания VMware выпустила обновление сервера управления виртуальной инфраструктурой - VMware vCenter Server 6.5b. Новых возможностей там три:

  • Последние обновления по временным зонам (time zones) при кастомизации гостевых операционных систем Linux и Windows.
  • Обновленный пакет Oracle (Sun) JRE package версии 1.8.0_12 с поддержкой турецкой временной зоны.
  • Значительно обновленный VMware vSphere Client (бывший HTML5 Client).

Последний пункт как раз и заслуживает внимания. В состав vCenter Server 6.5b вошел vSphere Client версии 6.5 (Build 5178943). Судя по версии билда - это нечто среднее между vSphere Client 3.7 (Build 5168275) и vSphere Client 3.8 (Build 5204615), которые доступны на сайте проекта VMware Labs. То есть, это практически самый свежий клиент.

Тем не менее, у vSphere Client 6.5 на сегодняшний день отсутствует следующая функциональность (подробнее тут):

Функциональная область Рабочий процесс / возможность Не поддерживается в vSphere Client
Cluster Configuration
  • DRS/HA virtual machine overrides
  • Proactive HA
Cluster Datastore
  • Configure SDRS rules and VM overrides
Cluster Monitor
  • Overview performance charts

Content Library

Deploy from template

  • Advanced deploy options
  • Advanced networking template customization

Datastore

Management

  • Datastore default policy read-only view
  • Create NFS 4.1 with Kerberos authentication
  • Create VVOL datastore wizard
  • VVOL datastore default profiles
  • VVOL capability profiles capacity summary portlet
  • Mount and unmount existing VVOL datastore to hosts
  • Register virtual machine
  • Copy, move, rename, and inflate datastore files
  • Change datastore default policy
  • Datastore protocol endpoints
  • Datastore selector advanced mode
  • Datastore capability sets
Distributed Switch Management
  • Add and manage hosts
  • Create new distributed switch
  • Remove distributed switch
  • Manage port groups for batch operations
  • Edit distributed port settings
  • Advanced features: NIOC, NetFlow, port mirror, traffic filtering, LACP, private VLAN
  • Import and export distributed switch and distributed port group
  • Manage physical network adapters for distributed switch

Fault Tolerance

Displays and Operations

  • Fault tolerance operations
  • Fault tolerance summary portlet
  • Migrate secondary workflow
Host Management Host Configuration
  • ESXi two-factor authentication
  • Configure host profiles
Host Management Network Configuration
  • Health checks
  • Edit TCP/IP stacks
  • Migrate VMs to another network

Host Management

Settings

  • Host VVOL protocol endpoints

Host Management

Storage Devices

  • Erase partition
  • Turn locator LED on and off
  • Mark and unmark flash disk

Host Management

Storage Policy

  • Global view
  • Summary view
  • Monitor view
  • Manage view
  • Related items view
  • VM storage policy assignments read-only view
  • Create and edit storage policy wizard
  • Integrate storage policies in deploy OVF wizard
  • Storage policy delete, check compliance, and reapply
  • Reset VSAN default policy
  • Delete storage policy component

Host Storage

iSCSI

  • Hardware iSCSI to IPv6 support
  • Edit advanced options

Host Storage

Management
  • Edit host cache configuration
  • Protocol endpoint properties, paths, and datastores
  • I/O filters

Host Storage

Virtual Flash

  • Resource management
  • Host swap cache configuration
  • Add virtual flash resource capacity
Performance Charts Advanced
  • Select full range of metrics in advanced performance charts
Performance Charts Overview
  • View overview performance charts
  • Select full range of metrics in advanced performance charts
Platform 508 Compliance
  • Initial support

Platform

Actions

  • Action button bar

Platform

Advanced search

  • Search for VMs by compliance status
Platform Docking
  • Drag and drop, close, and restore panes

Platform

Inventory Tree

  • Drag and drop
  • Inline rename
  • Aggregated nodes

Platform

Live Refresh

  • Object navigator live refresh
  • Related lists live refresh
Platform Object Selector
  • Show recent objects

Platform

Portlets

  • Close portlets
Platform Recent Objects View
  • View recent object pane
Platform Related Items Lists
  • Action button bar
  • Filter list
  • Quick filter lists

Platform

Selection Widget

  • Search
Platform Wizards
  • TIWO (Things I am Working On) wizard
  • Sticked workflows (wizard over wizard)

vApp

 

  • All edit and display settings
  • All workflows

VCHA

Management and Deployment

  • All workflows

VM Administration

Compliance

  • Check VM compliance
  • SPBM compliance column in VM list

VM Administration

Deployment

  • Deploy VM from content library wizard

VM Administration

Global Permissions

  • Read only view of global permissions details
  • Create permission
  • Edit existing role of a permission
  • Right click on object to add permission

VM Administration

Profiles

  • Manage VM profiles (including RGs)
  • Batch manage VM profiles

VM Administration

Single Sign-on

  • SSO users and groups
  • SSO configuration

VM Administration

Storage Policies

  • Reapply storage policies for out-of-date VMs
  • Storage policy components view
  • Create and edit storage policy component dialog
  • Delete storage policy component

VM Administration

Summary

  • VM compliance summary portlet

VM Configuration

VM Edit Settings

  • Device configuration options
  • Adding the hardware devices: exist hard disk, RDM disk, floppy drive, serial port, parallel port, host USB device, USB controller, SCSi device, PCI device, SATA controller
  • SDRS rules
  • vApp options
  • Boot options power management
  • Edit advanced settings
  • Remote console options
  • Fibre channel NPIV

VM Configuration

VM Summary

  • Advanced configuration portlet
  • Virtual machine storage policies portlet
  • vApp details portlet
  • Update manager compliance portlet
  • Video card details in hardware portlet

VM Crypt

All

  • All workflows

VM Customization

Image Customization

  • All workflows

VM Deployment

Deploy OVF/OVA

  • Advanced storage
  • Advanced networking
  • Customize template

VM Lists

VMs

  • VM list on vApp
  • Sorting and filtering by column

VM Migration

Drag & Drop

  • Tree to list
  • To and from datastore and datastore cluster
  • To and from standard network, opaque network, or distributed port group

VM Migration

Migrate VM

  • Migration of compute and storage
  • Migration to another VMware vCenter cluster
  • Migration of multiple virtual machines at once

VM Migration

Move To

  • All workflows

VM Operations

Remote Console

  • Changing preferred console from the gear icon

VM Provisioning

New VM

  • Missing devices for hardware customization

VM Provisioning

Register VM

  • UI validations
  • Customize text on page when registering VM template

VM Snapshot

Snapshot Operations

Скачать VMware vCenter Server 6.5b можно по этой ссылке, а Release Notes доступны тут.

Кроме того были выпущены обновления следующих продуктов:

  • VMware Fusion 8.5.5
  • VMware Workstation 12.5.4 для Linux и Windows

Таги: VMware, vCenter, Update, vSphere, Client

Готовый виртуальный модуль VMware ESXi 6.5 Virtual Appliance для тестирования и обучения.


Мы уже немало писали о платформе виртуализации VMware vSphere 6.5, которая стала доступна для загрузки недавно. Оказывается известный блоггер Вильям Лам регулярно создает и поддерживает готовый виртуальный модуль на базе ESXi, а недавно он обновил его до последней версии платформы - VMware ESXi 6.5 Virtual Appliance.

Этот виртуальный модуль в формате OVA создан для того, чтобы развернуть хост-серверы ESXi в виде виртуальных машин на платформе vSphere в целях обучения и тестирования. Помните, что VMware не поддерживает вложенную (nested) виртуализацию в производственной среде.

Вот конфигурация виртуального модуля:

  • GuestType: ESXi 6.5[новое]
  • Virtual Hardware 11 [новое]
  • 2 vCPU
  • 6 GB памяти
  • 2 x VMXNET vNIC
  • 1 x PVSCSI Adapter [новое]
  • 1 x 2GB HDD (под установку самого ESXi)
  • 1 x 4GB SSD (для использования с vSAN, по умолчанию пустой)
  • 1 x 8GB SSD (для использования с vSAN, по умолчанию пустой)
  • Добавлены параметр VHV (подробнее)
  • Добавлены параметры dvFilter Mac Learn в VMX-файл (подробнее)
  • Добавлены параметр disk.enableUUID в VMX-файл
  • VSAN-трафик тэгируется на интерфейсе vmk0
  • Отключенный VSAN device monitoring для целей тестирования (подробнее)
  • При создании нового тома VMFS будет использоваться новая версия VMFS 6 [новое]
  • Включенный sparse swap (подробнее) [новое]

Для запуска виртуального ESXi 6.5 вам потребуется как минимум VMware vSphere 6.0 Update 2. Кстати, а вот какие улучшения появились для виртуального ESXi, которые можно опробовать в версии 6.5:

  • Поддержка Paravirtual SCSI (PVSCSI)
  • GuestOS Customization
  • Поддержка ESXi 6.5 со стороны vSphere 6.0 Update 2
  • Поддержка Virtual NVMe

Скачать виртуальный модуль VMware ESXi 6.5 Virtual Appliance можно по этой ссылке.


Таги: VMware, vSphere, Nested, Blogs, ESXi, VMachines, Virtual Appliance

Размеры разделов и дисков VMDK в VMware vCenter Server Appliance (vCSA) и способ их увеличения.


Как мы уже писали, в новой версии VMware vSphere 6.5 компания VMware существенно улучшила функции виртуального модуля VMware vCenter Server Appliance (vCSA). В частности, в него был добавлен VMware Update Manager (VUM), который по традиции также идет отдельным разделом и диском VMDK, как и остальные сервисы. Расскажем ниже об увеличении раздела диска vCSA, которое описано в статье Вильяма Лама.

Давайте взглянем на таблицу разделов vCSA 6.5, каждому из которых соответствует диск VMDK, в сравнении с vSphere 6.0:

Disk 6.0 Size 6.5 Size Назначение Mount Point
VMDK1 12GB 12GB / and Boot  / and Boot
VMDK2 1.2GB 1.8GB Temp Mount /tmp
VMDK3 25GB 25GB Swap SWAP
VMDK4 25GB 25GB Core  /storage/core
VMDK5 10GB 10GB Log  /storage/log
VMDK6 10GB 10GB DB  /storage/db
VMDK7 5GB 15GB DBLog  /storage/dblog
VMDK8 10GB 10GB SEAT (Stats Events and Tasks)  /storage/seat
VMDK9 1GB 1GB Net Dumper  /storage/netdump
VMDK10 10GB 10GB Auto Deploy  /storage/autodeploy
VMDK11 N/A (Previously InvSrvc 5GB) 10GB Image Builder /storage/imagebuilder
VMDK12 N/A 100GB Update Manager  /storage/updatemgr

Как мы видим, кое-где изменились размеры стандартных разделов, для Image Builder поменялась точка монтирования, а также добавился отдельный раздел VUM на 100 гигабайт, которого не было раньше.

Размер каждого из разделов можно менять на горячую в настройках ВМ, ну а потом нужно из гостевой ОС vCSA расширить раздел на образовавшееся свободное пространство диска. Вот какие изменения произошли в версии vSphere 6.5 на эту тему:

  • Теперь вместо команды vpxd_servicecfg для расширения логического тома нужно использовать следующий скрипт:
    /usr/lib/applmgmt/support/scripts/autogrow.sh
  • Помимо расширения раздела из SSH, это можно сделать через интерфейс Virtual Appliance Management Interface (VAMI) REST API, который можно вызвать удаленно методом POST /appliance/system/storage/resize.

Посмотрим на расширение раздела с Net Dumper (VMDK9) с помощью нового VAMI API.

Выполним команду df -h, чтобы вывести таблицу разделов на vCSA:

Теперь в vSphere Client идем в настройки виртуальной машины vCSA и переходим в раздел управления дисками, где увеличиваем размер девятого виртуального диска с 1 ГБ до 5 ГБ:

Затем идем в браузере по адресу https://[VCSA-HOSTNAME]/apiexplorer, где выбираем пункт "appliance" в разделе Select API и нажимаем кнопку Login, после чего вводим логин/пароль от vCenter Server:

Скроллим до операции POST /appliance/system/storage/resize и раскрываем ее, чтобы увидеть детали:

Теперь нажимаем кнопку "Try it out!" и, в случае успешного выполнения, код ответа (Response Code) будет 200. Также эту же операцию можно выполнить и через PowerCLI:

Connect-CisServer -Server 192.168.1.150 -User administrator@vghetto.local -Password VMware1!
$diskResize = Get-CisService -Name 'com.vmware.appliance.system.storage'
$diskResize.resize()

В итоге, результат будет виден в выводе команды df: раздел, как и виртуальный диск VMDK, увеличился до 5 ГБ:


Таги: VMware, vCSA, VAMI, VMDK, Storage, vCenter, Обучение, Blogs

Возможность Sparse Swap в VMware Virtual SAN 6.2 - как сэкономить кучу байтов


Среди возможностей решения для создания отказоустойчивых хранилищ VMware Virtual SAN 6.2 мы забыли упомянуть о нововведении в части обработки файлов подкачки - Sparse Swap.

Как вы знаете при создании виртуальной машины в обычной инфраструктуре под нее резервируется файл *.vswp, который равен по размеру объему сконфигурированной оперативной памяти виртуальной машины (либо объему незарезервированной памяти, то есть разнице между сконфигурированной и зарезервированной памятью, если она указана в настройке reservation). Это нужно на случай, когда машине не хватает свободной физической памяти (в ситуации, если уже не спасают техники memory overcommit), и она начинает сбрасывать страницы памяти в своп-файл на диске.

То есть, если вы создали ВМ с оперативной памятью 4 ГБ, то столько же займет и файл подкачки для этой ВМ. А теперь посмотрим на инфраструктуру Virtual SAN: если у вас задан параметр FTT=1, то каждый дисковый объект (в том числе и файл *.vswp) будет задублирован (если у вас mirror-конфигурация).

Теперь посчитаем, сколько места съест своп 100 виртуальных машин, у каждой из которых 4 ГБ оперативной памяти и которые размещены в кластере VMware Virtual SAN с FTT=1 в зеркальной конфигурации:

100 ВМ * 4 ГБ * 2 (FTT равен 1) = 800 ГБ

Да, именно так - почти терабайт только под своп. Кому-то это покажется расточительством, поэтому в Virtual SAN сделали такую штуку, как Sparse Swap. Эта функция позволяет создавать файлы подкачки vswp как тонкие, то есть растущие по мере наполнения данными, диски.

Для того, чтобы включить опцию Sparse Swap, нужно выполнить следующую команду на хосте VMware ESXi:

esxcfg-advcfg -s 1 /VSAN/SwapThickProvisionDisabled

Ну а вот тут вы можете найти PowerCLI-скрипт для автоматизации применения этой настройки и отката назад.


Таги: VMware, vSphere, Virtual SAN, VSAN, Storage, VMachines

Что будет, если изменять Memory Reservation работающей виртуальной машины?


Как вы знаете, после запуска виртуальной машины на платформе VMware vSphere, в папке с машиной создается файл *.vswp, который предназначен для свопирования памяти ВМ в критической ситуации. Если у машины проявляется нехватка памяти на хосте VMware ESXi, и она не получает ее через механизм Memory Ballooning, то страницы памяти начинают сбрасываться в этот vswp-файл. Это самая плохая ситуация, так как структурная организация этого файла и то, как понимает своп операционная система, две большие разницы, а значит скорость работы существенно замедляется не только из-за того, что работа идет с диском вместо RAM, но еще и уходит время на поиск нужных страниц.

Соответственно, если у машины 4 ГБ оперативной памяти, то размер vswp-файла также 4 ГБ:

Если мы меняем Memory Reservation для виртуальной машины, то ее файл подкачки уменьшается на величину этого резерва - так как физическая память закрепляется за машиной и не возникнет условий, когда эту часть потребуется свопировать.

Но если сделать Memory Reservation для работающей ВМ (в данном случае 2 ГБ), то размер файла подкачки останется прежним:

Для того, чтобы vswp-файл уменьшился на величину Memory Reservation, надо перезагрузить ВМ - тогда он станет размером 2 ГБ:

Напомним, что у выключенной машины vswp-файла нет.

Но что если у включенной машины убрать (или изменить) Memory Reservation? Все просто - он автоматически увеличится до размера незарезервированной памяти ВМ. Убираем резерв в 2 ГБ и файл вырастает до 4 ГБ:

Ну и напомним формулу:

Swap (.vswp) file size = VM Configured Memory – VM reserved memory


Таги: VMware, vSphere, Memory, VMachines, Blogs

Небольшой гайд по использованию VMware Virtual Flash в vSphere 5.5.


Некоторое время назад мы писали о технологии VMware vFlash (она же Virtual Flash), которая позволяет использовать высокопроизводительные накопители SSD (вот тут - о производительности) для решения двух важных задач:

  • Предоставление виртуальным машинам дополнительного места, в которое будут свопиться страницы памяти в случае недостатка ресурсов на хосте (это намного более производительно, чем свопить на обычный HDD-диск). Эта техника называется Virtual Flash Host Swap и пришла на смену механизму Swap to SSD.
  • Прозрачное встраивание в поток ввода-вывода на хосте между виртуальными машинами и хранилищами, что позволяет существенно ускорить операции чтения данных виртуальных дисков. Называется это VMware Flash Read Cache (vFRC).

Ниже мы вкратце расскажем о настройке этих двух механизмов через VMware vSphere Web Client (в обычном C#-клиенте этого, к сожалению, нет). Если что, более подробно о технике vFRC можно почитать по этой ссылке.

Итак, в vSphere Web Client переходим на вкладку "Manage" для нужного хоста, далее в разделе "Settings" выбираем пункт "Virtual Flash Resource Management". Это кэш, который мы добавляем для того, чтобы в случае нехватки места, его могли использовать виртуальные машины, чтобы не свопить данные на медленный магнитный диск, кроме того он же будет использоваться для целей vFRC.

Нажимаем Add Capacity:

Выбираем диски, которые мы будем использовать как Host Swap и нажимаем "Ок" (все данные на них будут стерты):

Всего под нужды Virtual Flash может быть выделено до 8 дисков суммарной емкостью до 32 ТБ. Видим, что ресурс добавлен как Virtual Flash Resource (его емкость отдельно учитывается для vFRC и Host Cache):

Настройка Virtual Flash Host Swap

Первым делом рекомендуется настроить именно этот кэш, а остаток уже распределять по виртуальным машинам для vFRC.

Выбираем пункт "Virtual Flash Host Swap Cache Configuration" в левом меню, а далее в правой части мы нажимаем кнопку "Edit":

Указываем необходимый объем, который планируется использовать, и нажимаем "Ок":

После того, как мы настроили нужное значение - в случае недостатка ресурсов на хосте виртуальные машины будут использовать высокоскоростные диски SDD для своих нужд внутри гостевой ОС (файлы подкачки прочее).

Настройка VMware Flash Read Cache (vFRC)

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

Сам кэш vFRC можно настроить на уровне отдельных виртуальных машин на хосте VMware ESXi, а также на уровне отдельных виртуальных дисков VMDK.

Чтобы выставить использование нужного объема vFRC для отдельной виртуальной машины, нужно выбрать пункт "Edit Settings" из контекстного меню ВМ и на вкладке "Virtual Hardware" в разделе "Virtual Flash Read Cache" установить нужное значение для соответствующего виртуального диска:

Если этого пункта у вас нет, то значит у вас версия виртуального "железа" (Virtual Machine Hardware) ниже, чем 10, и ее нужно обновить.

По ссылке "Advanced" можно настроить размер блока для кэша (значение Reservation, установленное тут, обновит значение на предыдущем скрине):

Чтобы понять, какие значения SSD-кэша можно и нужно выставлять для виртуальных машин, рекомендуется почитать документ "Performance of vSphere Flash Read Cache in VMware vSphere 5.5".

 


Таги: VMware, Cache, vFRC, vSphere, Performance, VMachines, Storage, SSD

Самообслуживание с помощью Cisco UCS Director: как дать пользователям возможность самостоятельно создавать виртуальные сервера.


В этом посте специалисты компани ИТ-ГРАД расскажут о решении Cisco UCS Director и покажут как сделать так, чтобы конечные пользователи могли самостоятельно сформировать запрос на портале самообслуживания Cisco UCS Director и автоматически получить готовую виртуальную машину.

Для этого мы с вами научимся создавать наборы политик и объединять несколько политик в группу в рамках vDC, а также создадим каталог (шаблон) на базе этих политик, чтобы предоставить пользователям доступ к этому каталогу через портал самообслуживания.

Начнем с инфраструктуры. Инфраструктура, на базе которой мы будем выполнять все настройки, состоит из:

  • NetApp Clustered DataONTAP 8.2 Simulator в качестве дискового массива;
  • виртуальной инфраструктуры развернутой на базе:
  • ESXi appliance 5.5.0;
  • vCenter appliance 5.5.0a.

Выглядит это примерно так:

Сразу отмечу, что все настройки политик и параметров для шаблона(ов) виртуальных машин в нашем посте будут относиться к VMWare vSphere инфраструктуре..Читать статью далее


Таги: IT-Grad, Cisco, UCS, Hardware, Cloud, Cloud Computing, Обучение, VMware, vSphere

Как вернуть SSD-накопитель, который был создан как устройство vFlash, хосту VMware ESXi.


Достаточно давно мы писали о технологии VMware vFlash (теперь она называется vSphere Flash Read Cache), которая пришла на смену технологии Swap-to-SSD - она позволяет использовать локальные SSD-диски хостов VMware ESXi для задач кэширования. Напомним, что Flash Read Cache позволяет использовать кэширование данных только на чтение для дисков VMDK виртуальных машин, работает она на уровне гипервизора и существенно улучшает производительность виртуальных машин, которые интенсивно используют подсистему ввода-вывода для операций на чтение.

Очевидно, что SSD-кэш, который по производительности находится между оперативной памятью и обычными дисками, существенно повышает быстродействие в системах, где периодически наблюдается недостаток ресурсов RAM. Все это дело работает в кластере до 32 хостов ESXi.

Однако, иногда вам может понадобиться вернуть SSD-накопитель хосту ESXi, чтобы использовать его для других задач. Можно попробовать отключить использование ресурсов vFlash для всех виртуальных машин хоста, затем пойти в раздел "Virtual Flash Resource Management" и выбрать опцию "Remove All" - но это не сработает. Появятся следующие ошибки:

Host’s virtual flash resource is inaccessible.
The object or item referred to could not be found.

Чтобы вернуть диск SSD снова в строй понадобится удалить специальный раздел - vFlash File System partition. Для этого нужно сначала его найти. Выполняем команду:

ls /vmfs/devices/disks

Тут мы видим нашу SSD-партицию (видим в середине буквы "SSD" - не ошибитесь - нам нужен раздел без ":1"):

disk ID “t10.ATA_____M42DCT032M4SSD3__________________________00000000121903600F1F”

Сносим эту партицию с помощью утилиты partedutil, используя найденный Disk ID:

partedutil delete "/vmfs/devices/disks/t10.ATA_____M42DCT032M4SSD3__________________________00000000121903600F1F" 1

Что-то вроде этого:

После чего мы видим, что диск SSD освободился и его можно использовать на хосте VMware ESXi:

Источник.


Таги: VMware, ESXi, SSD, Storage, vFlash, Blogs

3D-ускорение VDI на практике (NVIDIA GRID). ТЕСТЫ. Часть 1.


Отсутствие аппаратного ускорения графики является существенным препятствием при внедрении технологий виртуализации в компаниях, работающих в сфере дизайна, проектирования, конструкторских разработок и пр. Рассмотрим, какие новые возможности появились с выходом адаптеров, предназначенных специально для работы с 3D-графикой NVIDIA GRID. Классный пост компании ИТ-ГРАД - с реальными тестами.


Таги: NVIDIA, GRID, VDI, IT Grad, VMware, Citrix, Performance

Сайзинг кластеров хранилищ VMware VSAN в VMware vSphere и их отказоустойчивость.


Как многие знают, в VMware vSphere 5.5 появились возможности Virtual SAN, которые позволяют создать кластер хранилищ для виртуальных машин на основе комбинации SSD+HDD локальных дисков серверов VMware ESXi. Не так давно вышла обновленная бета этого решения, кроме того мы не так давно писали о производительности VSAN тут и тут.

Сегодня же мы поговорим о том, как нужно сайзить хранилища Virtual SAN в VMware vSphere, а также немного затронем тему отказоустойчивости. Более детальную информацию можно найти в VMware Virtual SAN Design & Sizing Guide, а ниже мы расскажем о подходе к планированию хранилищ VSAN вкратце.

Объекты и компоненты Virtual SAN

Начнем с простого ограничения по объектам (objects) и компонентам (components), которое есть в VSAN. Виртуальные машины, развернутые на vsanDatastore, могут иметь 4 типа объектов:

  • Домашняя директория виртуальной машины Virtual Machine ("namespace directory").
  • Объект файла подкачки - swap object (для включенной ВМ).
  • Виртуальный диск VMDK.
  • Дельта-диски для снапшотов. Каждый дельта-диск - это отдельный объект.

Каждый объект, в зависимости от типа RAID, рождает некоторое количество компонентов. Например, один VMDK, размещенный на двух томах страйпа (RAID 0) рождает два объекта. Более подробно об этом написано вот тут.

Так вот, ограничения тут следующие:

  • Максимальное число компонентов на 1 хост ESXi: 3000.
  • Максимальное число компонентов для одного объекта: 64 (это включает в себя тома страйпов и также реплики VMDK с других хостов).

На практике эти ограничения вряд ли актуальны, однако о них следует знать.

Сколько дисков потребуется для Virtual SAN

Во второй бета-версии VSAN (и, скорее всего, так будет в релизной версии) поддерживается 1 SSD-диск и до 7 HDD-дисков в одной дисковой группе. Всего на один хост VMware ESXi поддерживается до 5 дисковых групп. Таким образом, на хосте поддерживается до 5 SSD-дисков и до 35 HDD-дисков. Надо убедиться, что контроллеры хоста поддерживают необходимое количество дисков, а кроме того нужно проверить список совместимости VSAN HCL, который постоянно пополняется.

Также надо учитывать, что кластер хранилищ Virtual SAN поддерживает расширение как путем добавления новых дисков, так и посредством добавления новых хостов в кластер. На данный момент VMware поддерживает кластер хранилищ максимум из 8 узлов, что суммарно дает емкость в дисках в количестве 40 SSD (1*5*8) и 280 HDD (7*5*8).

Сколько дисковой емкости нужно для Virtual SAN (HDD-диски)

Необходимая емкость под размещение VMDK зависит от используемого параметра FailuresToTolerate (по умолчанию 1), который означает, какое количество отказов хостов может пережить кластер хранилищ. Если установлено значение 1, то реплика одного VMDK будет размещена на дисках еще одного из хостов кластера:

Тут можно сказать о том, как работает отказоустойчивость кластера Virtual SAN. Если отказывает хост, на котором нет виртуальной машины, а есть только VMDK или реплика, то виртуальная машина продолжает работу с основной или резервной копией хранилища. В этом случае начнется процесс реконструкции реплики, но не сразу - а через 60 минут, чтобы дать время на перезагрузки хоста (то есть если произошел не отказ, а плановая или внеплановая перезагрузка), а также на короткие окна обслуживания.

А вот если ломается хост, где исполняется ВМ - начинается процедура восстановления машины средствами VMware HA, который перезапускает ее на другом хосте, взаимодействуя при этом с Virtual SAN.

Более подробно этот процесс рассмотрен вот в этой статье и вот в этом видео:

Однако вернемся к требующейся нам емкости хранилищ. Итак, если мы поняли, что значит политика FailuresToTolerate (FTT), то требуемый объем хранилища для кластера Virtual SAN равняется:

Capacity = VMDK Size * (FTT + 1)

Что, в принципе, и так было очевидно.

Сколько дисковой емкости нужно для Virtual SAN (SSD-диски)

Теперь перейдем к SSD-дискам в кластере VSAN, которые, как известно, используются для вспомогательных целей и не хранят в себе данных виртуальных машин. А именно, вот для чего они нужны (более подробно об этом тут):

  • Read Cache - безопасное кэширование операций на чтение. На SSD-диске хранятся наиболее часто используемые блоки, что уменьшает I/O read latency для ВМ.
  • Write Buffering - когда приложение внутри гостевой ОС пытается записать данные, оно получает подтверждение записи тогда, когда данные фактически записаны на SSD (не на HDD), таким образом твердотельный накопитель используется как буфер на запись, что небезопасно при внезапном пропадании питания или отказе хоста. Поэтому данные этого буфера дублируются на других хостах кластера и их SSD-дисках.

Так каковы же рекомендации VMware? Очень просты - под SSD кэш и буфер неплохо бы выделять 10% от емкости HDD-дисков хоста. Ну и не забываем про значение FailuresToTolerate (FTT), которое в соответствующее число раз увеличивает требования к емкости SSD.

Таким образом, необходимая емкость SSD-хранилищ равна:

Capacity = (VMDK Size * 0.1) * (FTT + 1)

Ну и напоследок рекомендуем отличнейший список статей на тему VMware Virtual SAN:


Таги: VMware, Virtual SAN, VSAN, vSphere, ESXi, Storage, Sizing, Blogs

Новые возможности VMware vSphere 5.5 - официально.


Не так давно мы уже писали о планируемых новых возможностях VMware vSphere 5.5, однако большинство новых функций были описаны в общих чертах, кроме того, до последнего момента так и не было окончательно известно, что же еще нового появится в vSphere 5.5. На проходящей сейчас конференции VMworld 2013 компания VMware наконец-то объявила о выходе обновленной платформы VMware vSphere 5.5, которая стала еще более мощным средством для построения виртуальных инфраструктур.


Таги: VMware, vSphere, Update, ESXi, vCenter, vNetwork, Storage, VMachines, VMFS

Очередные таблицы сравнения VMware vSphere 5.1 и Microsoft Hyper 2012 R2.


Вот и стали появляться первые сравнения платформ виртуализации VMware vSphere 5.1 и еще невышедшего Microsoft Hyper 2012 R2 (в составе Windows Server 2012 R2). О сильных и слабых сторонах продуктов мы уже давно не спорим, так как дело это пустое, а вот таблички из статьи, содержащие немало фактического материала, спорщикам пригодятся.

Итак, что мы имеем в плане максимальных параметров, вычислительных ресурсов и масштабирования:

System Resource Microsoft Hyper-V 2012 VMware vSphere 5.1
Free Hypervisor Essential Plus Enterprise Plus
Host Logical Processors 320 160 160 160
Physical Memory 4 TB 32 GB 2 TB 2 TB
Virtual CPUs per Host 2048 2048 2048 2048
Nested Hypervisor No Yes Yes Yes
VM Virtual CPUs per VM 64 8 8 64
Memory per VM 1 TB 32 GB 1 TB 1 TB (max 64GB with FT)
Maximum Virtual Disk 64 TB 2 TB 2 TB 2 TB
Hot-Add Only disks Disks/vNIC/USB Disks/vNIC/USB All
Active VMs per Host 1024 512 512 512
Cluster Maximum Nodes 64 N/A 32 32
Maximum VMs 8000 N/A 4000 4000

Сравнение vSphere 5.1 и Hyper-V 2012 R2 в плане хранилищ (Storage):

Capability Microsoft Hyper-V 2012 VMware vSphere 5.1
Free Hypervisor Essential Plus Enterprise Plus
Thin disks Yes (dynamic disks) Yes Yes Yes
Differential disks Yes No (only with API) No (only with API) No (only with API)
SAN
iSCSI/FC iSCSI/FC iSCSI/FC iSCSI/FC
NAS SMB 3.0 NFS 3 over TCP NFS 3 over TCP NFS 3 over TCP
Virtual Fiber Channel Yes Yes Yes Yes
3rd Party Multipathing (MPIO) Yes No No Yes
Native 4-KB Disk Support Yes No No No
Maximum Virtual Disk Size 64TB VHDX 2TB VMDK 2TB VMDK 2TB VMDK
Maximum Pass Through Disk Size 265TB+ 64TB 64TB 64TB
Storage Offload Yes (ODX) No No Yes (VAAI)
Storage Virtualization
No (only 3rd part) No (only 3rd part) VSA VSA (limited to 3 nodes)
Storage Encryption Yes No No No
Caching Yes (CSV read-only cache) Swap to host cache Swap to host cache Swap to host cache

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

Capability Microsoft Hyper-V 2012 VMware vSphere 5.1
Free Hypervisor Essential Plus Enterprise Plus
NIC Teaming Yes Yes Yes Yes
Extensible Switch Yes No No Replaceable
PVLAN Support Yes No No Yes (only with DVS)
ARP/ND Spoofing Protection Yes No No vCNS/Partner
DHCP Snooping Protection Yes No No vCNS/Partner
Virtual Port ACLs Yes No No vCNS/Partner
Trunk Mode to Virtual Machines Yes No No No
Port Monitoring Yes Per Port Group Per Port Group Yes
Port Mirroring Yes Per Port Group Per Port Group Yes
Dynamic Virtual Machine Queue Yes NetQueue NetQueue NetQueue
IPsec Task Offload Yes No No No
SR-IOV Yes Yes (No Live Migration support) Yes (No Live Migration support) Yes (No Live Migration support)
Network Virtualization Yes No No VXLAN
Quality of Service Yes No No Yes
Data Center Bridging (DCB) Yes Yes Yes Yes

О том, что лучше - VMware vSphere или Microsoft Hyper-V, можно рассуждать бесконечно, но однозначно можно сказать только одно - Hyper-V год от года становится значительно функциональнее, а вот VMware основные усилия по улучшению продукта направляет только на издание Enterprise Plus, купить которое не каждой компании по средствам.


Таги: VMware, vSphere, Microsoft, Hyper-V, Сравнение, Server

Почти бесполезно, но интересно - параметр Mem.MinFreePct в конфигурации VMware vSphere и оптимизация памяти.


Недавно Duncan Epping опубликовал интересную статью о параметре Mem.MinFreePct, который есть в настройках сервера VMware ESXi из состава vSphere. По-сути, этот параметр определяет, какое количество оперативной памяти VMkernel должен держать свободным на хосте, чтобы всегда были доступные ресурсы под нужды системы, и хост не вывалился в PSOD.

В VMware vSphere 4.1 параметр Mem.MinFreePct составлял 6% и его можно было изменять с помощью следующей команды:

vsish -e set /sched/freeMemoryState/minFreePct <Percentage>

Например, вот так можно было установить Mem.MinFreePct в значение 2%:

vsish -e set /sched/freeMemoryState/minFreePct 2

Этак команда, кстати, не требует перезагрузки, но зато после перезагрузки значение Mem.MinFreePct не сохраняется. Поэтому данную команду, если требуется, нужно занести в /etc/rc.local (подробнее в KB 1033687).

Параметр этот очень важный, поскольку от него зависят пороги использования различных механизмов оптимизации памяти хоста ESXi. При этом, если памяти на хосте много (например, десятки гигабайт), то держать постоянно 6% свободной памяти может быть для кого-то расточительством. Поэтому, начиная с VMware vSphere 5.0, параметр Mem.MinFreePct является "плавающим" и устанавливается в зависимости от объема физической памяти на хосте ESXi.

Вот какие значения принимает Mem.MinFreePct в зависимости от того, сколько RAM есть на вашем физическом хост-сервере:

Процент необходимой свободной памяти
Объем памяти хоста ESXi
6% 0-4 ГБ
4% 4-12 ГБ
2% 12-28 ГБ
1% Больше 28 ГБ

А вот какие механизмы оптимизации памяти на хосте работают, если свободной памяти становится все меньше и меньше:

Состояние свободной памяти хоста Пороговое значение Какие механизмы оптимизации памяти используются
High 6% -
Soft 64% от значения MinFreePct Balloon, Compress
Hard 32% от значения MinFreePct Balloon, compress,swap
Low 16% от значения MinFreePct Swap

Интересно, конечно, но как-то бесполезно. Зачем загонять хост в такие лимиты? Лучше как минимум процентов 10 всегда держать свободными и своевременно покупать новые серверы.


Таги: VMware, vSphere, Memory, ESXi, Blogs

Memory Overhead виртуальных ПК на платформе VMware Horizon View 5.2.


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

Для начала отметим, что на платформе VMware Horizon View 5.2 появились следующие изменения по сравнению с предыдущими версиями в плане графических режимов виртуальных ПК:

  • Horizon View 5.2 не позволяет установить 24-битную цветовую палитру, теперь используется только 32-битная.
  • Horizon View 5.2 позволяет устанавливать разрешения только 1680×1050, 1920×1200 и 2560×1600. Дефолтным является 1920×1200.

Теперь о накладных расходах по памяти для виртуальных машин.

3D Software Rendering отключен

В этом случае расходы дополнительной памяти сервера на виртуальный ПК зависят от используемого разрешения и количества мониторов для виртуальной машины (значения приведены в мегабайтах):

Затраты памяти Число мониторов
Разрешение/Мониторы 1 2 3 4
1680×1050 6.73 21.54 32.30 43.07
1920×1200 8.79 28.13 42.19 56.25
2560×1600 31.25 62.5 93.75 125

Как вы знаете, в ESXi 5.0 появились возможности VMX Swap, которые позволяют создать swap-файл для сегментов данных процесса vmx, куда сбрасываются страницы памяти, но только в случае нехватки физической оперативной памяти на хосте. Он в разы уменьшает использование физической памяти на Overhead виртуальных машин в случае недостатка ресурсов.

Затраты хранилищ (в мегабайтах) на создание второго *.vswp файла для механизма VMX Swap рассчитываются следующим образом:

VMX SWAP Число мониторов
Разрешение/Мониторы 1 2 3 4
1680×1050 107 163 207 252
1920×1200 111 190 248 306
2560×1600 203 203 461 589

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

3D Software Rendering включен

Для виртуальных ПК отдельно или в пределах пула можно установить объем видеопамяти (VRAM, не путать с vRAM) доступный гостевой системе, что влияет на накладные расходы на виртуализацию.

В этом случае дополнительно требуемая физическая память будет рассчитываться как 64 МБ + 16 дополнительных МБ на каждый монитор.

Что касается SWAP-файла, то требуемый для него объем существенно выше, чем в первом случае. Он зависит от выделенной видеопамяти:

VRAM .vswp (МБ)
64 MB 1076
128MB 1468
256MB 1468
512MB 1916

То есть, в некоторых случаях дополнительные затраты на хранилище отдельной виртуальной машины могут достигать 2 ГБ. Чтобы это все учитывать при планировании инфраструктуры виртуальных ПК, можно воспользоваться калькулятором от Andre Leibovici, по материалам которого и написана эта заметка.


Таги: VMware, View, Memory, Enterprise, Blogs, vSphere, ESXi, VMachines

Технология Virtual Flash (vFlash) для SSD-накопителей в VMware vSphere.


Как многие знают, с выходом VMware vSphere 5.1 компания VMware объявила о нескольких новых начинаниях в сфере хранения данных виртуальных машин, таких как концепция vVOL для хранилищ vSphere и сервисы распределенного хранения VMware Distributed Storage (концепция vSAN).

Кроме того, не так давно были воплощены в жизнь такие полезные службы 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)
  • Режим работы кэша (write-back или write-thru)
  • Размер блока (настраивается в зависимости от гостевой ОС)
  • Что делать с кэшем при перемещении виртуальной машины посредством vMotion (перенести вместе с ней или удалить)

При vMotion сервер vCenter будет проверять наличие необходимых ресурсов кэширования для виртуальной машины на целевом хосте ESXi. Для совместимости с технологией VMware HA, виртуальная машина должна будет иметь доступные vFlash-ресурсы на хранилищах хостов в случае сбоя (соответственно, потребуется эти ресурсы гарантировать).

В целом vFlash в VMware vSphere обещает быть очень перспективной технологией, что особенно актуально на волне роста потребления SSD-накопителей, постепенно дешевеющих и входящих в повсеместное употребление.


Таги: VMware, vSphere, vFlash, SSD, Storage, ESXi

8 фактов о файлах подкачки виртуальных машин на платформе VMware vSphere (Virtual Machine Swap File - vswp).


Мы уже не раз затрагивали тему vswp-файлов виртуальных машин (файлы подкачки), которые используются для организации swap-пространства гипервизором VMware ESXi. Эти файлы выполняют роль последнего эшелона среди техник оптимизации памяти в условиях недостатка ресурсов на хосте. Напомним, что в гипервизоре VMware ESXi есть такие техники как Transparent Page Sharing, Memory Ballooning, a также Memory Compression, которые позволяют разбираться с ситуациями нехватки памяти, необходимой виртуальным машинам.

Напомним также, что первым эшелоном оптимизации памяти является техника Memory Ballooning. Она работает за счет использования драйвера vmmemctl.sys (для Windows), поставляемого вместе с VMware Tools. Он позволяет "надуть" шар внутри гостевой ОС (balloon), который захватывает физическую память, выделенную этой ОС (если ее много), и отдает ее другим гостевым операционным системам, которые в ней нуждаются. Этот balloon не позволяет гостевой ОС производить работу приложений с данной областью памяти, поэтому если им потребуется дополнительная память - она будет уходить в гостевой своп. Это более правильный подход, чем свопировать гостевую ОС в файл подкачки vswp на томе VMFS, поскольку операционная система сама лучше разбирается, что и когда ей класть и доставать из свопа (соответственно, быстродействие выше).

Однако, когда памяти у всех виртуальных машин совсем мало или отдельной ВМ ее требуется больше, чем сконфигурировано, а также происходит постоянное обращение к памяти (особенно, если в гостевых ОС нет VMware Tools), гипервизор начинает использовать vswp-файл подкачки, который по умолчанию находится в папке с виртуальной машиной. Мы уже писали о том, что в целях повышения быстродействия можно положить vswp-файлы виртуальных машин на локальные SSD-хранилища серверов ESXi, а также о том, как удалять мусорные файлы vswp.

Ниже мы приведем 8 фактов о swap-файлах виртуальных машин, которые основаны на вот этой заметке Фрэнка Деннемана:

1. Хранение vswp-файлов на локальных дисках сервера ESXi (в том числе Swap to Host Cache) увеличивает время vMotion. Это очевидно, так как приходится копировать vswp-файл в директорию ВМ (или другую настроенную директорию), чтобы его видел целевой хост.

2. С точки зрения безопасности: vswp-файл не чистится перед созданием. То есть там лежат не нули, а предыдущие данные блоков. Напоминаем, что размер файла подкачки равен размеру сконфигурированной памяти ВМ (если не настроен Reservation). Если же у машины есть Reservation, то размер vswp-файла определяется по формуле:

Configured memory – memory reservation = size swap file

То есть, если в настройках памяти машины ей выделено 4 ГБ, а Reservation настроен в 1 ГБ, то vswp-файл будет составлять 3 ГБ.

3. Как происходит копирование vswp-файла при vMotion? Сначала создается новый vswp-файл на целевом хосте, а потом копируются только swapped out страницы с исходного в целевой vswp-файл.

4. Что происходит при разнице в конфигурации размещения vswp-файлов в кластере и для отдельных хостов? Напомним, что в настройках кластера VMware vSphere есть 2 опции хранения vswp-файлов: в папке с ВМ (по умолчанию) и в директории, которая указана в настройках хоста:

Если на одном хосте настроена отдельная директория для vswp, а на другом нет (то есть используется папка ВМ), то при vMotion такой виртуальной машины vswp-файл будет скопирован (в папку с ВМ), несмотря на то, что целевой хост видит эту директорию на исходном.

5. Обработка файлов подкачки при нехватке места. Если в указанной директории не хватает места для свопа ВМ, то VMkernel пытается создать vswp-файл в папке с ВМ. Если и это не удается, то виртуальная машина не включается с сообщением об ошибке.

6. vswp-файл лучше не помещать на реплицируемое хранилище. Это связано с тем, что используемые страницы памяти, находящиеся в двух синхронизируемых файлах, будут постоянно реплицироваться, что может вызывать снижение производительности репликации, особенно если она синхронная и особенно при vMotion в недефолтной конфигурации (когда происходит активное копирование страниц и их репликация):

7. Если вы используете снапшоты на уровне хранилищ (Datastore или LUN), то лучше хранить vswp-файлы отдельно от этих хранилищ - так как в эти снапшоты попадает много ненужного, содержащегося в своп-файлах.

8. Нужно ли класть vswp-файлы на хранилища, которые развернуты на базе thin provisioned datastore (на уровне LUN)? Ответ на этот вопрос зависит от того, как вы мониторите свободное место на тонких лунах и устройствах своего дискового массива. При создании vswp-файла VMkernel определяет его размер и возможность его создания на уровне хоста ESXi, а не на уровне устройства дискового массива. Поэтому если vswp-файл активно начнет использоваться, а вы этого не заметите при неправильной конфигурации и отсутствии мониторинга тонких томов - то могут возникнуть проблемы с их переполнением, что приведет к сбоям в работе ВМ.


Таги: VMware, vSphere, VMachines, Storage, swap, VMFS, Blogs, ESXi

Список политик безопасности для серверов VMware ESX/ESXi в vGate R2 и рекомендации по их применению.


Многие из вас уже знакомы с сертфицированным средством vGate R2, которое предназначено для защиты виртуальной инфраструктуры VMware vSphere средствами политик безопасности для хост-серверов и виртуальных машин, а также за счет механизма защиты от несанкционированного доступа. Сегодня мы детально рассмотрим существующие в vGate R2 политики безопасности и опишем некоторые рекомендации по их применению.


Таги: vGate, Security, VMware, vSphere, ESX, ESXi, vCenter

Memory Overhead виртуальных машин в VMware vSphere и возможности VMX Swap.


Как известно, виртуализация требует дополнительных ресурсов сверх тех, которые потребляет непосредственно виртуальная машина. Это называют накладными расходами на виртуализацию (так называемый virtualization overhead). Оверхэд есть как для процессора (примерно 3-5 процентов на хост-сервере), так и для оперативной памяти.

При этом для оперативной памяти накладные расходы гипервизора зависят от количества виртуальных процессоров (vCPU) и объема оперативной памяти, выделенных виртуальной машине. Мы уже писали о накладных расходах по RAM для виртуальных машин в VMware vSphere 4, где использовались следующие средние значения:

Информация эта взята из vSphere 4.0 Online Library.

В VMware vSphere 5 есть новая возможность, которая называется VMX Swap. При включении виртуальной машины гипервизор ESXi создает для нее vmx-процесс, управляющий различными структурами данных, под которые требуется физическая оперативная память. Ее объем, как было сказано, зависит от конфигурации ВМ - количества vCPU и RAM. Для снижения потребления этой памяти в ESXi 5.0 механизм VMX Swap создает swap-файл для сегментов данных процесса vmx, куда сбрасываются страницы памяти, но только в случае нехватки физической оперативной памяти на хосте.

VMX Swap создает файлы подкачки в директории с виртуальной машиной, через который и происходит загрузка и выгрузка страниц процесса vmx. Размещение этих файлов можно переопределить, добавив следующий параметр в расширенные настройки виртуальной машины:

sched.swap.vmxSwapDir

По умолчанию механизм VMX Swap включен и в критических ситуациях позволяет уменьшить overhead типичной виртуальной машины с 50 МБ до 10 МБ. Для виртуализации серверов такие порядки цифр может и не очень важны, зато для виртуализации настольных ПК (например, VMware View), где на одном сервере могут находиться десятки и даже сотни виртуальных машин, эта возможность может оказаться весьма кстати в условиях нехватки вычислительных ресурсов.

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

sched.swap.vmxSwapEnabled

Ну а теперь посмотрим сколько оверхэда по памяти потребляет виртуальная машина уже в VMware vSphere 5 с включенным по умолчанию VMX Swap:

20.29 24.28 32.23 48.16
25.90 29.91 37.86 53.82
48.64 52.72 60.67 76.78
139.62 143.98 151.93 168.60

Эта информация уже из vSphere 5 Documentation Center. Как мы видим из таблицы, накладные расходы по памяти с учетом VMX Swap уже значительно меньше (в некоторых случаях до 8-9 раз). Как уверяют коллеги из VMware, в условиях недостатка ресурсов VMX Swap почти не влияет на производительность хост-сервера ESXi, ну а в условиях достатка - не влияет совсем.


Таги: VMware, vSphere, Memory, Performance, ESXi

Залоченные файлы виртуальной машины в VMware vSphere - Could not power on VM: Lock was not free.


При эксплуатации виртуальной инфраструктуры VMware vSphere иногда случается ситуация, когда виртуальную машину нельзя включить из-за того, что ее какой-нибудь из ее файлов оказывается залоченным. Происходит это при разных обстоятельствах: неудачной миграции vMotion / Storage vMotion, сбоях в сети хранения и прочих.

Наиболее распространенная ошибка при этом выглядит так:

Could not power on VM: Lock was not free

Встречаются также такие вариации сообщений и ошибок при попытке включения виртуальной машины, которое зависает на 95%:

  • Unable to open Swap File
  • Unable to access a file since it is locked
  • Unable to access a file <filename> since it is locked
  • Unable to access Virtual machine configuration

Ну а при попытке соединения с консолью ВМ получается вот такое:

Error connecting to <path><virtual machine>.vmx because the VMX is not started

Все это симптомы одной проблемы - один из следующих файлов ВМ залочен хост-сервером VMware ESXi:

  • <VMNAME>.vswp
  • <DISKNAME>-flat.vmdk
  • <DISKNAME>-<ITERATION>-delta.vmdk
  • <VMNAME>.vmx
  • <VMNAME>.vmxf
  • vmware.log

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

Поиск залоченного файла ВМ

Хорошо если в сообщении при запуске виртуальной машины вам сообщили, какой именно из ее файлов оказался залоченным (как на картинке выше). Но так бывает не всегда. Нужно открыть лог vmware.log, который расположен в папке с виртуальной машиной, и найти там строчки вроде следующих:

Failed to initialize swap file : Lock was not free

Тут видно, что залочен .vswp-файл ВМ.

За логом на экране можно следить командой (запустите ее и включайте ВМ):

tail /vmfs/volumes/<UUID>/<VMDIR>/vmware.log

Проверка залоченности файла ВМ и идентификация владельца лока

После того, как залоченный файл найден, нужно определить его владельца. Сначала попробуем команду touch, которая проверяет, может ли бы обновлен time stamp файла, т.е. можно ли его залочить, или он уже залочен. Выполняем следующую команду:

# touch /vmfs/volumes/<UUID>/<VMDIR>/<filename>

Если файл уже залочен, мы получим вот такое сообщение для него:

cannot touch: Device or resource busy

Дальше выполняем такую команду:

# vmkfstools -D /vmfs/volumes/<UUID>/<VMDIR>/<filename>

В значении "owner" мы видим MAC-адрес залочившего файл хоста VMware ESXi (выделено красным). Ну а как узнать MAC-адрес хоста ESXi - это вы должны знать. Дальше просто делаем Cold Migration виртуальной машины на залочивший файл хост ESXi и включаем ее там.

Те, кто хочет дальше изучать вопрос, могут проследовать в KB 10051.

Источник: "Could not power on VM - lock was not free".


Таги: VMware, vSphere, Troubleshooting, Bugs, ESXi

Плакат VMware vSphere 5 Memory Management and Monitoring diagram.


Компания VMware в базе знаний опубликовала интересный плакат "VMware vSphere 5 Memory Management and Monitoring diagram", раскрывающий детали работы платформы VMware vSphere 5 с оперативной памятью серверов. Плакат доступен как PDF из KB 2017642:

Основные техники оптимизации памяти хостов ESXi, объясняемые на плакате:

Есть также интересная картинка с объяснением параметров вывода esxtop, касающихся памяти (кликабельно):

Пишут, что администраторы VMware vSphere скачивают его, распечатывают в формате A2 и смотрят на него время от времени, как на новые ворота. Таги: VMware, vSphere, Memory, ESX, esxtop, VMachines, Whitepaper, Diagram

1 | 2    >   >>
Реклама









Зал Славы Рекламодателя
Ближайшие события в области виртуализации:

17/07/2018:  NetApp Directions 2018
11/09/2018:  Облака 2018: настало время PaaS
08/11/2018:  CNews Forum 2018: Информационные технологии завтра

Быстрый переход:
VMware IT-Grad 5nine Hardware Citrix StarWind Veeam VeeamON Nutanix vSphere RVTools Enterprise Security Code Offtopic Cisco vGate Microsoft Cloud SDRS Parallels IaaS HP VMFS PowerCLI VM Guru Oracle Red Hat Azure KVM VeeamOn 1cloud Docker Storage NVIDIA Partnership Dell Virtual SAN Virtualization VMTurbo vRealize VirtualBox Symantec Gartner Softline EMC Login VSI Xen Teradici Amazon NetApp VDI Linux Hyper-V IBM Google VSI Security Windows vCenter VMachines Webinar View VKernel Events Windows 7 Caravan Apple TPS Hyper9 Nicira Blogs Sun VMC Xtravirt Novell IntelVT Сравнение VirtualIron XenServer CitrixXen ESXi ESX ThinApp Books P2V Horizon vCloud DRS App Volumes vSAN Labs OpenStack Backup Forum PowerShell SRM HA LSFS Lifecycle Tools Client Workspace Update vCSA Datacenter vROPs Visio NSX Intel Agent Networking esxtop VVols Book Photon VMworld Fusion Cloud Computing SSD Comparison Workstation Blast Performance Manager Nested AWS Log Insight XenDesktop VSA vNetwork SSO Host Client VMDK VTL iSCSI SDDC Virtual Appliance Whitepaper Appliance VUM V2V Cache Support Обучение Web Client Mobile Automation Replication Desktop Fault Tolerance DR Vanguard SaaS Connector Event Free SQL VSAN Sponsorship Finance FT Converter XenApp Snapshots VCP Auto Deploy SMB RDM Mirage XenClient MP Video Operations SC VMM Certification VDP Partners PCoIP RHEV vMA Award Network USB Licensing Logs Server Demo vCHS Calculator Бесплатно vExpert Beta SAN Exchange MAP ONE DaaS Monitoring VPLEX UCS SDK Poster VSPP Receiver vMotion VDI-in-a-Box Deduplication Reporter vShield ACE Go nworks iPad XCP Data Recovery Sizing Pricing VMotion Snapshot FlexPod VMsafe Enteprise Monitor vStorage Essentials Live Migration SCVMM TCO Studio AMD-V VirtualCenter NFS ThinPrint Upgrade Director API Troubleshooting Android Graphics Migration Diagram Bug Air CLI Plugin DPM Memory SIOC Flex Mac Open Source SSH VAAI Chargeback Heartbeat MSCS Ports SVMotion Storage DRS Bugs Composer
Интересные плакаты:

Постер VMware vSphere PowerCLI 6.3:

Постер VMware ESXi 5.1:

Постер VMware Hands-on Labs 2015:

Постер VMware Platform Services Controller 6.0:

Постер VMware vCloud Networking:

Постер VMware NSX (референсный):

Постер VMware vCloud SDK:

Постер VMware vCloud Suite:

Постер VMware vCenter Server Appliance:

Порты и соединения VMware vSphere 6:

Порты и соединения VMware Horizon 7:

Порты и соединения VMware NSX:

Управление памятью в VMware vSphere 5:

Как работает кластер VMware High Availability:

Постер VMware vSphere 5.5 ESXTOP (обзорный):

Постер Veeam Backup & Replication v8 for VMware:

Постер Microsoft Windows Server 2012 Hyper-V R2:

 

Популярные статьи:
Как установить VMware ESXi. Инструкция по установке сервера ESXi 4 из состава vSphere.

Включение поддержки технологии Intel VT на ноутбуках Sony VAIO, Toshiba, Lenovo и других.

Как настроить запуск виртуальных машин VMware Workstation и Server при старте Windows

Как работают виртуальные сети VLAN на хостах VMware ESX / ESXi.

Что такое и как работает виртуальная машина Windows XP Mode в Windows 7.

Типы виртуальных дисков vmdk виртуальных машин на VMware vSphere / ESX 4.

Инфраструктура виртуальных десктопов VMware View 3 (VDI)

Сравнение Oracle VirtualBox и VMware Workstation.

Бесплатные утилиты для виртуальных машин на базе VMware ESX / ESXi.

Проектирование инфраструктуры виртуализации VMware vSphere 4.

Как использовать возможности VMware vSphere Management Assistant (vMA).

Как поднять программный iSCSI Target на Windows 2003 Server для ESX

Бесплатные программы для VMware ESX / ESXi в среде Virtual Infrastructure / vSphere (часть 2).

Новые возможности VMware vSphere 5.0 - официально.

Отличия VMware ESXi 4 free (бесплатного), ESXi 4 и ESX 4 в составе VMware vSphere.

Все ресурсы о виртуализации:
Интервью:

Alessandro Perilli
virtualization.info
Основатель

Ратмир Тимашев
Veeam Software
Президент


Купить:

VMware vSphere 6.5


Veeam Backup 9.5


Полезные ресурсы:


Видео компании VMware

Видео про Citrix Xen

Видео о виртуализации Microsoft

Утилиты для виртуальных машин Microsoft.

Книги на английском языке

Блоги на английском языке

Блоги на русском языке

Агрегация статей в твиттере VMC:


Copyright VM Guru 2006 - 2018, Александр Самойленко. Правила перепечатки материалов.