Бета-версия macOS 27 не устанавливается в виртуальной машине? Инструкция по исправлению
Бета-версия macOS 27 Golden Gate не устанавливается в UTM, Parallels и VMware с ошибкой установки. Разбираемся, почему это происходит и как это исправить.
Вы делаете всё правильно и осторожно. Вместо того чтобы устанавливать свежую бета-версию macOS 27 «Golden Gate» на свой основной рабочий Mac, вы решаете сначала протестировать её в виртуальной машине — именно так, как и полагается поступать ответственному разработчику или продвинутому пользователю. Вы скачиваете образ восстановления, указываете его в UTM, Parallels или VMware Fusion, нажимаете на создание виртуальной машины, наблюдаете, как индикатор прогресса медленно ползёт вперёд несколько минут, а затем всё резко останавливается с лаконичным окном: «Произошла ошибка при установке. Установка не удалась.» Никакого лога, который стоило бы читать, никакого кода для поиска, ни единой подсказки о том, что пошло не так. Вы пробуете снова. Результат тот же. Вы переключаетесь между приложениями — от UTM к VirtualBuddy и Tart — и каждое из них падает в одном и том же месте с одним и тем же бесполезным сообщением. Если бета-версия macOS 27 не устанавливается в виртуальной машине на вашем Mac, дело не в неправильной настройке и не в повреждённом файле загрузки. Вы столкнулись с известной, признанной Apple ошибкой, и никакие повторные попытки её не исправят, пока вы не измените одну конкретную вещь в своей конфигурации.
Это одна из самых неприятных проблем, с которыми сталкиваются первые пользователи новой бета-версии macOS, именно потому, что она наказывает тех, кто делает всё правильно. Весь смысл использования виртуальной машины — избежать риска, а здесь ломается как раз безопасный путь. Хуже того, обобщённая ошибка «установка не удалась» создаёт впечатление локальной проблемы — плохой IPSW, нехватка места на диске, неверные настройки виртуальной машины, — из-за чего люди тратят часы на бесполезное устранение неполадок, которое в принципе не могло сработать, потому что первопричина вообще не на их стороне экрана. Она кроется во взаимодействии между версией macOS, которая сейчас работает на вашем Mac, и версией macOS, которую вы пытаетесь установить в гостевую систему.
В этом руководстве мы подробно разберём, как именно выглядит эта ошибка, кто с ней сталкивается, а кто нет, и почему вообще стоит тестировать бета-версию в виртуальной машине. Затем мы перейдём к сути дела: реальной первопричине — несовместимости в Virtualization framework от Apple между хостом на macOS 26.6 и инсталлятором macOS 27, — объяснённой достаточно понятно, чтобы вы точно поняли, почему все приложения для виртуализации падают одинаково. Далее мы рассмотрим три реально работающих обходных решения, особенности для каждого приложения — UTM, VirtualBuddy, Tart, Parallels и VMware Fusion, — а также более безопасные альтернативы, заслуживающие внимания. Это подвижная бета-ситуация, поэтому мы будем честны на всём протяжении статьи о том, что уже устоялось, а что может измениться со следующей сборкой.
Основные выводы
- Сообщение «Произошла ошибка при установке. Установка не удалась.» — это известная, признанная Apple ошибка, а не ваша оплошность: она проявляется одинаково в UTM, VirtualBuddy, Tart, Parallels и VMware Fusion, потому что все они используют один и тот же базовый механизм установки.
- Первопричина — несовместимость в Virtualization framework от Apple, а именно в API
VZMacOSInstaller, когда Mac под управлением macOS Tahoe 26.6 пытается установить образ восстановления macOS 27 Golden Gate в гостевую систему. Операционная система хоста слишком стара, чтобы управлять более новым инсталлятором. - Обходное решение 1: создайте или установите виртуальную машину с macOS 27 на Mac, на котором уже работает macOS 27, — это полностью устраняет несоответствие между хостом и гостевой системой.
- Обходное решение 2: сначала создайте виртуальную машину с macOS Tahoe, а затем обновите её до бета-версии macOS 27 изнутри гостевой системы через Software Update (после регистрации в программе Apple Beta), вместо того чтобы устанавливать 27 «с нуля» из IPSW.
- Обходное решение 3: просто подождите обновлённую бета-сборку или обновлённое приложение для виртуализации, которое устранит несоответствие в API, — поскольку это бета-версия, набор затронутых сборок может меняться от релиза к релизу.
- На Apple silicon все эти приложения работают поверх одного и того же фреймворка Apple, гостевые системы macOS исторически ограничены двумя виртуальными машинами на хост согласно лицензии Apple, а гостевые системы не могут входить в некоторые сервисы, привязанные к DRM и iCloud, — это стоит знать, прежде чем вообще вкладывать время в виртуальную машину.
Как выглядит ошибка «установка не удалась» и кто с ней сталкивается
Сбой выглядит почти одинаково независимо от того, каким приложением вы пользуетесь, — и это первый серьёзный намёк на то, что проблема не в самом приложении. Вы начинаете обычный процесс создания новой виртуальной машины с macOS: выбираете установку новой гостевой системы macOS, передаёте приложению образ восстановления macOS 27 (файл IPSW) или позволяете ему загрузить его самостоятельно, выделяете ядра процессора, память и диск, и запускаете процесс. На ранних этапах всё выглядит совершенно нормально. Приложение распаковывает образ восстановления, разворачивает временную среду установки и показывает индикатор прогресса, который убедительно продвигается вперёд от тридцати секунд до нескольких минут. Затем, где-то на середине пути, всё резко останавливается, и вы видите лаконичное диалоговое окно примерно такого содержания: «Произошла ошибка при установке. Установка не удалась.» Одни приложения показывают это как системное предупреждение macOS, другие выводят его в собственном интерфейсе или записывают короткую строку в лог. Формулировка намеренно обобщённая, потому что само приложение зачастую не получает от фреймворка, выполняющего основную работу, подробной причины сбоя.
Поскольку сообщение настолько скудное, люди естественным образом решают, что сделали что-то не так, и тратят время в погоне за причинами, которые никогда не были проблемой. Они заново скачивают IPSW на случай, если файл повреждён. Проверяют контрольные суммы. Выделяют виртуальной машине больше места на диске, больше оперативной памяти, больше ядер. Удаляют и заново создают виртуальную машину с нуля. Перебирают все настройки, какие только могут найти. Ничего из этого не меняет результат, потому что ни одна из этих вещей на самом деле не является причиной сбоя. Установка заходит достаточно далеко, чтобы доказать: ваша загрузка в порядке, а выделенных ресурсов достаточно — процесс не спотыкается о недостающий байт или тесный диск, — а затем упирается в стену, встроенную в сам механизм установки, которую никакая настройка на стороне виртуальной машины сдвинуть не может.
Точное поведение в разных приложениях
Эту ошибку легко узнать именно благодаря её постоянству. В UTM вы видите, как мастер создания виртуальной машины доходит до этапа установки и выдаёт сбой. В VirtualBuddy, созданном специально вокруг стека виртуализации Apple именно для такого рода тестирования, управляемый инсталлятор падает на том же этапе. Tart — ориентированный на командную строку инструмент, популярный в CI и автоматизированных настройках, — возвращает ошибку установки вместо готового образа. Parallels Desktop и VMware Fusion, два крупных коммерческих гипервизора, тоже дают сбой при передаче им образа восстановления macOS 27 на затронутом хосте. Если бы речь шла о локальной неправильной настройке, можно было бы ожидать, что приложения будут давать сбой по-разному — на разных этапах, с разными сообщениями, с разными особенностями, — ведь каждое из них по-своему оборачивает фреймворк. Тот факт, что все они падают в одной и той же точке с одной и той же обобщённой ошибкой, — это признак общей вышестоящей причины, а не пяти отдельных совпадений.
Кого это затрагивает, а кого нет
Граница проходит по тому, что установлено на вашем хост-Mac, а не по тому, какое приложение для виртуализации вы выбрали. Если ваш Mac сейчас работает на macOS Tahoe 26.6 (включая её бета-версии) и вы пытаетесь установить гостевую систему macOS 27 через стандартный путь установки Virtualization framework, вы попадаете в затронутую группу. Если ваш Mac уже работает на самой macOS 27 и вы создаёте гостевую систему 27-й версии, вы, как правило, не затронуты, поскольку хост и гостевая система совпадают по версии. Именно поэтому одни люди в интернете уверяют, что бета-версия устанавливается в виртуальной машине «нормально», а другие никак не могут пройти дальше ошибки — они просто работают на разных операционных системах хоста. Именно этим объясняется и то, насколько проблема привязана ко времени: она проявилась ровно тогда, когда люди на текущей ветке Tahoe начали пытаться развернуть только что вышедшую бету 27-й версии, и она сойдёт на нет по мере того, как хосты перейдут на 27-ю версию или Apple выпустит сборку, устраняющую несоответствие. Учитывайте, что, поскольку это бета-версия, ситуация подвижна: точные сборки по обе стороны границы могут меняться, поэтому воспринимайте указанные здесь номера версий как положение дел на момент написания, а не как постоянное правило.
Зачем вообще тестировать macOS 27 в виртуальной машине
Прежде чем перейти к решению, стоит чётко понять, почему столько людей идут на эти сложности, — это объясняет, почему данная ошибка настолько раздражает, а не просто пожимает плечами. Запуск совершенно новой, первогодней бета-версии macOS на Mac, от которого вы зависите каждый день, действительно рискован. Ранние бета-версии могут ломать расширения ядра, повреждать данные при откате, сажать батарею и делать сторонние приложения неработоспособными, а macOS 27 несёт в этом цикле дополнительную нагрузку, поскольку это первый релиз исключительно для Apple silicon, последний с поддержкой Rosetta 2 и конец эпохи Intel Mac — множество движущихся частей меняется одновременно. Виртуальная машина даёт возможность потыкать всё это, не ставя на кон свою рабочую среду ради беты, которую сама Apple называет незавершённой. Если вы хотите увидеть более широкую картину происходящих изменений, наш обзор того, что было анонсировано на WWDC 2026, включая функции, совместимость и сроки выхода, задаёт контекст того, почему именно этот релиз привлекает столько тестировщиков.
Снимки состояния и мгновенный откат
Самая главная причина тестировать именно в виртуальной машине — это снимок состояния (snapshot). Перед установкой рискованного обновления, экспериментами с новым API или запуском программы, которой вы не доверяете, вы делаете снимок — замороженную копию всего состояния машины, — и если что-то пойдёт не так, вы откатываетесь к нему за секунды. Никакой переустановки, никакого восстановления из резервной копии, никакого потерянного дня: вы нажимаете кнопку, и виртуальная машина снова точно такая же, какой была до того, как вы её сломали. Для тестирования бета-версий это меняет всё. Вы можете установить бету, посмотреть, как она разваливается, откатиться, что-то поправить и попробовать снова десяток раз за то время, которое ушло бы на одну переустановку macOS на реальном железе. Голое железо просто не может сравниться с таким циклом, поэтому разработчики, которым нужно надёжно воспроизводить ошибки, в первую очередь обращаются к виртуальным машинам.
Изоляция от ваших реальных данных и настроек
Виртуальная машина также представляет собой герметичную коробку. Что бы бета-версия ни делала — порождала странные фоновые процессы, портила настройки, некорректно вела себя с вашими учётными записями, — всё это происходит внутри гостевой системы, а не на вашем реальном диске. Ваши настоящие фотографии, документы, связки ключей и лицензии приложений остаются в безопасности на хосте, нетронутыми. Именно эта изоляция и делает ошибку «установка не удалась» такой болезненной: вся ценность виртуальной машины в том, что она позволяет осторожным людям безопасно тестировать пугающее программное обеспечение, а эта ошибка захлопывает дверь именно перед осторожным путём, оставляя широко открытым безрассудный путь «просто установить на основной Mac». Если вы не хотите бороться с виртуальной машиной вообще и рассматриваете бету на реальном железе, прочитайте наш честный разбор того, стоит ли устанавливать бета-версию macOS 27 для разработчиков и её известные проблемы, прежде чем решаться, — ведь от страховочной сетки виртуальной машины не стоит отказываться легкомысленно.
Первопричина: несоответствие между хостом и гостевой системой в Virtualization framework
Вот та часть, которая на самом деле всё объясняет. Причина, по которой бета-версия macOS 27 не устанавливается в виртуальной машине на хосте с Tahoe, — это несовместимость внутри собственного Virtualization framework от Apple, низкоуровневого системного компонента, на который опирается каждое из этих приложений при создании и установке гостевых систем macOS на Apple silicon. Конкретно речь идёт об инсталляторной части этого фреймворка — API, отвечающем за превращение образа восстановления macOS в загружаемую гостевую систему, — который не может корректно обработать образ восстановления macOS 27, когда работает на хосте с macOS 26.6. Apple признала это на Developer Forums как известную проблему. Короче говоря: Mac под управлением Tahoe 26.6 не может использовать путь установки через виртуализацию Apple для развёртывания образа восстановления macOS 27, и пока хост не будет обновлён либо Apple не исправит фреймворк, этот путь заблокирован.
Как на самом деле работает виртуализация на Apple silicon
Чтобы понять, почему это происходит, нужно разобраться, как виртуальные машины работают на Apple silicon, — а это сильно отличается от эпохи Intel. На Mac с Apple silicon сторонние приложения не поставляют собственный низкоуровневый гипервизор для запуска гостевых систем macOS. Вместо этого Apple предоставляет Virtualization framework (Virtualization.framework) как часть macOS, и именно этот фреймворк выполняет всю основную работу: он описывает виртуальное оборудование, загружает гостевую систему и — что критически важно здесь — устанавливает macOS в новую гостевую систему из образа восстановления. Такие приложения, как UTM, VirtualBuddy, Tart, Parallels и VMware Fusion, для случая гостевой системы macOS по сути представляют собой продуманные интерфейсы и слои управления, обёрнутые вокруг этого общего фреймворка Apple. Apple даже поставляет минималистичный эталонный инструмент macosvm, который демонстрирует те же самые базовые вызовы. Такая архитектура элегантна, и именно благодаря ей виртуализация macOS-в-macOS работает настолько чисто на Apple silicon в обычное время, — но это также означает, что каждое приложение наследует ошибки фреймворка, поскольку все они используют один и тот же движок. Наше более широкое руководство по виртуализации macOS подробнее разбирает эту архитектуру, если вам нужна полная картина.
Где ломается путь VZMacOSInstaller
Внутри этого фреймворка компонент, устанавливающий новую гостевую систему macOS, — это тот, который берёт ваш образ восстановления и превращает его в работающую систему. Когда вы передаёте приложению для виртуализации IPSW macOS 27 и просите его создать новую гостевую систему, приложение обращается к этому инсталляторному API, который считывает образ восстановления, проверяет его, настраивает виртуальное хранилище гостевой системы и записывает в него macOS 27. Проблема в том, что код инсталлятора, встроенный в хост с macOS 26.6, по сути старше, чем образ восстановления macOS 27, который его просят обработать. Образ 27-й версии ожидает поведения инсталлятора, которое фреймворк хоста с 26.6 ещё не предоставляет, и когда это несоответствие проявляется в середине установки, фреймворк прерывает процесс. Приложение сверху получает сбой без подробного объяснения и показывает вам обобщённое окно «установка не удалась». Это проблема расхождения версий: то, что выполняет установку, на шаг отстаёт от того, что устанавливается, и они не могут встретиться посередине.
Почему все приложения для виртуализации падают одинаково
Как только вы понимаете, что инсталлятор находится внутри фреймворка Apple, а не в самих приложениях, одинаковые сбои перестают казаться загадкой. UTM, VirtualBuddy, Tart, Parallels и VMware Fusion в конечном счёте направляют установку новой гостевой системы macOS через один и тот же инсталляторный API Apple. Поэтому, когда этот API не может обработать образ 27-й версии на хосте с 26.6, не имеет значения, через какой отполированный интерфейс вы к нему подошли, — все они упираются в одну и ту же сломанную дверь. Именно поэтому никакое устранение неполадок на стороне приложения не помогает и почему обновление одного лишь приложения для виртуализации может как исправить ситуацию, так и не исправить: решение должно прийти либо от операционной системы хоста (переход на версию, чей фреймворк понимает образ 27-й версии), либо от Apple, исправляющей фреймворк в обновлении хоста, либо от более поздней беты 27-й версии, чей образ текущий фреймворк способен обработать. Именно эта реальность формирует три обходных решения ниже.
Особенности для каждого приложения: UTM, VirtualBuddy, Tart, Parallels, VMware Fusion
Хотя первопричина общая, у каждого приложения есть свои особенности в том, как оно проявляет проблему и какие обходные решения подходят ему лучше всего. Вот чего ожидать от каждого из них.
UTM
UTM — популярный бесплатный виртуализатор с открытым исходным кодом, и для многих это первая остановка, поскольку он ничего не стоит и работает как с гостевыми системами macOS через виртуализацию Apple, так и с гостевыми системами на базе QEMU для других ОС. Для гостевой системы macOS 27 на Apple silicon он использует бэкенд Apple Virtualization, а значит, напрямую наследует ошибку инсталлятора. В UTM сбой обычно проявляется во время управляемой установки macOS после выбора IPSW. Пересоздание виртуальной машины, смена IPSW или изменение настроек ресурсов не помогут обойти проблему на затронутом хосте. Тем не менее UTM отлично подходит для обходного решения 2: сначала создайте гостевую систему macOS Tahoe в UTM (она устанавливается без проблем на хосте с Tahoe), а затем обновите эту гостевую систему до беты 27-й версии изнутри.
VirtualBuddy
VirtualBuddy — это бесплатный, узкоспециализированный инструмент, построенный специально вокруг Virtualization framework от Apple для загрузки, установки и запуска гостевых систем macOS, и он особенно любим именно для такого рода тестирования бета-версий, поскольку делает возможности фреймворка легко доступными. Эта тесная связь означает, что он также напрямую подвержен ошибке инсталлятора — весь его процесс установки и есть процесс установки фреймворка. VirtualBuddy отлично справляется с удобной загрузкой образов восстановления и управлением снимками состояния, поэтому он остаётся сильным выбором, как только вы обходите ошибку: используйте его для создания гостевой системы Tahoe и снимка состояния, а затем обновляйте на месте. Следите за его релизами, поскольку инструмент, настолько близкий к фреймворку, часто быстро добавляет поддержку новых особенностей бета-версий.
Tart
Tart — это инструмент виртуализации для командной строки, ориентированный на автоматизацию и непрерывную интеграцию, где виртуальные машины macOS создаются, используются и уничтожаются программно. Он тоже опирается на Virtualization framework от Apple, поэтому команда tart create, забирающая образ macOS 27 на хосте с 26.6, столкнётся с той же ошибкой установки вместо создания рабочего образа. Для CI-конвейеров эта ошибка особенно разрушительна, поскольку весь смысл в необслуживаемых, воспроизводимых сборках. Самое чистое решение для пользователей Tart — обходное решение 1: выполняйте шаг сборки образа на раннере, который уже работает на macOS 27, — либо заранее собирайте гостевую систему 27-й версии в другом месте и распространяйте готовый образ на свои раннеры вместо установки с нуля на каждом затронутом хосте.
Parallels Desktop
Parallels Desktop — отполированный коммерческий гипервизор, наиболее известный запуском Windows на Mac, но на Apple silicon он также создаёт гостевые системы macOS через фреймворк Apple, и эти гостевые системы macOS упираются в ту же инсталляторную стену на хосте с Tahoe. Parallels обычно оперативно выпускает обновления к новым релизам macOS, поэтому стоит проверить обновление приложения, — но помните: если дефект находится во фреймворке хоста, одно только обновление Parallels может не решить проблему, пока сам хост не продвинется вперёд. Parallels — комфортная среда для обходного решения 2, поскольку его инструменты снимков состояния и управления гостевыми системами достаточно зрелые и делают путь «установить Tahoe, затем обновить» простым.
VMware Fusion
VMware Fusion, теперь бесплатный для личного использования, аналогично полагается на Virtualization framework от Apple для гостевых систем macOS на Apple silicon и даёт сбой таким же образом при передаче образа восстановления macOS 27 на затронутом хосте. Как и в случае с Parallels, следите за обновлениями Fusion, но не рассчитывайте, что одно только обновление приложения преодолеет ограничение фреймворка хоста. Fusion хорошо подходит для пути «сначала Tahoe, затем обновление», и если ваша цель — просто иметь рабочую песочницу с macOS 27, а не тестировать именно процесс установки с нуля, этот путь приведёт вас туда, ничего не дожидаясь.
Общая нить для всех пяти одна и та же: выбранное вами приложение меняет интерфейс и удобные функции, но не фундаментальную причину. Выберите то, чьи инструменты снимков состояния и управления вам нравятся больше всего, а затем примените одно из обходных решений ниже.
Обходное решение 1: создайте виртуальную машину на Mac, уже работающем на macOS 27
Самое прямое решение полностью устраняет несоответствие: установите гостевую систему macOS 27 на Mac, на котором уже работает macOS 27 в качестве хоста. Поскольку суть ошибки в том, что фреймворк хоста отстаёт на шаг от образа гостевой системы, размещение хоста на том же поколении, что и гостевая система, позволяет инсталляторному API корректно обработать образ восстановления 27-й версии, и виртуальная машина создаётся нормально. Если у вас случайно есть второй Mac — или запасной раздел, или внешний загрузочный диск — уже на бете 27-й версии, создавайте свои гостевые системы 27-й версии там, и ошибка «установка не удалась» просто не возникнет.
Очевидная загвоздка носит замкнутый характер: многие хотят виртуальную машину именно для того, чтобы не запускать 27-ю версию на реальном Mac, а это обходное решение просит их запустить 27-ю версию на реальном Mac ради создания виртуальной машины. Это справедливое возражение, и если у вас только один Mac и вы не готовы переводить его на бету, этот путь не для вас — переходите к обходному решению 2. Но есть ситуации, где оно подходит идеально. Если у вас есть более старый или запасной Mac на Apple silicon, который вы можете позволить себе перевести на бету, выделить его под «фабрику виртуальных машин» — чистое решение: переведите эту машину на 27-ю версию, создайте и сделайте снимки состояния для стольких гостевых систем 27-й версии, сколько позволяет ваша лицензия, а затем эти образы гостевых систем можно переносить и переиспользовать. Команды, работающие с CI, могут применить ту же идею, выделив сборочные раннеры, живущие на 27-й версии, и генерируя там образы гостевых систем для потребления всеми остальными.
Если вы идёте этим путём, делайте это осознанно, а не переводя основную машину на бету по прихоти. Наше руководство по безопасной установке публичной беты macOS 27 описывает, как перевести реальный Mac на бету с надлежащими резервными копиями и путём отступления, что важно даже для машины, которую вы считаете расходной. А если позже вы захотите вернуть этот хост на стабильную macOS, заранее знайте путь выхода — наше пошаговое руководство о том, как откатиться с беты macOS 27 обратно на Tahoe без потери данных, существует именно для такого момента.
Обходное решение 2: сначала создайте виртуальную машину с Tahoe, затем обновите её через Software Update
Это обходное решение, которое на практике захотят использовать большинство владельцев одного Mac, поскольку оно не требует ничего, кроме Mac, уже работающего на Tahoe. Суть в том, что ошибка затрагивает только установку macOS 27 с нуля из образа восстановления через инсталлятор фреймворка. Она не затрагивает работу уже установленной гостевой системы macOS и не затрагивает обычный механизм обновления «на месте» внутри работающей гостевой системы. Поэтому вместо того чтобы пытаться установить 27-ю версию напрямую, вы сначала устанавливаете гостевую систему macOS Tahoe — которая прекрасно работает на хосте с Tahoe, поскольку хост и гостевая система совпадают, — а затем обновляете эту гостевую систему до беты 27-й версии изнутри, с помощью Software Update, точно так же, как обновляли бы реальный Mac.
Пошаговая инструкция
Начните с создания обычной виртуальной машины macOS Tahoe в выбранном вами приложении для виртуализации. Укажите ему образ восстановления Tahoe (или позвольте приложению загрузить его самостоятельно) и дайте ему установиться; поскольку хост и гостевая система относятся к одному поколению, это завершится без ошибки. Загрузите новую гостевую систему Tahoe, пройдите начальную настройку и доберитесь до рабочего рабочего стола. Прежде чем делать что-либо ещё, сделайте снимок состояния — это чистое состояние Tahoe стоит сохранить, и оно послужит вашим мгновенным откатом, если обновление пойдёт не так.
Теперь зарегистрируйте гостевую систему в бета-программе так же, как вы сделали бы это на физическом Mac. Откройте System Settings, перейдите в General, затем в Software Update, и с помощью элемента управления бета-обновлениями подключите гостевую систему к ветке программы Apple Beta, предлагающей macOS 27. После регистрации Software Update предложит бету macOS 27 в качестве доступного обновления. Сделайте ещё один снимок состояния непосредственно перед началом загрузки, а затем дайте ей скачаться и установиться. Поскольку это обновление «на месте», выполняемое собственным механизмом обновления программного обеспечения гостевой системы, а не свежая установка через фреймворк, оно полностью обходит сломанный путь инсталлятора, и гостевая система запускается уже под управлением macOS 27.
Почему это обходит ошибку
Различие, благодаря которому это работает, стоит сформулировать прямо: путь VZMacOSInstaller фреймворка вызывается только тогда, когда хост создаёт новую гостевую систему из образа восстановления. Обновление уже существующей, работающей гостевой системы до новой версии macOS обрабатывается обычной системой обновления macOS, работающей внутри гостевой системы, — это другой путь кода, который не зависит от способности фреймворка хоста обработать образ восстановления 27-й версии. По сути, вы позволяете гостевой системе обновить саму себя, как это делает любой Mac, вместо того чтобы просить хост установить 27-ю версию в пустую коробку. Это занимает больше времени, чем прямая установка, и потребляет чуть больше места на диске, но надёжно даёт вам рабочую виртуальную машину с macOS 27 на хосте с Tahoe уже сегодня, без второго Mac и без ожидания патча.
Обходное решение 3: дождитесь обновлённой бета-сборки или приложения для виртуализации
Иногда правильный шаг — пока ничего не делать. Поскольку дефект кроется во взаимодействии между фреймворком хоста и образом восстановления гостевой системы, это именно тот случай, который разрешается обычной чередой обновлений бета-сезона. Есть три способа, которыми это может исправиться само собой. Во-первых, Apple может выпустить обновление хоста — более позднюю сборку Tahoe 26.6 или финальный релиз, — чей Virtualization framework понимает образ восстановления 27-й версии, и тогда установка с нуля начнёт работать на этом хосте. Во-вторых, Apple может выпустить пересмотренную бету macOS 27, чей образ восстановления текущий фреймворк способен обработать. В-третьих, сами приложения для виртуализации могут адаптироваться к этой особенности в обновлении, по крайней мере там, где решение находится в их власти. Любой из этих вариантов снова включает путь прямой установки.
Именно поэтому важно следить за темпом выхода бета-версий. В этом цикле Apple итерирует быстро: за сборкой developer beta 3 в течение недели последовала пересмотренная developer beta 3 наряду с первой публичной бетой, — и пересмотры, закрывающие двухнедельные пробелы, здесь обычное дело. Если вы никуда не торопитесь, проверка ещё раз после следующего выпуска беты — вполне рациональная стратегия, и она вам ничего не стоит. Ожидание — также честная рекомендация в тех случаях, когда в противном случае у вас возник бы соблазн сделать что-то радикальное со своим основным Mac лишь для того, чтобы протестировать бету. Эта ошибка — артефакт бета-версии, а не постоянное положение дел, и у бета-версий по определению должны быть подобные шероховатости.
Тем не менее будьте реалистичны насчёт компромисса. Вариант «подождать» отлично подходит, если ваша цель — непринуждённое исследование, и ужасен, если у вас есть реальный дедлайн: ошибка, которую нужно воспроизвести, приложение, которое нужно проверить на совместимость с новым релизом, клиент, которому нужен ответ на этой неделе. В таком случае используйте обходное решение 2, чтобы получить рабочую гостевую систему 27-й версии уже сейчас, а любое будущее исправление фреймворка воспринимайте как бонус. И поскольку ситуация текучая, сопротивляйтесь искушению чрезмерно вкладываться в какую-то одну конкретную сборку: то, что не работает сегодня, может установиться гладко на следующей неделе, а то, что установится на следующей неделе, может снова вести себя иначе. Отслеживайте список известных проблем, а не предполагайте, что поведение, которое вы увидели однажды, уже исправлено. Наш постоянно обновляемый обзор известных проблем бета-версии macOS 27 для разработчиков — хорошее место, чтобы проверить, отмечена ли проблема установки в виртуальной машине как решённая, прежде чем тратить на неё ещё один вечер.
Как получить IPSW и проверить его
Хотя образ восстановления не является причиной ошибки, вам всё равно нужен корректный образ для обходного решения 1 и для любой прямой установки, которую вы попробуете позже, так что эту часть стоит сделать правильно. На Apple silicon macOS распространяется для целей виртуализации и восстановления в виде файла IPSW — подписанного, самодостаточного образа восстановления, — а не в виде приложения «Install macOS», используемого для обычных обновлений. Самые безопасные источники — это собственные каналы разработчиков Apple для бета-образов и образы восстановления, которые загружает для вас ваше приложение для виртуализации. Несколько инструментов из перечисленных здесь, особенно VirtualBuddy и управляемые инсталляторы в коммерческих приложениях, могут скачивать нужный образ восстановления напрямую, что избавляет вас от необходимости искать файл самостоятельно и снижает риск получить не ту сборку.
Сверьте сборку и подтвердите целостность
Когда вы получаете IPSW вручную, убедитесь, что это действительно та бета-сборка macOS 27, которую вы собираетесь тестировать, а не неверно помеченный или устаревший файл. Отметьте идентификатор сборки там, где его указывает источник, и отслеживайте, с какой сборкой вы работаете, поскольку бета-сборки меняются часто, и поведение между ними может различаться. После загрузки убедитесь, что файл цел: проверьте, что размер совпадает с указанным источником, и, если опубликована контрольная сумма, проверьте её перед использованием образа. Обрезанная или повреждённая загрузка даст сбой по-своему — часто раньше и с другими симптомами, чем ошибка фреймворка, — поэтому проверка целостности заранее позволяет чётко отделить проблемы «плохого файла» от проблемы фреймворка хоста, о которой идёт речь в этом руководстве. Если установка даёт сбой только после того, как индикатор прогресса убедительно продвигался какое-то время, а сообщение — это обобщённое «установка не удалась», вы почти наверняка имеете дело с ошибкой фреймворка, а не с плохим IPSW, особенно если проверенный по контрольной сумме образ даёт сбой точно так же.
Храните проверенный IPSW там, где сможете использовать его повторно, поскольку вы, вероятно, будете создавать одну и ту же гостевую систему не один раз в процессе тестирования, а заново скачивать многогигабайтные образы восстановления каждый раз — пустая трата времени. Единственный проверенный, правильно помеченный образ, используемый повторно во всех попытках, также сохраняет чистоту вашего устранения неполадок: если один и тот же заведомо исправный файл даёт сбой на хосте с Tahoe и успешно устанавливается на хосте с 27-й версией, вы сами подтвердили диагноз.
Снимки состояния и откат: главный смысл виртуальной машины
Каким бы обходным решением вы ни получили работающую гостевую систему macOS 27, не растрачивайте впустую ту самую функцию, которая делает тестирование в виртуальной машине стоящим усилий. Делайте снимки состояния щедро и осознанно. Снимок фиксирует полное состояние гостевой системы в конкретный момент времени — диск, память, настройки, всё, — чтобы позже вы могли вернуться к этому же моменту одним кликом. При тестировании бета-версий это ваш ремень безопасности. Сделайте снимок чистой установки, прежде чем что-либо настраивать. Сделайте ещё один снимок перед регистрацией в бете, перед любым крупным обновлением и перед запуском чего-либо экспериментального. Если тест повреждает гостевую систему или обновление до беты идёт не так, вы откатываетесь за секунды вместо пересборки с нуля, что на хосте с заблокированной установкой с нуля иначе означало бы заново проходить весь танец «сначала Tahoe, потом обновление».
Выработайте вокруг этого небольшую дисциплину. Называйте свои снимки так, чтобы понимать, что каждый из них представляет — «чистая Tahoe», «зарегистрирована в бете, перед обновлением», «27 установлена, перед тестом», — а не накапливайте кучу безымянных точек восстановления, которые невозможно отличить друг от друга. Удаляйте старые снимки, которые вам больше не нужны, поскольку каждый занимает место на диске, но сохраняйте ключевые вехи. Сочетание соответствующего базового снимка Tahoe и рабочего снимка 27-й версии означает, что вы можете почти мгновенно переключаться между стабильной и бета-средой, а именно такая гибкость делает виртуальную машину превосходящей голое железо для этой работы. Относитесь к снимку как к конечному результату, а не как к второстепенной мелочи: работающая гостевая система 27-й версии ценна именно потому, что вы всегда можете вернуться к её заведомо исправной версии.
Более безопасная альтернатива: отдельный том APFS или внешний диск
Виртуальная машина — не единственный способ осторожно протестировать бета-версию, и в зависимости от вашей цели она может даже не быть лучшим вариантом. Заслуживают внимания два подхода, близких к «железу», особенно учитывая текущую ошибку установки. Первый — это отдельный том APFS на внутреннем диске вашего Mac. Поскольку APFS позволяет нескольким томам разделять одно и то же физическое пространство, вы можете добавить новый том в существующий контейнер, установить macOS 27 на этот том и загружаться в него, когда захотите тестировать, — оставляя ваш основной том со всеми реальными данными полностью отдельным. Вы сами выбираете, с какого тома загружаться при старте, и бета-версия живёт в своём собственном пространстве. Это работает на реальном железе на полной скорости, что важно для всего, что чувствительно к производительности или GPU и что виртуальная машина не может достоверно воспроизвести, а также полностью исключает ошибку инсталлятора фреймворка, поскольку это обычная установка на железо, а не установка через виртуализацию.
Второй вариант — это внешний диск. Установка беты на быстрый внешний SSD и загрузка Mac с него даёт вам полностью изолированную тестовую среду, которая вообще не затрагивает ваш внутренний диск. Отключите внешний диск, и ваш Mac загрузится прямо обратно в вашу нетронутую стабильную систему. Как и подход с отдельным томом, это работает на реальном кремнии и пропускает путь установки через виртуализацию, поэтому ошибка «установка не удалась» здесь не применима.
Честно взвесьте это против виртуальной машины. Компромисс в том, что ни отдельный том, ни внешний диск не дают вам мгновенного цикла снимок-и-откат, который делает итерации в виртуальных машинах такими быстрыми, — откат реальной установки означает переустановку или восстановление, а не нажатие кнопки, — и оба варианта требуют перезагрузки для переключения между средами, а не запуска беты в окне рядом с вашей обычной работой. Но они работают на нативной скорости, точно отражают поведение реального железа и прямо сейчас невосприимчивы к той самой ошибке, которая блокирует установку в виртуальных машинах. Если ваша цель тестирования — оценить реальную производительность, поведение драйверов или аппаратные функции, а не быстро итерировать по программному обеспечению, отдельный том или внешний диск на самом деле могут оказаться более разумным инструментом, и это по-настоящему безопасный способ сохранить основную систему нетронутой.
Ограничения виртуализации на Apple silicon, о которых стоит знать
Даже когда у вас уже есть работающая гостевая система macOS 27, полезно понимать границы, которые Apple устанавливает для виртуализации macOS, поскольку они формируют то, что вы реально можете делать внутри виртуальной машины, и объясняют некоторое поведение, которое иначе выглядело бы как ошибка.
Лицензионное правило двух виртуальных машин
Исторически условия программной лицензии Apple ограничивают количество виртуальных машин macOS, которые можно запускать на одном хосте, — обычно это понимается как до двух гостевых систем macOS на Mac, помимо самого хоста. Это лицензионное ограничение, а не техническая стена, но оно реально, и это важно, если вы планировали развернуть целый парк гостевых систем macOS 27 на одной машине для параллельного тестирования. Если вам нужно больше, вам нужно больше хостов. Для большинства индивидуальных разработчиков и продвинутых пользователей двух гостевых систем более чем достаточно — чистая базовая линия и активная тестовая среда, — но командам, строящим CI-матрицы, следует учитывать это ограничение на хост при планировании мощностей, а не предполагать, что один мощный Mac может разместить неограниченное количество гостевых систем macOS.
Отсутствие DRM и некоторых сервисов iCloud в гостевой системе
Гостевые системы macOS, работающие под управлением Virtualization framework от Apple на Apple silicon, не имеют доступа к некоторым защищённым сервисам. На практике это означает, что часть контента, защищённого DRM, и ряд сервисов iCloud и привязанных к учётной записи, либо не смогут войти, либо не будут полноценно работать внутри гостевой системы. Виртуальная машина не предоставляет ту же аппаратную идентичность и защищённые аттестации, что и реальный Mac, а Apple привязывает доступ к определённым сервисам именно к этому. Так что если часть вашего плана тестирования включает вход в сервисы, зависящие от DRM уровня устройства или определённых прав iCloud, ожидайте затруднений или полного отказа внутри виртуальной машины. Это сделано намеренно, а не является недостатком вашей настройки, и это ещё одна причина, по которой для определённых видов тестирования отдельный том или внешний диск на реальном железе — более подходящая среда. Знание этого заранее избавляет вас от вывода, что бета-версия сломана, тогда как на самом деле просто работает граница виртуализации, выполняющая свою функцию.
Эти ограничения не являются препятствиями для обхода ошибки установки, но они формируют ожидания. Виртуальная машина превосходно подходит для тестирования ОС, API и большинства приложений, и она намеренно отгорожена от небольшого числа возможностей, привязанных к оборудованию и учётной записи. Планируйте своё тестирование соответственно и полагайтесь на установки на реальное железо для всего, что упирается в эти ограждения.
Устранение распространённых проблем
Проблема: установка macOS 27 даёт сбой в одном и том же месте, сколько бы раз я ни пересоздавал виртуальную машину и каким бы приложением ни пользовался.
Решение: это признак ошибки фреймворка хоста, а не локальной неправильной настройки. Пересоздание виртуальной машины не поможет, поскольку сбой происходит в общем пути инсталлятора Apple, а не в приложении или ваших настройках. Прекратите повторные попытки и смените стратегию: используйте обходное решение 2, чтобы создать гостевую систему Tahoe и обновить её до 27-й версии изнутри, либо создайте гостевую систему на Mac, уже работающем на 27-й версии.
Проблема: я обновил приложение для виртуализации до последней версии, но установка всё равно даёт сбой.
Решение: одно только обновление приложения может не исправить дефект, который находится во Virtualization framework операционной системы хоста. Приложения оборачивают инсталляторный API Apple, поэтому, если этот API не может обработать образ 27-й версии на хосте с 26.6, даже более новая сборка приложения всё равно упрётся в ту же стену. Переведите хост на macOS 27, используйте путь «сначала Tahoe, затем обновление» или дождитесь обновления хоста или беты, устраняющего несоответствие.
Проблема: я не уверен, вызван ли сбой повреждённым IPSW или известной ошибкой.
Решение: сначала проверьте образ восстановления — убедитесь, что размер файла совпадает с указанным источником, и проверьте любую опубликованную контрольную сумму. Повреждённый файл обычно даёт сбой раньше и по-другому. Если проверенный по контрольной сумме образ всё равно даёт сбой после того, как индикатор прогресса продвигался минуту-другую, заканчиваясь обобщённым сообщением «установка не удалась», и делает это одинаково во всех приложениях, вы имеете дело с ошибкой фреймворка, а не с плохой загрузкой.
Проблема: виртуальная машина с Tahoe устанавливается нормально, но внутри гостевой системы в Software Update мне не предлагается бета-версия macOS 27.
Решение: сначала гостевую систему нужно зарегистрировать в правильной ветке бета-программы, точно так же, как реальный Mac. В гостевой системе откройте System Settings, перейдите в General, затем в Software Update, и с помощью элемента управления бета-обновлениями подключитесь к ветке программы Apple Beta, предлагающей macOS 27. После регистрации бета 27-й версии должна появиться как доступное обновление. Сделайте снимок состояния перед началом загрузки, чтобы иметь возможность откатиться.
Проблема: некоторые сервисы iCloud или медиасервисы не входят или не работают внутри гостевой системы macOS 27.
Решение: это ожидаемо. Гостевые системы macOS на Apple silicon не получают доступа к некоторым сервисам, защищённым DRM и привязанным к учётной записи, поскольку виртуальная машина не предоставляет ту же аппаратную идентичность, что и реальный Mac. Это намеренная граница виртуализации, а не ошибка бета-версии. Если вам обязательно нужно протестировать именно эти сервисы, установите бету на отдельный том APFS или внешний диск на реальном железе вместо виртуальной машины.
Часто задаваемые вопросы
Ошибка «установка не удалась» — это ошибка в моём приложении для виртуализации или в macOS?
Это ошибка в самой macOS — конкретно в пути инсталлятора Virtualization framework на хосте с macOS 26.6, обрабатывающем образ восстановления macOS 27. Apple признала это известной проблемой. UTM, VirtualBuddy, Tart, Parallels и VMware Fusion дают сбой одинаково, потому что все они используют один и тот же базовый инсталлятор Apple, а не потому, что виновато какое-то одно конкретное приложение.
Поможет ли переустановка приложения для виртуализации или повторная загрузка IPSW?
Нет. Поскольку дефект находится во Virtualization framework хоста, а не в приложении или файле, переустановка приложения или повторная загрузка уже проверенного образа восстановления ничего не меняет. Оба этих действия здесь — распространённая трата времени. Единственные реальные решения — перевести хост на macOS 27, обновить гостевую систему Tahoe изнутри через Software Update или дождаться исправляющего обновления.
Могу ли я установить macOS 27 в виртуальной машине без второго Mac?
Да. Используйте обходное решение 2: создайте виртуальную машину macOS Tahoe на своём существующем хосте с Tahoe, загрузите её, зарегистрируйте в программе Apple Beta через Software Update и обновите эту гостевую систему до macOS 27 на месте. Путь обновления внутри гостевой системы обходит сломанный инсталлятор фреймворка, так что одного Mac достаточно, чтобы в итоге получить рабочую гостевую систему macOS 27.
Безопаснее ли тестирование на отдельном томе APFS, чем в виртуальной машине?
Пожалуй, это безопаснее для ваших данных, и это позволяет обойти именно эту ошибку, поскольку это реальная установка на железо, а не установка через виртуализацию. Компромисс в том, что вы теряете мгновенный откат по снимку состояния и должны перезагружаться для переключения между средами. Для оценки реальной производительности или поведения оборудования это отличный вариант; для быстрой итерации по программному обеспечению снимки состояния виртуальной машины всё же побеждают, когда вам удаётся её запустить.
Сколько виртуальных машин macOS 27 я могу запустить на одном Mac?
Условия лицензии Apple исторически ограничивали количество гостевых систем macOS двумя на хост, помимо самого хоста. Это лицензионное правило, а не техническая блокировка, но оно реально и важно для всех, кто планирует параллельное тестирование. Если вам нужно больше одновременных гостевых систем macOS, вам нужны дополнительные хост-машины, а не нагромождение их на одной.
Стоит ли мне просто подождать, пока Apple это исправит?
Если вы исследуете это непринуждённо и у вас нет дедлайна, ожидание разумно — более поздняя бета-сборка, обновление хоста или обновлённый фреймворк могут восстановить прямые установки, а бета-версии итерируют быстро. Если у вас есть реальная работа, зависящая от песочницы с macOS 27, не ждите: используйте путь «сначала Tahoe, затем обновление», чтобы получить рабочую гостевую систему уже сегодня, а любое будущее исправление воспринимайте как бонус.
Заключение
Отказ беты macOS 27 устанавливаться в виртуальной машине — одна из тех проблем, которая ощущается как личная неудача, но таковой ничуть не является. Обобщённое сообщение «установка не удалась» скрывает конкретную, признанную Apple причину: хост с macOS Tahoe 26.6 не может заставить инсталлятор Virtualization framework развернуть более новый образ восстановления macOS 27, поэтому каждое приложение, построенное на этом общем фреймворке — UTM, VirtualBuddy, Tart, Parallels, VMware Fusion, — даёт сбой в одной и той же точке. Как только вы понимаете, что инсталлятор находится внутри фреймворка Apple, а не в самих приложениях, одинаковые сбои обретают смысл, бесплодные повторные попытки прекращаются, а путь вперёд становится ясным. Ничто из того, что вы можете изменить в настройках виртуальной машины, не сдвинет стену, встроенную в хост.
Хорошая новость в том, что у вас есть три реальных способа обойти эту проблему и одна по-настоящему безопасная альтернатива. Создайте гостевую систему на Mac, уже работающем на macOS 27, если у вас есть запасной; на одном-единственном Mac установите гостевую систему Tahoe и обновите её до беты изнутри через Software Update, что аккуратно обходит сломанный инсталлятор; либо просто подождите бета-сборку, обновление хоста или приложения, закрывающее пробел, поскольку это подвижная бета-ситуация, и набор затронутых сборок может меняться. А если скорость итераций по снимкам состояния вам не нужна, отдельный том APFS или внешний загрузочный диск дадут вам тестовую среду на полной скорости, на реальном железе, невосприимчивую к этой ошибке и сохраняющую вашу основную систему нетронутой. Каким бы путём вы ни пошли, делайте снимки состояния рано и часто, учитывайте лицензионный лимит в две виртуальные машины и границы DRM и iCloud внутри гостевых систем, а также держите под рукой проверенный IPSW.
Если вы всё ещё решаете, насколько далеко зайти по бета-дороге, сначала укорените свой план в более широком контексте: прочитайте о том, что меняется в macOS 27 и когда она выйдет, проверьте свои приложения на соответствие окончанию поддержки Rosetta 2 и переходу от Intel-приложений, и посмотрите, где ваше железо оказывается в финальном списке совместимости для Intel Mac. Тестируйте с умом, держите путь отступления наготове и позвольте виртуальной машине делать то, что у неё получается лучше всего, — брать риск на себя, чтобы вашему реальному Mac не пришлось этого делать никогда.