UMGUM.COM 

KVM + FreeBSD ( О запуске FreeBSD в среде виртуализации Qemu-KVM. )

28 апреля 2017

Virtualizer: QEMU version 2.5.0.
OS: FreeBSD 9.3, 10.3.

В очередной раз столкнувшись с необходимостью протестировать сервисы на FreeBSD, с некоторым удивлением обнаружил, что легенды о полнейшей "невиртуализируемости" этой операционной системы живы даже среди весьма активных энтузиастов серверного и сетевого администрирования. Это не так, конечно же - FreeBSD отлично живёт в среде полной аппаратной виртуализации Hyper-V, VMware и Qemu-KVM. Как многолетний пользователь последней системы виртуализации напишу немного о работе FreeBSD в ней.

Гостевые драйверы поддержки "virtio" для FreeBSD версий старше 9.3 не были включены в базовое ядро, и распространялись в виде порта, как и вообще всё для этой замечательной ОС, а в более молодых релизах драйверы "virtio" оформлены в виде автоматически запускаемого стабильного модуля ядра. В общем, начиная с "FreeBSD 9.3" таковая запускается в среде виртуализации Qemu-KVM запросто, с указанием ряда параметров в конфигурационных файлах.

При создании виртуальной машины в конфигураторе следует изначально выбрать следующие параметры оборудования виртуальной машины:

Disk: virtio, raw.
Network: virtio.

Соответственно, при инсталляции ОС на этапах конфигурации сетевой и дисковой подсистемы следует обратить внимание на правильный выбор соответствующего оборудованию драйверов:

Disks: VirtIO Block Device (vtbd0).
Network: VirtIO Networking Adapter (vtnet0).

Предположим, на этапе инсталляции мы выбрали эмуляцию дисковых и сетевых устройств аналогичных физическим, а сейчас желаем перейти (или вообще хотим виртуализировать аппаратное решение, благо это делается простым: dd < /dev/ada0 bs=8M | ssh user@host.example.net "dd > /storage/virt-ada0 bs=8M") на использование более скоростных драйверов "virtio". Исходя из того, что у нас есть дистрибутивные модули ядра, осуществляем поэтапный перевод ОС на работу с виртуальным оборудованием через драйверы "virtio".


Перед внесением изменений в конфигурацию проверяем, загружаемы ли в принципе нужные нам модули ядра:

# kldload -nv virtio

virtio is already loaded

Дистрибутивные модули ядра загружаются автоматически, так что никаких добавлений опций вроде "virtio_load=YES" в файл "/boot/loader.conf" не требуется.

В соответствии с изменением именования блочных устройств, правим параметры монтирования, подставляя зарезервированное для "virtio"-устройств имя "vtbd" вместо физических "ad", "da" или "acd":

# vi /etc/fstab

# Device      Mountpoint  FStype  Options Dump  Pass#
#/dev/ada0p2  /           ufs     rw      1     1
/dev/vtbd0p2  /           ufs     rw      1     1
#/dev/ada0p3  none        swap    sw      0     0
/dev/vtbd0p3  none        swap    sw      0     0
....

Соответственно корректируем имена сетевых карт, подставляя зарезервированное для "virtio"-устройств имя "vtnet" вместо физических "dc", "fxp" или "em":

# vi /etc/rc.conf

....
#ifconfig_em0="DHCP"
ifconfig_vtnet0="DHCP"
....

Если со старым именем сетевого интерфейса уже много чего связано и переделка проблематична, то на этапе инициирования можно переименовать новый, виртуальный, по названию старого:

# vi /etc/rc.conf

....
ifconfig_vtnet0_name="em0"
ifconfig_em0="DHCP"
....

После сохранения конфигурации дисковой и сетевой подсистемы останавливаем виртуальную машину:

# shutdown -p now

Теперь остаётся изменить параметры виртуального оборудования, указав типы устройств "virtio" в соответствии в приведённым в начале заметки рекомендациями.


Заметки и комментарии к публикации:


Оставьте свой комментарий ( выразите мнение относительно публикации, поделитесь дополнительными сведениями или укажите на ошибку )