QEMU-KVM под LXC

[Erelecano]

Простите, а где хотя бы ссылка на автора?
Ссылки на автора у вас нет

https://stgraber.org/2014/01/01/lxc-1-0-security-features/
Stéphane Graber — один из основных разработчиков LXC и LXD

[WriteX]

дана ссылка на перевод. за оригинал — спасибо, сейчас размещу

[Erelecano]

Вы переводчика назвали автором, что неправильно. Переводчик — огромный молодец, но он не автор, ну совсем. У Stéphane еще хорошие статьи и по LXD были, их тоже рекомендую.

[WriteX]

спасибо! исправил жуткую несправедливость.

[Erelecano]

Да я взъелся потому, что Stéphane — наглядный пример того, что Canonical за свои деньги несет пользу коммунити. LXC и LXD разрабатываются сотрудником Canonical, да еще он прекрасные статьи пишет в свободное время.
Переводчик-то тоже молодец, перевести цикл статей это тоже нужно время и желание.

[Ipeacocks]

У Стефана статьи отличные, да.

[WriteX]

…

[Lelik13a]

Конечно молодцы, что разобрались, но чего-то революционного и «креативного» нет — достаточно только внимательно почитать документацию и посмотреть логи.
У меня virtualbox точно так же в контейнере крутится.

И не забудьте, что сперва все необходимые модули должны быть установлены и загружены в нулевом домене.

[Fox_exe]

Немного погуглил, но так и не понял, какой смысл ставить Libvirt в Proxmox — ведь там и так есть KVM.
Разница в производительности или в функционале?

[lovecraft]

Решение в лоб — не помогло, попытка установить libvirtd потребовала удаления proxmox.

Вроде Proxmox основан на пакетной базе Debian, значит, чтобы избежать проблем с зависимостями, нужно было чуть-чуть подправить control-файл в deb-пакете libvirt и у вас бы все встало. Или проблема была глубже и конфликт был на уровне файлов/библиотек?

запускаем систему и ставим всё что нам необходимо в нашем контейнере — не нарушив ничего у заказчика

Можно было бы вообще загнать libvirt c QEMU внутрь полноценной виртуальной машины с помощью nested kvm, но там IOPS немного просядут, зато изоляция полная )

[WriteX]

задача не только не тронуть proxmox, но и отделить все компоненты от основной, уже настроенной системы.
можно было и пакеты поломать немного, и другие варианты рассмотреть, но связаны были бы системы в плотный клубок.

[Uirandir]

Вам бы пришлось ломать пакеты проксмоса, то есть фактически брать на себя поддержку специальной репы с их пакетами, но собранными так, что бы оно не кричало на либвирт. Не-не-не. Все правильно сделали, раз уж подобная задача стояла.

[Uirandir]

> нужно было чуть-чуть подправить control-файл в deb-пакете libvirt

Проблема в зависимостях пакета proxmox, это у него прописан конфликт с libvirt. А libvirt вообще не знает о существовании проксмокса, ибо тот — сторонняя разработка существующая только в собственной репе

[lovecraft]

Зачем менять Proxmox? У него конфликт со всем, что предоставляет libvirt (строка Provides в control-файле), а ваш пакет будет предоставлять libvirt-custom, и все дела.

[SchmeL]

а зачем kvm на хосту с proxmox, который по сути тоже — kvm, разве стенд нельзя развернуть на proxmox?
Вот если бы еще видеокарту в lxc можно было бы пробросить…

[WriteX]

надо попробовать.
видеокарта ведь такое же устройство…
хост систему с терминала запустить, а видео отдать гостю…
по крайней мере с KVM такое прокатывало

[Uirandir]

> Вот если бы еще видеокарту в lxc можно было бы пробросить…

Посмотрите сюда:
http://sqream.com/setting-cuda-linux-containers-2/

[hokum13]

Я наверное выражу вопрос многих: а зачем? Зачем разворачивать libvirt на proxmox? Тем более на продакшане?

[Uirandir]

Ну тогда вопрос должен скорее звучать как «А зачем разворачивать Proxmox, а не использовать libvirt в продакшене?»
Судя по тексту ребятам пришлось работать с тем, что есть, а их скрипты(это уже не текст, а догадка) завязаны на либвирт. Логично не костылить велосипед к проксмоксу, а использовать свое готовое, но пришлось заюзать lxc для того, что бы не мешать системе.

[hokum13]

Не, ну proxmox вполне пригоден для продакшана. Но да, вопрос именно в том, что нужно таки определиться с платформой, а не городить костыли для продакшана. Ведь на GNU/Linux можно сотворить очень многое (почти все что угодно), но поддерживать натворенное с «фантазией» после этого — ад!

[Fox_exe]

Особенно если собирал один (И очень давно), а поддерживать другому…

[WriteX]

поэтому выбран был способ, при котором не надо проходить все круги.
и использовали штатные средства, но с небольшим хаком.

[hokum13]

Нифига себе штатные средства… Логика примерно такая: «Нам нужно сайт развернуть. Но работает он только под nginx. Дописывать его под apache мы не хотим. А заказчик нам выделил место на продакшн виртуалке с apache, поэтому мы вместо того чтобы спорить с заказчиком запилили ему туда контейнер с nginx развесив их(apache&nginx) на разные порты.»
Зачем вообще прикручивать libvirt туда, где уже неплохо крутится proxmox? Чего такого невменяемо крутого может дать libvirt по сравнению с proxmox, чтобы городить в продакшене велостыли? Зачем вы так сделали?

[WriteX]

Выше уже дан ответ из контекста, «обстоятельства диктуют правила».
Все написано было под одну систему, отлажено, проверено.
вместо предоставления отдельного железа нам дали готовый proxmox со словами — вот, но ничего не сломать и ничего не трогать. и работать должно к утру.

[hokum13]

Проблема в том, что через пол года местный СА может пульнуть sudo apt-get update&& sudo apt-get dist-upgrade -y и снести все ваши наработки, похоронив уже работающий проект вместе с каким-нибудь бизнес-процессом. Или при той же команде улетит сам proxmox.

Впрочем не мне Вас судить, сам тот еще костыльщик.