Виртуализация

KVM

Какие ОС будут?
Есть ли требования к кастомным ядрам?

Если все linux и без кастомных ядер - то lxc или openvz (контейнеры). Если нужна полноценная виртуализация - KVM.

Если железо слабое, то еще один плюс к контейнерам.

Debian, железо чуть ниже среднего. FX-4300 и 16ГБ ОЗУ

Ставь openvz, есть репо для деба[br/] https://openvz.org/Installation_on_Debian

Сколько гостей будет?
Какие ОС на гостях?

Лучше уже CentOS, для которого ядро VZ родное.

Если так хочется deb, то я бы юзал LXC

+1

centos не стоит мучится с дебианом, если нужна винда, то только kvm.

По пожиранию ресурсов вроде как идет в таком порядке
KVM>=XEN>OpenVZ>=LXC.
Другими словами KVM жрет больше всех, LXC меньше всех.
В качестве гипервизора советую libvirt

На работе было на одном серваке 4 kvm и 4 LXC. Все под линем, перешел на openvz доволен как слон. Производительность значительно возросла(из-за перехода kvm->openvz) и ограничение ресурсов просто замечательное, ограничить можно что угодно, а главное внутри гостя видно только доступные ресурсы, в отличие от LXC, где память ограничивается через cgroups, и гость все равно видит всю оперативную память хоста, в итоге бывают накладки.

Все зависит от задач. Если просто сервис повесить в отдельное виртуальное окружение до достаточно LXC. Если же нужна более «виртуализованность» (ограничение ресурсов, сортировка процессов разных гостей и хоста и т.д.) то между Openvz и LXC советую Openvz. Это естественно если все гости и хост будут на линуксах.

Для разных систем, советую kvm или xen. Для xen нужны модифицированные образы ОС, для паравиртуализации. Также xen вроде умеет работать как и kvm, через аппаратную виртуализацию процессора. В таком случае производительность будет равная.

К тому же никто не мешает использовать несколько технологий одновременно. На другом серваке у нас на kvm стоит Windows Server 2008 R2, и куча линуксов на LXC.

Кстати все на debian'ах у нас. Ну для libvirt (гипервизор) и правда centos роднее.

для сервера OpenVZ и ещё была какая-то специфичная контейнерная. КВМ я считаю, излишество, под нужны консольки.

В вики debian написано:

LXC may not provide sufficient isolation at this time, allowing guest systems to compromise the host system under certain conditions

LXC не готов? Или старая информация?

Какая версия lxc? Насчёт дебиана хз, использую lxc на убунту. Версии lxc =>1.0 можно юзать.

Ты понял что сказал?

Пока не совсем понятно про какую версию написано. Если что, читаю тут: https://wiki.debian.org/LXC

Ты понял что я сказал?!?!

https://packages.debian.org/wheezy/lxc

Наркомани на городі!

а, скородрочер, ну ясно всё

Ничем не лучше. Юзаю как ovz как на deb так и на centos.

Это не так

Если использовать в качестве chroot, то готов полностью.
Но по функционалу до openvz ему далеко.
Единственное что не удобно, он активно развивается. Например помню в один прекрасный момент пропала команда lxc-list.

Это не так

А какие отличия? юзаю OpenVZ на debian не вижу каких либо ограничений. Вы не могли бы конкретизировать?

KVM

Это так

Если контейнеры - попробуй Docker, оно щас очень активно развивается.
Если именно «виртуализация» - рекомендую KVM, благо выбор по актуальным дистрам сейчас очень хороший.

Докер! Докер! Стильно, модно, молодёжно, будешь как все в стаде, ничо не соображая качать чьи-то образы из интернета и запускать их.

lxc or kvm

http://www.itroad.ru/iz-novogo-debian-7-wheezy-ubrali-podderzhku-openvz это чепуха? :)

А докер разве не LXC использует?

LXC не готов?

LXC (а точнее, его ядерная часть) — это то, чем стремится стать OpenVZ. Последние версии vzctl уже умеют работать с ванильным ядром, но функциональность пока недостаточна для полноценной реальзации всего того, что есть в ядре OpenVZ.

Так что да, пока существует OpenVZ ядро — LXC не готов. Как станет готов, так и нужда в существовании отдельного ядра отпадёт, и тогда OpenVZ тулзы и LXC тулзы станут просто разными способами управления одной и той же функциональностью, доступной в ядре.

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

о функциональность пока недостаточна для полноценной реальзации всего того, что есть в ядре OpenVZ

Я бы сказал что в LXC ОЧЕНЬ много не хватает того, что есть в ядре OpenVZ.

http://www.itroad.ru/iz-novogo-debian-7-wheezy-ubrali-podderzhku-openvz это чепуха? :)

Я конечно не понимаю, что автору помешало просто в /etc/apt/sources.list подключить репозиторий OpenVZ и пользоваться на здоровье. Я перешел на OpenVZ уже когда использовал Debian Wheezy. Поэтому видимо таких проблем не заметил.

Ну обновился он, ядро исчезло. Ну подключи репозиторий OpenVZ да установи ядро. Перезагрузись. Все - проблема решена. Решение 5-15 минут. Автор статьи сильно передергивает.

О как завернули, два раза перечитал. А я думал , что это ребята из Paralels начали пушить часть своего ядерного кода в ванильное ядро - а LXC это как раз пользует. Да и LXC для чего не готов? Для дома?

Я бы сказал что в LXC ОЧЕНЬ много не хватает того, что есть в ядре OpenVZ.

Зато ядро родное

Зато ядро родное

Согласен. Это удобней.

А я думал , что это ребята из Paralels начали пушить часть своего ядерного кода в ванильное ядро

А вот это тоже очень круто.

Я там ищу ? http://download.openvz.org/debian-systs/dists/ Не могу найти wheezy

https://openvz.org/Installation_on_Debian

Вроде бы поставил. Разобрался с квотами итп (по мануалу все). А как идет привязка аккаунтов к созданным контейнерам?

А как идет привязка аккаунтов к созданным контейнерам?

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

Извиняюсь, не подумал. Забыл что контейнеру дается IP

А можно ли настроить подключение к контейнерам с глобала при условии что в наличии есть всего один IP ?

через тунели putty может быть как-то?

в таблице nat

-A PREROUTING -d <<HNIP>> -p tcp -m tcp --dport 11080 -j DNAT --to-destination 192.168.10.11:80 -m comment --comment «forward http to ve111»
-A PREROUTING -d <<HNIP>> -p tcp -m tcp --dport 11022 -j DNAT --to-destination 192.168.10.11:22 -m comment --comment «forward ssh to ve111»

потом заходишь ssh на HNIP:11022

Можно немного разжевать? :)

-A PREROUTING -d <<HNIP>> -p tcp -m tcp --dport 11080 -j DNAT --to-destination 192.168.10.11:80 -m comment --comment «forward http to ve111» -A PREROUTING -d <<HNIP>> -p tcp -m tcp --dport 11022 -j DNAT --to-destination 192.168.10.11:22 -m comment --comment «forward ssh to ve111»

Обычный nat.
prizident здесь имеет в виду что эти правила iptables прописываются на машине хоста.

HNIP - Внешний IP хоста.
11080,11022 - порты через которые ты будешь подключаться из вне к гостю. То есть на хосте это будут порты 11080, 11022, при подключении к ним, тебя перенаправит на 80,22 порты гостя. prizident приводит пример с ними, так как обычно на 80 висит веб-сервер, а на 22 ssh. Что тебе нужно пробросить в твоем конкретном случае решать тебе.
192.168.10.11 - это предположение что IP адрес гостя такой.
-m comment --comment «forward http to ve111 - комментарии не обязательны.

Другими словами если немного упростить, нужно вбить две команды:
iptables -t nat -A PREROUTING -d ip_хоста -p tcp -m tcp --dport 11080 -j DNAT --to-destination ip_гостя:80
iptables -t nat -A PREROUTING -d ip_хоста -p tcp -m tcp --dport 11022 -j DNAT --to-destination ip_гостя:22

Порты 11080,11022 использовать не обязательно, можешь использовать любые на твое усмотрение. Главное чтобы они были не заняты.

Если есть желание разобраться в iptables советую прочитать http://www.opennet.ru/docs/RUS/iptables/

через тунели putty может быть как-то?

Через тунели тоже можно.
Если подключение идет с машины на линуксе, у нужно подключиться к ssh гостя.

Достаточно на хосте настроить ssh. Не забыть включить опцию AllowTcpForwarding.
На госте я по умолчанию понимаю что ssh тоже настроен и готов принимать входящие соединения.
По умолчанию, чтобы было понятно где какой порт, пусть на хосте ssh слушает на 2222 порту, а на госте на 22 порту. Хотя ничего не мешает им слушать одинаковые порты.
Из вне из клиента пишем ssh -f -N -p 2222 -L локальный_порт:ip_гостя:22 ip_хоста
Туннель проброшен, теперь можно подключаться к гостю по ssh.
Открываем другой ssh -p локальный_порт 127.0.0.1