Pull to refresh

Comments 67

Меня поражает мощь и блеск qemu, потрясающий инструмент. Спасибо большое за статью!

UFO just landed and posted this here
  1. А как там насчет прокинуть в macOS usb или bluetooth?
    Пробовал через https://github.com/foxlet/macOS-Simple-KVM, так и не удалось подружить с iPhone.

  2. Я правильно понимаю, что в xcode можно таким образом собирать и публиковать приложения для iOs?

Да, я отправляю билды приложений с такой виртуалки на айфон, все работает)

Для этого в OpenCore-Boot.sh надо добавить строку:

-device usb-host,bus=ehci.0,vendorid=0x05ac,productid=0x12a8,guest-reset=false,id=iphone

Не погружался в подробности этих параметров, но vendorid это айдишник Apple, productid это айдишник для iPhone. Есть пара нюансов: после вставки шнура в порт USB нужно нажать Trust на телефоне до запуска виртуалки и второе - у меня не получалось использовать одновременно использовать проводную мышь и держать подключенный айфон. Видимо, если в другие USB-порты подключено что-то еще, оно перебивает шину. Но я не спец

Подробнее можно почтитать здесь: https://github.com/arindas/mac-on-linux-with-qemu/issues/25

Я передаю целый USB порт - подключать и отключать можно что хочешь. Не очень известная опция: -device usb-host,hostbus=1,hostport=7,bus=usb.0

lsusb даст понять какие есть bus и port на хосте, а опцию bus можно убрать или поставить тот который у вас задан в VM

Раньше мне часто приносили прошить или анлокнуть смартфоны и планшеты, и если с андроидом всё ок, то для фблочек нужно было поднимать виртуалку с масдаем или макосью. Я прокидывал usb устройство внутрь виртуалки и нормально шил, но дело в том что загруженное в ос, загруженное в рекавери и выключенное устройстов apple это три разных девайса и приходилось делать лишние телодвижения..

Жаль что этого коммента мне не попалось лет 10 назад..
Но всё равно спасибо вам, буду знать (и ведь вроде не раз доку на qemu читал по разным причинам, а такого варианта даже не встретил и сам не додумался).

Яблоки перешивать не доводилось, но в игровую виртуалку прокидывался целиком USB-контроллер, железкой, после чего подключение устройства в нужную ОС становилось тривиальным.

Виртуалка-то видит телефон, а XCode - нет.

Только это нелегально с юридической точки зрения (виртуалки и макхаки - нельзя).

Чтобы легально делать продукты для эппл - нужна железка эпл (б/у мак мини найти за $150 вполне реально) + рега в apple developer ($100 в год), чтобы подписывать, нотаризовать и степлерить свои криативы(отдельный квест), и выкладывать их в app store.

от куда такая инфа? я когда первый хакинтош ковырял общался с саппортом меня конкретно интересовал вопрос того на сколько это законно, на что чувак ответил примерно следующее
"Мы знаем о том что многие используют ОС на своих компьютерах и не ведем охоту на ведьм, все в порядке пока вы не пытаетесь делать бизнес на продаже своих кастомных компьютеров с нашей ОС как настоящие маки, пользуйтесь на здоровье мы уверенны что вам понравится и вы пожелаете приобрести себе настоящий мак"
это все сжато там был довольно развернутый ответ еще упоминал что при возникновении каких либо проблем тех.поддержка может проигнорировать запрос, это было по моему во времена Каталины

Есть ещё ряд вариантов с арендой макожелеза в облаке, в диапазоне от $25 за месяц. Правда, не знаю, можно ли с такого железа что-то выкладывать в аппстор.

Как с производительностью решения? Есть видео как бегает xcode?

Для начала бы увидеть, как икскод на родном ябловском железе бегает

Я запускал через VMWare из-под windows на i7-11370 + 32GBRAM и оно весьма тормозило.

Запускал под qemu (Proxmox) и вроде достаточно нормально работала. У меня виртуалка на своём отдельном SSD, который выделен только для OSX. Вроде как это даёт небольшой прирост к скорости на i/o.

Вообще, XCode сама по себе не из торопливых приложений даже на родном железе. При возможности я кодил в VSC, а собирал и гонял тесты в XCode.

И как примерно он бегает?

Ну скажем так - не очень торопливо. На учебных проектах из песочницы норм даже на эйрах, но с ростом проекта естественно скорость снижается. И ладно у меня мак мини, но коллега сидит на мак студии с полным фаршем, и у него тоже скорость икскода так себе. При этом с остальным софтом проблем особых не замечал (ну я конечно не весь софт в мире использую).

Проблема усугубляется, когда в большом проекте очень грязный код - большие файлы, излишняя связанность, нет модификаторов доступа (то есть по умолчанию всё открыто) - индексирование проекта, автоподсказки, подсветка страдают. Правда и такого бардака, как в моём нынешнем проекте, я больше нигде не видел.

Плохо бегает. Собирал хакинтош для целей звукозаписи и не только, и в целом он работал значительно производительней мака взятого за образец. Logic и Final Cut очень хорошо работали. Решил посмотреть ради интереса на Xcode, так вот он тормозил настолько, что всякие идеи тратить время в нём на перенос чего-нибудь в эко-систему macOS развеялись сразу. Надо очень любить мак чтобы этим пользоваться, а если ещё и на оригинальном железе...)

Если не хотите, чтобы оно тормозило, надо пробрасывать дискретную GPU в виртуалку через VT-d.

Также в упомянутом в статье репозитории неграмотно настроен эмулируемый процессор. С -cpu Penryn вместо host или хотя бы Haswell XNU будет загружать Mach-O только в режиме архитектуры x86_64, а не x86_64h, что приведёт к тому, что не во всех системных библиотеках будут работать оптимизации AVX 2.0, а это дополнительно снижает производительность.

Была бы дискретная видеокарта...

У меня встроенная AMD Renoir, живём с тем, что есть

Вы написали в целом, или вы реально знаете как сделать, чтобы переброшенная карта подхватилась системой? Ибо сам проброс-то дело минут 5.

Лично делать это не приходилось, но пользователи, у которых такие конфигурации есть и работают, к нам в багтрекер приходили.

Я бы рекомендовал установить Monterey, чтобы пользоваться современными версиями Xcode и других инструментов.

Для последнего Xcode нужна Ventura. И только с последнего Xcode можно отправлять приложения в стор.

В стор можно отправлять с Xcode 14.2 - он нормально на Monterey становится.

По этой инструкции с этого же репа нормально ставится и ventura. Буквально месяц назад ставил. Ноутбук с i5 1155G7 и 16гб озу, полет нормальный, была бы еще дискретная видюха, вообще классно бы работало....

А можете внутри Geekbench запустить? Интересно насколько производительность падает относительно хоста

qemu -- достаточно хороший эмулятор в этом плане. Особенно если ставить cpu host, то вообще будет довольно близко.

> В заключение упомяну, что при запуске уже установленной виртуальной машины можно столкнуться с такой проблемой

Это паника ядра, но вывод списка загруженных кекстов закрывает саму панику. Нужно в config.plist поставить PanicNoKextDump=YES (см. OpenCore Configuration.pdf), чтобы увидеть.

Мне тоже понадобился XCode для эпизодических задач. Не помню, но какой-то первый нагугленный вариант с ходу не завелся. Потом нашел OneClick macOS Simple KVM. Ничего не настраивал вроде бы — только добавил ядер и памяти до 16ГБ и пару раз уже расширял диск. Устройства не пробрасывал, интеграцию с буфером обмена тоже не делал. Процессор со встройкой (AMD Ryzen 5700G), SSD.
Особо вроде ничего не тормозит в XCode и AppCode. Единственное, что умирает на несколько секунд — это анимированная минимизация окна. Но так я делаю очень редко и лень искать, где что отключить.

Единственное, что умирает на несколько секунд — это анимированная
минимизация окна. Но так я делаю очень редко и лень искать, где что
отключить.

Посмотрите Системные настройки - Рабочий стол и Dock - Убирать в Dock с эффектом "Простое уменьшение", также могут помочь включение опций "Уменьшить движение", "Уменьшить прозрачность" в Универсальном доступе - Дисплей. Это помогает и для удалёнки, создаёт меньше перерисовок.

Круто конечно в плане поюзать, но для разработки сомневаюсь что подойдёт, например запуститься ли Swift 5.8 c последними конкуренси абилками? Хотя под линукс он и компилится, но думаю на эмулятор такое не прокатит

Но как обычно есть нюансы с работой аппстора на такой вируталке, и еще куча проблем. Оно неполноценно(например установка brew на такой машине с 16 ядрами + 48 рам занимало минут 20. Установка сертбота еще минут 40 из под этого brew), но для целей MacOS server или иного MDM решения вполне подойдет. Вполне аналогично разворачивается под проксмоксом кстати. Если не пробрасывать gpu становиться больно, причем что при прямом взаимодействии, что через vnc

Статья пришлась очень кстати, как раз собирался заняться сборкой пет-проекта под макось.

Подскажите, каким образом можно прокинуть видеокарту внутрь такой виртуалки? А то простое сворачивание окна с Geanie-эффектом всё намертво вешает на несколько секунд.

MacOS официально поддерживается в VMware Fusion и есть дрова с поддержкой графики 'VMware Tools on macOS - com.vmware.kext.VMwareGfx'
Народ ставит бесплатный VMware Workstation Player. Патчит его. Ставит MacOS и VMwareTools. Все давно отработано. Материалов в сети масса.
Есть и поддержка iCloud supported device

В VMware Workstation Player есть драйвер только с софтварным рендерингом, и его производительность плюс-минус эквивалентна virtio gpu без ускорения, который используется в QEMU, тем более, что во втором случае драйвер писали вообще в Apple. Хардварный рендеринг с пробросом виртуальной GPU Metal работает же только на macOS Host или с пробросом реальной GPU через VT-d.

Лет 8-м использую на ноутах VMware Workstation Player с виртулками MacOS в походном(командировочном) варианте.
Графикой доволен(darwin.iso darwinPre15.iso) да и сами машинки быстро бегают.
На работе VMware Fusion.
Ну а для дома Proxmox VE без MacOS
Годная дока от Mr. Macintosh: List of Mac BoardID, DeviceID, Model Identifiers & Machine Models

Хорошо работает и на AMD-ных процах:

smc.version = "0"
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"
smbios.reflectHost = "TRUE"
hw.model = "MacBookPro14,3"
board-id = "Mac-551B86E5744E2388"

А вы же в курсе, что эти действия нарушают EULA, да?

С массой звёздочек и нарушением презумпции невиновности.
Во-первых автор может запускать это на железе Apple, что легально до такой степени, что так работают в Штатах "облака маков".
Во-вторых с 1280 ГК РФ можно и на не-яблочное железо попробовать "натянуть".
Но автору бы не помешало добавить это в дисклеймер, и в корпоративной среде такие эксперименты лучше бы не ставить, если только это не забивший на международное право госсектор некоей неназванной страны

Цитирую:

под рукой нет макбука, а покупать его только чтобы открыть Xcode кажется делом сомнительным

Если бы все разработчики читали EULA, то у пользователей macOS точно не было бы портов ПО и репозиториев типа Homebrew.

Я думал, будет что-то вроде докера... Чтобы "прямо без виртуалок".
А тут виртуалка, причём другая. В смысле, чтобы запустить - придётся сперва заглушить и выгрузить модули virtualbox.

(по секрету: под макось можно собирать с помощью ванильного clang (начиная с 13-го). С консольными приложухами вообще "на ура". На любой платформе, хоть на raspberry pi)

А тут виртуалка, причём друга

ну что значит "другая"?
самая "родная" для linux и самая адекватная (настолько что именно на qemu/kvm работает большинство хостеров)

ну а то что:

придётся сперва заглушить и выгрузить модули virtualbox

так это просто означает что вы зачем-то замусорили свою систему этими модулями

Не "зачем-то замусорил" а активно пользуюсь. И поэтому если надо макось - запускаю виртуалку с ним там же.

А заголовок статьи и первые строчки как бы намекают, что это можно сделать "прямо без виртуалок", чем вводит в заблуждение.

придётся сперва заглушить и выгрузить модули virtualbox.

Зачем? Qemu прекрасно работает при загруженных модулях VirtualBox.

Сам по себе - да, работает. Например, софтово arm эмулировать.

Но как только ему нужен kvm (а без него смысла особого нет) - тут же всё заканчивается. По крайней мере несколько лет назад нужно было выбирать - либо kvm, либо vbox. Оба вместе не живут.

Виртуалку virtualbox просто закрываю, после чего macOS в qemu нормально загружается. Kubuntu 22.04

Её нельзя просто закрыть. В смысле, в ней тоже идёт работа.

Когда-то так и делали - смотрели, чтобы не была запущена противоположная виртуалка, потом выгружали её модули, запускали свои и запускали свою виртуалку. И был выбор в определённый момент времени - либо работать с семейством qemu через kvm, либо с virtualbox через vbox. Оба одновременно, увы, не работали. Собственно, и сейчас не работают. Просто в тот момент, когда clang научился быть по-настоящему кросс-платформенным, надобность в этих всех виртуалках для сборки отпала (для тестов всё ещё нужны).

Никакие модули явно не выгружаю и не загружаю. Компьютер не перегружаю. Одновременно, да, не работают, сначала одну надо закрыть — я это делаю "выключением" виртуалки.

Да, очень давно эмулирует (но тут же статья, что оно "без всяких вот этих", якобы).

И не может совместно с kvm. Что бы там ни писали на SO в вопросе 10-летней давности. Софтовая эмуляция - пожалуйста. А вот Intel-VT или AMD-V (тогда это имеет хоть какой-то смысл) - кто первый халат надел, тот и доктор.

Увы.
`runs on top of QEMU + KVM`

Ну и все команды запуска это подтверждают:
`docker run -it --device /dev/kvm...`

Виртуалка в докере - это всё равно виртуалка.
Проблема в том, что если память/диск/сеть можно поделить на сотню кусков, изолировать, и каждому докеру дать по кусочку - то вот гипервизор пока что один. И если другой встал, то не факт, что вы сможете пробросить /dev/kvm.

Докер - это особый предмет. Его НЕЛЬЗЯ запустить нативно на чужой системе - потому что он подразумевает работу под линукс. Докер на винде - через wsl. Докер на маке - через маленькую виртуалку с линуксом внутри. Ни на винде, ни на маке нет нативного слоя ядра, и нет namespaces, поэтому всё только так.
Равно как и чужую систему, если это не линукс, невозможно запустить в докере. Потому что внутри у вас неизбежно будет ядро линукс.

А с запуском на Hyper-V есть какие-нить новости? Понимаю, что вероятно можно собссно описанным выше методом в Hyper-V запустить что-то линуксовое, а там уже макось, но хотелось бы более прямолинейно.

Есть некий проект https://github.com/acidanthera/MacHyperVSupport но там что-то ни разу не Далее-Далее-Profit даже для давнего гентушника ))

Всё работает, проект правильный, но вроде с macOS 13 были нюансы, и графику мы так и не прокинули пока. По сложности сопоставимо с развёртыванием обычного хакинтоша.

ого, спасибо! буду пытаться! Мне графа, кстати, не нужна... лишь бы сеть работала норм в бридже с хостовой локалкой

Это возможно установить на WSL? Было бы классно иметь все 3 ОС на одной машине.

Попробовал — не получилось. Выяснилось, что нужна nested virtualization, а с AMD для этого обязательно нужна свежая Win11, а у меня Win10 LTSC.

Как выставить разрешение побольше, на ubuntu 22.04 сработало

How to increase screen resolution for macOS-Simple-KVM

(Thanks to passthroughpo.st and urcomputertechnics.com for the tips.)

  1. In the macOS Finder, look for EFI in the left bar under Volumes. If it isn't visible you will have to mount it:

  • Open the macOS Terminal and type diskutil list and look for the disk/partition location of the EFI. (There may be more than one.)

  • Type sudo diskutil mount diskYsZ, using the disk/partition location name where you see EFI.

  • The EFI partition will appear in the left Finder bar under Volumes.

  • If you don't see anything in that volume after browsing to it, try the other ones that you found in diskutil.

  1. In the EFI volume, go into the Clover directory and open the config.plist file in the macOS text editor.

  2. There should be a section of the file that looks like this:

<key>ScreenResolution</key>
<string>1280x720</string>
  • Edit that to your preferred screen resolution.

  • Some odd/intermediate resolutions like 1366×768 may not work well. Try to stick to more common 16:9, 16:10, and 4:3 form factors.

  1. Shut down the VM, relaunch it using basic.sh script and follow the following steps:

  • Press Escape key as soon as the window comes up.

  • In the interface that comes up, select Device Manager->OVMF Platform Configuration->Change Preferred and select the correct resolution.

  • Press F10 to save the changes.

  • Press Escape multiple times to come back to main menu, and then select Continue on it.

Маленький апдейт, после закрытия вируталки она будет забывать разрешение из config.plist

Что-бы она не забывала нужно выставить в config.plist в папке OpenCore и пересобрать образ командой
rm -f OpenCore.qcow2; sudo ./opencore-image-ng.sh --cfg config.plist --img OpenCore.qcow2

Sign up to leave a comment.