При старте сервера в части VE процессы виснут на записи в консоль

Дано: сервер Debian 7 с ядром 2.6.32-openvz-042stab117.14-amd64 и vzctl 4.9.4-2.

Проблема: при перезапуске сервера часть сервисов в части VE не стартует.
strace показывает, что все они висят на попытке отправить что-то в syslog.

Например, в одной VE висит sshd, strace показывает:
sendto(3, "<83>Sep 23 22:22:19 sshd: nss_ld"..., 155, MSG_NOSIGNAL, NULL, 0

В другой VE висит сам rsyslog:
sendto(3, "<83>Sep 23 22:22:14 rsyslogd: ns"..., 159, MSG_NOSIGNAL, NULL, 0

В третьей висит logger -s текст (вызывается из upstart-сценария):
sendto(1, "<11>Sep 23 22:24:20 simple-wrapp"..., 50, MSG_NOSIGNAL, NULL, 0

Если вручную сделать "vzctl restart подвисшая-VE", то VE запускается нормально.
Это известная бага? Если да, то как её исправить или обойти?

Выпуск OpenVZ 7.0, ставший итогом слияния проектов OpenVZ и Virtuozzo

Разработчики проекта OpenVZ выпустили финальную версию OpenVZ 7.0, продукта, образованного в результате слияния кодовых баз открытой системы контейнерной виртуализации OpenVZ и коммерческого продукта Virtuozzo (Parallels Cloud Server). Теперь все желающие получили возможность промышленного использования последней версии контейнеров OpenVZ. Исходный код новой версии полностью открыт и доступен в публичном репозитории и зеркале на GitHub.

Основные изменения по сравнению с предыдущей версией OpenVZ: теперь OpenVZ это полноценный Linux дистрибутив и поддержка установки компонентов OpenVZ поверх других дистрибутивов не предоставляется, проприетарный гипервизор Parallels заменён на гипервизор KVM/QEMU, Linux ядро базируется на последней версии ядра от Red Hat - RHEL 7 (версия соответствует ядру 3.10+), добавлена возможность интеграции с LibVirt с помощью отдельного драйвера virtuozzo, "живая" миграция для контейнеров реализована с помощью инструментария CRIU и P.Haul, для новой версии доступна полноценная документация, переход на использование EZ-шаблонов для контейнеров, доступна интеграция с OpenStack.

К сожалению была потеряна обратная совместимость с утилитой vzctl. Для управления контейнерами и виртуальными машинами рекомендуется использовать утилиту prlctl, так как в последующих версиях планируется полностью отказаться от утилиты vzctl и использовать prlctl как основную.

Для установки OpenVZ 7.0 доступен установочный образ, который можно загрузить с одного из основных серверов OpenVZ или с одного из зеркал проекта. Сценарий переноса контейнеров с предыдущей версии OpenVZ на OpenVZ 7.0 описан в документации.

Более подробный анонс на opennet.

  • poige

Intercepting Proxy внутри VE видит свои же пакеты, при использовании DNAT

Не пробовал ещё запускать Squid на HN0, но, есть такое ощущение, что там будет работать нормально.

В случае, если Squid запущен внутри VE, то он мало того, что получает запросы, которые были завёрнуты ему через DNAT, но и свои же тоже (когда он сам подрывается выполнять запрос), причём, конфигурация netfilter это исключает (то есть, это не проблема набора правил, а, скорее всего, особенности реализации сетевого стека).

У кого какие мысли?

Я думаю попробовать ещё TPROXY в netfilter's mangle, но это потребует пересборки Squid, поскольку, по-умолчанию, этот модуль в нём отсутствует (Ubuntu).

Уже пробовал поднять OpenVPN между HN0 и VE со Squid'ом, чтобы закидывать пакеты в VE через tun-интерфейс. Результат тот же.
  • poige

vzctl Can not dump container No such device — попытка suspend на 2.6.32-openvz-042stab093.5-amd64

— WTF? Причём, такое ощущение, что это только с тему VE, которые были в анабиозе до обновления версии ядра. Они нормально вышли из него после reboot, а вот снова в suspend — не получается.

Ещё «забавное»:
Restore error, undump failed: Input/output error
Error: can't open file /dev/ptyp0
Error: rst_file: -5 12661784
Error: rst_files: -5
Error: make_baby: -5
Error: rst_clone_children
Error: make_baby: -5
Error: rst_clone_children
Container restore failed
— это start после suspend.
Бритый небритый
  • shaplov

Что это было?? (Пропали /dev/* и не отрабатывает запуск сервисов)

Товарищи, у меня в странную позу встал контейнер (дебиан на дебиане). Никак не могу понять что с ним произошло и самое главное такие вещи восстанавливать не через переустановку.

Решил я значит обновить накатить обновления в связи с уязвимостью в баше. Накатил, говорю reboot. Оно отказывается (чем мотивировало не записал). Выхожу из контейнера, кладу контейнер через vzctl stop, а оно мне говорит что-то вроде "Child 8332 exited with status 1" и надолго задумывается. Но в конце концов сообщает что таки да остановлено.

При попытке включить обратно, оно в контейнер входить отказывается, сообщая что "error: open pty: No such file or directory". И vzlist сообщает что в контейнере работают всего три процесса.
Зашел в файлы контейнера, обнаружил что все содержимое /dev директории оказалось в корневой директории, вернул файлы устройств на родину. После этого оно заходить по vzctl enter стало, но запущенных процесса все равно 3, ни sshd ни nginx не стартует.

Кто-нибудь с таким сталкивался? Знает что именно это было? Знает как с этим бороться?

А то я остальные контейнеры трогать боюсь. :-) Этот был не особенно критичный. А вдруг что-то важное поломается... А я не знаю как такое восстанавливать...

Update: Проблема, оказалось результатом бага https://bugzilla.openvz.org/show_bug.cgi?id=2647

Для уже убитого апдейтом контейнера следует выполнить инструкции из https://openvz.org/Container_enter_failed#LEGACY_PTYS, Остановить контейнер, перенести созданные устройства из корня в директорию dev (они почему-то не в нужном месте создадутся).
Из скачать внутрь файловой системы контейнера пакет с upstart
http://ftp.us.debian.org/debian/pool/main/u/upstart/upstart_1.6.1-1_i386.deb
запустить контейнер, зайти в него через vzctl enter (теперь это получится) и заменить sysvinit обратно на upsart
# apt-get remove sysvinit
# sudo dpkg -i upstart_1.6.1-1_i386.deb
выходим из контейнера останавливаем его и запускаем заново. Все должно заработать.
После этого принимаем меры чтобы sysvinit больше не поставился бы, как сказано https://bugzilla.openvz.org/show_bug.cgi?id=2647#c6
nepal
  • k001

Интервью с ANK

Алексей Кузнецов, человек-легенда, работает в Parallels. Помимо современного TCP/IP стека, он написал утилиты ip и tc, а для OpenVZ -- checkpoint/restore и ploop. Алексей очень редко даёт интервью, но как-то так случилось, что в прошлом году их было аж два. Кто не читал -- рекомендую.

http://www.opennet.ru/opennews/art.shtml?num=38016

http://lifehacker.ru/2013/08/01/ank/
nepal
  • k001

Устарел ли OpenVZ?

Какое провокационное название (на самом деле нет).

Оказалось, что многие люди считают OpenVZ устаревшим, и когда я спрашиваю их, почему они так думают, в ответ обычно говорят что-то из этого:

1. Ядро OpenVZ древнее и устаревшее, потому что базируется на 2.6.32, а в 2013 году уже все используют 3.x.
2. Будущее за LXC, OpenVZ в прошлом.
3. OpenVZ больше не разрабатывается -- его даже выкинули из Debian Wheezy.

Прокомментирую все три заблуждения, по очереди.

1. "У OpenVZ древнее ядро". Свежие ядра OpenVZ базируются на ядрах из дистрибутива Red Hat Enterprise Linux 6 (для краткости RHEL6). Это последняя и самая лучшая версия дистрибутива для предприятий от Red Hat, компании, чьё имя почти всегда стоит на самом верху списка тех компании, которые внесли самый большой вклад в разработку ядра Linux (случайные примеры: 1, 2, 3, 4). Конечно, никакое ядро не может быть идеальным и безошибочным, но ядро из RHEL6 -- довольно хорошая аппроксимация такого ядра.

Разработка ядра для RHEL делается вот как -- инженеры из Red Hat берут ванильное ядро и форкают его, убирая баги и принося из апстрима фиксы (в том числе исправления дыр в безопасности), обновлённые драйвера, и иногда новые фичи. Так они делают примерно полгода до релиза (иногда и больше), так что к моменту релиза это ядро уже "древнее и устаревшее" -- во всяком случае, так кажется, если смотреть на его версию. Так вот, не следует оценивать книгу по обложке, фильм по трейлеру, а ядро по номеру версии. Конечно же, никакое оно не древнее и не устаревшее, а просто более стабильное и безопасное. Далее, после релиза, это ядро очень хорошо поддерживается -- добавляется поддержка современного железа, регулярно выходят новые версии, вовремя исправляются дырки в безопасности. И всё это на протяжении нескольких лет.

Всё вышеописанное делает это ядро идеальной базой для OpenVZ ядра. В каком-то смысле, мы стоим на плечах гиганта в красной шляпе (а поскольку это опенсорс, то и они тоже немножечко стоят на наших плечах).

Сейчас в Red Hat идёт работа над очередной версией -- RHEL7, ядро в которой будет базироваться на одном из ядер серии 3.x (возможно, это будет 3.10). Как только это ядро будет доступно, мы будем портировать на него OpenVZ. Пока же, ядро OpenVZ на базе RHEL6 -- это самое последнее и самое лучшее ядро, и пусть вас не обманывают цифры 2.6.32.

2. OpenVZ против LXC. Ядро в OpenVZ, так уж сложилось, раньше разрабатывалось отдельно от основного ядра Linux. Эту ошибку мы осознали в 2005 году, и с тех пор активно работаем над включением разных компонентов нашего ядра в апстримное. Времени это заняло больше, чем мы ожидали -- мы всё ещё где-то в середине процесса (хотя уже перевалили за экватор). Некоторый отличный функционал -- типа network namespaces или CRIU -- уже в ядре, а что-то всё ещё пока в нашем списке TODO. В будущем (через ещё восемь лет? кто бы знал...) вся функциональность ядра OpenVZ, возможно, уже будет в апстриме, так что проект выродится просто в набор утилит. Очень приятно видеть, что Parallels -- не единственная компания, заинтересованная в контейнерах для Linux, так что это может случится немного раньше. Пока что, впрочем, мы всё ещё полагаемся на наше родное тёплое ламповое ядро (хотя, напомню, оно уже сейчас не является обязательным).

Теперь, что такое LXC? Это всего лишь ещё одна утилита (навроде vzctl), которая работает поверх свежего апстримного ядра (опять же, навроде vzctl). В то время как мы вливаем нашу функциональность в апстрим, утилита LXC начинает эту функциональность использовать, таким образом получая выигрыш от нашей работы. Сейчас примерно половина всей ядерной функциональности, которую использует LXC, была разработана нашими инженерами. И хотя мы не работаем над утилитой LXC, не будет преувеличением сказать, что Parallels внёс самый большой вклад в LXC.

Таким образом, и OpenVZ и LXC активно развиваются и у них есть будущее. Возможно даже, когда-то мы сольём обе утилиты в одну (это уже кратенько обсуждалось на прошедшей мини-конференции по контейнерам на Linux Plumbers в Новом Орлеане). Однако, LXC не является преемником OpenVZ -- это два разных проекта, хотя и не совсем отдельных друг от друга (так как команда OpenVZ очень много добавляет в ядро, и обе утилиты используют одну и ту же ядерную функциональность). Сейчас OpenVZ -- это по сути LXC++, так как она добавляет некоторые вещи, которых нет (пока) в апстримном ядре -- например, более сильную изоляцию, лучшее управление ресурсами, и некоторые фичи типа ploop.

3. OpenVZ больше не разрабатывается, её даже из Дебиана выкинули. Команда ядерных мейнтейнеров Debian решила убрать OpenVZ (и некоторые другие) варианты ядра из Debian 7, он же Wheezy. Это вполне понятно и объяснимо: на поддержку ядер уходит время и другие ресурсы, которых в их команде, видимо, не хватает. Из этого, однако, вовсе не следует, что OpenVZ больше не разрабатывается. Даже странно с этим спорить, но посмотрите хотя бы нашу страничку News/updates (или архивы списка рассылки announce@). В этом году мы выпустили примерно 80 обновлений софта. Это примерно по 2 обновления каждую неделю. Большая часть -- это обновления ядер. Не похоже ведь на что-то заброшенное?

Что же касается Debian Wheezy, у нас есть свой репозиторий с ядрами и утилитами, как мы совсем недавно сообщили.