Всем привет! Делюсь своими изысканиями по запуску виртуальных машин MacOS на процессорах AMD. Возможно кому-то это поможет и сэкономит время.
Предыстория: у меня в наличии есть несколько гостевых виртуалок с макосью, на одном физическом хосте, с которыми долгое время не было никаких проблем. Версии - от Mojave до Monterey, они даже обновлялись штатно через Software Update. Далее, при апдейте на Ventura/Sonoma ловим кернел панику и loop boot, и что с этим делать не совсем понятно.
Беглый гугл по проблеме сказал, что решения этой проблемы нет. Придется искать обходной путь. Глаз пал в сторону хакинтоша, но как его правильно конфигурировать под образы VMware тоже оказалось не совсем понятным (по крайней мере мне), поэтому и пишу эту статью. Мои вводные - Ryzen 5950X, Windows 10, VMware Workstation 16.2 (была версия 16.0, пока не столкнулись в проблемой, первым делом попробовали обновиться, и перенакатить анлокер - ожидаемо не помогло).
Что понадобится (чем пользовался лично я):
OCAT - графический редактор plist-конфигов.
ProperTree - еще одна редачилка plist'a, мне через нее было удобно копипастить блок с патчем для AMD (удобно открыть patches.plist из репы, и выдернуть оттуда весь блок patch, чтоб вставить его в наш конфиг)
Рекомендация по настройке конфига под AMD - в целом тут исчерпывающие данные по тому, какие опции необходимо отметить в конфиге.
Готовые SSDT для нубасов вроде меня (насколько я понял это таблицы с ID оборудования, которое инициализируется при старте ОС. Что-то подобное можно создавать самому уже на конкретном железе. Тут же в статье описано как сгенерить свои таблицы, но я не совсем понял, насколько это аффектит виртуальные машины, и нужно ли это для них.
Гайд по EFI драйверам и кекстам - тут в целом достаточно полная и понятная дока по необходимым файлам. Драйвера я оставил все, т.к. они не влияют напрямую на процесс загрузки и работы гостевой ОС. А вот про кексты напишу позже.
Кастомный .vmdk диск, с которого мы будем бутаться. (создаем сами)
Выкладываю свою версию EFI - не факт, что именно с ней у вас все взлетит, но может будет полезным для примера.
Теперь про OpenCore и что он из себя представляет
Нас интересует версия X64, внутри есть папка EFI, ее в дальнейшем нужно будет закинуть на наш загрузочный раздел диска, с которого мы будем бутаться. При включении нашей виртуалки первым делом загружается /EFI/BOOT/BOOTx64.efi, который затем запускает /EFI/OpenCore.efi (если вы будете в firmware вмвари указывать файл загрузчика, указывайте путь к BOOTx64.efi)
Что еще внутри папки EFI :
EFI/OC/ACPI - тут лежат SSDT/DSDT таблицы оборудования. Если удалять лишнюю, обязательно нужно проверить, чтоб не было ссылок на нее в config.plist иначе будет краш.
EFI/OC/Drivers - тут лежат драйверы .efi. OpenRuntime.efi и HfsPlus.efi обязательны, я не стал удалять лишние драйвера, но ради интереса поигрался и выяснил, что без OpenCanopy.efi, OpenLinuxBoot.efi, OpenLegacyBoot.efi - загрузчик не взлетал. Насколько я понял, эти драйвера не влияют на дальнейшую работу макоси, а сугубо отвечают за работоспособность загрузчика и его возможности.
-
EFI/OC/Kexts - тут валяются расширения ядра (kext - kernel extension), нужны для успешного запуска самой макоси, а так же для корректной инициализации и работы устройств. Любой хакинтош начинается с Lilu.kext, затем должен идти фейковый SMC (я заводил тачку с VirtualSMC.kext), потом уже все остальное. Их последовательность определяется конфигом config.plist, в каком порядке они указаны, в таком они и будут инжектиться при загрузке ОС.
Экспериментальным путем выяснено, что система не бутается без:
AppleMCEReporterDisabler.kext - Required on macOS 12.3 and later on AMD systems, and on macOS 10.15 and later on dual-socket Intel systems. *из доки по OpenCore
CryptexFixup.kext - Я так понял, что это обязательный кекст не только для AMD, но и для Intel до Haswell
NoAVXFSCompressionTypeZlib-AVXpel.kext - возможно избыточно, без него тоже бутается.
На всякий случай оставил:
VoodooHDA.kext - инициализация звука в MacOS
HibernationFixup.kext - на виртуалке проще вообще отключить сон, но если забыли или хотим оставить, возможно этот будет фиксить. Дело в том, что под хакинтошами у макоси есть проблемы со сном, вернее с выходом из него)
Whatevergreen.kext - фикс инициализации графики, по идее он не нужен, т.к. есть VMWARE tools.
Создаем свой .vmdk
Для его создания я создавал новую виртуалку -> "установлю потом" -> тип системы other, создал диск 0.2GB, но с таким размером VMware создала тиск с типом IDE, поэтому я его удалил, и пересоздал уже как SATA (можно просто создать новый диск для уже существующей виртуалки). Из доп. настроек нужно выбрать store virtual disk as a single file.
Далее монтируем этот диск через Daemon Tools. Теперь открываем оснастку управления дисками, для этого жмем WIN+R, вводим diskmgmt.msc и enter, система тут предложит проинициализировать новый диск. Выбираем GPT, жмем ОК. Далее создаем том и форматируем в FAT32, в поле Label вписываем любой понятный для вас, я так и назвал OpenCore. Те же процедуры можно выполнить и через DISKPART, или сторонние инструменты - кому как удобнее. Все, теперь осталось закинуть на наш подмонтированный диск папку EFI, размонтировать его и можно пробовать бутаться.
Несовместимость гостя и vmdk диска (если подкидываем его к уже готовой машине)
При попытке подсунуть загрузочный vmdk, который был создан в другой версии VMware, возникнет ошибка совместимости:
Варианта 2: либо пересоздавать новый vmdk для этой виртуалки, форматировать его и засовывать туда EFI, либо конвертировать виртуалку:
жмем по ней правой кнопкой мыши → manage → Change Hardware Compatibility.
Мой первый EFI был создан в версии 16.2.x, поэтому выбираю ее, чтоб версия совпадала с той, в которой он создавался. Далее вмварь спросит, хотите склонировать или конвертировать текущую билд-тачку. Тут уже на ваше усмотрение, у меня с конвертацией проблем не возникло. После конвертации диск подцепится без ошибок)
Что дальше?
Отныне любая макось, будь то инсталлер или уже установленная версия - должны запускаться только через наш кастомный EFI. Иначе в дальнейшем у них будет паника ядра.
С чистой установкой все просто: (не буду останавливаться на том, как создать новую ВМ, как пропатчить ее unlocker'ом, как создать диск, выделить ресурсы и т.д.)
Добавляем в виртуалку наш EFI, в настройках смотрим на какой порт сата он добавился (в статьях рекомендуют сделать SATA 0:0, но можно забить, это ни на что не влияет (кроме порядка первой загрузки) - поэтому тут на ваше усмотрение.
В виртуальный CD добавляем .iso образ установщика макоси (можно взять с торрента, либо зашить самому, но для этого нужен отдельный гайд).
Далее в VMware выбрать Power on firmware
После этого у нас будет возможность бутануться с нужного диска, тут нам и понадобится номер порта SATA
Выбираем диск, жмем Enter.
Далее мы попадаем в меню OpenCore:
Если нажать пробел, появятся дополнительные опции загрузки
Выбираем установщик и далее штатно проходим установку (не забываем запустить дисковую утилиту перед запуском установщика и отформатировать наш целевой vmdk в формат APFS).
Для тех, кто хочет обновить свой старенький Monterey
У вас варианта два, либо обновляться штатно, через Software Update, либо с iso (точно так же, как чистая установка в абзаце выше, но без форматирования целевого диска)
Правило одно в обоих случаях - перед апдейтом, вы должны обязательно бутаться с кастомного загрузчика. Если макось словит Kernel Panic в процессе обновления (она несколько раз рестартится пока идет процесс обновления), то ее попердолит так, что даже с подсунутым EFI она не будет бутаться.
Перед апдейтом можете снять снапшот, откат поможет в случае если что-то пойдет не так.
Какие могут быть проблемы
Если макось в процессе рестартов установщика загрузится не через OpenCore, а напрямую, и словит панику - ее уже будет не восстановить. (выше уже писал об этом, но лучше задублирую - это важно!)
Если после успешной загрузки макоси не работает мышь/клава, либо у мыши очень высокая чувствительность, что невозможно ею пользоваться - нужно проверить в настройках гостя версию эмулируемого USB контроллера. Должна быть 3.1.
доп. может понадобиться VoodooPS2Controller.kextПроброс Bluetooth лучше убрать (там же, где настройки USB)
Перед изменением количества ядер, выделенных гостю, лучше править патчи в config.plist на EFI разделе. Иначе могут быть проблемы: Патчи для AMD
У меня зависало, если выделял больше 4х ядер без патча.ОБЯЗАТЕЛЬНО ОТКЛЮЧИТЬ TSO https://communities.vmware.com/t5/VMware-Fusion-Discussions/VMware-Fusion-Only-Upload-Internet-Speed-is-Super-Slow-compared/td-p/2955386
sysctl net.inet.tcp.tso=0 и для того, чтоб работало после рестарта - создать файл /etc/sysctl.conf и вставить «net.inet.tcp.tso=0»
Если этого не сделать, то не будет работать VNC/SCP/загрузка файлов на самбу, может что-то еще (очень низкая UPLOAD скорость для TCP соединений)-
И НЕ ЗАБЫВАЕМ, ЧТО В VMX конфиг нужно прописать
это было обязательным правилом и для более ранних версий MacOS
cpuid.0.eax = "0000:0000:0000:0000:0000:0000:0000:1011"
cpuid.0.ebx = "0111:0101:0110:1110:0110:0101:0100:0111"
cpuid.0.ecx = "0110:1100:0110:0101:0111:0100:0110:1110"
cpuid.0.edx = "0100:1001:0110:0101:0110:1110:0110:1001"
cpuid.1.eax = "0000:0000:0000:0001:0000:0110:0111:0001"
cpuid.1.ebx = "0000:0010:0000:0001:0000:1000:0000:0000"
cpuid.1.ecx = "1000:0010:1001:1000:0010:0010:0000:0011"
cpuid.1.edx = "0000:0111:1000:1011:1111:1011:1111:1111"
ethernet0.virtualDev = "vmxnet3"
Вынесу отдельно: из непофикшеного есть проблема с рестартами виртуалки. Она успешно останавливает систему и повисает
Прибить ее можно из командной строки:"ваш путь установки вмвари\VMware Workstation\vmrun.exe" -T ws stop "путь к виртуалке.vmx"
Благодарю за внимание. Это моя первая статья на хабре, надеюсь она кому-то сохранит время и нервы. Предполагаю что она будет актуальна как минимум до тех пор, пока Apple окончательно не выпилит поддержку x86 в своих системах. Эта статья не является пошаговым руководством по установке системы. В ней я скорее попытался рассказать с какими проблемами столкнутся те, кому нужно будет обновлять свои виртуалки для получения Xcode последних версий. Особенно актуально, т.к. насколько я понял через месяц заканчивается поддержка версий Xcode из Monterey.
P.S.: Забыл еще упомянуть: После того, как вы установите макось, вы можете сконфигурировать OpenCore прямо на основном VMDK из самой макоси (подмонтировать ее встроенный EFI и записать туда OpenCore) - лично я не стал этого делать, потому что тогда у вас скорее всего не будет доступа к OpenCore извне гостя. Т.к. форматированный макосью vmdk Daemon Tools не в состоянии примонтировать. Возможно тут может помочь утилита для чтения APFS томов, но я не стал это проверять.
crawlingroof
КАК до этого можно было додуматься?! Я закончил на обновлении vmware и вычитке reddita, где решения не было. Спасибо вам.
Okeu Автор
Все началось с того, что я нашел видео одного индуса (или не индуса), где он предлагает юзать его готовый .vmdk с загрузчиком. Если что-то смог сделать индус, значит и я могу)
Как минимум до текущих виртуалок, я уже разворачивал хакинтоши через Clover, потому что на то время (2017-2018 годы) хакинтош на Core i7 7700k делал сборки сильно быстрее любого доступного мака на рынке, а бонусом можно юзать быстрые диски, и много памяти воткнуть) Поэтому опыт хакинтоша, хоть и не очень большой - уже был. Правда в то время до работоспособной версии у меня уходило по 2 недели пердолинга. Нынешний OpenCore, конечно, сделал огромный шаг вперед.