Зависимость от версии и платформы
Сначала зафиксируйте симптом и границу сбоя
Первичная последовательность диагностики
Цель первых действий — сохранить диагностические данные и понять, какой компонент отвечает за ошибку.
- 1Запишите наблюдаемый фактСохраните полный текст ошибки, код, время с часовым поясом, имя VM, имя хоста и операцию: запуск, остановка, подключение к консоли, миграция или добавление диска. Сделайте снимок экрана сообщения и списка последних задач. Это позволит сопоставить ошибку с событием хоста, datastore или сети.
- 2Определите масштабПроверьте, затронута ли одна VM, несколько VM на одном узле или все ресурсы хоста. Если недоступны несколько VM и управление хостом, начинайте с хоста, его сети управления и хранилища. Если сбоит одна VM, сравните её конфигурацию, расположение файлов и последние изменения с работающей VM того же типа.
- 3Сопоставьте время с журналамиОткройте задачи, события и журналы объекта VM, хоста и используемого хранилища. Ищите сообщения с тем же временем: недостаток места, недоступный путь, отказ устройства, блокировка файла, ошибка прав, несовместимость CPU или виртуального оборудования.
- 4Проверьте зависимости без измененийУбедитесь, что хост включён и доступен, нужное хранилище подключено, есть свободное место, виртуальная сеть существует, а целевой узел миграции виден. Ожидаемый результат — причина сужается до одного слоя. Если зависимость недоступна, устраняйте её, а не параметры гостевой ОС.
- 5Только затем выполняйте корректирующее действиеНапример, освободите или расширьте хранилище штатным способом, восстановите доступность сети, снимите документированную блокировку или исправьте конфигурацию VM. После действия повторите исходную операцию и сохраните новый результат.
Первичная развилка по симптому
| Наблюдение | Вероятная граница | Что проверить первым | Безопасное следующее действие |
|---|---|---|---|
| Не работает одна VM | Конфигурация VM, её файлы, гостевая ОС | Последняя задача запуска, консоль VM, доступность её дисков и сети | Различить отказ запуска VM и сбой загрузки гостевой ОС |
| Не работают несколько VM на одном узле | Хост, datastore, общая сеть, ресурсы | Состояние хоста, хранилищ, сетевых uplink и события узла | Не перезапускать все VM; восстановить общую зависимость |
| Не открывается интерфейс управления | Management-сеть, службы управления, сам узел | Локальную/out-of-band-консоль, IP-адрес, маршрут, состояние служб | Отделить сетевую недоступность от отказа гипервизора |
| VM включена, но нет сети | vNIC, vSwitch/Port Group/bridge, VLAN, uplink или гостевая ОС | Подключение vNIC и путь до физической сети | После подтверждения гостевого уровня перейти к диагностике ОС |
| VM не видит диск | Конфигурация VM, контроллер, datastore либо гостевая ОС | Присоединён ли диск и доступно ли хранилище | Не изменять вручную файлы дисков и снимков |
| Не проходит миграция | Совместимость двух хостов, сеть, хранилище, права | Полный текст задачи на исходном и целевом узлах | Проверить предварительные условия конкретного механизма миграции |
Действия, которые могут ухудшить ситуацию
VM не запускается, зависает или не загружается
Ошибка запуска VM возникает до передачи управления гостевой ОС: платформа обычно сообщает о проблеме в задаче питания или запуска — с ресурсами хоста, доступом к файлам, виртуальным оборудованием, правами либо совместимостью. Сбой гостевой ОС начинается позже: VM получает состояние Running/Powered On, открывается консоль, видны BIOS/UEFI, загрузчик или сообщения ОС, но сама система не доходит до входа или сервисов.
Проблема
Виртуальная машина не включается
Возможные причины
- Недоступен либо заполнен datastore или иное хранилище.
- На хосте не хватает доступных ресурсов, действует резервирование, лимит или политика размещения.
- В конфигурации VM указан недоступный ISO, диск, контроллер, passthrough-устройство или сеть.
- Файлы VM заблокированы, конфигурация повреждена или создана для несовместимого виртуального оборудования.
- Для кластерной VM не выполняются правила размещения или требования высокой доступности.
Решение
Откройте последнюю задачу VM и связанное событие хоста. Проверьте состояние хоста, доступность хранилища, свободное место, подключённые виртуальные устройства и последние изменения конфигурации. При ошибке хранилища восстановите доступ к нему или штатно обеспечьте место; при недоступном устройстве исправьте именно эту привязку по документации платформы. Если платформа сообщает о блокировке, не удаляйте файлы: сначала установите, какой хост или процесс удерживает объект, и используйте штатную процедуру платформы.
Проблема
Виртуальная машина зависает или не загружается после включения
Возможные причины
- Ошибка загрузчика, файловой системы, драйвера или службы внутри гостевой ОС.
- Неправильный порядок загрузки, отключённый загрузочный диск либо несовместимый режим BIOS/UEFI.
- Недоступность диска или виртуального контроллера во время старта.
- Проблема хоста или хранения затрагивает несколько VM.
Решение
Сначала проверьте консоль: если отображается загрузчик или ошибка ОС, запуск VM состоялся и дальнейший поиск ведётся в госте. Проверьте, виден ли загрузочный диск в конфигурации VM и соответствует ли режим загрузки созданной VM. Если консоль не реагирует и похожее происходит с другими VM на узле, вернитесь к журналам хоста, datastore и ресурсам. Подробная диагностика производительности и зависаний после локализации ресурсной причины — в статье «Производительность виртуализации: ресурсы VM и поиск узких мест»; диагностика ОС — в материалах разделов Linux Server, Windows Server и Security.
VMware ESXi: задачи, события, журналы и недоступность хоста
В поддерживаемых релизах vSphere задачи и события объекта обычно открывают в vSphere Client: выберите VM, ESXi-хост, datastore, кластер или доступный сетевой объект, затем перейдите в представление Monitor → Tasks and Events. Недавние операции также отображаются в Recent Tasks. Журналы самого ESXi-хоста просматривают у выбранного хоста в Monitor → Logs либо через соответствующее представление ESXi Host Client. Для ошибки VM сопоставляйте задачу питания с событиями VM и хоста; для стандартных vSwitch и Port Group проверяйте события и журналы хоста, а для distributed switch — также задачи и события этого объекта; для хранилища сопоставляйте события datastore и хоста. Точные названия и расположение разделов различаются между версиями vSphere Client, ESXi Host Client и vCenter Server.
Первичная диагностика ошибки VMware ESXi
- 1Проверьте доступность самого ESXiЕсли vCenter или веб-клиент не подключается, проверьте локальную либо out-of-band-консоль ESXi, IP-адрес management-интерфейса и связность до него. Если консоль хоста доступна, а сеть управления нет, проблема не обязательно означает отказ ESXi: локализуйте её в management-сети.
- 2Откройте последнюю неуспешную задачуВыберите VM или хост, найдите задачу с временем сбоя и прочитайте полный текст. Ожидаемый результат — указание на ресурс, файл, устройство, совместимость либо право. Если текст указывает на datastore, переходите к проверке его доступности и свободного места.
- 3Сверьте событие на уровне хостаПроверьте события и журналы ESXi-хоста за тот же промежуток времени. Сообщения о пути к устройству, файловой системе, сетевом адаптере или потере хранилища объясняют ошибку VM как следствие, а не как её первопричину.
- 4Остановитесь при признаках аварии гипервизораЕсли есть признаки Purple Screen of Death, повторяющиеся аппаратные ошибки либо требуется сбор дампов, не пытайтесь маскировать проблему перезапусками VM. Первичная задача — сохранить сведения о сбое и передать случай в отдельную процедуру диагностики ESXi.
Если ESXi не запускается после перезагрузки сервера, отделите проблему загрузки физического сервера, firmware и загрузочного носителя от доступности management-сети. Неисправность одного веб-интерфейса не доказывает отказ хоста: проверка локальной консоли и сетевой доступности определяет дальнейший путь. Установку и базовую конфигурацию ESXi рассматривает «Установка и первичная настройка VMware ESXi: хост, VM, datastore и vSwitch».
Hyper-V: разделите роль, гипервизор, службы и отдельную VM
Сообщение «ошибка Hyper-V» недостаточно для поиска причины. Последовательно различают: невозможность установить роль Hyper-V; установленную роль, после перезапуска которой не загрузился гипервизор; недоступные службы управления; и ошибку создания или запуска одной VM. Эти случаи используют разные журналы и не исправляются одинаковым перезапуском.
systeminfoПри незагруженном гипервизоре вывод содержит значения VM Monitor Mode Extensions, Virtualization Enabled In Firmware, Second Level Address Translation и Data Execution Prevention Available. При загруженном гипервизоре Windows сообщает, что он обнаружен и сведения об отдельных требованиях Hyper-V не отображаются.Get-WindowsFeature Hyper-V*; Get-VM; Get-VMHostGet-WinEvent -LogName 'Microsoft-Windows-Hyper-V-VMMS/Admin' -MaxEvents 30Как локализовать ошибки Hyper-V
| Симптом | Проверка | Что означает результат | Направление исправления |
|---|---|---|---|
| Роль не устанавливается | Проверить компоненты роли, System/Event Viewer, совместимость ОС и оборудования | Ошибка до создания VM | Проверить 64-битный CPU, аппаратную виртуализацию, SLAT, DEP и состояние firmware |
| После перезагрузки Hyper-V не запускается | Выполнить systeminfo, проверить события Hyper-V-Hypervisor и параметры загрузки | Роль может быть установлена, но гипервизор не загружен | Проверить включение виртуализации и DEP/NX/XD в firmware, конфликты загрузочной конфигурации и документацию Microsoft |
| Hyper-V Manager не подключается | Проверить службу VMMS, права, связь с сервером и журналы VMMS | Проблема управления не равна отказу всех VM | Восстановить службу или сетевую доступность без изменения конфигурации VM |
| Ошибка создания VM Hyper-V | Проверить путь хранения, права, свободное место, имя и параметры поколения | Ошибка относится к операции создания | Исправить каталог, разрешения или совместимость выбранных параметров |
| Виртуальная машина Hyper-V не запускается | Проверить событие Hyper-V-Worker, память, диски, контроллеры и состояние VM | Причина локальна для VM либо её зависимостей | Исправить подтверждённую зависимость; если VM включилась, перейти к диагностике гостя |
Для актуально поддерживаемых Windows Server Microsoft требует для Hyper-V 64-разрядный процессор с расширениями режима мониторинга VM, аппаратную виртуализацию, включённую в firmware, Second Level Address Translation (SLAT), и доступный аппаратный DEP: NX для AMD или XD для Intel. Наличие параметра в BIOS/UEFI нужно проверять по документации производителя сервера; универсального пути меню нет. Безопасный порядок включения описан в материале о VT-x, AMD-V и IOMMU.
Generation 1 Hyper-V VM использует эмулируемую BIOS-среду и поддерживает, в частности, загрузку с IDE-диска, виртуального DVD и legacy network adapter. Generation 2 использует UEFI и поддерживает загрузку с виртуального SCSI-диска, виртуального DVD либо сетевого адаптера; для совместимых гостевых ОС доступен Secure Boot. Поддержку поколения, гостевой ОС и выбранного шаблона Secure Boot нужно сверять для используемой версии Windows Server. Штатно изменить поколение уже созданной VM нельзя: при неверном выборе создают новую совместимую VM и планируют перенос данных. Создание VM и выбор поколения разобраны в «Установка и настройка Hyper-V на Windows Server: роль, VM и сеть».
Proxmox VE: узел, веб-интерфейс, сеть управления и no-subscription
При ошибке Proxmox сначала установите, загрузился ли узел. Если локальная консоль доступна, но веб-интерфейс Proxmox VE не открывается, проверяйте IP-адрес, сеть управления, DNS при его использовании, firewall и службы управления. Если веб-интерфейс работает, а не запускается одна VM, это уже отдельная проблема VM, её storage, сети или конфигурации.
systemctl --failed; journalctl -b -p warningpvesh get /nodes/$(hostname)/status; qm listqm status <VMID>; qm config <VMID>В веб-интерфейсе Proxmox VE обычно полезны состояние узла, история задач и журналы; на уровне ОС — системный журнал и состояние служб. Пути журналов, состав сервисов и конкретные команды зависят от версии Proxmox VE и базовой Debian-системы. Если VM стартует из интерфейса, но гостевая ОС не загружается, используйте её консоль и рассматривайте это как сбой гостя либо загрузочного диска, а не веб-интерфейса.
Что означает Proxmox no-subscription
no-subscription сообщает, что для узла нет действительной подписки. Само по себе оно не доказывает неисправность VM, кластера или узла. Enterprise Repository предназначен для систем с действительной подпиской; No-Subscription Repository — отдельный канал без требования подписки, но с иным назначением и моделью обновлений. Отдельно проверьте, соответствует ли настроенный репозиторий релизу Proxmox VE и выбранной модели сопровождения; предупреждение в интерфейсе не является доказательством того, какой репозиторий фактически на строен.Если Proxmox VE не загружается, не ограничивайтесь проверкой веб-порта: изучите сообщения загрузки, доступность системного диска, сетевых интерфейсов и служб. Если не открывается только интерфейс по сети, но узел и VM продолжают работать, исправление может находиться в management-сети, а не в VM. Первичную установку и выбор репозитория рассматривает «Установка и первичная настройка Proxmox VE».
VM не видит сеть: локализуйте путь до гостевой ОС
Проверяйте сеть по цепочке: виртуальный сетевой адаптер VM → подключение к виртуальному коммутатору, Port Group или bridge → VLAN → физический uplink → физический коммутатор и маршрутизация. Неработающий ping не доказывает сбой гипервизора: сначала нужно понять, получает ли vNIC линк и попадают ли кадры в правильный сегмент.
Первый уровень поиска ошибки виртуальной сети
| Платформа | Что проверить на VM | Что проверить на хосте | Граница, которую это определяет |
|---|---|---|---|
| VMware ESXi | vNIC присутствует, включён и подключён к ожидаемой Port Group | Port Group существует, VLAN согласован, vSwitch или distributed switch имеет рабочий uplink | Сбой находится до гостевой ОС, если vNIC не подключён либо недоступны Port Group, VLAN или uplink |
| Hyper-V | Адаптер VM подключён к правильному виртуальному коммутатору | Тип коммутатора, физический адаптер внешнего switch и состояние хоста | Доступная связность определяется типом switch: private, internal или external |
| Proxmox VE | В конфигурации VM есть net-интерфейс и назначен верный bridge/VLAN | Bridge или Open vSwitch активен, физический порт и VLAN доступны | Сбой находится до гостевой ОС, если недоступны bridge, VLAN или uplink |
В Hyper-V внешний виртуальный коммутатор подключает VM к физической сети; внутренний обеспечивает связь VM с хостом, но не прямой выход во внешнюю сеть; частный соединяет только VM одного хоста. Поэтому VM на private switch не должна иметь внешнюю связность без отдельной маршрутизации. В зависимости от Windows Server для проверки используют Hyper-V Manager, Virtual Switch Manager, Event Viewer и PowerShell, например Get-VMSwitch и Get-VMNetworkAdapter.
Get-VMSwitch; Get-VMNetworkAdapter -VMName '<имя_VM>'Если vNIC подключён правильно, bridge/Port Group доступен, VLAN и uplink проверены, а проблема остаётся только в одной VM, граница обычно переходит внутрь гостевой ОС: драйвер адаптера, IP-конфигурация, шлюз, DNS, маршрутизация или firewall. Не меняйте эти параметры наугад на уровне гипервизора. Подробности по vSwitch, VLAN, bridge и uplink — в «Сети виртуальных машин в ESXi, Hyper-V и Proxmox VE: vSwitch, VLAN и bridge»; дальнейшая проверка гостя — в профильных материалах по Linux Server, Windows Server и Security.
VM не видит виртуальный диск или datastore недоступен
Фраза «VMware не видит жесткий диск» может описывать разные состояния: диск отсутствует в конфигурации VM, отключён, подключён к другому контроллеру, datastore недоступен либо диск присутствует на виртуальном оборудовании, но его не видит гостевая ОС. Первые четыре случая ищут на уровне гипервизора; последний — уже в гостевой ОС.
Проверка диска и хранилища VM
- 1Проверьте конфигурацию VMУбедитесь, что виртуальный диск назначен VM, включён и подключён к существующему виртуальному контроллеру. Сверьте путь или объект хранилища с тем, что указан в неуспешной задаче. Если диска нет в конфигурации, не пытайтесь искать и подключать случайный файл без понимания его происхождения.
- 2Проверьте доступность storageНа уровне хоста убедитесь, что datastore, NFS/SMB-ресурс, SAN-путь, локальное хранилище или storage Proxmox VE отображаются доступными. Проверьте события пути к хранилищу и ошибки файловой системы. Если объект недоступен для нескольких VM, первопричина почти наверняка общая.
- 3Проверьте свободное местоСопоставьте свободную ёмкость с последними операциями: созданием snapshot, консолидацией, ростом thin-provisioned диска, клонированием или миграцией. Заполненный datastore может сорвать запуск VM, запись в диск или операцию со снимками. Освобождайте место только контролируемыми штатными операциями.
- 4Отделите гостевой уровеньЕсли виртуальный диск виден в настройках VM, задача запуска успешна и контроллер доступен, откройте консоль гостя. При отсутствии диска уже внутри ОС проверяют драйвер контроллера, обнаружение устройства, разметку и монтирование в рамках диагностики гостевой ОС.
Не исправляйте цепочку файлов вручную
Особенно внимательно проверяйте свободное место при thin provisioning и снимках: логически выделенная ёмкость может превышать физически свободное пространство, а операция консолидации сама нуждается в ресурсе хранилища. Устройство datastore, локального и общего хранения, а также vSAN разобраны в «Datastore и VMware vSAN: как организовать хранение виртуальных машин».
Ошибка при миграции виртуальной машины
Ошибка vMotion, Hyper-V Live Migration или миграции Proxmox VE должна анализироваться одновременно на исходном и целевом хостах. Конкретный набор предварительных условий зависит от типа миграции: для разных сценариев проверяют совместимость CPU и виртуального оборудования, сеть миграции, доступность и ёмкость хранилища, соответствие виртуальных сетей, права и функции, доступные в используемой платформе.
Базовые условия миграции
| Условие | Как проверить | Типичное следствие несоответствия |
|---|---|---|
| Совместимость хостов и CPU | Сверить поколения CPU, режимы совместимости и требования платформы к VM | Миграция отклоняется из-за неподдерживаемых инструкций или виртуального оборудования |
| Ресурсы целевого узла | Проверить доступную память, CPU, ограничения размещения и резервирования | Целевой хост не может принять VM |
| Сеть миграции | Проверить связность нужных интерфейсов, маршруты, MTU и выделенную конфигурацию по проекту | Передача состояния VM не начинается или прерывается |
| Хранилище | Установить, общее ли оно для обоих хостов или требуется перенос дисков | Целевой хост не видит файлы VM либо недостаточно места для переноса |
| Сеть VM на целевом хосте | Сверить Port Group, vSwitch, Hyper-V switch или bridge/VLAN | VM может мигрировать, но потерять сетевую связность после переноса |
| Права и функции платформы | Проверить полномочия учётной записи, конфигурацию кластера и доступность механизма в используемой редакции или подписке | Операция недоступна или запрещена до начала переноса |
Что сделать при неуспешной миграции
- 1Сохраните ошибку и проверьте обе стороныЗафиксируйте источник, цель, тип операции и полный текст ошибки. Сопоставьте время операции с задачами, событиями или журналами исходного и целевого хостов. Отметьте, на каком этапе произошёл сбой: предварительная проверка, передача памяти, перенос хранения или финальное переключение.
- 2Проверьте совместимость до повторной попыткиСравните CPU, версию виртуального оборудования, конфигурацию VM и ограничения устройств. Для VMware также учитывайте настроенный режим совместимости CPU, например EVC, если он применяется. Не изменяйте эти параметры на работающей критичной VM без плана отката.
- 3Проверьте путь данныхУбедитесь, что сеть миграции доступна между участниками, а требуемое хранилище доступно цели. При миграции с локальными дисками отдельно проверьте механизм переноса storage и запас места на целевой стороне.
- 4Сверьте виртуальные сети и праваЦелевой хост должен иметь соответствующую сеть для VM, а учётная запись — права на операцию и связанные объекты. Если задача отклонена политикой, лицензией или правами, исправьте именно это условие.
- 5Вынесите сложный сценарий в отдельный разборЕсли ошибка связана с Storage vMotion, Live Migration, Replica, кластером, локальным storage, passthrough-устройствами или несовместимостью версий, не подбирайте настройки на рабочей VM. Используйте отдельную процедуру миграции с проверкой простоя и отката.
Для VMware права на vMotion и доступность функций зависят от архитектуры vCenter/vSphere и приобретённых прав на конкретный набор продуктов. Для Hyper-V Live Migration важны настройки аутентификации, сеть, совместимость и конфигурация участвующих хостов. В Proxmox VE возможности зависят от версии, кластерной конфигурации, доступности storage и выбранного типа миграции; наличие или отсутствие подписки само по себе не является диагностикой ошибки миграции. Подробные сценарии — в «Миграция виртуальных машин: live migration, V2V и P2V» и «Hyper-V Live Migration, Storage Migration, Replica и высокая доступность».