> 1) Надо было смонтировать .iso image чтобы выковырить файл. Для ядра драйвера loop.o не оказалось. Ядро 2.4.20-021stab028.19.777-enterprise. Это кривизна рук swsoft'а или хостера? Что мне делать?

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

> а нах оно вообще кому-то надо?

http://openvz.org/documentation/tech/usage-scenarios

> Надо было смонтировать .iso image чтобы выковырить файл.

loopback device не поддерживается внутри VPS, в силу его реализации.

Используйте утилиту isoinfo (isoinfo -i /path/to/img.iso -x /file/to/extract > file), или просто поставьте mc и заходите в .iso как в архив.

> Где-то проскакивало, что RedHat в Fedora 5 хочет XEN включить,

Дык, в четвертой уже есть

>еще ':)' поставил

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

да хоть центильен смайликов поставь

>Пусть Red Hat и включает это в свои поделки

надо понимать ты и gcc не пользуешься по идеологическим соображениям

зы. запарили быдлодистрофаны на лоре

Господа, а правда, кто такой Патрик?

http://ru.wikipedia.org/wiki/Патрик_Волкердинг

Патрик - Бог

> loopback device не поддерживается внутри VPS, в силу его реализации.

Пасибо за ответ. А что с TTL?

>Если совсем вкратце, то Xen запускает много модифицированных линуксовых ядер под управлением гипервизора, а OpenVZ имеет одно модифицированное линуксовое ядро, которое умеет создавать изолированные виртуальные среды. Плюсы подхода OpenVZ - большая производительность, более полное использование ресурсов железа. Минусы - невозможность запускать разные ядра, чуть более меньшая изоляция (в теории).

=> к минусам можно причислить невозможность запуска других ОС, верно ? То есть в этом случае Xen обходит OpenVZ по полной программе ...

openvz и xen это разные вещи, более или менее близкий аналог сабжа - jail

>Как раз вчера. Ищем в толксах топик про депрессию в гноме и удивляемся.

В какой реализации ОС *nix собирал то?

>openvz и xen это разные вещи, более или менее близкий аналог сабжа - jail

Тогда нафига эт онужно в ядре ? per-process namespace ?

> Тогда нафига эт онужно в ядре ? per-process namespace ?

а куда же его еще девать? ;) только в кернель и можно

> Господа, а правда, кто такой Патрик?

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

А в сравнении с vserver чем этот OpenVZ отличается? А то по Usage scenarios, упомянутым выше, примерно то же самое...

производительность выше, лучше обращается с ресурсами сервера

> производительность выше, лучше обращается с ресурсами сервера

еще можно добавить - по большему числу параметров управляет VPS'ом

>Тогда нафига эт онужно в ядре ? per-process namespace ?

OpenVZ не умеет per VPS namespaece.

>Патрик конечно не имеет отношения к разротке ядра, но спросить у него все-таки надо :)

Угу и появится оно в слаке только тогда, когда появится в vanilla.

> OpenVZ не умеет per VPS namespaece.

Не совсем так. Внутри VPS вы, конечно, чужие процессы не увидите. А вот находясь в "нулевом" VPS (то есть в хост системе) -- таки да, вы видите все процессы всех VPSов.

Так оно сделано для удобства -- ведь из хост-системы всё равно есть доступ ко всем VPSам, так зачем не показывать их процессы?

>Не совсем так. Внутри VPS вы, конечно, чужие процессы не увидите. А вот находясь в "нулевом" VPS (то есть в хост системе) -- таки да, вы видите все процессы всех VPSов.

Не впечатляет .. однако.

> к минусам можно причислить невозможность запуска других ОС, верно ? То есть в этом случае Xen обходит OpenVZ по полной программе ...

Да, совершенно верно (если вы имеете в виду возможность запуска других ядер - ибо различные дистрибутивы Линукса сосуществуют внутри разных VPSах на ура). точно так же, как и VMware обходит Xen.

Вопрос в том, что за всё надо платить. Вы, наверное, замечали, что софт на "виртуальном железе" VMware работает несколько медленней, чем на обычном железе? В этом минуc VMware - а плюс его в том, что запустить можно любую ОС.

Точно так же, OpenVZ в силу специфики используемого подхода к виртуализации ("виртуализация на уровне ядра") не позволяет запускать разные ядра. Это минус. Однако, накладные расходы на виртуализацию минимальны (1-3%), поэтому производительность максимальна (практически не отличается от "железной").

В каждом конкретном случае выбор остаётся за пользователем. Если вам надо запускать Линукс и Винду на одной машине - это VMware, и вы сможете запустить, скажем, 5-10 виртуальных машин. Если вам надо запускать разные ядра на одной машине - это Xen, и вы сможете запустить несколько десятков виртуальных машин. Если вам надо запускать разные дистрибутивы линукса на одной машине - это OpenVZ, и вы сможете запустить несколько сотен виртуальных машин.

Ещё о том, что умеет делать OpenVZ и не умеет делать Xen:

# позволяет работать сотне VPSов на машине с 1GB RAM

# не имеет накладных расходов на ввод-вывод, как Xen (20-40%)

# поддерживает (и всегда поддерживала) многопроцессорность внутри VPS (если бы вы знали, как это тяжело реализовать в Xen)

# стартовать-стопить VPS за несколько секунд

# создавать новую VPS меньше, чем за за минуту

# менять все QoS параметры на лету (место на диске, лимиты и гарантии на CPU и память)

# позволяет гораздо полнее использовать ресурсы, память, которая не используется в VPS, никуда не резервируется.

>>Не совсем так. Внутри VPS вы, конечно, чужие процессы не увидите. А вот находясь в "нулевом" VPS (то есть в хост системе) -- таки да, вы видите все процессы всех VPSов.

>Не впечатляет .. однако.

Вы *блестяще* аргументировали свою точку зрения, коллега! Технично, лаконично и грамотно. Против таких аргументов, пожалуй, я возражать не берусь.

А вот как vps-ы лучше бэкапить? останавливая их? или есть какие-то иное средство против перхоти.

PS. Рассматриваю вопрос практического применения.

> Ещё о том, что умеет делать OpenVZ и не умеет делать Xen: > ... > # не имеет накладных расходов на ввод-вывод, как Xen (20-40%)

Этим у вас Кузнецов руководит? :)

> ovzkir (19.01.2006 17:36:30)

> 2) Хотел (будучи рутом) выставить TTL на интерфейсе так - echo 128 > /proc/sys/net/ipv4/ip_default_ttl (или как-то так) - а мне ядро говорит permission denied. Так и должно быть или что? Что делать?

Да, у нас не виртуализован TTL. А для чего это вам понадобилось? В принципе, виртуализовать TTL не так уж и сложно -- была бы веская причина.

Не могли бы дать адрес, где можно прочитать что такое vanila kernel?

> Не могли бы дать адрес, где можно прочитать что такое vanila kernel?

http://www.linux.org.ru/jump-message.jsp?msgid=1222110

>>>Не совсем так. Внутри VPS вы, конечно, чужие процессы не увидите. А вот находясь в "нулевом" VPS (то есть в хост системе) -- таки да, вы видите все процессы всех VPSов.

>>Не впечатляет .. однако.

>Вы *блестяще* аргументировали свою точку зрения, коллега! Технично, лаконично и грамотно. Против таких аргументов, пожалуй, я возражать не берусь.

Приз зрительских симпатий в студию!

Кстати, правильно ли я понял, что далеко не к каждой версии ядра выпускаются патчи?

>Не совсем так. Внутри VPS вы, конечно, чужие процессы не увидите. А вот находясь в "нулевом" VPS (то есть в хост системе) -- таки да, вы видите все процессы всех VPSов.

в исходном сообщении шел разговор о disk namespace. Которое позволяет держать независимые mount tree. VZ & OpenVZ это не поддерживают - все моунты у них общем дереве.

> Ещё о том, что умеет делать OpenVZ и не умеет делать Xen:
> [snip]

-> [как обычно?] SWsoft ориентирует свои решения на хостеров, имея в этом свою законную нишу :)

// wbr

ovzkir ответьте пожалуйста ... а когда OpenVZ сможет запускать необходимые мне ядра Plan9 ? У меня на одной машине три системы ... :)

> ovzkir ответьте пожалуйста ... а когда OpenVZ сможет запускать необходимые мне ядра Plan9 ? У меня на одной машине три системы ... :)

как в таких случаях говорят - "Любой каприз за Ваши деньги" :)

>как в таких случаях говорят - "Любой каприз за Ваши деньги" :)

А зачем, если есть Xen ?

> А зачем, если есть Xen ?

Ну вот Вы и ответили сами себе. :)

А вот такой вопрос - например, нужно 20 VPS'ов. Это что, мне 20 систем поднимать (каждая метров по 150-200), или есть что-то типа UnionFS? В коммерческом виртуозо что-то есть (вроде как), а в Опене?

> Кстати, правильно ли я понял, что далеко не к каждой версии ядра выпускаются патчи?

Правильно. Текущий OpenVZ patchset базируется на ядре 2.6.8 -- это в основном сделано по соображениям стабильности (точно так же, как и RHEL4, даже с последними апдейтами, до сих пор базируется на 2.6.9; ну и со SLES такая же ситуация). То есть, имея старый кернель, в котором все баги более-менее известны и в OpenVZ поправлены, а новых багов не добавлено, и проводя тщательное и длительное тестирование, мы получаем на выходе _очень_ стабильное ядро.

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

И да, это довольно обширная по объёму работа, но только так можно сделать *действительно* стабильное ядро.

PS всё это не значит, что OpenVZ так и останется на ядре 2.6.8. Будут патчи и под другие ядра, в том числе и не только под ванильное.

> мне 20 систем поднимать (каждая метров по 150-200)

Время создания VPS - чуть меньше минуты (зависит от железа, конечно). А дисковое место...как подсказывает мне gdb, используемый в качестве калькулятора, 20 VPS по 200 мегабайт будут занимать 4GB. По-моему, это не то, из-за чего стоит переживать.

Хотя можно попробовать поизвращаться с UnionFS или с хардлинками, если есть желание.

> а когда OpenVZ сможет запускать необходимые мне ядра Plan9 ?

Никогда. Она для этого не предназначена. Точно так же, как, к примеру, vim не предназначен для создания презентаций, а MS Word - для использования в качестве редактора кода.

Предназначение OpenVZ -- возможность делить ваш Линукс на много маленьких Линуксов. Если вам нужно что-то другое - используйте другой продукт, благо их есть (VMware, Parallels, QEmu, Bochs). Умеет ли Xen запускать ядра Plan9 - не уверен, наверное, нет.

> А вот как vps-ы лучше бэкапить? останавливая их? или есть какие-то иное средство против перхоти.

Думаю, лучше всего применить подход "два rsync'a". Бекапите VPS с помощью rsync, пока он ещё раннится, потом останавливаете VPS (дабы базы закрылись и т.п.) и запускаете rsync второй раз, он "докатывает" всё то

ИМХО базы данных и аналогичный по другому побекапить не получится... Остальной софт можно побекапить и на лету, без остановки. Так что как промежуточный вариант - можно остановить всё типа баз и побекапить.

VZ

К виртуоззе присматривается сбербанк, только им больше интересна версия под оффтопик...