...И смерть его — на кончике иглы.

Иногда замечаю за собой желание чрезмерно усложнять вещи. Конечно, не в той степени, чтобы любой девайс превращался в часы с кукушкой, но все же. Вот казалось бы, сделай домашний сервер на linux и живи, горя не знай, но нет, мне понадобилось поставить на него OpenBSD. А потом внезапно захотелось накатить разный софт, который, внезапно, в соответствии с современными веяниями, поставляется в виде образа Docker. И в этот момент возникает закономерный вопрос "а что делать то?". Слабый духом человек откажется от OpenBSD, чуть более уверенный в себе пойдет скрести по сусекам, чтобы в эпоху тотального дефицита всей вычислительной электроники (ну ладно, не дефицита, но негуманной стоимости) собрать хоть что-то, что может потянуть пяток Docker-контейнеров, ну а отважный (но, возможно, с долей слабоумия) любитель странного попытается выбрать третий путь.

Так что, всю эту эпопею я затеял для того, чтобы у меня была возможность ставить софт из docker, но при этом не загромождать полку еще одним системником, где крутился бы linux. Именно поэтому, я пошел по несколько запутанному пути и сделал на своем сервере, работающем на OpenBSD виртуальную машину, куда поставил Debian, и куда, в свою очередь поставил docker (а точнее — podman, так как мне он кажется куда более интересной реализацией механизма контейнеризации)

Лирическое отступление. Много лет я считал docker блажью для хипстеров, которые не умеют майнтайнить пакеты под разные дистрибутивы, однако позже, когда работа вынудила меня все же потрогать контейнеры, уже почитав о внутреннем устройстве того, что в основе контейнеризации лежит, я понял, что мой негатив был в основном вызван теми, кто его продвигает, как "универсальное средство дистрибуции", а не тем, как эта технология вообще реализована. К реализации, у меня, по итогу особо претензий и не нашлось. Но повторюсь, это лирика. В 2026м году, docker и правда стал стандартом распространения многих программ, как минимум, серверного назначения, и при правильном приготовлении, он прекрасно работает.

Но, как известно, он использует механизмы, глубоко прошитые в ядро Linux, и поэтому запустить докер-контейнеры под OpenBSD не представляется возможным. Что и привело меня к следующему решению: на сервере с OpenBSD мы поднимаем виртуальную машину, которая и служит у нас средой запуска для контейнеров.

Понятное дело, что можно было просто поставить какой-нибудь KVM (и заиметь интересные проблемы из-за особенностей OpenBSD), но я решил воспользоваться более нативным решением. А именно - vmd. Встроенный демон виртуализации, который идет в OpenBSD из коробки. Из нюансов его применения стоит упомянуть невозможность (на момент написания этой заметки) отдать виртуальной машине больше одного ядра CPU, так что это плохой вариант, если нужно запускать прожорливый софт. Но мне требовалось поднять не слишком требовательные приложения, поэтому я был вполне готов потерпеть просадку производительности в этом месте.

Также, нам нужно, чтобы процессор поддерживал SLAT для AMD или EPT для Intel. У меня в сервере изначально стоял дохлый двухядерный i3, без EPT, поэтому мне пришлось сначала провести довольно крупный апгрейд (который совпал с большой аварией, про которую будет отдельная заметка). Процессор я заменил на подходящий по сокету Intel Xeon на 3ГГц, с четырьмя физическими ядрами. Пришлось прикупить новый кулер (который оказался с RGB-подсветкой, но, к счастью, в закрытом корпусе этого не видно) и выпросить ненужную видеокарту уровня "Затычка", так как у Xeon нет встроенного видеоядра. Также пришлось обновить BIOS на материнской плате, так как поддержка Xeon-ов на моей материнке появилась лишь на поздних версиях прошивки. Но все это, в итоге, было не слишком трудно. Главное — не забыть в BIOS включить поддержку аппаратной виртуализации, а то придется перезагружаться лишний раз (вы можете догадаться, что именно это я и забыл сделать, когда загрузился на новом процессоре в первый раз).

Система загружена, теперь активируем службу vmd:

# rcctl enable vmd
# rcctl start vmd

Дальше стоит настроить сеть. Я решил выбрать вариант с бриджем, чтобы виртуалка получала адрес моей локальной сети от роутера. Для этого делаем следующее:

# mv /etc/hostname.em0 /etc/hostname.vport0
# echo up >> /etc/hostname.vport0
# echo up >> /etc/hostname.em0
# sh /etc/netstart em0 vport0


# cat <<END > /etc/hostname.veb0
add em0
add vport0
up
END
# sh /etc/netstart veb0

Пример взят из OpenBSD FAQ, так что имя em0 нужно поменять на то, которое будет у вас.

Также я добавил в конфигурацию vport0 намертво прошитый MAC-адрес (я его взял от основного интерфейса, увеличив на единичку), чтобы сделать раздачу IP статической. Делается это так:

lladdr XX:XX:XX:XX:XX:XX

После этого я бы рекомендовал еще раз на всякий случай перезагрузиться. Возможно, это я что-то сделал не так, но у меня без перезагрузки сеть не хотела нормально подхватывать адреса.

Теперь, следуя инструкции все из того же FAQ, создаем диск под ВМ:

# vmctl create -s 50G disk.qcow2

Здесь все понятно. Указываем размер диска и название файла. В принципе, в FAQ написано, как можно стартовать ВМ уже на этом месте, но как вариант, можно сразу описать ее в конфиге vmd:

switch "uplink" {
    interface veb0
}


vm "debian" {
        disable


        memory 4G


        cdrom "/path/to/iso/debian-13.4.0-amd64-netinst.iso"
        disk "/path/to/vm/debian.qcow2"


        interface {
                switch "uplink"
                lladdr XX:XX:XX:XX:XX:XX
        }
}

Здесь я описываю виртуальный свитч, который живет на интерфейсе veb0, и виртуальную машину с именем debian, которой выделено 4 гигабайта оперативной памяти, у которой два диска (HDD и CD-ROM) и которая, по умолчанию, отключена, то есть, после перезагрузки не запустится автоматически. Я это сделал умышленно, чтобы система при загрузке не ругалась на несмонтированный рейд)

Чтобы запусить эту машину, говорим ей

# vmctl start debian

Теперь начинается интересное. Единственный способ взаимодействовать с инсталлятором - это serial console, читай, COM-порт. vmd услужливо закидывает нас в эту консоль, и мы даже можем увидеть GRUB, но при попытке запустить хотя бы текстовый инсталлятор, у нас все начинает разваливаться и ругаться, потому что инсталлятор пытается начать показывать красивые шрифты в VESA-режиме, что, само собой, срывает крышу нашей бедной консоли последовательной.

Чтобы это починить, нужно подшаманить с аргументами ядра.

Для этого выбираем в GRUB правку параметров загрузки, стираем из параметров ядра vga-что-то-там и вместо этого пишем:

console=ttyS0,115200n8

Теперь инсталлятор Debian не выпендривается и благополучно начинает показывать себя в последовательной консоли.

Не думаю, что нужно продолжать рассказ о том, как ставить debian, человек, который решил поставить его в виртуалку в OpenBSD наверняка или знает, как это делать, или без труда разберется.

В итоге, мы имеем небольшую, одноядерную виртуалку, работающую внутри OpenBSD-хоста, на которой можно спокойно развернуть небольшое docker-окружение и поставить нужный софт. К сожалению, нет возможности без бубна примонтировать папки с хост-машины в виде дисков внутри виртуалки, но это не слишком большое неудобство и с ним можно жить.