>В: Может ли VServer запустить RHEL 3.x с ядром 2.4.2? (ЗдЕсЬ бЫл Саныч)
для Ъ:
> Не имею ни малейшего понятия. У нас есть патчи для ядер 2.4.х, и учитывая, что RHEL 3.x работает с веткой 2.4.х, все должно работать. Обратите внимание, что большинство дистрибутивов не делают _ничего_, что бы требовало специального ядра (кроме вещей, связанных с железом, но это все равно делается на уровне хост системы), так что все должно работать на _любом_ дистрибутиве, который вы выберете в качестве Linux-VServer гостя.
Знает ли кто-нибудь систему виртуализации наподобие OpenVZ/Vserver, но без виртуализации ФС ? Т.е каждый пользователь может иметь свой сетевой интерфейс, но все будут вешать один и тот же /usr/bin/httpd. Здесь будет плюс и по использованию диска, и по использованию shared памяти между процессами разных юзеров.
Я знаю что так устроен VDSManager от ISPsystems, но интересует свободное решение.
>Знает ли кто-нибудь систему виртуализации наподобие OpenVZ/Vserver, но без виртуализации ФС ? Т.е каждый пользователь может иметь свой сетевой интерфейс, но все будут вешать один и тот же /usr/bin/httpd.
Я, возможно, не понял вопроса, но ни ovz, ни vserver не виртуализируют FS. Все выглядит как обычная директория, где лежит chroot системы. И из хоста можно примаунтить в гвест что угодно с помощью mount bind.
Ну так вот, нужно обойтись без чрута, т.е все остается как обычно, только можно нормально раздать пользователям ограничения по памяти и процессору, сети.
>Знает ли кто-нибудь систему виртуализации наподобие OpenVZ/Vserver, но без виртуализации ФС ? Т.е каждый пользователь может иметь свой сетевой интерфейс, но все будут вешать один и тот же /usr/bin/httpd. Здесь будет плюс и по использованию диска, и по использованию shared памяти между процессами разных юзеров.
Если для экономии места, то:
What is vhashify?
The successor of vunify, a tool which does unification based on hash values (which allows to find common files in arbitrary paths.)
It creates hardlinks to files named after a hash of the content of the file. If you have a recent version of the vserver patch (2.2+), with CONFIG_VSERVER_COWBL enabled, you can even modify the hardlinked files inside the vservers and the links will be broken automatically.
There seems to be a catch when a hashified file has multiple hardlinks inside a guest, or when another internal hardlink is added after hashification. Link breaking will remove all the internal hardlinks too, so the guest will end up with different copies of the original file. The correct solution would be to not hashify files that have multiple links prior to hashification, and to break the link to the hashified version when a new internal hardlink is created. Apparently, this is not implemented yet (?).
Кстати в интервью прозвучала правильная мысль до многих красноглазых недоходящая:
"В: Есть ли у вас есть планы по превращению проекта в бизнес?
Я не думаю, что такие понятия, как "бизнес" и отличный софт хорошо ладят вместе. Обычно бизнес сдвигает фокус проекта с разработки очень хорошего продукта на продажу продукта :)
Хотя, конечно же, как консультант, я часто работаю над проектами, связанными с Linux-VServer."
> по памяти, процессам и месту на диске можно
> обычными ulimitами ограничиться, IMHO.
Ты смотрел вообще, что такое ulimit? Это ряд ограничений на процесс (!), плюс одно ограничение на юзера -- количество процессов. Короче, это не работает вообще, невозможно толком задать какие-либо ограничения. Именно поэтому очень большая часть в OpenVZ -- это user beancounters, то есть всякие лимиты на группу процессов (а не на процесс).
Ну и, понятное дело, что "по месту на диске" -- это disk quota, а никакой не ulimit. Опять же, в обычном линуксе есть дисковая квота для пользователей (и групп), плюс к тому в OpenVZ есть квота на группу процессов.
> Ты смотрел вообще, что такое ulimit? Это ряд ограничений на процесс (!), плюс одно ограничение на юзера -- количество процессов. Короче, это не работает вообще, невозможно толком задать какие-либо ограничения. Именно поэтому очень большая часть в OpenVZ -- это user beancounters, то есть всякие лимиты на группу процессов (а не на процесс).
Все зависит от конкретных задач, ulimitы и квоты работают очень даже хорошо для некоторых случаев. а насчет того, что в ulimit только одно ограничение на юзера - не совсем верно: все ограничения на процессы выставляются для конкретных пользователей и групп.
> "по месту на диске" -- это disk quota, а никакой не ulimit.
согласен.
> "Именно поэтому очень большая часть в OpenVZ"
причем тут OpenVZ? :-) сдался вам OpenVZ, как папуасу бусинки, честное слово :)