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.
Network: virtio.
Соответственно, при инсталляции ОС на этапах конфигурации сетевой и дисковой подсистемы следует обратить внимание на правильный выбор соответствующего оборудованию драйверов:
Disks: VirtIO Block Device (vtbd0).
Network: VirtIO Networking Adapter (vtnet0).
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
....
#/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"
....
#ifconfig_em0="DHCP"
ifconfig_vtnet0="DHCP"
....
Если со старым именем сетевого интерфейса уже много чего связано и переделка проблематична, то на этапе инициирования можно переименовать новый, виртуальный, по названию старого:
# vi /etc/rc.conf
....
ifconfig_vtnet0_name="em0"
ifconfig_em0="DHCP"
....
ifconfig_vtnet0_name="em0"
ifconfig_em0="DHCP"
....
После сохранения конфигурации дисковой и сетевой подсистемы останавливаем виртуальную машину:
# shutdown -p now
Теперь остаётся изменить параметры виртуального оборудования, указав типы устройств "virtio" в соответствии в приведённым в начале заметки рекомендациями.
