-
Что такое сохранённое состояние в Hyper-V?
-
Почему VM Hyper-V не запускается?
-
Что происходит при удалении сохранённого состояния в Hyper-V?
-
Как исправить VM Hyper-V, зависшую в сохранённом состоянии?
-
Защитите виртуальные машины Hyper-V с Vinchin
-
Часто задаваемые вопросы о проблеме запуска Hyper-V из сохранённого состояния
-
Заключение
Когда VM Hyper-V отказывается запускаться, потому что зависла в сохранённом состоянии (Saved State), работа может полностью остановиться. Эта проблема часто встречается у ИТ-администраторов, особенно после перезагрузки хоста или во время аварийного восстановления. В этом руководстве мы объясним, что такое сохранённое состояние в Hyper-V, почему VM может не запускаться из этого состояния, что происходит при удалении сохранённого состояния и как пошагово исправить зависшую VM. Также рассмотрим расширенное устранение неполадок для сложных сред и лучшие практики, которые помогут избежать такой проблемы в будущем.
Что такое сохранённое состояние в Hyper-V?
Сохранённое состояние в Hyper-V фиксирует всё состояние работающей VM в определённый момент: содержимое памяти и состояние устройств. Благодаря этому можно приостановить работу и позже продолжить её без потери текущего прогресса. Когда вы переводите VM в сохранённое состояние, Hyper-V записывает в её папку два ключевых файла: .bin для данных памяти и .vsv для контекста устройств.
Вместе эти файлы позволяют Hyper-V безопасно "заморозить" активность VM. Файл .bin содержит точную копию данных, которые находились в RAM в момент паузы или завершения VM через Save, а не через Turn Off или Shut Down. Файл .vsv сохраняет сведения вроде регистров CPU и буферов сетевого адаптера.
Почему это важно? Если нужно перезагрузить хост-сервер или выполнить обслуживание, но при этом вы хотите, чтобы VM продолжили работу с того же места, а не просто перезапустились, используются именно эти файлы. Некоторые инструменты резервного копирования также переводят VM в сохранённое состояние, чтобы создать согласованные снимки без выключения гостевых ОС.
Важно не путать сохранённые состояния с checkpoints (снимками). Checkpoints включают изменения дисков, а сохранённые состояния сохраняют только временные данные из памяти.
Почему VM Hyper-V не запускается?
Когда VM зависает при попытке восстановления из сохранённого состояния и не загружается, сообщение об ошибке часто выглядит примерно так:
"Failed to restore virtual machine state" или
"The virtual machine is not compatible with physical computer."
Такая проблема означает, что между сохранением и восстановлением снимка памяти что-то нарушилось. Рассмотрим возможные причины:
Во-первых, повреждённые файлы .bin или .vsv не позволят возобновить работу, потому что важные данные отсутствуют или не читаются. Ещё одна частая причина - изменения оборудования: если VM перемещали между хостами с разными CPU или меняли аппаратные настройки, например добавляли или удаляли сетевые адаптеры, старый образ памяти может больше не соответствовать новой аппаратной конфигурации.
Также часто встречается нехватка ресурсов: если на хосте недостаточно свободной RAM или дискового пространства, он просто не сможет загрузить большой дамп памяти обратно в работу. Проблемы с хранилищем, например отключённые диски или изменённые буквы дисков, приводят к тому, что Hyper-V вообще не может найти нужные файлы.
Права доступа тоже имеют значение: если настройки безопасности Windows блокируют доступ к любой части папки VM, в том числе после того, как антивирус заблокировал файлы при проверке, появятся ошибки отказа в доступе.
Наконец, прерванные задания резервного копирования иногда оставляют VM в промежуточном и непригодном для запуска состоянии.
В кластерных средах с общим хранилищем (Cluster Shared Volumes) появляется дополнительная сложность: live migration между узлами может вызвать несовместимость версий, если хосты работают на разных сборках Windows Server или имеют разные уровни обновлений.
Иногда даже удаление сохранённого состояния не помогает, если в основе проблемы лежат более глубокие ошибки конфигурации, например несовместимые типы прошивки (VM Generation 1 и Generation 2) или разные версии integration services на хостах.
Что происходит при удалении сохранённого состояния в Hyper-V?
Удаление сохранённого состояния удаляет из папки VM оба файла: .bin и .vsv. Это заставляет виртуальную машину запускаться заново, как если бы питание было отключено принудительно, а не через корректное завершение работы.
Что это означает для данных? Любая несохранённая работа, которая находилась только в RAM, будет потеряна навсегда. Однако всё, что уже записано на виртуальные диски, останется в безопасности, поскольку удаление образов памяти само по себе не затрагивает диски.
Такой подход часто устраняет проблемы совместимости, вызванные повреждённым сохранённым состоянием, но перед удалением этих файлов в производственных системах всегда убедитесь, что у вас есть резервные копии. Обычно удаление безопасно, но оно необратимо для несохранённых данных приложений внутри гостевых ОС.
Если вы используете кластерные хосты с Cluster Shared Volumes (CSV), помните, что удаление сохранённых состояний, на которые всё ещё ссылаются другие узлы, может вызвать дополнительные проблемы синхронизации, если не выполнять операцию аккуратно через Failover Cluster Manager.
Как исправить VM Hyper-V, зависшую в сохранённом состоянии?
Рассмотрим решения от простых действий до расширенных методов восстановления, подходящих для корпоративных сред и даже кластеров. Каждый метод начинается с краткого объяснения, чтобы было понятно, почему он работает, прежде чем переходить к шагам.
Метод 1. Удалите сохранённое состояние через Hyper-V Manager
Большинство администраторов начинают с этого способа, потому что он быстрый и часто помогает устранить небольшие сбои, связанные с повреждёнными файлами сохранённого состояния.
Откройте Hyper-V Manager, затем выберите проблемную VM в списке слева. В правой панели в разделе Actions нажмите Delete Saved State и подтвердите действие. Затем попробуйте снова запустить VM через Start в Actions. Она должна загрузиться так, как будто ранее была выключена.
Метод 2. Проверьте ресурсы хоста и доступность хранилища
Если удаление не помогло или этот вариант недоступен, следующим шагом проверьте, не блокирует ли запуск нехватка ресурсов.
Сначала убедитесь, что на хост-сервере достаточно свободной RAM. Откройте Task Manager, перейдите на вкладку Performance и проверьте доступную память при обычной работе остальных нагрузок.
Затем проверьте свободное место на диске: откройте File Explorer, щёлкните правой кнопкой системные диски, выберите Properties и сравните свободное пространство с потребностями крупных VM.
Если VM хранятся на внешних дисках, SAN или NAS, подключённых через буквы дисков, проверьте, не изменились ли эти сопоставления с момента последнего успешного запуска. Несовпадающие пути нарушат попытку восстановления.
Для кластерных развертываний с CSV убедитесь через Failover Cluster Manager, что все узлы видят одинаковые пути к хранилищу, иначе могут возникнуть ошибки, связанные с миграцией.
Метод 3. Исправьте права доступа к файлам виртуальной машины
Ошибки отказа в доступе обычно указывают на нарушенные NTFS-разрешения в папках VM, часто после ручного перемещения или копирования файлов вне поддерживаемых инструментов.
Убедитесь, что учётная запись NT VIRTUAL MACHINE\<GUID> имеет Full Control для всех файлов внутри папки (.vhdx, .bin, *.vsv). Если разрешения отсутствуют:
1. Нажмите Add
2. Введите точное имя объекта
3. Предоставьте Full Control
4. Примените изменения рекурсивно
Либо запустите Command Prompt от имени администратора (не PowerShell) и выполните:
icacls.exe "C:\Path\To\VM\{VM-GUID}.bin" /grant "NT VIRTUAL MACHINE\{VM-GUID}":(F)
icacls.exe "C:\Path\To\VM\{VM-GUID}.vsv" /grant "NT VIRTUAL MACHINE\{VM-GUID}":(F)Если наследование разрешений полностью нарушено, используйте флаг /reset:
icacls.exe "C:\Path\To\VM\" /reset /T
Перед повторной попыткой запуска обязательно проверьте доступ через File Explorer.
Метод 4. Удалите файлы сохранённого состояния вручную
Иногда ни графический интерфейс, ни исправление разрешений не решают проблему. В таком случае может потребоваться прямое удаление файлов.
Перед началом:
1) Убедитесь, что нет активных заданий резервного копирования или checkpoints
2) Используйте Resource Monitor (resmon.exe) > вкладка CPU > строка поиска Associated Handles; введите часть имени файла (.bin, .vsv), чтобы убедиться, что целевые файлы не заблокированы
3) Если файл заблокирован, сначала остановите соответствующий процесс или службу
Затем:
1) Полностью выключите затронутую VM, если это возможно
2) Откройте консоль Services (services.msc)
3) Найдите службу Hyper-V Virtual Machine Management
4) Щёлкните правой кнопкой и выберите Stop
5) Перейдите в C:\ProgramData\Microsoft\Windows\Hyper-V\Virtual Machines
6) Удалите оба файла .bin и .vsv, соответствующие GUID зависшего экземпляра
7) Перезапустите службу управления через ту же консоль (Start)
8) Попробуйте снова запустить затронутую VM
Метод 5. Обновите версию конфигурации виртуальной машины
Старые VM, созданные в предыдущих версиях Windows Server, могут хранить форматы сохранённого состояния, несовместимые с новыми хостами после обновлений или миграций. Это частая проблема при обновлении инфраструктуры.
В таких случаях:
1) Убедитесь, что целевая VM полностью выключена, а не просто приостановлена или сохранена
2) Откройте Hyper-V Manager
3) Выберите нужный экземпляр
4) В панели Actions нажмите Upgrade Configuration Version
5) Подтвердите обновление
После этого попробуйте запустить VM обычным способом. Большинство проблем совместимости исчезает, когда метаданные соответствуют стандартам текущей платформы.
Метод 6. Устраните конфликты сетевых адаптеров и совместимости хостов
Ошибки с упоминанием несовместимости часто возникают из-за неправильной конфигурации сетевых адаптеров после миграции между хостами или из-за переименования/удаления связанных виртуальных коммутаторов.
Откройте Virtual Network Manager в интерфейсе Hyper-V Manager и убедитесь, что каждый подключённый адаптер соответствует действительному имени switch, доступному на локальном хосте или узлах.
При необходимости:
переименуйте switches обратно, чтобы имена совпадали на исходном и целевом серверах;
переназначьте адаптеры напрямую в окне Settings каждой затронутой гостевой системы.
Для опытных пользователей: проверьте уникальность MAC-адресов всех адаптеров с помощью PowerShell:
Get-VMNetworkAdapter -All | Select Name,MacAddress
Дублирующиеся MAC-адреса могут вызывать трудноуловимые проблемы с подключением, особенно после одновременного импорта или экспорта нескольких гостевых систем.
Метод 7. Экспортируйте и повторно импортируйте конфигурацию виртуальной машины
Если полное пересоздание кажется слишком радикальным, но повреждение конфигурации сохраняется, попробуйте экспортировать и импортировать метаданные:
1) Запустите PowerShell с повышенными правами
2) Выполните Export-VM -Name "<Your_VM_Name>" -Path "<Export_Directory>"
3) Удалите исходный экземпляр из инвентаря (не удаляйте диски!)
4) Импортируйте обратно с помощью Import-VM -Path "<Export_Directory>\<Config_File>.xml"
5) Подключите существующие диски при соответствующих запросах мастера импорта
Этот процесс обновляет внутренние ссылки, не затрагивая пользовательские данные на подключённых томах.
Метод 8. Пересоздайте виртуальную машину с существующими дисками (крайний вариант)
В крайнем случае сначала задокументируйте все текущие настройки, включая назначенные CPU, RAM и сетевую схему, из исходной конфигурации в инструментах управления.
Полностью удалите неисправный экземпляр (НЕ удаляйте диски .vhdx/.avhdx!)
Создайте новую гостевую систему с теми же характеристиками
В мастере выберите вариант "Use an existing virtual hard disk" и укажите сохранённые файлы дисков
Запустите новый экземпляр. Он должен работать так же, но уже поверх чистого слоя метаданных и конфигурации.
Защитите виртуальные машины Hyper-V с Vinchin
Чтобы дополнительно защититься от непредвиденных простоев, вызванных проблемами вроде "saved state cannot start", стоит внедрить надёжную защиту резервными копиями. Vinchin - корпоративное решение, специально разработанное для профессионального резервного копирования виртуальных машин на более чем 15 популярных платформах, включая полную поддержку Microsoft Hyper-V, а также VMware, Proxmox VE, oVirt, OLVM, RHV, XCP-ng, XenServer, OpenStack, ZStack и других.
Vinchin предоставляет комплексные функции, такие как Бесконечное инкрементное резервное копирование для минимизации использования хранилища, встроенные дедупликация и сжатие для оптимизации производительности, удобная кроссплатформенная V2V-миграция, резервное копирование по расписанию и повторяющиеся задания для автоматизации, а также многое другое.
В интуитивно понятной веб-консоли Vinchin резервное копирование VM Hyper-V выполняется всего за четыре шага:
1. Выберите конкретную машину Hyper-V из инвентаря;

2. Выберите место хранения резервных копий;

3. Настройте стратегии, например расписание, дедупликацию и шифрование, в соответствии с требованиями политики;

4. Отправьте задание.

Тысячи организаций по всему миру доверяют Vinchin, а стабильно высокие оценки подтверждают качество решения. Вы можете без риска оценить все возможности продукта с бесплатной 60-дневной пробной лицензией, которая включает полный набор функций.
Часто задаваемые вопросы о проблеме запуска Hyper-V из сохранённого состояния
Вопрос 1. Может ли обновление Windows Server привести к тому, что сохранённые состояния работающих VM не запустятся?
Ответ: Да. Крупное обновление может изменить базовые компоненты, из-за чего старые сохранённые состояния станут несовместимыми, пока их не удалят вручную или корректно не обновят конфигурацию.
Вопрос 2. Как быстро проверить, какой процесс блокирует файл .bin/.vsv?
Ответ: Откройте Resource Monitor > вкладка CPU > введите часть имени файла в поле Associated Handles > сразу определите процесс или службу, которая блокирует файл.
Вопрос 3. Что делать, если кластерный узел отказал во время live migration и несколько VM зависли?
Ответ: Используйте Failover Cluster Manager > временно перенесите владение ролью на другой узел > вручную очистите сохранённое состояние для каждой затронутой гостевой системы, а затем верните владение рабочей нагрузкой обратно.
Заключение
Зависшее сохранённое состояние может нарушить работу бизнеса, но аккуратное устранение неполадок в большинстве случаев помогает быстро вернуть VM в рабочее состояние без лишнего пересоздания. Регулярное резервное копирование остаётся обязательным. Vinchin делает защиту даже сложных многохостовых сред простой, надёжной и эффективной. Попробуйте Vinchin сегодня и держите простои под контролем.