Восстанавливаем файловую систему загрузочного диска ESXi

Столкнулся с проблемой установки/обновления VMware Tools на машинах, работающих на одном из хостов в кластере:



С машинами, работающими на других хостах кластера такой проблемы нет, можно без ошибок установить/обновить VMware Tools.
После прочтения, предложенного в сообщении об ошибке KB Installing and upgrading the latest version of VMware Tools on existing hosts, подключился по SSH к проблемному хосту и обнаружил следующую картину:



Файловая система раздела, содержащего VMware Tools разрушена.
Первая мысль переустанавливать ESXi с нуля, но подумав пару минут, пришло осознание, ESXi все-таки Linux и должен быть путь «починить» файловую систему раздела без полной переустановки ESXi.

Возможно, данная проблема связана с KB High frequency of read operations on VMware Tools image may cause SD card corruption.
Начиная с ESXi 6.0 U3 появился дополнительный параметр, который позволяет при загрузке ESXi создать RAM диск, содержащий образы VMware Tools. Это снизит нагрузку на загрузочный диск при многократной установке VMware Tools.

Итак, первым делом выводим хост в Maintenance Mode.
Далее, нужно понять какой раздел смонтирован в папку /store (locker – это ссылка на store). Для это этого выполним команду:

vmkfstools -P /store

Обычно это 8 раздел загрузочного устройства (почему 8 раздел можно прочитать в статье Загрузка ESXi c USB/SD и что меняется, когда появляется vSAN):



Запускаем проверку диска для 8 раздела загрузочного диска:

dosfsck -a -w /dev/disks/mpx.vmhba32:C0:T0:L0:8

Бывает, что требуется ручное исправление ошибок на диске, тогда:

dosfsck -v -w -r /dev/disks/mpx.vmhba32:C0:T0:L0:8

Далее, удаляем содержимое папки /store и перезагружаем проблемный хост:

rm -r /store/*

При загрузке ESXi восстановит необходимые файлы и папки в store, но vib пакет с VMware Tools нам придется восстановить руками, можно это сделать, например, через Update Manager:




К сожалению, я сталкивался с ситуациями, когда USB/SD карты выходили из строя или «ломались» партиции на них. Вообщем, разбираться и «чинить» точно бы заняло кучу времени.
На этот случай есть возможность создания резервной копии конфигурации ESXi и последующего восстановления из нее. Все это описано в KB How to back up ESXi host configuration. Данная процедура работает и для хостов с VMware vSAN без необходимости эвакуировать данные с проблемного хоста.

Делаем резервную копию конфигурации, например, через PowerCLI:

Connect-VIServer -Server host_ip
Get-VMHostFirmware -VMHost host_ip -BackupConfiguration -DestinationPath C:\Temp

Переустанавливаем ESXi с нуля. И восстанавливаем настройки из резервной копии:

Connect-VIServer -Server host_ip
Set-VMHost -VMHost -State 'Maintenance'
Set-VMHostFirmware -VMHost host_ip -Restore -SourcePath C:\Temp\configBundle host_ip.tgz -HostUser root -HostPassword Password

Corrupt дисковой системы. Что делать?

Рассмотрим ситуацию: достоверно известно, что случился corrupt на уровне дисковой системы. Битые сектора или что-то еще - не столь важно. Сверху живет VMFS и виртуальные машины, но в ВМ вроде ничего не случилось, они продолжают работать.
В этой ситуации вполне может быть, что битая область вообще не затрагивает ВМ и все данные остались целыми. Так что же сделать, чтобы свести риски к минимуму?

1. Выключаем затронутые ВМ.
2. Клонируем ВМ на заведомо исправный датастор.
3. Включаем клоны, запускаем проверку целостности файловой системы в каждой ВМ. Можно использовать встроенные средства ОС или использовать любой Rescue CD.

Зачем выключать? При дальнейшей работе, в особенности в случае машин с тонкими дисками и снапшотами, можем затронуть битую область и соотв. ВМ приходит в негодность.
Обратите внимание, что ВМ именно клонируем, а не перемещаем. И тем более не делаем Storage vMotion, иначе есть риск остаться наедине с резервной копией. В случае если она вообще есть.

Проблема USB и Workstation 7

После установки Workstation 7 у меня долгое время наблюдались странные проблемы с USB устройствами. Перестал работать Bluetooth на домашнем и рабочем десктопе, на ноутбуке удалось заставить работать USB 3G модем только при помощи адского шаманства - модем непременно нужно было воткнуть в выключенный ноутбук, а потом загрузиться. Причем никакого hibernate.

Если у вас похожие необъяснимые проблемы - виновата 7я Workstation.

Лечение: остановить и перевести в состояние Manual или Disabled сервис VMware USB Arbitration Service (VMUSBArbService).

Если же вам непременно нужно пробрасывать USB в виртуальную машину - откатывайтесь на Workstation 6.5

Грабли: после установки обновлений не стартует Veeam Backup

Грабли: после установки обновлений не стартует управлялка Veeam Backup с сообщением "Value does not fall within the expected range." При этом Veeam.Backup.Service.exe виден в списке процессов.

Подробности: Windows 2003 R2 SP2, установлены *все* вышедшие обновления.

Лечение: удалить Internet Explorer 8. С IE7 или IE6 проблем нет.

Грабли: Veeam со странными ошибками при работе с vSphere 4.1

Проблемы c Veeam Backup & Replication после апгрейда до vSphere 4.1:
1) При репликации ВМ возникают постоянные ошибки "Create virtual disk. The requested operation is not implemented by the server", а так же ошибки с удалением файлов - файлы удаляются только с 4го раза.
2) При репликации внезапно перестает видеть replica.vbk, хотя файл в директории присутствует.

Лечение: апгрейд до последней версии Veeam Backup & Replication 4.1.2

Грабли: апгрейд VMware Tools не проходит

Проблема:
1. "Правый клик / Guest / Install/Upgrade VMware Tools / Automated" практически сразу выдает ошибку "Error upgrading VMware Tools"
2. При апгрейде через интерфейс VMware Tools в гостевой Windows (кнопка "Upgrade") ничего не происходит.
3. Апгрейд в интерактивном режиме проходит нормально.

Существует статья в KB: Upgrading VMware Tools may fail when using Automatic Tools Upgrade in the vSphere Client

Решение: удалить VMwareToolsUpgrader.exe из %Temp% (обычно C:\Windows\Temp) и перезапустить апгрейд.

Алексей Тараненко любезно помог с PowerShell скриптом для автоматизации процесса.

Upgrade to vSphere 4.1 - первые грабли с vCenter

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

Итак, как известно, VMware отказывается от 32битных систем. Поэтому те, кто собрался апгрейдиться до 4.1, наверняка подумали о том, чтобы заодно поменять и ОС на машине с vCenter до, скажем, 2008 R2.

Здесь закопана одна собака. Если снести полностью все, что было (считаем, что БД удаленная), и попытаться поставить еще пахнущий краской vCenter 4.1 на такую же свежую Windows и при этом подключиться к старой базе (мы ведь не хотим терять конфигурации), то можно получить следующее сообщение: "Setup located a vCenter Server database but not the companion SSL certificates."
И vCenter отказывается ставиться дальше.

Лечение: ДО выноса старой системы необходимо сделать резервную копию SSL сертификатов.

• Для Windows 2003 "C:\Documents and Settings\All Users\Application Data\VMware\VMware Virtual Center\SSL\"
• Windows 2008 "C:\ProgramData\VMware\VMware VirtualCenter\SSL\"

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

Но что же делать, если вы сейчас читаете это уже постфактум, и сертификаты соотв. пропали бесследно? Ничего страшного, можно поставить свежий чистый vCenter на другую БД, и скопировать сертификаты у него. Или взять их от тестового vCenter, если он у вас есть. Правда в этом случае все хосты будут в состоянии "Disconnected", но подключить их назад дело нескольких минут.

По материалам KB Article: 1014314.

Особенности многопроцессорных ВМ

Грабли: ВМ с Windows XP создана с 4мя процессорами, а XP видит только 2, хотя физически в сервере 2 4-ядерных процессора.

Причина: ничего общего презентуемые ВМ виртуальные процессоры с физическими не имеют. Каждый vCPU является одноядерным - соотв. XP ведет себя совершенно нормально, поскольку по условиям лицензии ограничена 2мя процессорами (сокетами).

Лечение: в Advanced Settings для ВМ создать параметр cpuid.coresPerSocket и присвоить ему желаемое значение. Соотв. если для 4х процессорной ВМ cpuid.coresPerSocket = 2, то ВМ увидит 2 2-ядерных процессора.

Грабли: Установка AppSpeed не проходит

Продолжим бег по граблям. Итак,

Грабли: AppSpeed успешно развернулся из OVF, но не проходит первичная настройка с проблемой "Reconfigure virtual machine appspeed-srv - Insufficient resources to satisfy configured failover level for HA."

Причина: AppSpeed требует резерва в 3 GHz, что приводит к срабатыванию Admission Control в HA кластере. Подробнее - здесь.

Лечение: в Advanced Settings для HA выставить das.slotCpuInMHz в более-менее разумное значение. Я поставил 512 MHz.

Грабли: Update Manager fails to scan host

Грабли: При попытке выполнить "Scan for updates" появляется сообщение об ошибке "Failed to scan esx.domain.com for patches".

Проблема: был переезд с одного datastore на другой, а переменная ConfiguredScratchLocation указывала на директорию на старом datastore. Доступ к старому datastore соотв. отключили.

Лечение: указать существующую директорию ScratchConfig.ConfiguredScratchLocation и перезагрузить хост

P.S. Путь до директории должен быть полным, таким как "/vmfs/volumes/4b1dcdcb-280db784-d073-00215aaeeac8/scratch/esx-2p". И для каждого хоста требуется отдельная директория.

Грабли: vCenter web access и Linux

Проблема: Remote Console не может подключиться к ВМ через web access, если подключение происходит с Linux десктопа. Выдается сообщение “Unable to connect to MKS: Host address lookup for server esx.domain.com failed: Name or service not known”

Причина: Remote Console по каким-то причинам не может работать с DNS серверами.

Лечение: Прописать все ваши ESX в /etc/hosts

P.S. SR ушел в VMware Support

Upd: Web Access находится в состоянии experimental, возможно данная проблема будет исправлена в 4.5, но пока придется пользоваться /etc/hosts

Грабли: Performance Overview + Oracle DB

Продолжаем тему граблей, щедро расставленных и разложенных в самых неожиданных местах.
Сегодня грабли для тех, кто использует Oracle DB для vCenter.

Знакомая картинка, не правда ли?


Решение было под самым носом, как всегда.

Грабли: отваливаются бэкапы, миграция и клонирование ВМ etc

Проблема: начали отваливаться бэкапы в процессе, невозможно склонировать ВМ или перенести на другой datastore. Файловые операции в консоли ESX отваливаются по таймауту.

Причина: скорее всего одна из ВМ решила полностью нагрузить дисковую систему и в частности datastore, на котором и наблюдаются проблемы. Напоминаю, что нагрузка на дисковую систему измеряется не в сотнях мегабайт в секунду, а в операциях в секунду - IOPS.
Как пример из реальной жизни - машина с syslog сервером, из-за которой все и случилось, генерировала примерно 1.5-2 мегабайта в секунду. Вроде бы смешная цифра для Fibre Channel дисковой полки с 10 дисками, но эти 2 мегабайта в секунду с другой стороны равнялись 1200 IOPS - а больше дисковая полка просто не могла выдать.

Решение: размещение выскоконагруженных по дисковым операциям ВМ на выделенных datastore, размещающихся на выделенных дисковых группах. Почему критичны выделенные дисковые группы в данном случае? При размазанных дисковых группах, когда LUN'ы нарезаются на одной большой дисковой группе, стоит вырасти дисковой нагрузке от одной ВМ - ВСЕ datastore на LUN'ах с этой дисковой группы просядут.

Как отследить машинку-негодяйку? В первую очередь esxtop, разумеется. Но значительно удобнее в таких случаях использовать Veeam Monitor, у которого, кстати, есть Free Edition.

Грабли: vCenter 4 и ESX3 - не хочет работать Storage VMotion

Дано: vCenter 4 управляет смешанной инфраструктурой из ESX 4 и 3.5, все лицензии Enterprise. ESXi 3.5 - standalone, не в кластере.
Проблема: невозможно совершить Storage VMotion для ВМ на ESXi 3.5, поскольку "VMotion is not licensed for host".

Возникает вопрос - как это нет лицензии, у меня же Enterprise?!

Решение: для VMkernel интерфейса включить поддержку VMotion, даже если мы не собираемся мигрировать машины на другие хосты. VMotion для 3.5 является отдельным продуктом и требует свою собственную лицензию, и потому соотв. изначально запрашивается лицензия только ESX Standard + vCenter Agent. Чтобы хост получил лицензию VMotion, он должен ее сначала попросить у сервера лицензий, а если нет VMotion интерфейса, то и просить нечего :)

vShield: грабли с View Offline Desktop

Проблема: vShield Autoinstall failed для хоста, на котором лежит выгруженная ВМ с Offline Desktop. Созданы временные портгруппы, процесс инсталляции (деинсталляции) прерван.
Причина: для выгруженной Offline Desktop ВМ запрещено изменение параметров. Соотв. процесс инсталляции спотыкается на этой ВМ и прерывается.
Лечение: завершить инсталляцию вручную. А конкретно создать и переименовать портгруппы до нужного состояния, переключить ВМ в нужные портгруппы. Как это должно выглядеть - смотреть на хосте без Offline Desktop ВМ.

vShield: грабли при развертывании

Грабли, на которые наступил тут.

При деплойменте vSield Manager и vShield из OVF необходимо использовать File / Deploy OVF template в vSphere клиенте. Только так сохраняются правильные настройки сетевых адаптеров. VMware Converter, во всяком случае Standalone, наплевал на них и создал один адаптер типа Flexible, что неправильно.

Правильные адаптер для vShield Manager - E1000. Для vShield их три, mgmt - E1000, а prot и unprot - VMXNET3.

Грабли. Низкая производительность ВМ.

Проблема: производительность ВМ неожиданно низкая, все очень тормозит.
Диагностика: посмотрите на загрузку памяти ВМ, если она 100%, все интенсивно свопится, а для машины при этом значительные цифры видны в Memory Ballooned, то это проблема с выставленным Memory Limit.
Лечение: Memory Limit выставить в значение, равное памяти ВМ, или в Unlimited.

Если машин много, то можно сделать это скриптами.

vShield: не поднимается сеть

Первые грабли с vShield на ESX4.0 - не поднимается и не конфигурируется сеть ни на vShield Manager, ни на vShield машинах.

Лечение: после импорта appliance в инфраструктуру сменить сетевые адаптеры машин с Flexible на, например, VMXNET3.

Первопричина проблем

Существует очень распространенная причина проблем. Она звучит как "нехватка места на диске".

Только что на форуме VMware случилось обсуждение очередной ее инкарнации: процесс апдейта падал с сообщением "failed to download". Не хватало места на диске под пакет.

Бывает, падает прокси, интернет кончается для всей конторы. А разгадка одна - кончилось свободное место на в разделе с лог-файлами. Можно два часа искать проблему с внешними каналами и ругаться с саппортом провайдера, а толку будет ноль.

Всегда, в первую очередь проверяйте при возникновении проблем, а осталось ли свободное место?