>>Очень сложно соблюдать дисциплину при разделении ресурсов
>
>Вот почему и сказал про 2.6.18/rhel5 branch. Там ещё не было
>всё разломано при переезде на linux containers, и --cpus работает, и
>всё прочее задокументированное (по крайней мере у меня).
>в 2.6.18/AMD64 я встретил очень редкий баг с утечкой памяти, который кроме меня на форуме только один пользователь описал.
>>тем более что для OpenVZ практически нет хороших бесплатных панелей управления.
>
>Тут не смотрел -- webvz/easyvz совсем не то?
webvz я даже пытался править - там от меня на каждой странице в последних релизах есть одна строчка. Но принципиально я ruby не использую - слишком много тащить с ним надо, и есть у webvz фундаментальный глюк - долгие операции типа копирования или создания, при прерывании HTTP сеанса, могут окончится плохо, и уж точно я не узнаю о результатах их выполнения, так что это только запускалка скриптов. Машины три я этим оснастил, потом забил.
easyvz смотреть не стал. Такого уровня поделки я могу и сам написать достаточно быстро, но пользы от них мало. proxmos я бы ещё запустил, но он требует аппаратной поддержки, а у меня достаточно машин без оного. hypervm пробовал, круто, но во-первых слишком круто, во-вторых требует real ip, во-вторых он всё равно спёкся.
>
>>Миграция машины на другое оборудование может привести к самым неожиданным эффектам,
>>причём не сразу.
>
>По части лимитов, если памяти/процессоров существенно иначе? Вообще-то мне доводилось таскать
>и HN+VE, и отдельные VE по совсем разным железкам и как
>раз был поражён, насколько _мало_ это заняло времени и насколько _не_
>породило проблем (в том числе и в дальнейшем).
Например, живая миграция возможна только на однотипное оборудование, но это мелочи; а вот лимиты на процессор в относительных попугаях - и непонятно, как эти единицы будут пересчитаны.
Несмотря на эти проблемы 5 машин под OpenVZ у меня есть.
