Comments 92
Я не спешу переходить на PVE 4 и LXC из-за одной, по моему, более глобальной проблемы — Live Migration (CRIU — не допилен). В 3й версии Live Migration с OpenVZ — просто счастье.
мучаемся с proxmox 4 с осени, кроме неработающих нормально бекапов и живой миграции всё в целом устраивает. :)
сторэйдж-бекенд — lvm+iscsi.
а так согласен, контейнерам мало времени уделяют. к pct вместо vzctl привык буквально за месяц.
из явных косяков:
если в контейнере больше одного блочного устройства, то бекапится только первое.
апи контейнеров не полностью работает, только через pct.
сторэйдж-бекенд — lvm+iscsi.
а так согласен, контейнерам мало времени уделяют. к pct вместо vzctl привык буквально за месяц.
из явных косяков:
если в контейнере больше одного блочного устройства, то бекапится только первое.
апи контейнеров не полностью работает, только через pct.
Кстати говоря, только вот выпустили criu 2.0, так может быть и до проксмокса вскоре доедет.
http://www.opennet.ru/opennews/art.shtml?num=44015
http://www.opennet.ru/opennews/art.shtml?num=44015
"платный вариант virtuozo сильно ушел по кодовой базе в бок и в какой-то момент оказалось, что openvz работает только на старом ядре версии 2.6.32, а работы по слиянию openvz и virtuozo7 идут, сказать честно, не быстро."
Похоже что пост писали около года назад, когда мы объявили о слиянии OpenVZ и коммерческой Virtuozzo.
А сейчас, когда уже доступна Virtuozzo 7 Beta с работающей миграцией и в течение следующих нескольких месяцев планируется выпустить RTM, это слышать по меньшей мере странно.
"платный вариант virtuozo сильно ушел по кодовой базе в бок"
в openvz три основных компонента: ядро (vzkernel), ploop и vzctl. Из этих трех компонентов разъехался только vzctl. Новая бесплатная и открытая версия Virtuozzo включает vzctl из коммерческой версии Vz. Если какие-то фичи из vzctl для OpenVZ для вас критичны, то их можно спортировать.
Просто возьмите последнюю версию Virtuozzo 7 и покритикуйте, но не пишите что OpenVZ на старом ядре и прочие неактуальные вещи :)
Похоже что пост писали около года назад, когда мы объявили о слиянии OpenVZ и коммерческой Virtuozzo.
А сейчас, когда уже доступна Virtuozzo 7 Beta с работающей миграцией и в течение следующих нескольких месяцев планируется выпустить RTM, это слышать по меньшей мере странно.
"платный вариант virtuozo сильно ушел по кодовой базе в бок"
в openvz три основных компонента: ядро (vzkernel), ploop и vzctl. Из этих трех компонентов разъехался только vzctl. Новая бесплатная и открытая версия Virtuozzo включает vzctl из коммерческой версии Vz. Если какие-то фичи из vzctl для OpenVZ для вас критичны, то их можно спортировать.
Просто возьмите последнюю версию Virtuozzo 7 и покритикуйте, но не пишите что OpenVZ на старом ядре и прочие неактуальные вещи :)
А у него есть веб интерфейс? Я бы сказать честно с радостью смигрировал бы на него.
можно использовать веб-интерфейс от LibVirt, т.к. в Virtuozzo 7 есть отдельный драйвер для управления контейнерами и виртуальными машинами.
Почитал я тут ишью известные
https://openvz.org/Virtuozzo_7_Technical_Preview_-_Containers
Как то печаль для продакшена.
https://openvz.org/Virtuozzo_7_Technical_Preview_-_Containers
Как то печаль для продакшена.
Ага, печально. Потому что никто в здравом уме Technical preview не будет ставить в production. Мы об этом честно писали во всех анонсах.
К тому же вы зачем-то ссылаетесь на описание ограничений для 1-го Technical preview, который был в июле 2015 года. Хотя неделю назад вышла Beta. Она также не годится для production, но в ней можно пробовать и ВМки и контейнеры. Следующей версей Vz7 уже будет RTM. Вот список ограничений для последней Beta — https://docs.openvz.org/virtuozzo_7_readme.webhelp/_known_issues_and_restrictions.html
Баги постоянно исправляются и новые валидные билды выкладываются каждый день.
К тому же вы зачем-то ссылаетесь на описание ограничений для 1-го Technical preview, который был в июле 2015 года. Хотя неделю назад вышла Beta. Она также не годится для production, но в ней можно пробовать и ВМки и контейнеры. Следующей версей Vz7 уже будет RTM. Вот список ограничений для последней Beta — https://docs.openvz.org/virtuozzo_7_readme.webhelp/_known_issues_and_restrictions.html
Баги постоянно исправляются и новые валидные билды выкладываются каждый день.
Посмотрел, сыромятно все, панельки нативной нет, только либвиртовские, где все довольно убого, ждем релиза и нормальной панели.
Какая производительность плупа дискового? Насколько велик оверхед?
слишком общий вопрос, смотря какой паттерн нагрузки.
В общем случае производительность близка к обычной ФС,
а лучше сделать тестовый контейнер и погонять под своими нагрузками.
Если хочется побольше про ploop узнать, что можно с этих источников начать:
В общем случае производительность близка к обычной ФС,
а лучше сделать тестовый контейнер и погонять под своими нагрузками.
Если хочется побольше про ploop узнать, что можно с этих источников начать:
Не очень понял, что тут имеется в виду:
Не работает коннект к unix сокету (например /var/run/mysql.sock) или по IP? Если был localhost и помогла замена на 127.0.0.1, то это коннект по IP и подозреваю, что дело в пустом файле hosts.
В centos 6 пхп не коннектиться к сокету mysql, надо везде прописывать вместо localhost айпи 127.0.0.1
Не работает коннект к unix сокету (например /var/run/mysql.sock) или по IP? Если был localhost и помогла замена на 127.0.0.1, то это коннект по IP и подозреваю, что дело в пустом файле hosts.
Когда ты пишешь в коннекте localhost php коннектится по сокету, а не по айпи.
А когда 127.0.0.1 то коннект идет по айпи и его можно видеть в том же tcpdump
А когда 127.0.0.1 то коннект идет по айпи и его можно видеть в том же tcpdump
Ну так а mysql слушает этот сокет? Команда mysql может подключится по сокету? Может права на сокет странные?
ну конечно слушает
ну конечно подключается к сокету мускуль клиент
ну отличные права и любой может читать и писать в него
ну такие то детские проблемы я бы поди на десятке то контейнеров смог бы и сам решить.
ну конечно подключается к сокету мускуль клиент
ну отличные права и любой может читать и писать в него
ну такие то детские проблемы я бы поди на десятке то контейнеров смог бы и сам решить.
lxc у меня совсем не много, но postgres и mysql там есть и работают. У вас хост случайно не убунта? Беглый обзор гугла выявил такую проблему для включённого apparmor, при хранении фалов гостя на ФС хоста.
у вас mysql на centos 6 и можете подключиться с php-mysql?
Это баг именно этой связки.
Это баг именно этой связки.
Какие версии php и mysql взять для теста? Хост будет debian testing
стандартные из centos 6
Итак потестил. Debian testing.
создал контейнер. sudo lxc-create -n ct6 -t centos — R 6
Сразу обнаружилось, что для старта upstart необходима sys_nice. Добавил.
Поставил стандартные mysql-server и php-fpm php-cli php-mysql
Создал скрипт из примера в интернете.
Создал пользователя в мускле. и потестил.
sudo -u apache php /tmp/t.php
php /tmp/t.php
В обоих случаях все работает прекрасно.
Следовательно проблема с проксмос. Они что-то делают не так с конфигом. Например активируют apparmor. Ведь хост убунта?
создал контейнер. sudo lxc-create -n ct6 -t centos — R 6
Сразу обнаружилось, что для старта upstart необходима sys_nice. Добавил.
Поставил стандартные mysql-server и php-fpm php-cli php-mysql
Создал скрипт из примера в интернете.
t.php
<?php
echo 'hello';
$link = mysql_connect('localhost', 'lxcct6', 'lxcct6') or die('Не удалось соединиться: '. mysql_error());
mysql_select_db('mysql') or die('Не удалось выбрать базу данных');
$result = mysql_query('show tables;') or die('Запрос не удался: '. mysql_error());
while ($line = mysql_fetch_array($result, MYSQL_ASSOC)) {
foreach ($line as $col_value) {
echo "$col_value";
}
echo "\n";
}
?>
echo 'hello';
$link = mysql_connect('localhost', 'lxcct6', 'lxcct6') or die('Не удалось соединиться: '. mysql_error());
mysql_select_db('mysql') or die('Не удалось выбрать базу данных');
$result = mysql_query('show tables;') or die('Запрос не удался: '. mysql_error());
while ($line = mysql_fetch_array($result, MYSQL_ASSOC)) {
foreach ($line as $col_value) {
echo "$col_value";
}
echo "\n";
}
?>
Создал пользователя в мускле. и потестил.
sudo -u apache php /tmp/t.php
php /tmp/t.php
В обоих случаях все работает прекрасно.
вывод скрипта
hellocolumns_priv
db
event
func
general_log
help_category
help_keyword
help_relation
help_topic
host
ndb_binlog_index
plugin
proc
procs_priv
servers
slow_log
tables_priv
time_zone
time_zone_leap_second
time_zone_name
time_zone_transition
time_zone_transition_type
user
db
event
func
general_log
help_category
help_keyword
help_relation
help_topic
host
ndb_binlog_index
plugin
proc
procs_priv
servers
slow_log
tables_priv
time_zone
time_zone_leap_second
time_zone_name
time_zone_transition
time_zone_transition_type
user
Следовательно проблема с проксмос. Они что-то делают не так с конфигом. Например активируют apparmor. Ведь хост убунта?
Версии
Debian stretch/sid
lxc 1:1.1.5-1
kernel 4.3.0-1-amd64
CentOS release 6.7 (Final)
php-common-5.3.3-46.el6_7.1.x86_64
php-pdo-5.3.3-46.el6_7.1.x86_64
php-mysql-5.3.3-46.el6_7.1.x86_64
php-cli-5.3.3-46.el6_7.1.x86_64
mysql-libs-5.1.73-5.el6_6.x86_64
mysql-5.1.73-5.el6_6.x86_64
php-fpm-5.3.3-46.el6_7.1.x86_64
mysql-server-5.1.73-5.el6_6.x86_64
lxc 1:1.1.5-1
kernel 4.3.0-1-amd64
CentOS release 6.7 (Final)
php-common-5.3.3-46.el6_7.1.x86_64
php-pdo-5.3.3-46.el6_7.1.x86_64
php-mysql-5.3.3-46.el6_7.1.x86_64
php-cli-5.3.3-46.el6_7.1.x86_64
mysql-libs-5.1.73-5.el6_6.x86_64
mysql-5.1.73-5.el6_6.x86_64
php-fpm-5.3.3-46.el6_7.1.x86_64
mysql-server-5.1.73-5.el6_6.x86_64
А не покажите конфиг, сгенеренный проксмоксом для этого контенера?
На днях бодался с этой проблемой. Да, дело в правах доступа на файл с сокетом.
Пока не нашел ничего лучше чем в стартовом скрипте воткнуть chmod 777 $socketfile
Пока не нашел ничего лучше чем в стартовом скрипте воткнуть chmod 777 $socketfile
Что то правами у меня эта проблема не решилась
у вас там systemd или V init?
в centos 6 нет никакого системд
а на всех остальных мускул нормально работает
не запустился только старый дебиан, в целом я уже понял что lxc мертвая технология и уже дураку понятно надо мигрировать.
а на всех остальных мускул нормально работает
не запустился только старый дебиан, в целом я уже понял что lxc мертвая технология и уже дураку понятно надо мигрировать.
Отгреб аналогичных проблем при миграции, еще и не все устройства корректно прокидываются с хота в гостевую систему, адски деградировала сеть, у меня есть контейнер с разбором трафика на L7, так производительность упала боле чем в 10 раз, промучился с неделю, откатился назад на 3 ветку прокса, буду сидеть там до последнего. На сколько я понимаю, предлагаемый тут Virtuozzo не умеет KVM, у меня хоть и не много таких машин, но есть с десяток в кластере и городить отдельный гипервизор как-то не хочется. Меня более чем устраивает OpenVZ в плане допиленности и стабильности, надеюсь что OpenVZ все таки догонит virtuozo7 и прокс вернут обратно OpenVZ, к сожалению lxc даже близко не готов к продакшину.
Сказать честно я ожидал, что все будет не гладко, но что все настолько чудовищно просто сложно представить пока не попробуешь.
"На сколько я понимаю, предлагаемый тут Virtuozzo не умеет KVM"
Серьезно?
[root@s164 ~]# rpm -qa | grep -e "qemu"
qemu-kvm-tools-vz-2.3.0-31.2.4.vz7.12.x86_64
ipxe-roms-qemu-20130517-7.gitc4bce43.vz7.2.noarch
qemu-kvm-common-vz-2.3.0-31.2.4.vz7.12.x86_64
qemu-kvm-vz-2.3.0-31.2.4.vz7.12.x86_64
libvirt-daemon-driver-qemu-1.3.1-1.vz7.3.x86_64
qemu-img-vz-2.3.0-31.2.4.vz7.12.x86_64
[root@s164 ~]# cat /etc/issue
Virtuozzo Linux release 7.2
Kernel \r on an \m
Одна из особенностей версии 7 это переезд на открытый гипервизор KVM и QEMU.
Серьезно?
[root@s164 ~]# rpm -qa | grep -e "qemu"
qemu-kvm-tools-vz-2.3.0-31.2.4.vz7.12.x86_64
ipxe-roms-qemu-20130517-7.gitc4bce43.vz7.2.noarch
qemu-kvm-common-vz-2.3.0-31.2.4.vz7.12.x86_64
qemu-kvm-vz-2.3.0-31.2.4.vz7.12.x86_64
libvirt-daemon-driver-qemu-1.3.1-1.vz7.3.x86_64
qemu-img-vz-2.3.0-31.2.4.vz7.12.x86_64
[root@s164 ~]# cat /etc/issue
Virtuozzo Linux release 7.2
Kernel \r on an \m
Одна из особенностей версии 7 это переезд на открытый гипервизор KVM и QEMU.
Спасибо, последнее что читал в новостях, что виртуалки вроди как в планах, но не знал что допилили. Как только закончится поддержка proxmox 3, самый вероятный кандидат для миграции значит будет Virtuozzo, к лету будет ясно в какую сторону двигаться. Отдельно благодарю за ссылку на вменяемый туториал, я так понимаю вы в теме, подскажите как дела обстоят с кластеризацией? Есть ли живая миграция, поддержка фенсинга и прочие фишки "из коробки" или это уже решается на свое усмотрение средствами самой операционки гипервизора? Есть ли единая система управления кластером? Может по ценам за продукт знаете, а то на сайте нет указаний, только звоните.
Насчет цен не знаю, не уверен что сами Odin уже точно по ценам что-то утвердили. В этом вопросе наверняка estet подскажет.
Что касается кластеризации, в документации я ничего об этом не нашел, немного написано только о storage кластерах.
Живую миграцию недавно тестировал, до сих пор не работает.
Что касается кластеризации, в документации я ничего об этом не нашел, немного написано только о storage кластерах.
Живую миграцию недавно тестировал, до сих пор не работает.
По описанию выглядит вполне достойной альтернативой, подождем релиза. storage — можно кластеризировать средствами самого СХД, либо собрать CEPH, а вот поддержка со стороны гипервизора перевода виртуалки/контейнера на другой сервер при проблемах на основном — фишка очень нужная, как и фенсинг, без которого сервер может зависнуть наглухо так, что плющить будет весь кластер, пока его по питанию не дернуть.
Живую миграцию недавно тестировал, до сих пор не работает.
должно работать. Зафайлите пожалуйста баг в https://bugs.openvz.org/
По фичам можете здесь посмотреть — https://openvz.org/Comparison и заодно посмотреть feature parity с другими решениями для виртуализации.
HA, распределенное хранилище данных (vzstorage) будут доступны только в платной версии, после установки дополнительных пакетов и активации лицензии. По ценам ничего подсказать не могу. Живая миграция и для контейнеров и для вирутальных машин уже доступна в opensource версии.
TRD про функциональность живой миграции:
https://lists.openvz.org/pipermail/users/2016-February/006792.html
https://lists.openvz.org/pipermail/users/2016-February/006793.html
Ну и если просто хотите доступные фичи попробовать, то имеет смысл глянуть гайд "Virtuozzo Beta Homework" — https://docs.openvz.org/
HA, распределенное хранилище данных (vzstorage) будут доступны только в платной версии, после установки дополнительных пакетов и активации лицензии. По ценам ничего подсказать не могу. Живая миграция и для контейнеров и для вирутальных машин уже доступна в opensource версии.
TRD про функциональность живой миграции:
https://lists.openvz.org/pipermail/users/2016-February/006792.html
https://lists.openvz.org/pipermail/users/2016-February/006793.html
Ну и если просто хотите доступные фичи попробовать, то имеет смысл глянуть гайд "Virtuozzo Beta Homework" — https://docs.openvz.org/
Наймите уже тесторов что ли. Меня например )
Велкам
А вообще анонсы о новой функциональности это часть открытой разработки. Некоторым пользователям интересно попробовать фичи как только они появляются в продукте, поэтому мы и анонсируем их.
Естественно у нас есть свой отдел QA, который днями и ночами в хвост и гриву тестирует Virtuozzo. Вот чуть-чуть про наше тестирование ядра:
А вообще анонсы о новой функциональности это часть открытой разработки. Некоторым пользователям интересно попробовать фичи как только они появляются в продукте, поэтому мы и анонсируем их.
Естественно у нас есть свой отдел QA, который днями и ночами в хвост и гриву тестирует Virtuozzo. Вот чуть-чуть про наше тестирование ядра:
А дайте панельку погонять бесплатно вашу ?
А тут разве не оно лежит? https://download.openvz.org/virtuozzo/releases/ Тоже собрался погонять на выходных.
тут — https://download.openvz.org/virtuozzo/releases/7.0-rtm/x86_64/iso/
Ставьте ISO и регулярно обновляйте с помощью yum, обновления каждый день появляются.
Ставьте ISO и регулярно обновляйте с помощью yum, обновления каждый день появляются.
она не готова пока
А когда ожидается релиз?
Дошли руки осилить туториал по вашей ссылке, в его todo наткнулся на ссылку на свою же статью на хабре по пробросу устройств в OpenVZ, страшная вещь рекурсия.
>Два контейнера у меня намертво зависли и их не получилось убить никакими способами
Я на это же напоролся и прекратил эксперименты с LXC. Какой смысл экономить ресурсы, чтобы перегружать весь сервер?
Я на это же напоролся и прекратил эксперименты с LXC. Какой смысл экономить ресурсы, чтобы перегружать весь сервер?
"Два контейнера у меня намертво зависли и их не получилось убить никакими способами"
Имею более 3000 контейнеров с приложениями на openvz centos6.
Так вот залипших таким образом контейнеров скапливается за неделю до сотни минимум. Их невозможно прибить, vzctl залипает и не убивается даже через kill -9. Через gdb выяснил, что зависает на ioctl VZCTL_ENV_CREATE.
Дальше не колупал, так как нашёлся костыль — vzctl CTID --cpulimit 0. После этого, внезапно, все процессы оживают.
Имею более 3000 контейнеров с приложениями на openvz centos6.
Так вот залипших таким образом контейнеров скапливается за неделю до сотни минимум. Их невозможно прибить, vzctl залипает и не убивается даже через kill -9. Через gdb выяснил, что зависает на ioctl VZCTL_ENV_CREATE.
Дальше не колупал, так как нашёлся костыль — vzctl CTID --cpulimit 0. После этого, внезапно, все процессы оживают.
Все комменты не читал, но с миграциями с PVE3 на PVE4 провозился месяца 2 в общем.
Глобальной проблемой оказались (внимание) обновления проксмокса. Т.е. с каждой новой версией появлялись новые проблемы. После одного обновления вырубилась сеть. После другого — перестала высвобождаться память. Так, создание бэкапов (рсинком) файлов убивал насмерть всю ноду. Сначала грешил на ZFS, но после долгих переборов собрал версии всех компонентов, которые точно работают. Кстати, конкретно проблема с памятью при использовании zfs была прям в оригинальном скачанном с офсайта релизе 4.1.
В одной из миграций вообще получилось так, что в контейнере с редмайном не запускался mysql — не было прав на mysql.pid
До этого в 3 версии все работало пару лет вооообще без проблем. Переезд на 4 нужен был из за нового ядра в первую очередь. В целом, в итоге все вроде стабильно стало работать. Но плевался долго.
Глобальной проблемой оказались (внимание) обновления проксмокса. Т.е. с каждой новой версией появлялись новые проблемы. После одного обновления вырубилась сеть. После другого — перестала высвобождаться память. Так, создание бэкапов (рсинком) файлов убивал насмерть всю ноду. Сначала грешил на ZFS, но после долгих переборов собрал версии всех компонентов, которые точно работают. Кстати, конкретно проблема с памятью при использовании zfs была прям в оригинальном скачанном с офсайта релизе 4.1.
В одной из миграций вообще получилось так, что в контейнере с редмайном не запускался mysql — не было прав на mysql.pid
До этого в 3 версии все работало пару лет вооообще без проблем. Переезд на 4 нужен был из за нового ядра в первую очередь. В целом, в итоге все вроде стабильно стало работать. Но плевался долго.
В общем статья критикует LXC но все проблемы тут исключительно в Proxmox.
По ссылкам на форум в конце поста вообще смешно читать. Просто жалобы без попыток разобраться.
И получается плох LXC, а проксмокс просто ошибся с выбором.
- Миграция ovz -> lxc утилитами Proxmox
- IO проблемы скорее всего связаны с монтированием qcow2 образов через nbd.
Зависшие контейнеры, наверное единственная проблема. Но я не встречал такого на LXC ранее. А вот на OVZ — прям сейчас.
По ссылкам на форум в конце поста вообще смешно читать. Просто жалобы без попыток разобраться.
И получается плох LXC, а проксмокс просто ошибся с выбором.
lxc реально плох, я уже два раза до этого пытался его заюзать вместо виртуалок несколько лет назад, тогда это был тоже ад, ещё больший чем сейчас, в целом для домашних страничек он ничего, но в продакшене уж лучше на докер перейти, реально он позже стал развиваться, но счастья в нем намного больше, сейчас в нем держит мой программист все проекты.
Миграция это меньшее из зол, в целом я нашел пути как побороть все проблемы с запуском контейнеров после миграции.
ИО проблемы связаны с loopfs которую юзает lxc ну и как вариат в thin provision тоже работает чертовски медленно.
Проблема в том что мы ставим его не для потестить, а для продакшена.
НУ а 3 процента зависших контейнеров меня бы уже давно заставили бы смигрировать на какой нибудь квм.
Миграция это меньшее из зол, в целом я нашел пути как побороть все проблемы с запуском контейнеров после миграции.
ИО проблемы связаны с loopfs которую юзает lxc ну и как вариат в thin provision тоже работает чертовски медленно.
Проблема в том что мы ставим его не для потестить, а для продакшена.
НУ а 3 процента зависших контейнеров меня бы уже давно заставили бы смигрировать на какой нибудь квм.
Тут проблема именно в реализации LXC в Proxmox. Отдельно LXC плотно не ковырял, однозначно говорить что проблема в нем не буду, но по факту миграции, когда перенес на тест всего около сотни контейнеров из Proxmox3 в Proxmox4 — начался сущий ад, все виснет, тупит, зависает, отваливается и не работает, один глюк чинишь — вылазит 2 новых, производительность деградировала просто в разы, либо разработчики прокса взяли в команду рукожопов, которые и занимались прикручиванием LXC, либо не все так гладко в королевстве LXC. Я не говорю что OpenVZ безупречен, там своих проблем хватает (контейнеры пару раз висли, из примерно 2.5К контейнеров за крайний месяц зависал один и тот-же дважды), но то, что началось после попытки миграции — кромешний ад. Если LXC по вашему хорош — подскажите продукт на его основе, где он работает без сбоев не на локалхосте (напильник в виде, не нравится — перепиши сам, не предлагать) думаю многие скажут спасибо.
Жалобы идут обычно после попыток разобраться, когда известные методы решения проблем кончились, если вас веселит откровенно хреновая работа технологии, возможно с вашим ч.ю. что-то не так.
По ссылкам на форум в конце поста вообще смешно читать. Просто жалобы без попыток разобраться.
Жалобы идут обычно после попыток разобраться, когда известные методы решения проблем кончились, если вас веселит откровенно хреновая работа технологии, возможно с вашим ч.ю. что-то не так.
Надеюсь, simfs допилят в Virtuozzo…
лучше не надеяться и попробовать самому, чтобы о багах узнать до релиза, а не после него
Одно из распространённых заблуждений в использовании opensource — люди думают, что надо немного подождать, пока другие выловят все баги, отрепортят их, сами исправят или добьются того, чтобы кто-то исправил, а они потом уже начнут использовать хорошо протестированную версию. Так вот это не так. Ваши сценарии использования могут отличаться от сценариев других пользователей. И если у кого-то все работает хорошо, то это не значит, что и у вас будет тоже все хорошо :) Именно поэтому стоит попробовать тестовую версию до финального релиза — чтобы убедиться, что на ваших сценариях ПО работает.
Ну и хочу напомнить, что стоимость исправления дефекта прямо пропорциональна времени разработки проекта, поэтому после релиза далеко не каждый баг будет исправлен.
Ну и хочу напомнить, что стоимость исправления дефекта прямо пропорциональна времени разработки проекта, поэтому после релиза далеко не каждый баг будет исправлен.
Эх, нагуглил этот пост только сегодня в понедельник после выходных проведенных с Proxmox 4. Да, скорость работы дисковой подсистемы на запись сильно огорчила. Сделал уже restore с --rootfs local:0. Производительность чуть выросла, но все равно пока грустно.
Один контейнер (из ДВУХ!) уже успел намертво повиснуть разок.
Кстати, пользуясь случаем хотел уточнить, а как правильно ребутить сервер с Proxmox? В случае с подвисшим контейнером пробовал reboot и shutdown -r now на ноде — реакции никакой.
Один контейнер (из ДВУХ!) уже успел намертво повиснуть разок.
Кстати, пользуясь случаем хотел уточнить, а как правильно ребутить сервер с Proxmox? В случае с подвисшим контейнером пробовал reboot и shutdown -r now на ноде — реакции никакой.
хардресет кнопкой
Я тестовый с 4 веткой через IPMI передергивал (за 2 суток 4 раза подвис наглухо сволочь), вообще у меня в продакшинах фенсинг настроен, хотя третья ветка и не подвисает особо.
Как-то так:
sync;
echo 3 > /proc/sys/vm/drop_caches
echo 1 > /proc/sys/kernel/sysrq
echo b > /proc/sysrq-trigger
Вы конечно же отобразили свое негодование в багтрекере проксмокса?
Да там как бы всем все известно, проблемы то дикие, и в багтрекере есть и на форуме куча постов и это все прекрасно видят разработчики.
Sign up to leave a comment.
Проблемы после миграции с openvz на lxc в Proxmox 4.x