Pull to refresh

Comments 9

А зачем использовать EFI, если kvm умеет напрямую загружать ядро из хоста. Не требуется загрузчик, легко управлять параметрами загрузки и версией загружаемого ядра. Можно так-же размещать виртуалки на LVM томах без таблицы разделов. В общем все, что описано в статье. Скорей всего даже шаренный реад-онли виртио диск будет работать (не проверял).
А как попросить qemu-kvm взять ядро с хоста?
Я использую этот метод для того, чтобы не вытаскивать руками обновленные версии ядра из гостей на гипервизор и не управлять параметрами загрузки ядер самому, а доверять это конфигам гостевых систем.
А что если /boot монтировать по nfs? То есть, грузить ядро с хоста, а затем по nfs монтировать /boot, чтобы ядро обновлялось с гостевой системы?
Это отличный вариант, но мне не подошел. В Ubuntu, например, образы ядер содержат в своем названии версию, а символьная ссылка со стандартным именем на актуальную версию делается в корне файловой системы, т. е. вне /boot. В связи с этим, после обновления, нужно будет что-то править на гипервизоре, например, изменять имя файла ядра в конфиге гостя. Ну и параметры ядра задаются вне гостя, что тоже, иногда, не удобно.
Настроил у себя, оказалось что grub-efi детектит 2 непонятно откуда вылезших диска очень похожих на floppy. При загрузке в консоле вылезают две строки:

Boot Failed. EFI Floppy
Boot Failed. EFI Floppy 1


И наша rootfs съезжает на hd3:

grub> ls -l
[…]
Device hd1: No known filesystem detected - Total size 2880 sectors
Device hd2: No known filesystem detected - Total size 2880 sectors
[…]


Так и не удалось победить и убрать эти лишние 2 диска :(

Чтобы не зависеть от номера hd, можно вместо ключика -p "(hd1)/boot/grub/" вписать -c grub-early-config.conf, а в конфиг grub-early-config.conf вписать примерно такое:

search.fs_label ROOT root
set prefix=($root)/boot/grub


Тогда grub-efi будет искать rootfs по метке диска («ROOT», в данном случае). Во всех виртуальных машинах нужно будет выставить одинаковую метку диска.
Сообщения про флопы это, вроде, фича OVMF. После ковыряния в BIOS виртуалки на EFI разделе появится файлик NvVars, в котором хранится настроеная последовательность загрузки. Пока его нет, OVMF грузится в захардкоженой последовательности — первые два флоповода и потом существующие диски. При этом параметр libvirt <boot dev='hd'/> в OVMF не работает. Сообщения про первые два флопа появляются и у меня, хотя рут никуда не съезжает и флопов в системе нет.

Не понятно, откуда у вас еще пара винтов взялась. Можно конфиг libvirt посмотреть?

С меткой диска решение очень удачное, спасибо.
В конфиге libvirt флопов нету, конечно же (конфиг лежит тут: pastie.org/private/bhu05zgk8zhlow3paquv0a). И ядро при загрузке их не находит. Эти два левых флопа вылезают только если с обычной схемы (grub-pc и /boot на отдельном виртуальном диске) переключиться на описанную вами. Может быть, OVMF чудит, а может быть в паре с QEMU. У меня OVMF из дебиана jessie, но пробовал и с SourceForge — то же самое.

ii  ovmf                           0~20131112.2590861a-2  all                    UEFI firmware for virtual machines
ii  qemu-system-x86                2.1+dfsg-2             amd64                  QEMU full system emulation binaries (x86)

Sign up to leave a comment.

Articles