Виртуализация FreeBSD на Hyper-V

6 июля 2015, 12:29

Решил побаловаться с SCVMM 2012 R2, посмотреть, что это такое и с чем его едят. Развернул два хоста с Hyper-V Server 2012 R2, и один хост с Win2012 R2 под общее хранилище кластера виртуализации.

Первым делом поставил в виртуалку фрю, чтобы посмотреть, как оно себя там чувствует. Оказалось, что чувствует фря себя там относительно неплохо. Прямо из коробки есть синтетический сетевой, и синтетический же дисковый адаптер. Правда, с последним возник касичок, о чём и пойдёт речь ниже.

Суть косяка в том, что фря видит ДВА диска там, где по факту он всего один. На этапе установки это выглядит так:

Я выбрал при установке da0, и поставил систему туда, и всё отлично заработало. Но решил разобраться, в чём тут дело. Первое предположение было, что фря видит два диска из-за проблем в драйвере. И ada0 — это эмулируемый дисковый контроллер, а da0 — синтетический. Гуглинг ничего не показал, кроме указаний на статью в MSDN. Но там никакого внимания этой проблеме не уделено, просто скриншот (это как раз он выше) представлен, и всё. И пользователь в комментариях задаёт вопрос, типа, «why attached virtual disk to guest is visible twice? It's visiblle as ada0 and da0». Или, иными словами, а почему диск виден дважды под разными именами? Но ответа на этот вопрос не последовало.

Больше никакой информации найти не удалось, поэтому я решил написать команде разработчиков в Microsoft, которые пилят поддержку гостевых компонентов Hyper-V во фре. Написал безо всякой надежды на ответ, однако на следующий день мне ответили.

В общем, по итогам общения выяснилось, что действительно, два диска представляют по сути один диск, но видимый через разные дисковые контроллеры. ada0 — это эмулируемый контроллер, da0 — синтетический. Разработчики рекомендовали использовать da0, так как будет выше производительность и ниже нагрузка на процессор. И можно слегка поправить исходники соответствующего модуля, чтобы система перестала видеть диск ada0 вообще, и остался только da0. Для этого нужно сделать следующее: в файле /usr/src/sys/dev/hyperv/stordisengage/hv_ata_pci_disengage.c необходимо найти функцию v_ata_pci_probe(), и заменить в ней возвращаемое значение (return value) с BUS_PROBE_DEFAULT на BUS_PROBE_VENDOR. После этого пересобрать и установить ядро. Я проделал это, и проблема исчезла.

Также был затронут вопрос про KVP daemon. Это процесс, который умеет из гостевой фри общаться с гипервизором, и принимать/передавать туда-сюда key-values pairs. Т. е. какие-то параметры конфигурации. В частности, он используется для того, чтобы в Hyper-V manager можно было видеть IP-адрес, который имеет гостевая фря. И, по слухам, также может получать статические IP из пула, назначаемого из SCVMM, и прописывать его в гостевую систему. Но это я ещё не проверял, поэтому не знаю.

В общем, с KVP (процесс hv_kvp_daemon) тоже проблемка — он стартует только один раз после установки системы, а потом отказывается. Я порылся, и выяснил, что при запуске hv_kvp_daemon пытается создавать директорию /var/db/hyperv/pool. И если эта директория уже существует, (и следовательно, создать её не удаётся), то hv_kvp_daemon не запускается. Налицо просто некорректная обработка ошибки при попытке создания каталога. Т. е. вместо проверки на существование каталога делается попытка создания, и если она неудачная, то fail. Удаление каталога руками проблему решает — hv_kvp_daemon запускается. Непонятно, почему в системе нет стартового скрипта для этого демона, и его нужно запускать ручками. Возможно, считается, что демон ещё не доведён до ума, поэтому и стартового скрипта нет. В принципе, эту проблему с создание каталога можно обойти в стартовом скрипте — удалять каталог после остановки демона, и проверять каталог на существование при старте, и если он есть — опять таки, удаляем, hv_kvp_daemon его создаст себе сам.

Мораль: фрю вполне можно использовать в качестве гостевой ОС внутри Hyper-V. Я вижу в коммитах фрёвых исходников, что какая-то работа потихоньку, поддержка Hyper-V во фре допиливается, медленно, но верно. Остаётся дождаться только работы динамической памяти в гостевой фре, и можно совершенно смело гостевать фрю на Hyper-V. Сейчас оно всё работает — сетка и диски видны из коробки (на фре 10.1), крутится довольно стабильно. Правда, я нагрузки большой не давал, но в рамках той нагрузки, что есть, всё работает.

3 комментария
solyara

Спасибо, интересное исследование.
Проблему с KVP я решил так:
sed -i '' 's/action \«\/usr\/sbin\/hv_kvp_daemon\»;/action \«rm -rf \/var\/db\/hyperv\/pool ; \/usr\/sbin\/hv_kvp_daemon\»;/' /etc/devd/hyperv.conf

По сути просто в файле /etc/devd/hyperv.conf
action «/usr/sbin/hv_kvp_daemon»;
заменил на
action «rm -rf /var/db/hyperv/pool ; /usr/sbin/hv_kvp_daemon»;

Автор блога

А вы фрю в Hyper-V виртуализируете? Как оно там себя показывает?

Мы просто только тестовое окружение в Hyper-V строили, для общего развития, в продакшн не пускали.

solyara

У нас в Hyper-V фряхи используются как узлы для отдела тестирования и отдела разработки, в основном это web серверы на nginx и apache и шлюзы с ipfw nat. Заказчики обычно ставят продукты на железки так что Hyper-V + FreeBSD не сильно востребовано, но мне нравится.

Автор блога

Виртуализация шагает по планете, везде наоборот, от железа отказываются в пользу виртуалок :-)

У нас в конторе одно подразделение есть, «отдел контроля качества». Они тут как-то доколупались в трудную минуту, «а почему у вас сервер такой-то тормозит, и давайте вы его будете выносить на железо». Им в цветных выражениях быстро объяснили, что «вот тут оно тупит, но работает, а если чихнёт ваше железо, чинить можно будет очень долго, и не исключено, что безуспешно». После этого товарищи отвяли :-)

solyara

Фря вообще за последние года три серьезно поднялась как продукт для бизнеса. Во многом благодаря должному вниманию Фри как гостевой машине. Ещё бы гипервизором могла быть конкурентоспособным и цены бы ей не было. Очень надеюсь на развитие bhyve во фре.

Автор блога

Поднялась, факт.

Я, правда, не очень понимаю, зачем фре собственный гипервизор. Всё равно до акул этого бизнеса bhyve ещё пилить и пилить. Там же масса всего — централизованное управление, кластеризация, live migration в разных позах, fault tolerance, автоматическая балансировка нагрузки. А на одиночном хосте гипервизор сейчас мало интересен, разве что в лабораторных условиях.

Это Микрософт целенаправленно выделил бабла, серьёзно доработал свой гипервизор и обвязку к нему, и за жалкие 3-4 года сумел отжать у VMware крупную долю рынка. У фри в этом плане ресурсов куда как меньше. Так что я скорее склонен скептически смотреть на bhyve.

Ваш комментарий
адрес не будет опубликован

ХТМЛ не работает

Ctrl + Enter
Популярное