Комментарии 25
Простите, а где хотя бы ссылка на автора?
Ссылки на автора у вас нет
https://stgraber.org/2014/01/01/lxc-1-0-security-features/
Stéphane Graber — один из основных разработчиков LXC и LXD
Ссылки на автора у вас нет
https://stgraber.org/2014/01/01/lxc-1-0-security-features/
Stéphane Graber — один из основных разработчиков LXC и LXD
дана ссылка на перевод. за оригинал — спасибо, сейчас размещу
…
Конечно молодцы, что разобрались, но чего-то революционного и «креативного» нет — достаточно только внимательно почитать документацию и посмотреть логи.
У меня virtualbox точно так же в контейнере крутится.
И не забудьте, что сперва все необходимые модули должны быть установлены и загружены в нулевом домене.
У меня virtualbox точно так же в контейнере крутится.
И не забудьте, что сперва все необходимые модули должны быть установлены и загружены в нулевом домене.
Немного погуглил, но так и не понял, какой смысл ставить Libvirt в Proxmox — ведь там и так есть KVM.
Разница в производительности или в функционале?
Разница в производительности или в функционале?
Решение в лоб — не помогло, попытка установить libvirtd потребовала удаления proxmox.
Вроде Proxmox основан на пакетной базе Debian, значит, чтобы избежать проблем с зависимостями, нужно было чуть-чуть подправить control-файл в deb-пакете libvirt и у вас бы все встало. Или проблема была глубже и конфликт был на уровне файлов/библиотек?
запускаем систему и ставим всё что нам необходимо в нашем контейнере — не нарушив ничего у заказчика
Можно было бы вообще загнать libvirt c QEMU внутрь полноценной виртуальной машины с помощью nested kvm, но там IOPS немного просядут, зато изоляция полная )
задача не только не тронуть proxmox, но и отделить все компоненты от основной, уже настроенной системы.
можно было и пакеты поломать немного, и другие варианты рассмотреть, но связаны были бы системы в плотный клубок.
можно было и пакеты поломать немного, и другие варианты рассмотреть, но связаны были бы системы в плотный клубок.
> нужно было чуть-чуть подправить control-файл в deb-пакете libvirt
Проблема в зависимостях пакета proxmox, это у него прописан конфликт с libvirt. А libvirt вообще не знает о существовании проксмокса, ибо тот — сторонняя разработка существующая только в собственной репе
Проблема в зависимостях пакета proxmox, это у него прописан конфликт с libvirt. А libvirt вообще не знает о существовании проксмокса, ибо тот — сторонняя разработка существующая только в собственной репе
а зачем kvm на хосту с proxmox, который по сути тоже — kvm, разве стенд нельзя развернуть на proxmox?
Вот если бы еще видеокарту в lxc можно было бы пробросить…
Вот если бы еще видеокарту в lxc можно было бы пробросить…
Я наверное выражу вопрос многих: а зачем? Зачем разворачивать libvirt на proxmox? Тем более на продакшане?
Ну тогда вопрос должен скорее звучать как «А зачем разворачивать Proxmox, а не использовать libvirt в продакшене?»
Судя по тексту ребятам пришлось работать с тем, что есть, а их скрипты(это уже не текст, а догадка) завязаны на либвирт. Логично не костылить велосипед к проксмоксу, а использовать свое готовое, но пришлось заюзать lxc для того, что бы не мешать системе.
Судя по тексту ребятам пришлось работать с тем, что есть, а их скрипты(это уже не текст, а догадка) завязаны на либвирт. Логично не костылить велосипед к проксмоксу, а использовать свое готовое, но пришлось заюзать lxc для того, что бы не мешать системе.
Не, ну proxmox вполне пригоден для продакшана. Но да, вопрос именно в том, что нужно таки определиться с платформой, а не городить костыли для продакшана. Ведь на GNU/Linux можно сотворить очень многое (почти все что угодно), но поддерживать натворенное с «фантазией» после этого — ад!
Особенно если собирал один (И очень давно), а поддерживать другому…
поэтому выбран был способ, при котором не надо проходить все круги.
и использовали штатные средства, но с небольшим хаком.
и использовали штатные средства, но с небольшим хаком.
Нифига себе штатные средства… Логика примерно такая: «Нам нужно сайт развернуть. Но работает он только под nginx. Дописывать его под apache мы не хотим. А заказчик нам выделил место на продакшн виртуалке с apache, поэтому мы вместо того чтобы спорить с заказчиком запилили ему туда контейнер с nginx развесив их(apache&nginx) на разные порты.»
Зачем вообще прикручивать libvirt туда, где уже неплохо крутится proxmox? Чего такого невменяемо крутого может дать libvirt по сравнению с proxmox, чтобы городить в продакшене велостыли? Зачем вы так сделали?
Зачем вообще прикручивать libvirt туда, где уже неплохо крутится proxmox? Чего такого невменяемо крутого может дать libvirt по сравнению с proxmox, чтобы городить в продакшене велостыли? Зачем вы так сделали?
Выше уже дан ответ из контекста, «обстоятельства диктуют правила».
Все написано было под одну систему, отлажено, проверено.
вместо предоставления отдельного железа нам дали готовый proxmox со словами — вот, но ничего не сломать и ничего не трогать. и работать должно к утру.
Все написано было под одну систему, отлажено, проверено.
вместо предоставления отдельного железа нам дали готовый proxmox со словами — вот, но ничего не сломать и ничего не трогать. и работать должно к утру.
Проблема в том, что через пол года местный СА может пульнуть sudo apt-get update&& sudo apt-get dist-upgrade -y и снести все ваши наработки, похоронив уже работающий проект вместе с каким-нибудь бизнес-процессом. Или при той же команде улетит сам proxmox.
Впрочем не мне Вас судить, сам тот еще костыльщик.
Впрочем не мне Вас судить, сам тот еще костыльщик.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
QEMU-KVM под LXC