Скорость загрузки MikroTik RouterOS очень низкая — vmware

У меня такая же проблема. (VMWare Workstation v17.5.0 build-22583795; Windows 10; CHR v7.12) Полностью запуститься и стать работоспособной RouterOS получается только через несколько (3 и более) минут. Во время загрузки на экране появляется надпись «Load system». Та же проблема (но без решения) описана здесь: https://communities.vmware.com/t5/VMware-Workstation-Pro/MikroTik-RouterOS-boot-speed-is-drastically-slow/td-p/2291456 Это делает CHR почти непригодным для моих лабораторных сценариев, где часто приходится перезагружать CHR. Есть ли какое-нибудь решение этой проблемы?

Я использовал образ OVA (версия 7.12) для импорта виртуальной машины в VMWare Workstation. Недавно попробовал обновить «совместимость оборудования» виртуальной машины до VMWare Workstation 17.5 (по умолчанию была версия 10; также пробовал уровень совместимости «ESXI 7.0») согласно https://docs.vmware.com/en/VMware-Workstation-Pro/17/com.vmware.ws.using.doc/GUID-9D101F2A-D85F-4F08-A74A-D1FE6C580D8D.html. Проблема осталась. Кто-нибудь из Mikrotik, пожалуйста, посмотрите на это — сейчас невозможно нормально использовать локальные VM с CHR. Спасибо. Обновление: провёл дополнительные тесты. CHR v6 OVA — та же проблема CHR v7 VMDK — та же проблема

Я пробовал выставлять версию железа на 18 (ESXi 7.0 U1 (7.0.1) / Workstation Pro 16.x). Проблема осталась.

Да, это настройка по умолчанию для OVA, и именно с этого я и начал. Та же проблема.

Только что протестировал это на VMWare Fusion. Пытался обновиться с v7.14betaX до стабильной 7.14… После перезагрузки появилось сообщение «Load system»… и только спустя более 2 минут появился экран входа. Пробовал OVA и VMDK с Fusion на новой машине — оба варианта запускаются минутами. Перезагрузка с RouterOS — тот же многоминутный тайм-аут.

Кратко: загрузка CHR через UEFI в Fusion происходит ОЧЕНЬ быстро — примерно 15 секунд. Проблема в том, что образы CHR не поддерживают правильный UEFI, и VMWare не запускает CHR без «Legacy BIOS». Не уверен, что это полная причина «медленной загрузки», но, что любопытно, так проблема решается.

Пользуюсь CHR с виртуализацией Apple (хотя бы на Intel Mac) — пробую уйти от VMWare. Там нужен UEFI, потому что у Apple нет опции «Legacy BIOS», в отличие от VMWare. Поскольку у меня уже был UEFI-совместимый CHR-образ, решил попробовать на Fusion… И всё сработало.

Как получить UEFI-образ CHR — подсказал @kriszos: http://forum.mikrotik.com/t/router-os-7-on-uefi/156661/5 — он отмечает, что CHR на самом деле имеет EFI-загрузчик, но схема разметки разделов Mikrotik не совпадает со стандартом EFI, поэтому «исправление» — просто конвертировать первый раздел из EXT2 в FAT (EXT2 не поддерживается в UEFI). Это небольшое изменение через gdisk, судя по всему, позволяет загружать CHR в режиме UEFI на Hyper-V gen2, LXD и Apple. Похоже, то же работает и для VMWare Fusion.

Если использовать скрипт @kriszos для создания UEFI-образа CHR, а затем последним шагом конвертировать его в VMDK с помощью командной строки:

qemu-img convert -f qcow2 -O vmdk chr.qcow2 chr.vmdk

(пример: вместо vhdx в последнем шаге скрипта @kriszos меняем на vmdk)

Далее используйте этот «модифицированный» CHR-образ (с новой схемой разделов) в качестве диска и установите загрузку через UEFI в гостевой системе VMWare.

CHR 7.14 stable, похоже, загружается быстро.

У меня нет VMWare Workstation, но если кто-то захочет попробовать… и не заморачиваться с вышеупомянутым bash-скриптом — я уже запустил GitHub CI для автоматической работы скрипта @kriszos «UEFI creator» и добавил VMDK-файл в релизы, чтобы упростить задачу: https://github.com/tikoci/fat-chr/releases

Интересно, поможет ли это решить проблему «медленной загрузки» в Windows VMWare…

Я мог бы выразиться яснее… Официальный образ CHR от Mikrotik требует «Legacy BIOS». А на Fusion такие системы загружаются очень медленно (несколько минут). Использование загрузки через «UEFI» с официальным образом Mikrotik не работает — хотя там и есть код для загрузки через EFI.

Ссылки на мои «переразмеченные» образы CHR — именно они вроде как решают проблему «медленной загрузки» на Fusion — требуют, чтобы в VMWare была включена загрузка через «EFI». Так как VMWare обычно работает одинаково на ESXi, Fusion и Workstation, я предполагаю, что это может помочь и в Workstation — симптомы там такие же, как и в Fusion.

В VMWare Workstation это можно настроить в настройках виртуальной машины: раздел Settings, потом Options, затем вкладка Advanced. Но в VMWare Player, возможно, такой опции выбора между EFI и BIOS нет, точно не знаю.

Во всех VMWare используются файлы VMX, так что в худшем случае можно просто отредактировать файл VMX и поменять там параметр firmware. Если в .VMX есть строка firmware=“efi”, значит загрузка идет через UEFI. Если такой строки нет, можно добавить firmware=“efi” в VMX, чтобы включить эту загрузку.

Как я уже говорил, я тестировал на Fusion, и именно там была проблема с медленной загрузкой. Просто я не знаю точных шагов для текущей версии Workstation, чтобы создать гостевую систему с EFI-загрузкой…

Я добавил GitHub Action для этого bash-скрипта здесь: https://github.com/tikoci/fat-chr/releases В разделе «Assets» вы найдёте vmdk для любой версии 7.12.2 или новее, в вариантах «testing» или «stable». Дайте знать, если у вас тоже загрузка пойдёт быстрее. Я проверял только на Fusion, и у меня всё работало.

_Важное замечание: Mikrotik рекомендует скачивать их образы напрямую, а не использовать «сторонние» пакеты._

На GitHub весь процесс сборки можно посмотреть во вкладке «Actions» здесь: https://github.com/tikoci/fat-chr. Но, да, надеюсь, они выложат нормальный UEFI-образ для скачивания, чтобы не пришлось переделывать пакеты. Я думаю, UEFI нужен для других платформ на базе X86.

@homerouter, нет, образ, похоже, не работает нормально. Он запускается быстро (примерно за 5 секунд) только при отключении функций виртуализации Windows (hypervisorlaunchtype = off), что не позволяет системе использовать важные функции безопасности, такие как «Изоляция ядра». Для многих пользователей это неприемлемый вариант. @Amm0, проверю и отпишусь, когда найдется время. Спасибо.