Это первая часть очередной истории о том, как можно наступить на грабли, там, где обычно этого не ожидаешь. Началось всё с того, что для очередного развёртывания нескольких однотипных виртуальных машин Hyper-V с гостевой ОС Windows Server 2012 R2 был подготовлен эталонный образ виртуального диска с установленной ОС. В эталонный образ были включены все актуальные обновления, после чего для уменьшения размера диска был применён метод очистки хранилища компонент Windows в каталоге WinSxS, а логический том системного диска по своему объему был усечён таким образом, что на нём оставалось около 5GB свободного пространства. Перед отключением ВМ в эталонной гостевой ОС по законам жанра была выполнена утилита sysprep. В дальнейшем с этого образа было успешно развёрнуто несколько ВМ, имеющих конфигурацию ВМ, сопоставимую с эталонной ВМ. Спустя некоторое время после всей этой истории с пониманием того, что ранее несколько развёртываний с образа прошли успешно, была предпринята попытка развернуть ещё пару ВМ с этого же образа.
К нашему удивлению при первом же запуске новой ВМ гостевая ОС отказалась загружаться с сообщением об ошибке "Windows Setup could not configure Windows to run onthis computer's hardware" на этапе первичной инициализации.
Аналогичная ситуация повторилась и на второй новой ВМ, которую мы попытались развернуть с этого же образа. Попытка повторного перезапуска на обеих ВМ привела к другому сообщению об ошибке "Windows could not complete the installation. To install Windows on this computer restart the installation"
Далее после нажатия кнопки "OK" система отправлялась в перезагрузку и при следующей загрузке ситуация со второй ошибкой повторялась.
В попытках понять суть происходящего, в момент возникновения последней ошибки (не нажимая кнопки "OK" в окне сообщения об ошибке) жмём волшебную комбинацию клавиш Shift+F10 и попадаем в окно командной строки, выполняемое в контексте прав Администратора. Выполняем листинг содержимого файлов на системном диске C:\ …
dir C:\ /a
…и обнаруживаем, что свободного места на диске практически нет. При этом размер файла подкачки pagefile.sys, размещаемого по умолчанию в корне этого диска имеет внушительный размер.
И здесь мы вспоминаем про то, что предыдущие успешные развёртывания с данного образа виртуального диска выполнялись на виртуальные машины, имеющие небольшой объём ОЗУ, а последние две ВМ, где мы столкнулись с проблемой, при создании были сконфигурированы на использование большого объема ОЗУ. И предположительно, причиной невозможности корректной первичной инициализации системы стал раздутый файл подкачки.
В такой ситуации можно попробовать умерить аппетиты гостевой ОС на расширение файла подкачки, установив на время ограниченный максимальный размер файла. Для этого из уже открытой командной строки можем вызвать апплет управления свойствами системы sysdm.cpl. В открывшейся форме переходим на закладку управления расширенными настройками Advanced и в блоке Performance нажимаем кнопку Settings. В дополнительно открывшейся форме переходим на вкладку Advanced и в разделе Virtual memory используем кнопку Change чтобы изменить параметры файла подкачки.
Отключим используемое по умолчанию автоматическое определение размера файла подкачки, укажем первичный и максимально допустимый размеры файла через опцию Custom size (например, от 512MB, но не больше 2GB) и нажмём Set, затем OK.
Теперь можно попробовать перезагрузить виртуальную машину, и при следующей загрузке гостевой ОС свободного места на системном диске должно быть достаточно для нормальной первичной инициализации системы. В нашем случае одна из ВМ загрузилась успешно, а вторая ВМ, не смотря на доступность места на диске продолжила выдавать ошибку "Windows could not complete the installation…". Вероятно, в процессе первого запуска ОС с наличием проблемы с нехваткой свободного места на диске с механизмом OOBE (Out-of-Box Experience) что-то пошло не так.
На фоне сообщения об ошибке жмём уже знакомую комбинацию клавиш Shift+F10 и, попав в командную строку, перемещаемся в каталог C:\Windows\System32\oobe , где выполняем ручной запуск утилиты msoobe.exe
cd /d C:\Windows\System32\oobe msoobe.exe
В случае успешного вызова этой утилиты перед нами должно появиться стандартное окно первичной настройки параметров системы, которое появляется при первом запуске ранее sysprep-нутой системы.
После того, как определим языковые параметры, и на следующих двух экранах примем лицензионное соглашение и укажем учётные данные администратора, мастер первичной инициализации закроется и мы снова вернёмся на первоначальный чёрный экран с открытой командной строкой, в которой вызовем команду штатной перезагрузки гостевой системы:
shutdown /r /t 0
В нашем случае после перезагрузки гостевая система успешно загрузилась.
Если ранее установили небольшой фиксированный файл подкачки, то не забываем его вернуть обратно в автоматический режим, либо указываем другой устраивающий нас размер.
Делаем вывод, что если нам заранее известно то, что внутри шаблонного виртуального диска на системном томе гостевой ОС немного свободного места, то перед первым запуском ВМ лучше установить минимальный объём ОЗУ, исходя из которого система не будет пытаться создать файл подкачки большого размера. А уже после окончания процесса первичной инициализации можно будет увеличить размер ОЗУ ВМ до нужного объёма. Ну или же при создании эталонного диска можно устанавливать небольшой фиксированный размер файла подкачки, который, возможно, потребуется после первичной инициализации новой гостевой ОС, выставлять обратно в автоматический режим либо увеличивать под свои нужды.
С другой стороны, если Вам критична стабильность и предсказуемость работы развёрнутой из шаблона гостевой ОС и Вы испытали проблемы в ходе первичной инициализации OOBE, то лучше пытаться выполнять развёртывание повторно до тех пор, пока оно не отработает штатно. То есть лучше безжалостно удалять виртуальный диск, где первичная инициализация ОС прошла с ошибками и цеплять шаблонный диск к новой ВМ повторно для получения нужного результата. В противном случае с такой "кое-как взлетевшей" системой может случиться ещё несколько историй в духе "О сколько нам открытий чудных …". Одной из таких дивных историй я поделюсь в следующей заметке.
RSS - Записи
Обратная ссылка: Ошибка запуска службы MSDTC EventID 4691 "The run-time environment was unable to initialize for transactions required to support transactional components. Make sure that MS-DTC is running. (DtcGetTransactionManagerEx(): hr = 0x8000 /
Алексей, при всем уважении, мне кажется Вы сами наступили на собственные грабли. У МС есть рекомендации по минимальному объему диска под Windows server 2012. И вы явно ужались ниже их. И потом Вы же ужимаете виртуальный диск. А смысл? Он и так лежит файл-контейнером с минимальным объемом. Если ему не хватает физического диска - он сам добирает его.
Поделюсь своим опытом - Я развертываю виртуалки с МДТ2013. Сделано полностью молчаливое развертывание с преднастроенными ролями и установленными обновлениями. Время развертывания - 20 минут. Дальше уже доводка руками по месту. Раз в полгода делается новый образ (из-за приезжающих обновлений) Если есть желание - готов поделиться опытом в MDT-строении
Сергей, разумеется я согласен с тем, что сам аккуратно положил грабли, а потом про них благополучно забыл, и теперь эта заметка (как и следующая), как красивая шишка на лбу, будет напоминать мне об этом. Тут двух мнений быть не может. Однако по отношению к матёрой серверной ОС у меня всегда остаётся маленькая и наивная надежда в духе "оно должно само..." на предмет обработки подобных ситуаций. И с каждыми такими граблями надежда эта всё меньше и меньше :)
Ну ведь согласитесь, довольно неприятно осознать тот факт, что процесс выхода системы из сиспрепа довольно прямолинеен и дуболомен, так как не имеет банальной предварительной проверки наличия факта нехватки места на системном диске. Хотя, возможно, такая проверка и есть, но она никак не сопряжена с возможным неконтролируемым ростом файла подкачки в процессе запуска ОС.
Доброго! Подскажите, можно ли разместить десятку на единственном разделе, без создания томов EFI и recovery? Мой BIOS умеет грузить EFI с NTFS-раздела.
С семёркой, до появления UEFI, я обычно делал так: из-под рабочей системы создавал один активный загрузочный раздел NTFS/MBR и силами программки WinNTSetup выполнял стадию распаковки на него. После перезагрузки запускалась завершающая стадия - и готово. Recovery система размещала прямо на этом же томе.
Попробовал так же с десяткой, только на UEFI/GPT - не хочет: "Windows Setup could not configure Windows". Это она хочет EFI-раздел? Или что-то ещё ей не нравится? Как сделать правильно?