?

Log in

OpenVZ in Russian (mostly)'s Journal
 
[Most Recent Entries] [Calendar View] [Friends]

Below are the 20 most recent journal entries recorded in OpenVZ in Russian (mostly)'s LiveJournal:

[ << Previous 20 ]
Tuesday, July 26th, 2016
10:41 am
[estetus]
Выпуск 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.

Wednesday, December 9th, 2015
8:29 pm
[poige]
Intercepting Proxy внутри VE видит свои же пакеты, при использовании DNAT
Не пробовал ещё запускать Squid на HN0, но, есть такое ощущение, что там будет работать нормально.

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

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

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

Уже пробовал поднять OpenVPN между HN0 и VE со Squid'ом, чтобы закидывать пакеты в VE через tun-интерфейс. Результат тот же.
Tuesday, October 6th, 2015
10:48 pm
[poige]
Как бы так элегантней получить список сокетов, которые торчат на VE0?
А то вы же понимаете — сделать на VE0 netstat -ln, если там куча VE'шек копошится, вообще не вариант.
Thursday, October 16th, 2014
2:08 pm
[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.
Friday, October 3rd, 2014
6:53 pm
[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
Wednesday, August 6th, 2014
2:14 am
[poige]
Thursday, June 12th, 2014
5:33 pm
[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/
Friday, March 21st, 2014
3:49 pm
[ext_1782439]
Кто-нибудь тестировал OpenVZ ploop + flashcache? Как результаты? Как стабильно работает? Спасибо.
Monday, October 21st, 2013
2:28 pm
[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, у нас есть свой репозиторий с ядрами и утилитами, как мы совсем недавно сообщили.
1:32 pm
[k001]
OpenVZ пакеты для Debian

(Ниже перевод моего недавнего поста в openvz. Как и любой перевод, он несколько корявый -- простите великодушно!)

Хорошие новости!
Проф. Фарнсворт

Много кто использует OpenVZ на Дебиане. Более того, Дебиан был один из первых дистрибутивов, в который было включено ядро и утилиты OpenVZ. К сожалению, сейчас это не так -- из Дебиана 7 "Wheezy" убрали ядро OpenVZ. Обходным вариантом решения этой проблемы было преобразование RPM-пакета с ядром в формат .deb при помощи утилиты alien -- но это процесс ручной и не очень естественный.

К счастью, сейчас у нас есть работающая билд-система для Дебиановских пакетов, и репозиторий для wheezy с последними самыми лучшими ядрами (и утилиты там тоже есть). На самом деле даже два репозитория: один для стабильных, другой для тестовых ядер и утилит. Ядра билдятся в .deb и выпускаются одновременно с rpm-пакетами. На сегодня утилиты (vzctl/vzquota/ploop) лежат только в репозитории "wheezy-test" -- как только мы получим достаточно много писем о том, что они работают хорошо, мы перенесём их в стабильный репозиторий "wheezy".

Чтобы включить эти репозитории:

cat << EOF > /etc/apt/sources.list.d/openvz.list
deb http://download.openvz.org/debian wheezy main
deb http://download.openvz.org/debian wheezy-test main
EOF
apt-get update

Для установки ядра:

apt-get install linux-image-openvz-amd64

Ссылки по теме:

Wednesday, August 28th, 2013
3:44 pm
[pavel_odintsov]
Диски OpenVZ контейнеров ploop на NFS шаре

Всем привет!

Сразу скажу, что опыт с NFS в контексте хранения файлов имел весьма посредственный, но при этом весьма негативный.

Но в случае использования ploop все становится весьма радужно, так как вместо тысяч файлов контейнеров мы храним лишь один единственный, причем, не пользуемся даже частью POSIX фич ФС.

Также стоит вопрос - NFS3 vs NFS4, есть ли в контексте данной задачи у NFS4 явные преимущества?

Вопрос - у кого есть реальный опыт эксплуатации такого в продакшене и кто будет рад им поделться?

5:42 pm
[poige]
tcpdump: lo: SIOETHTOOL(ETHTOOL_GTSO) ioctl failed: Operation not permitted
Басню как-то изменили? )

2.6.32-042stab079.5

UPD.: А, ну и вот это #2698 скорее всего оно же и есть.

UPD. (2013-08-29 23:22): решается вот так: vzctl set NumNum --capability=net_admin:on --save (но не факт, что это фича, а не бага).
Saturday, August 17th, 2013
1:03 pm
[poige]
Tuesday, May 7th, 2013
10:25 pm
[ext_1782439]
Включение pfcache в openvz
pfcache в OpenVZ - по changelog вроде уже работает в OpenVZ ядрах. Я попробовал его включить MOUNT_OPTS="discard,pfcache_csum,pfcache=/vz-ssd/pfcache"

Далее в логах я нашел

May 7 11:52:49 kernel: [1162584.490801] EXT4-fs (ploop50161p1): mounted filesystem with ordered data mode. Opts:
May 7 11:52:49 kernel: [1162584.491138] PFCache: relink 182:802577 to "/vz-ssd/pfcache" +0 -0 =0 peers
May 7 11:52:49 kernel: [1162584.491259] EXT4-fs (ploop50161p1): loaded balloon from 12 (0 blocks)
May 7 11:52:49 kernel: [1162584.492775] CT: 104: started


Так и должно быть? Права на /vz-ssd/pfcache -> 0700? Папка остается пустой, по du -sh -> 4.0K

Kir пишет

Важно вот что -- если контейнер доступается до файла, у которого есть такая прописанная в xattrs чексумма, И файл с такой чексуммой есть в "общаке" -- то внутри ядра файл подменяется на файл из общака. Как следствие -- шаринг памяти (и экономия i/o, и лучшее использование кеша).


В официальной wiki я почти ничего не нашел на счет pfcache. Кто-нибудь пробовал включать? На сколько ускоряется i/o? На сколько лучше использование кеша?
Работает ли это вместе с Page cache isolation? Есть паблик бенчмарки?

И мой частный случай. Я использую 2xSATA(RAID-1 софт) - под бекапы, 2xSSD(RAID-1 софт) -> на каком из массивов лучше размещать pfcache?
2:55 pm
[ext_1782439]
Перезагрузка/ выключение контейнера во время ploop snapshot
Всем привет! Делаю бекап контейнеров с помощью ploop snapshot -> вот таким скриптом.
Мне стало интересно, что может произойти -> если я перезагружу контейнер во время бекапа.
Результат можно увидеть на видео.



Контейнер не блокируется и далее можно потерять данные.

Далее я решил попробовать сделать тоже самое во время vzctl compact. В этом случае контейнер не перезагрузился, но остался в статусе -> mounted.
Даже когда vzctl compact закончился, контейнер продолжал оставаться в статусе -> mounted.
То есть если пользователь VPS во время vzctl compact -> перезагрузит свою VPS, то единственное, что ему останется или ребут через панель или писать в тех поддержку.
Thursday, April 25th, 2013
2:50 pm
[k001]
vzstats
Предвидя вал негативных комментов, всё же рискну попросить о помощи.

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

А что нам нужно и зачем? Нам нужно всё и сразу. Хочется понять, например, каково распределение между RHEL5 и RHEL6-based ядрами. Как часто люди обновляют vzctl. Насколько широко используется ploop и vswap. Под какое количество CPU, памяти, контейнеров нам оптимизировать софт. И так далее.

Вам, быть может, тоже что-нибудь из этого интересно. Поэтому результаты открыты, они есть на сайте http://stats.openvz.org/. Возможно, я сделаю доступным дамп базы данных, если его можно будет совсем уж обезличить (сейчас там хранится uuid -- случайно сгенерированный привязанный к ноде идентификатор).

Несколько более подробно про сам проект на http://openvz.org/vzstats.

Попросить хочу о двух вещах:

1. Помогите нам это потестить. Поставьте клиент себе на ноды (yum install vzstats). Изучить его исходники можно на http://git.openvz.org/?p=vzstats;a=summary

2. Напишите, что можно исправить или улучшить. Если вы не хотите ставить клиента, напишите (хотя бы тут в комментах), почему именно, и что можно сделать для того, чтобы изменить ваше решение.

Ну и спрашивайте, если что хотите узнать. Пока это всё в режиме бета- (а может и альфа-) тестирования.
Wednesday, April 24th, 2013
6:36 pm
[poige]
Чем больше я имею дело с OpenVZ, тем больше недоумения вызывает userspace этого проекта
Весь, буквально весь!
  1. Хуки при старте/стопе VE. Почему-то есть хуки, которые будут вызваны в контексте VE, а не HN. Непродуманность подхода очевидна сразу же — из HN легко и просто запустить что угодно внутри VE, из VE в HN — по определению нельзя. Кто и чем думал, чем руководствовался ­— непонятно, но ясно одно — только не здравым смыслом. Не я один это понимаю, да.
  2. Настройка VETH с какими-то proxy_arp, /32-роутами через broadcast-интерфейс. Зачем?! Правильно это делается просто «развешиванием» одной IP-сети (начиная с /30) на стороне HN, и VE. Внутри VE получается логичный и простой default gateway IP-address. Это (детка) — Ethernet, всё остальное тут уже слегка кривовато. Тем более, что есть pointopoint ус-во VENET.
  3. Численные идентификаторы VE 100500, вместо возможности использовать alias'ы — ns.foobar.com, внутри которых хранились бы UUID'ы — уникальные идентификаторы каждой VE. Миграция упрощается на раз-два, риск коллизий номеров практически 0. Очевидные удобства обращения с символическими именами, вместо численных параметров известны со времён изобретения ассемблера, или, хотя бы, DNS.
  4. Про внезапное перетирание конфигов внутри VE (простым перезапуском VE с конфигом в котором руками добавлен параметр IP_ADDRESS) я уже писал. Что характерно, в переписаном /etc/network/interfaces вам скажут, типа, "don't edit, автоматишен генерашен файло", но предупреждения postfactum это скорее издевательство, чем предупреждения. Бэкап никто сделать не догадался. Предложенный патч для бэкапа перетираемого конфига, если в нём нет предупреждения (читай ванильный юзерский конфиг), нужно пропихивать через список рассылки разработчиков — иначе нет пути (потому что все очень гордые, а некоторые ещё и умные).
  5. Забавное (мягко говоря) использование 127.0.0.2. Типа, чтобы Debian 3 поддержать, ага. А ничего, что сетка 127/8 — это loopback, и если уж иметь резоны использовать IP, который логически внутри неё, то хотя бы помнить, что 127. — это класс A, и маска, по-умолчанию, будет /8, и нужно использовть что-то более узкое, типа /32, ну или /30. А ещё лучше использовать какой-нибудь link-level autoconfig scope, а не loopback. А ещё лучше вообще без этих костылей сделать поддержку. Закат солнцаУдаление маршрутов через интерфейс, при переводе его в down — из той же оперы.
Friday, April 12th, 2013
9:02 pm
[poige]
Приходилось ли вам делать vzmigrate в пределах одной HN?
Необходимость может быть очень простой — например перетащить VE с одного раздела на другой, без прерывания сервисов.

Судя по man'у, штатной возможности для локальной миграции не предусмотрено вовсе, но наверное можно поискать обходные пути.
Tuesday, April 2nd, 2013
9:47 pm
[poige]
А вы не считаете, что сетевая «автоматизация» в CT не должна быть включеной по-умолчанию?
— Сейчас единственный(?) вариант — это вытирать из конфига OSTEMPLATE, в противном случае, ваш /etc/network/interfaces (для Debian/Ubuntu) будет заботливо испоганен простым запуском виртуалки, в конфиге которой прописан IP-адрес. Без предупреждений, собственно. Нафига? Я понимаю, что уши OpenVZ торчат из Virtuozzo, и такая автоматизация там была частью ТЗ (возможно), но зачем она OpenVZ по-умолчанию?

UPD.: Кстати, 2-й вопрос это чей сумрачный гений выдал такое(!):
# Auto generated venet0 interface
auto venet0
iface venet0 inet manual
        up ifconfig venet0 up
        up ifconfig venet0 127.0.0.2
        up route add default dev venet0
        down route del default dev venet0
        down ifconfig venet0 down
— ? Тут же каждая строчка прекрасна!
Friday, March 29th, 2013
12:27 am
[poige]
О, прелесть какая: xfsaild in D-state

Мало того, что Btrfs в 2.6.32-RHEL/OVZ сырая и старая (попробовать выдрать свежак из Oracle Unbreakable Linux, что ли), так теперь ещё и XFS доставляет. Неудивительно, что новое поколение выбирает LXC…
[ << Previous 20 ]
About LiveJournal.com