Столкнулись с очередной задачей — заказчик поставил условие развернуть стенд на уже имеющейся, конфликтующей инфраструктуре. У него кластер Proxmox, у нас Libvirt
Решение в лоб — не помогло, попытка установить libvirtd потребовала удаления proxmox. Не долго думая решили скреативить. Смотрите под катом элегантное решение как и на ёлку залезть и ничего не ободрать.
Коротко о нас — команда разработчиков WriteX Team. Работаем с Linux с 2000го года под девизом — нет ничего невозможного для Linux. Сказано — сделано. пошли думать. Варианты развития: скомпилировать libvirt либо уйти в контейнер. Гугл как обычно помог, нашел очень полезную статью: stgraber.org/2014/01/01/lxc-1-0-security-features и смотрим, что в принципе можно подарить контейнеру любое устройство. Смотрим (без разрешения автора, но не убирая ссылок. немного копипаста):
Большинство LXC шаблонов устанавливает только несколько записей
# Default cgroup limits
lxc.cgroup.devices.deny = a
## Allow any mknod (but not using the node)
lxc.cgroup.devices.allow = c *:* m
lxc.cgroup.devices.allow = b *:* m
## /dev/null and zero
lxc.cgroup.devices.allow = c 1:3 rwm
lxc.cgroup.devices.allow = c 1:5 rwm
## consoles
lxc.cgroup.devices.allow = c 5:0 rwm
lxc.cgroup.devices.allow = c 5:1 rwm
## /dev/{,u}random
lxc.cgroup.devices.allow = c 1:8 rwm
lxc.cgroup.devices.allow = c 1:9 rwm
## /dev/pts/*
lxc.cgroup.devices.allow = c 5:2 rwm
lxc.cgroup.devices.allow = c 136:* rwm
## rtc
lxc.cgroup.devices.allow = c 254:0 rm
## fuse
lxc.cgroup.devices.allow = c 10:229 rwm
## tun
lxc.cgroup.devices.allow = c 10:200 rwm
## full
lxc.cgroup.devices.allow = c 1:7 rwm
## hpet
lxc.cgroup.devices.allow = c 10:228 rwm
## kvm
lxc.cgroup.devices.allow = c 10:232 rwm
смотрим, коды устройств на dom0,
# ls -lah /dev/kvm
crw-rw-rw- 1 root kvm 10, 232 Июн 1 11:55 /dev/kvm
и далее, разрешаем все нужные нам устройства и создаем их в контейнере:
mknod /dev/net/tun c 10 200
mknod /dev/kvm c 10 232
запускаем систему и ставим всё что нам необходимо в нашем контейнере — не нарушив ничего у заказчика. По моему — круто!
Готовы ловить помидоры, но только после полного осознания глубины креатива ;-)
Ссылки на материалы:
Комментарии (25)
Lelik13a
02.06.2017 07:31Конечно молодцы, что разобрались, но чего-то революционного и «креативного» нет — достаточно только внимательно почитать документацию и посмотреть логи.
У меня virtualbox точно так же в контейнере крутится.
И не забудьте, что сперва все необходимые модули должны быть установлены и загружены в нулевом домене.
Fox_exe
02.06.2017 08:55Немного погуглил, но так и не понял, какой смысл ставить Libvirt в Proxmox — ведь там и так есть KVM.
Разница в производительности или в функционале?
lovecraft
02.06.2017 09:48Решение в лоб — не помогло, попытка установить libvirtd потребовала удаления proxmox.
Вроде Proxmox основан на пакетной базе Debian, значит, чтобы избежать проблем с зависимостями, нужно было чуть-чуть подправить control-файл в deb-пакете libvirt и у вас бы все встало. Или проблема была глубже и конфликт был на уровне файлов/библиотек?
запускаем систему и ставим всё что нам необходимо в нашем контейнере — не нарушив ничего у заказчика
Можно было бы вообще загнать libvirt c QEMU внутрь полноценной виртуальной машины с помощью nested kvm, но там IOPS немного просядут, зато изоляция полная )
WriteX
02.06.2017 13:37задача не только не тронуть proxmox, но и отделить все компоненты от основной, уже настроенной системы.
можно было и пакеты поломать немного, и другие варианты рассмотреть, но связаны были бы системы в плотный клубок.Uirandir
02.06.2017 13:43Вам бы пришлось ломать пакеты проксмоса, то есть фактически брать на себя поддержку специальной репы с их пакетами, но собранными так, что бы оно не кричало на либвирт. Не-не-не. Все правильно сделали, раз уж подобная задача стояла.
Uirandir
02.06.2017 13:38> нужно было чуть-чуть подправить control-файл в deb-пакете libvirt
Проблема в зависимостях пакета proxmox, это у него прописан конфликт с libvirt. А libvirt вообще не знает о существовании проксмокса, ибо тот — сторонняя разработка существующая только в собственной репеlovecraft
02.06.2017 14:18Зачем менять Proxmox? У него конфликт со всем, что предоставляет libvirt (строка Provides в control-файле), а ваш пакет будет предоставлять libvirt-custom, и все дела.
SchmeL
02.06.2017 12:28а зачем kvm на хосту с proxmox, который по сути тоже — kvm, разве стенд нельзя развернуть на proxmox?
Вот если бы еще видеокарту в lxc можно было бы пробросить…WriteX
02.06.2017 14:14надо попробовать.
видеокарта ведь такое же устройство…
хост систему с терминала запустить, а видео отдать гостю…
по крайней мере с KVM такое прокатывало
Uirandir
02.06.2017 14:24> Вот если бы еще видеокарту в lxc можно было бы пробросить…
Посмотрите сюда:
http://sqream.com/setting-cuda-linux-containers-2/
hokum13
02.06.2017 13:38Я наверное выражу вопрос многих: а зачем? Зачем разворачивать libvirt на proxmox? Тем более на продакшане?
Uirandir
02.06.2017 13:45Ну тогда вопрос должен скорее звучать как «А зачем разворачивать Proxmox, а не использовать libvirt в продакшене?»
Судя по тексту ребятам пришлось работать с тем, что есть, а их скрипты(это уже не текст, а догадка) завязаны на либвирт. Логично не костылить велосипед к проксмоксу, а использовать свое готовое, но пришлось заюзать lxc для того, что бы не мешать системе.hokum13
07.06.2017 09:31Не, ну proxmox вполне пригоден для продакшана. Но да, вопрос именно в том, что нужно таки определиться с платформой, а не городить костыли для продакшана. Ведь на GNU/Linux можно сотворить очень многое (почти все что угодно), но поддерживать натворенное с «фантазией» после этого — ад!
Fox_exe
07.06.2017 19:32Особенно если собирал один (И очень давно), а поддерживать другому…
WriteX
07.06.2017 21:22поэтому выбран был способ, при котором не надо проходить все круги.
и использовали штатные средства, но с небольшим хаком.hokum13
08.06.2017 09:05Нифига себе штатные средства… Логика примерно такая: «Нам нужно сайт развернуть. Но работает он только под nginx. Дописывать его под apache мы не хотим. А заказчик нам выделил место на продакшн виртуалке с apache, поэтому мы вместо того чтобы спорить с заказчиком запилили ему туда контейнер с nginx развесив их(apache&nginx) на разные порты.»
Зачем вообще прикручивать libvirt туда, где уже неплохо крутится proxmox? Чего такого невменяемо крутого может дать libvirt по сравнению с proxmox, чтобы городить в продакшене велостыли? Зачем вы так сделали?WriteX
08.06.2017 11:11Выше уже дан ответ из контекста, «обстоятельства диктуют правила».
Все написано было под одну систему, отлажено, проверено.
вместо предоставления отдельного железа нам дали готовый proxmox со словами — вот, но ничего не сломать и ничего не трогать. и работать должно к утру.hokum13
08.06.2017 17:00Проблема в том, что через пол года местный СА может пульнуть sudo apt-get update&& sudo apt-get dist-upgrade -y и снести все ваши наработки, похоронив уже работающий проект вместе с каким-нибудь бизнес-процессом. Или при той же команде улетит сам proxmox.
Впрочем не мне Вас судить, сам тот еще костыльщик.
Erelecano
Простите, а где хотя бы ссылка на автора?
Ссылки на автора у вас нет
https://stgraber.org/2014/01/01/lxc-1-0-security-features/
Stephane Graber — один из основных разработчиков LXC и LXD
WriteX
дана ссылка на перевод. за оригинал — спасибо, сейчас размещу
Erelecano
Вы переводчика назвали автором, что неправильно. Переводчик — огромный молодец, но он не автор, ну совсем. У Stephane еще хорошие статьи и по LXD были, их тоже рекомендую.
WriteX
спасибо! исправил жуткую несправедливость.
Erelecano
Да я взъелся потому, что Stephane — наглядный пример того, что Canonical за свои деньги несет пользу коммунити. LXC и LXD разрабатываются сотрудником Canonical, да еще он прекрасные статьи пишет в свободное время.
Переводчик-то тоже молодец, перевести цикл статей это тоже нужно время и желание.
Ipeacocks
У Стефана статьи отличные, да.