U-SERVER

Troubleshooting VMware ESXi: решение ошибок и проблем

Полное руководство по диагностике и устранению ошибок VMware ESXi: PSOD, проблемы загрузки, работа с логами, решение проблем виртуальных машин и сети.

Средний
Troubleshooting VMware ESXi: решение ошибок и проблем
В этом руководстве рассмотрим все основные категории ошибок ESXi: от критичного Purple Screen of Death до проблем с виртуальными машинами, сетью и хранилищем. Вы получите практические инструкции по диагностике через SSH, работе с логами и пошаговые решения типичных проблем.
VMware ESXi — один из самых надежных гипервизоров, но даже в нем возникают ошибки, которые могут парализовать работу критичной инфраструктуры. По статистике VMware, около 60% проблем ESXi связаны с аппаратными сбоями, 25% — с ошибками конфигурации, и 15% — с программными багами. Быстрая диагностика и устранение ошибок VMware ESXi — ключевой навык любого системного администратора.

Purple Screen of Death (PSOD): причины и решение

Основные причины PSOD

  • **Аппаратные сбои**: дефекты памяти (ECC errors), проблемы с процессором, перегрев
  • **Несовместимые драйверы**: устаревшие или некорректные драйверы сетевых карт, RAID-контроллеров
  • **Проблемы с памятью**: битые модули RAM, несовместимая память
  • **Баги в VMkernel**: редкие программные ошибки в самом ESXi
  • **Конфликты устройств**: несовместимость оборудования с ESXi (проверяйте HCL)

Как читать информацию PSOD

  1. **Exception type** — тип исключения (например, #PF, #NMI)
  2. **Error code** — код ошибки в шестнадцатеричном формате
  3. **Backtrace** — стек вызовов, показывающий где произошел сбой
  4. **Module name** — имя модуля/драйвера, вызвавшего ошибку
  5. **Core dump location** — путь к core dump для последующего анализа

Процедура восстановления после PSOD

Важно

Повторяющиеся PSOD с одинаковым кодом ошибки обычно указывают на аппаратную проблему. Не игнорируйте эти сигналы — они могут привести к полной потере данных.

ESXi не запускается: диагностика загрузки

Этапы загрузки ESXi

  1. **POST (Power-On Self-Test)** — тестирование оборудования BIOS/UEFI
  2. **Boot loader** — загрузка SYSLINUX/UEFI bootloader
  3. **VMkernel load** — загрузка ядра гипервизора
  4. **Driver initialization** — инициализация драйверов устройств
  5. **Service startup** — запуск системных сервисов ESXi
  6. **Network initialization** — настройка сети и management интерфейса

Проблемы на уровне BIOS/UEFI

  • **No boot device found** — проверьте boot order в BIOS, убедитесь что USB/SD с ESXi подключен
  • **RAID controller not detected** — инициализируйте RAID контроллер в pre-boot меню
  • **Secure Boot issues** — отключите Secure Boot или настройте правильные ключи
  • **Memory errors on POST** — протестируйте память, переставьте модули

Ошибки загрузчика (bootloader)

Error loading /s.v00
Fatal error: 33 (Inconsistent data)

Not a COM32R image
boot:

Bank6 not a VMware boot bank

Проблема

Bootloader не может загрузить ESXi (ошибки типа 'Error loading /s.v00' или 'Not a VMware boot bank')

Возможные причины

  • Повреждение файловой системы на USB/SD карте
  • Сбой при обновлении ESXi
  • Аппаратная проблема с boot устройством

Решение

1. Загрузитесь с установочного ISO ESXi. 2. В boot menu выберите 'Repair ESXi' вместо установки. 3. Система восстановит bootloader и boot banks. 4. Если не помогает — переустановите ESXi, сохранив конфигурацию через backup.

Как избежать

Регулярно делайте backup конфигурации через 'vim-cmd hostsvc/firmware/backup_config'. Используйте качественные USB/SD карты enterprise уровня.

Восстановление через установочный ISO

# После загрузки с ISO в режиме Troubleshooting
# Монтируем существующий раздел ESXi
esxcli system maintenanceMode set --enable true

# Восстанавливаем конфигурацию из backup
vim-cmd hostsvc/firmware/restore_config /vmfs/volumes/datastore1/backup.tgz

# Или делаем чистую установку с сохранением VMFS разделов
# В установщике выбрать 'Upgrade' вместо 'Install'

Совет профессионала

Всегда держите backup конфигурации ESXi на внешнем хранилище. Команда 'vim-cmd hostsvc/firmware/backup_config' создает .tgz архив с полной конфигурацией хоста, который можно восстановить за минуты.

Диагностика через SSH и ESXi Shell

Включение SSH на ESXi

  1. **Через vSphere Client**: Host → Configure → System → Services → SSH → Start
  2. **Через DCUI** (локальная консоль): F2 → Troubleshooting Options → Enable SSH
  3. **Через API** если есть доступ к vCenter

Безопасность

SSH на production ESXi лучше держать выключенным и включать только для диагностики. Используйте ключи вместо паролей, ограничьте доступ через firewall rules.

Основные команды диагностики

Проверка версии ESXi и build number
esxcli system version get
Вывод:
   Product: VMware ESXi
   Version: 8.0.0
   Build: Releasebuild-20513097
   Update: 0
Статус всех сервисов ESXi
esxcli system service list
Вывод:
hostd          running  true
vpxa           running  true
ntpd           stopped  false
# Проверка CPU
esxcli hardware cpu list
esxcli hardware cpu global get

# Проверка памяти
esxcli hardware memory get

# Проверка storage
esxcli storage core adapter list
esxcli storage core device list

# Проверка сети
esxcli network nic list
esxcli network ip interface list
# Список всех VM
vim-cmd vmsvc/getallvms

# Статус конкретной VM (VMID из предыдущей команды)
vim-cmd vmsvc/power.getstate <VMID>

# Включение VM
vim-cmd vmsvc/power.on <VMID>

# Информация о VM
vim-cmd vmsvc/get.summary <VMID>

Мониторинг в реальном времени через esxtop

Диагностика performance

В режиме CPU (клавиша 'c') смотрите на параметр **%RDY** (CPU Ready Time). Если значение > 5% — виртуальная машина испытывает нехватку CPU resources из-за overcommit.

Работа с логами ESXi для поиска ошибок

Основные типы логов

Команды для работы с логами

# Последние 50 строк vmkernel.log
tail -50 /var/log/vmkernel.log

# Мониторинг в реальном времени
tail -f /var/log/vmkernel.log

# Поиск ошибок за последний час
grep -i error /var/log/vmkernel.log | tail -100

# Поиск конкретной VM по имени
grep -i 'vm-name' /var/log/vmware.log

# Все ошибки за сегодня
grep $(date +'%Y-%m-%d') /var/log/vmkernel.log | grep -i error

Примеры поиска конкретных ошибок

Поиск проблем с доступностью storage (All Paths Down)
grep -i "APD\|PDL\|all paths down" /var/log/vmkernel.log
Вывод:
2024-12-15T10:23:45.123Z: WARNING: NMP: Lost access to volume datastore1
2024-12-15T10:23:46.456Z: ScsiDeviceIO: APD detected on device naa.600...
Диагностика проблем с сетевыми адаптерами
grep -i "lost link\|vmnic" /var/log/vmkernel.log | tail -20
Вывод:
2024-12-15T11:45:12.789Z: vmnic2: Link is Down
2024-12-15T11:45:13.123Z: Net: Lost connection to physical network

Экспорт логов для техподдержки

# Создание полного diagnostic bundle
vm-support

# Bundle будет сохранен в /var/tmp/
# Скачайте файл через SCP
scp root@esxi-host:/var/tmp/esx-*.tgz .

# Или через web interface
# https://esxi-ip/host → Monitor → Logs → Export logs

Хранение логов

По умолчанию ESXi хранит логи на ramdisk — они теряются при перезагрузке. Для production настройте syslog на удаленный сервер через Host → Configure → System → Advanced Settings → Syslog.

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

VM не запускается: диагностика

  • **Lock файлы** — предыдущий процесс VM не закрылся корректно
  • **Поврежденный VMDK** — ошибки файловой системы виртуального диска
  • **Нехватка ресурсов** — недостаточно RAM или CPU для reservation
  • **Ошибки конфигурации** — некорректный .vmx файл
  • **Snapshot проблемы** — цепочка снапшотов повреждена

Проблема

VM не включается с ошибкой 'Failed to lock the file'

Возможные причины

  • Процесс VM не завершился корректно
  • Файлы .lck (lock files) остались на datastore
  • Другой ESXi хост держит блокировку (в кластере)

Решение

1. Проверьте, что VM точно не запущена на другом хосте. 2. Найдите lock файлы: 'find /vmfs/volumes/ -name '*.lck' | grep vm-name'. 3. Удалите директории .lck: 'rm -rf /vmfs/volumes/datastore1/vm-name/*.lck'. 4. Попробуйте включить VM снова. 5. Если не помогает — снимите VM с инвентаря и зарегистрируйте заново.

Как избежать

Всегда используйте graceful shutdown для VM. Избегайте hard power off кроме критических ситуаций.

VM зависает или тормозит

# Через esxtop в batch mode для конкретной VM
esxtop -b -n 10 | grep vm-name

# CPU Ready time через vim-cmd
vim-cmd vmsvc/get.summary <VMID> | grep cpu

# Статистика памяти VM
esxcli vm process list | grep -A 10 vm-name

Проблемы со снапшотами

# Список snapshot конкретной VM
vim-cmd vmsvc/snapshot.get <VMID>

# Удаление всех snapshot
vim-cmd vmsvc/snapshot.removeall <VMID>

# Поиск больших delta файлов (активные snapshot)
find /vmfs/volumes/ -name '*-delta.vmdk' -size +50G

# Consolidation если snapshot не удаляется
vim-cmd vmsvc/snapshot.consolidate <VMID>

Осторожно

Удаление старых больших снапшотов (> 100GB) может занять часы и серьезно нагрузить storage. Планируйте consolidation в maintenance window. Snapshot замедляет VM и расходует место на datastore.

Проблемы с VMware Tools

Проверка статуса VMware Tools
vim-cmd vmsvc/get.summary <VMID> | grep toolsStatus
Вывод:
toolsStatus = 'toolsOk'  # или toolsOld, toolsNotInstalled, toolsNotRunning

Таблица частых ошибок VM

Проблемы с сетью в ESXi

Проблемы с vSwitch и Port Groups

  • **Uplink down** — физический адаптер (vmnic) потерял link
  • **Неправильный VLAN** — VM в port group с некорректным VLAN ID
  • **Security policy** — блокировка трафика promiscuous mode или MAC changes
  • **NIC teaming issues** — проблемы с failover или load balancing
# Список сетевых адаптеров и их статус
esxcli network nic list

# Детали конкретного адаптера
esxcli network nic get -n vmnic0

# Список vSwitch
esxcli network vswitch standard list

# Port groups
esxcli network vswitch standard portgroup list

# Проверка connectivity (аналог ping)
vmkping -I vmk0 192.168.1.1

# Статистика по vmnic (ошибки, drops)
esxcli network nic stats get -n vmnic0

Проблема

Сетевой адаптер vmnic отображается как 'Down' или 'Not connected'

Возможные причины

  • Отключен сетевой кабель
  • Проблема на коммутаторе (порт down, spanning tree)
  • Сбой драйвера сетевой карты
  • Аппаратная неисправность NIC

Решение

1. Проверьте физическое подключение кабеля. 2. Проверьте статус порта на коммутаторе. 3. Перезагрузите драйвер: 'esxcli network nic down -n vmnic0 && esxcli network nic up -n vmnic0'. 4. Обновите firmware NIC и драйвер. 5. Проверьте настройки speed/duplex — установите auto-negotiation.

Как избежать

Используйте NIC teaming (минимум 2 vmnic на vSwitch) для redundancy. Мониторьте link status.

Проблемы с VLAN

# VLAN ID для port group
esxcli network vswitch standard portgroup list | grep -i portgroup-name

# Убедитесь что VLAN tagged на физическом коммутаторе
# Для trunk порта должны быть разрешены все используемые VLAN

# Временно установите VLAN в 0 (untagged) для теста
esxcli network vswitch standard portgroup set -p 'VM Network' -v 0

Быстрая диагностика сети

Используйте 'vmkping' с указанием конкретного vmkernel interface для проверки connectivity: 'vmkping -I vmk0 8.8.8.8'. Это помогает отделить проблемы management network от VM network.

Проблемы с хранилищем и datastore

APD и PDL: потеря доступа к хранилищу

  • **APD (All Paths Down)** — временная потеря всех путей к storage, возможно восстановление
  • **PDL (Permanent Device Loss)** — постоянная потеря устройства, требует intervention

Проблема

Datastore недоступен, ошибка 'All Paths Down' (APD)

Возможные причины

  • Проблемы с SAN: потеря связи, отключение LUN
  • Сбой всех контроллеров хранилища
  • Проблемы с Fiber Channel switches или cables
  • Неправильная конфигурация multipathing

Решение

1. Проверьте connectivity к storage: 'esxcli storage core adapter list'. 2. Проверьте статус paths: 'esxcli storage core path list'. 3. Проверьте SAN оборудование: switches, cables, контроллеры. 4. Если paths восстановились, remount datastore. 5. Перезапустите affected VM после восстановления доступа.

Как избежать

Настройте multipathing с несколькими путями к storage. Мониторьте storage connectivity. Используйте storage DRS для распределения VM.

Диагностика storage через esxcli

# Список storage адаптеров
esxcli storage core adapter list

# Список всех LUN/дисков
esxcli storage core device list

# Подробная информация о диске
esxcli storage core device list -d naa.600xxxx

# Проверка multipath paths
esxcli storage core path list

# Проверка VMFS datastores
esxcli storage vmfs extent list

# Rescan storage адаптеров
esxcli storage core adapter rescan --all

# Storage latency statistics
esxcli storage core device stats get

Нехватка места на datastore

# Информация о всех datastore
df -h

# Детальная информация через esxcli
esxcli storage filesystem list

# Поиск больших файлов (snapshot, logs, ISO)
find /vmfs/volumes/datastore1 -type f -size +10G -exec ls -lh {} \;

# Удаление старых snapshot файлов (осторожно!)
find /vmfs/volumes/ -name '*-delta.vmdk' -mtime +30

VMFS ошибки и проверка целостности

Проверка целостности VMFS (аналог fsck)
voma -m vmfs -f check -d /vmfs/devices/disks/naa.600xxxx:1
Вывод:
Checking VMFS volume:
Phase 1: Checking metadata
Phase 2: Checking resource allocation
Phase 3: Checking file blocks
VMFS check completed successfully

Критически важно

Перед проверкой VMFS целостности через voma обязательно остановите все VM на datastore и unmount его. Проверка на live datastore может привести к повреждению данных!

Аппаратные проблемы и мониторинг

Мониторинг через IPMI/iLO/iDRAC

  • **Температуры** — CPU, память, системная плата, ambient
  • **Напряжения** — проверка стабильности power supply
  • **Скорость вентиляторов** — предупреждение о перегреве
  • **Memory errors** — ECC исправимые и некорректируемые ошибки
  • **Hardware health logs** — IML (Integrated Management Log) с историей событий

Проверка оборудования через ESXi

# Общая информация о сервере
esxcli hardware platform get

# Информация о CPU
esxcli hardware cpu list
esxcli hardware cpu global get

# Информация о памяти
esxcli hardware memory get

# Температуры и сенсоры (если поддерживается)
esxcli hardware ipmi sdr list

# Проверка PCI устройств
esxcli hardware pci list

# Firmware версии компонентов
esxcli hardware platform get

ECC ошибки памяти

Поиск ошибок памяти в логах
grep -i "memory.*error\|ECC" /var/log/vmkernel.log
Вывод:
2024-12-15T08:30:15.234Z: MemECC: Correctable ECC error detected
2024-12-15T08:30:16.567Z: MemECC: DIMM 3 Bank 1

Замена памяти

Если в логах появляются некорректируемые (uncorrectable) ECC ошибки — замените модуль памяти немедленно. Это может привести к PSOD и потере данных. Даже исправимые ошибки при высокой частоте требуют замены DIMM.

Диагностика дисков и SMART

# SMART статус локальных дисков
esxcli storage core device smart get -d t10.ATA____XXX

# Список локальных дисков
esxcli storage core device list | grep -i local

# Проверка через RAID контроллер (зависит от вендора)
# Для LSI/Broadcom:
/opt/lsi/storcli64 /c0 show all

# Для Dell PERC:
omreport storage pdisk controller=0

Hardware Compatibility List (HCL)

Проверка совместимости

VMware HCL доступен на https://www.vmware.com/resources/compatibility/search.php — проверьте модель сервера, RAID контроллер, сетевые карты, HBA адаптеры на совместимость с вашей версией ESXi.

FAQ: частые вопросы по ошибкам ESXi

FAQ

1Как сбросить пароль root на ESXi если забыл?

Сброс пароля root требует физического доступа к серверу. 1) Перезагрузите сервер и в меню загрузки нажмите Shift+O для редактирования параметров. 2) Добавьте параметр 'resetPassword=1' в конец строки загрузки. 3) ESXi загрузится и предложит установить новый пароль. Альтернативно, можно загрузиться с установочного ISO в режиме восстановления и изменить пароль через chroot. Важно: это работает только при локальном доступе, удаленно сбросить пароль невозможно по соображениям безопасности.

2Что делать если vCenter не видит ESXi хост?

Проблема обычно в connectivity или в агенте vpxa. Диагностика: 1) Проверьте сетевую связь — 'ping' между vCenter и ESXi должен работать. 2) Проверьте статус vpxa сервиса: 'service vpxa status'. 3) Если vpxa stopped — перезапустите: 'service vpxa start'. 4) Проверьте сертификаты: 'ls -la /etc/vmware/ssl/'. 5) В крайнем случае удалите хост из vCenter и добавьте заново. Проверьте логи /var/log/vpxa.log для деталей.

3Как восстановить конфигурацию ESXi после сбоя?

Если у вас есть backup конфигурации (файл .tgz созданный через 'vim-cmd hostsvc/firmware/backup_config'): 1) Загрузитесь с установочного ISO ESXi той же версии. 2) При установке выберите диск с существующим ESXi. 3) Выберите 'Upgrade' вместо 'Install'. 4) После установки скопируйте .tgz файл на сервер. 5) Выполните восстановление: 'vim-cmd hostsvc/firmware/restore_config /tmp/configBundle.tgz'. 6) Сервер перезагрузится с восстановленной конфигурацией. Без backup придется настраивать все заново вручную.

4Почему ESXi пишет ошибку 'Insufficient resources' при запуске VM?

Ошибка возникает когда не хватает ресурсов для выполнения резервирований (reservations) VM. Причины: 1) **Memory overcommitment** — суммарная память reservations превышает физическую RAM. 2) **CPU overcommitment** — аналогично для CPU. 3) **HA Admission Control** — в кластере включен admission control и недостаточно failover capacity. Решение: увеличьте физические ресурсы хоста, уменьшите reservations на VM, или отключите admission control (не рекомендуется для production). Проверьте доступные ресурсы через vSphere Client → Host → Monitor → Performance.

5Как правильно обновлять ESXi и когда это делать?

Обновления ESXi выходят регулярно и содержат security fixes и bug fixes. Best practices: 1) **Всегда читайте Release Notes** — там указаны известные проблемы. 2) **Тестируйте на непродуктивной среде** сначала. 3) **Делайте backup конфигурации** перед обновлением. 4) **Используйте vSphere Update Manager** для централизованного управления патчами. 5) **Планируйте maintenance window** — обновление требует перевода хоста в maintenance mode. Минимум обновляйтесь раз в квартал для закрытия критичных CVE. Для production используйте только stable builds, избегайте самых новых релизов первые 2-3 месяца.

6Куда обращаться за помощью если не могу решить ошибку VMware ESXi самостоятельно?

Варианты получения помощи: 1) **VMware Support** — если у вас есть активная подписка (обязательна для production). Откройте ticket через My VMware portal, приложите vm-support bundle. 2) **VMware Communities** — бесплатный форум с большим комьюнити. 3) **Reddit r/vmware** — активное сообщество администраторов. 4) **Консультанты и интеграторы** — нанимайте сертифицированных VMware специалистов для критичных проблем. Наша компания предоставляет услуги по поддержке инфраструктуры виртуализации, включая экстренную помощь 24/7. Контакты в разделе 'Связаться с нами'.

7Как включить расширенное логирование для диагностики сложных проблем?

Для детальной диагностики можно увеличить уровень логирования: 1) **Для hostd**: 'esxcli system syslog config logger set --id=hostd --level=verbose'. 2) **Для vpxa**: измените /etc/vmware/vpxa/vpxa.cfg, установите <level>verbose</level>. 3) **Для VMkernel**: 'esxcli system syslog config logger set --id=vmkernel --level=verbose'. 4) Перезапустите соответствующие сервисы. Не забудьте вернуть уровень логирования обратно после диагностики — verbose генерирует огромные объемы данных и может заполнить /var/log раздел.

Заключение: профилактика и best practices

Превентивные меры

  • **Регулярные обновления** — устанавливайте security patches ежеквартально минимум
  • **Мониторинг 24/7** — используйте vRealize Operations, Zabbix или аналоги для отслеживания метрик
  • **Backup конфигурации** — автоматизируйте ежедневный backup через 'vim-cmd hostsvc/firmware/backup_config'
  • **Hardware monitoring** — настройте alerts на температуры, ECC ошибки, disk failures
  • **Документирование** — ведите актуальную документацию по конфигурации, network topology, storage
  • **Capacity planning** — не допускайте overcommit ресурсов выше разумных значений (RAM < 1.5x, CPU < 3x)
  • **Тестовая среда** — имейте отдельный lab для тестирования обновлений и изменений

Best Practice

Настройте SNMP traps или syslog forwarding с ESXi на централизованную систему мониторинга. Это позволит получать уведомления о проблемах до того, как они приведут к downtime.

Когда нужна помощь специалистов

  • **Критичный production down** — каждая минута простоя стоит денег
  • **Повторяющиеся PSOD** — требуется глубокий анализ core dumps
  • **Data corruption** — риск потери критичных данных
  • **Проектирование инфраструктуры** — правильная архитектура с самого начала
  • **Migration** — переезд на новую версию ESXi или смена оборудования

Нужна помощь с инфраструктурой виртуализации?

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