На полноценную публикацию для Хабра не тянет, но описанный ниже момент для кого-то может оказаться полезным.
Итак, краткие исходные данные таковы (полный расклад в статье по ссылке выше): 1) 2 видеокарты: "Lexa PRO [Radeon 540/540X/550/550X / RX 540X/550/550X]" (используется для ВМ с Win10) и "Park [Mobility Radeon HD 5430]" (используется для хост-системы);
2) "Radeon HD 5430" (старенькая видюха) воткнута в первый pcie-слот материнки, а "Lexa PRO" (железяка поновее) - во второй (кстати, в статье этот момент описан не совсем корректно);
Видеокарту "Radeon HD 5430" понадобилось перекинуть с хост-системы на ВМ, а "Lexa PRO" - на хост-систему.
Чтобы это сделать корректно, необходимо карту из первого слота явно отвязать от хост-системы. Небольшая сложность тут в том, что она идёт первой в очереди на инициализацию хост-системой.
Очерёдность инициализации выводится посредством получения содержимого procfs-файла "/proc/fb" (fb = framebuffer). Выглядеть это будет, например, так
0 efifb vga 1 amdgpudrmfb
Чтобы не использовать видеокарту в хост-системе для передачи в ВМ в статье было задействовано как изменение параметров ядра (grub) при загрузке, так и механизм подгружаемых модулей ядра (modprobe), т.е.
1) добавление параметров «intel_iommu=on iommu=on rd.driver.pre=pci-stub pci-stub.ids=1002:67ff,1002:aae0» (идентификаторы "Lexa PRO") в grub и 2) «blacklist amdgpu» и «options pci-stub ids=1002:699f,1002:aae0» -> «/etc/modprobe.d/local.conf».
Т.к. первой хост-система (ОС AlmaLinux8) захватывала "Radeon HD 5430", то проблем в рамках описанной в статье конфигурации не было.
В случае же, когда есть необходимость в ВМ прокинуть карту, находящуюся в более приоритетном слоте, в параметры загрузки мы должны прописать явный запрет на захват целевой карты. Делается это посредством добавления подстроки "video=efifb:off" (подстрока "efifb" взята из вывода "cat /proc/fb") в параметр GRUB_CMDLINE_LINUX ("/etc/default/grub") и последущим исполнением команд grub2-mkconfig + dracut + перезагрузка.
Итого, файл "/etc/default/grub" должен иметь примерно такой вид.
1002:68e1,1002:aa68 - идентификаторы "Radeon HD 5430"
В файле «/etc/modprobe.d/local.conf» также меняем идентификаторы, но не отправляем в блэк-лист драйвер "radeon", т.к. оный необходим ОС при загрузке. В общем, файл "local.conf" должен содержать только одну строку - "options pci-stub ids=1002:68e1,1002:aa68".
Всем привет. Делюсь своими изысканиями по запуску виртуальных машин MacOS на процессорах AMD. Возможно кому-то будет полезным: Предыстория: в наличии несколько виртуалок, с которыми долгое время не было никаких проблем. Версии - от Mojave до Monterey, они даже обновлялись штатно. Далее, при апдейте на Ventura/Sonoma ловим кернел панику - никакие рекомендации из интернета не помогли. Глаз пал в сторону хакинтоша, но как его конфигурировать под вмварь тоже оказалось не совсем понятным, поэтому и напишу этот гайд: вводные - Ryzen 5950X, Windows 10, VMware Workstation 16.2 (была версия 16.0, пока не столкнулись в проблемой апдейта макоси).
Что понадобится (чем пользовался лично я): OCAT - графический редактор plist ProperTree - еще одна редачилка plist'a, мне через нее было удобно копипастить блок с патчем для AMD (удобно открыть patches.plist из репы, и выдернуть оттуда весь блок patch, чтоб вставить его в наш конфиг) Рекомендация по настройке конфига под амуде Готовые SSDT для нубасов вроде меня (насколько я понял это таблицы с ID оборудования, которое инициализируется при старте ОС. Что-то подобное можно создавать самому уже на конкретном железе. У меня стоял вопрос - а каким оно должно быть и как его создать на VMware, возможно кто-то из шарящих в теме пояснит в комментах, как это работает, и как это связано с DSDT таблицами) Гайд по EFI драйверам и кекстам - по кекстам я ниже еще отпишу. А драйвера я оставил все, которые идут с редакцией OpenCore, но не все они обязательны. Ну и загрузчик OpenCore собственной персоной Кастомный .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, но вмварь тогда создает диск IDE, поэтому я его удалил, и пересоздал уже как SATA. Размер выбрал с потолка, сам EFI весит около 10-15 МБ. Поэтому можете назначить меньше. Из доп. настроек нужно выбрать store virtual disk as a single file Далее монтируем этот диск через Daemon Tools. Теперь открываем оснастку управления дисками, для этого жмем WIN+R, вводим diskmgmt.msc и enter, система тут предложит проинициализировать новый диск. Выбираем GPT, жмем ОК. Далее создаем том и форматируем в FAT32, в Label вписываем любой удобный и понятный, я так и назвал OpenCore. Все, теперь осталось закинуть на диск папку 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
мой пример: 0:0 это EFI, 2:0 это целевой диск с макосью, 1:0 CD дисковод с инсталлером.
Выбираем диск, жмем Enter. Далее мы попадаем в меню OpenCore:
Скрин для примера, тут конфиг с уже установленной системой
Если нажать пробел, появятся дополнительные опции загрузки
OpenCore делает ВЖЖ ВЖЖ
Бутаем установщик и далее штатно проходим установку (не забываем запустить дисковую утилиту в установщике и отформатировать наш целевой vmdk в формат APFS).
Для тех, кто хочет обновить свой старенький Monterey У вас варианта два, либо обновляться штатно, через Software Update, либо обновляться с iso (точно так же, как чистая установка в абзаце выше, но без форматирования целевого диска) Правило одно в обоих случаях - перед апдейтом, вы должны обязательно бутаться с кастомного загрузчика. Если макось словит Kernel Panic в процессе обновления (она несколько раз рестартится пока идет процесс обновления), то ее попердолит так, что даже с подсунутым EFI она не будет бутаться. Перед апдейтом можете снять снапшот, откат поможет в случае если что-то пойдет не так.
Какие могут быть проблемы
Если макось в процессе рестартов установщика загрузится не через OpenCore, а напрямую, и словит панику - ее уже будет не восстановить. (выше уже писал об этом, но лучше задублирую - это важно!)
Если после успешной загрузки макоси не работает мышь/клава, либо у мыши очень высокая чувствительность, что невозможно ею пользоваться - нужно проверить в настройках виртуалки версию USB контроллера. Должна быть 3.1. доп. может понадобиться VoodooPS2Controller.kext
Проброс Bluetooth лучше убрать (там же, где настройки USB)
Перед изменением количества ядер, выделенных виртуалке, лучше править патчи в config.plist на EFI разделе. Иначе тачка будет вставать в фриз: Патчи для AMD Без них будут проблемы. У меня зависало, если выделял больше 4х ядер. "C:\Program Files (x86)\VMware Workstation\vmrun.exe" -T ws stop "путь к виртуалке.vmx"
UPD: вынесу отдельно: из непофикшеного есть проблема с рестартами виртуалки. Она успешно останавливает систему и повисает
При этом кнопки Power OFF в VMware неактивны
Прибить ее можно из командной строки (путь до vmrun.exe может отличаться: "C:\Program Files (x86)\VMware Workstation\vmrun.exe" -T ws stop "путь к виртуалке.vmx"
Всем привет! Появилась острая необходимость в изучении вводных в виртуализацию (администрирование, развертывание, да и вообще что это за фрукт и с чем его готовить). Прошу знающих откликнуться и наставить недоразвитого сисьадмина на путь истинный))
Ну ок, раз снесли пост, процитирую выдержки из него здесь:
В прошлом посте я дал ссылку на статью на хабре. Решил поделиться здесь - потому что сама идея показалась мне забавной, плюс, местами были реализованы своеобразые решения:
Все началось с того, что нам понадобилась облачная платформа. Давайте посмотрим, какие задачи обычно решают облачные платформы. Если говорить совсем просто, то облако позволяет взять физические ресурсы ваших узлов (например, CPU, RAM или дисковое пространство) и нарезать из них виртуальные машины — по сути, виртуальные серверы, в которых будут запускаться те или иные рабочие нагрузки.
Казалось бы, нормальное решение, если бы они выбрали под свои нужды ту или иную облачную платформу, и реализовывали собтвенные хотелки на ней. Но, по видимому, это не путь джедая.
Поэтому, ребята проанализирвали рынок облачных платформ, и приняли решение пилить собтвенный велосипед, чтобы помещать виртуальные машины в кубер согласно собственным хотелкам.
Вынесем за скобки то, что промышленные системы виртуализации, вроде той же vmware, имеют нативную поддержку кубера (vmware tanzu), и их использовать было бы более целесообразно. И даже опустим то, что запихнуть ВМ в контейнер целиком - крайне специфичное, нишевое решение.
Но некоторый реализованный функционал вызывает оторопь странными принятыми решениями, яркий пример которых ниже:
Да, они определенными костылями добились того, что трафик идет только на один из них, но выглядит это настолько "надежно", что совать это в прод - я бы не рискнул.
Виртуальная карта — это фактически набор цифр. Она не имеет физического носителя. Пользователю при получении просто выдаются 16-значный номер карты, срок ее действия и коды безопасности CVV2 или CVC2 (на пластиковых картах они обычно написаны сзади).
Считается, что такие карты более безопасны, чем обычные, пластиковые, поскольку защищают от мошенничества непосредственно с самой картой и ее реквизитами: для нее нельзя создать дубликат, сфотографировать или подсмотреть данные. (Или можно, но другими способами).
С другой стороны, полностью заменить виртуальной картой реальную пока проблематично
Во первых банки, как правило, предлагают короткий период действия таких карт, обычно это несколько месяцев, а значит использовать их для постоянных автоматических платежей будет довольно проблематично. Банки объясняют такую меру тем, что виртуальные карты «имеют высокую вероятность компрометации», - то есть тоже не безопасны.
Во вторых такой картой удобно расплачиваться при онлайн шоппинге, но вот наличку с нее, как вы понимаете, не снять. Вообще следует помнить, что механизм оплаты как пластиком, так и виртуальной картой, один и тот же и риски плюс- минус равны.
В третьих сегодня существует тренд на оформление валютных виртуальных карт, выпущенных не российскими банками, которые можно использовать для оплаты услуг или товаров, например, на зарубежных сайтах. Это дает интересные возможности но, в то же время, является своего рода лотереей: нет никаких гарантий, что на такой карте вообще окажутся деньги, а также что она сработает в нужном вам интернет магазине. Многие магазины как в РФ, так и за рубежом, не дают оплачивать свои товары с помощью таких карт.
В общем, Виртуальная карта, например привязанная к телефону, часам или другому гаджету, может быть весьма полезным вспомогательным способом оплаты. Однако полностью заменить пластик ею пока не получится. К тому же лучше не держать на таких картах значительные суммы, чтобы не рисковать оказаться в один далеко не приятный момент временно не платежеспособным.