Исправление Windows 7 BSOD Stop 0x7B в виртуальной машине Xen после миграции с физического раздела на логический том

Question

У меня была двойная загрузка моего ноутбука (Sony Vaio-VGNCR26B) с двумя операционными системами Win7 и Ubuntu 12.04 LTS (я думаю, что сейчас это называется 12.04.1 LTS). Ранее я мог загружать родные окна с помощью VBox. Из любопытства я решил перейти на гипервизор с голым металлом, например, на Xen.

Сначала я клонировал весь 160 ГБ диск, чтобы убедиться, что я ничего не потерял. Затем я отдельно клонировал раздел Windows, используя Clonezilla. Вычистил жесткий диск и установил Ubuntu 12.04.2 LTS поверх LVM. ( Примечание: я дал Ubuntu 9 Гб пространства). После входа в новую систему я скачал, собрал и установил Xen 4.2.0. Наконец, я создал виртуальную машину для Windows 7.

Затем я установил Win7 на новый логический том 120 Гб, созданный для Windows. Это создало два раздела внутри логического тома. Системный раздел размером около 100 МБ, в котором хранится папка \Boot, а другой раздел передается корневой файловой системе. После успешной установки я восстановил сохраненный образ Windows, используя partclone, поверх текущего корневого раздела. Во время операции клонирования я увидел, что исходный образ (раздел) был 117 ГБ, а целевой раздел - 120 ГБ.

После завершения операции клонирования у меня осталась виртуальная машина Windows, которая переходит на начальный экран Windows и затем останавливается с BSOD (STOP: 0x0000007b). Расширенные параметры загрузки не помогают, поскольку в нем просто говорится, что я должен попытаться восстановить систему с помощью аварийного диска. Загрузка в режиме Win7 Rescue и выполнение Bootrec /fixboot (или /fixmbr) не помогают. Интересно, что Bootrec /ScanOs показывает 0 установок Windows. Все эти ошибки указывают на неверную таблицу разделов. Несмотря на то, что я могу без проблем смонтировать раздел под Linux, и Windows Rescue может увидеть раздел. Я также попытался включить драйверы из реестра, установив значение Start для всех ключей со ссылкой "Scsi Miniport" на 0 (0h). Я также проверил, была ли проблема с подписью диска, но подпись в реестре и уникальный идентификатор диска совпадают.

Итак, кто-нибудь знает какие-либо методы для исправления геометрии диска? Разрушит ли это данные на ВМ? Как я должен клонировать раздел 117 ГБ на 120 ГБ "диск"?

Заранее благодарю за то, что уделили время на мой вопрос!

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

Answer 1

Первой проблемой, с которой вы столкнулись, была не геометрия диска, это контроллер / драйвер хранилища в Windows. Проблема заключается в том, что собственная система Windows с двойной загрузкой использует любой контроллер хранилища, встроенный в вашу систему, в то время как Xen domU использует более старый контроллер IDE для представления эмулируемого диска (даже если вы проходите через физический раздел - это по-прежнему эмулирует контроллер хранилища). Для правильной загрузки Windows вам необходимо исправить накопитель в Windows - то есть вам нужно установить новый контроллер хранилища в Windows во время загрузки. Основная проблема заключается в том, что для установки нового драйвера хранилища необходимо успешно загрузить Windows. Я полагаю, что в большинстве руководств по P2V вы устанавливаете этот драйвер хранилища на нативную платформу перед тем, как завершить работу Windows и запустить ее на виртуальной платформе. Поэтому вам может потребоваться вернуться к двойной загрузке и загрузиться в Windows на собственном компьютере, установить новый драйвер хранилища, а затем выключить его, загрузить Xen и загрузить виртуальную машину Windows. Вы можете найти в Google множество руководств по Windows P2V, которые проведут вас через эти шаги.

Проблема с прохождением только раздела Windows к Xen domU заключается в том, что он пропускает только этот раздел, а не MBR или что-либо подобное. Для Windows 7 это может быть особенно плохо, так как она использует отдельный загрузочный раздел и фактически нуждается в обоих этих разделах. Загрузившись в режим восстановления и выполнив fixmbr, вы, вероятно, записали MBR в первые несколько секторов реального раздела Windows, что уничтожает некоторые данные. Возможно, есть способ исправить это, но на данный момент проще всего начать с нуля в Windows.

Кроме того, один последний момент - большинство компьютеров поставляются с лицензией OEM Windows. Я не эксперт по лицензированию, но Windows почти наверняка будет жаловаться на изменение аппаратной платформы и должна будет повторно лицензировать / активировать себя под новым оборудованием, которое может работать некорректно, так как Xen BIOS не имеет волшебного Windows OEM лицензионный бит.