https://bugzilla.redhat.com/show_bug.cgi?id=503988
Баге много лет и она снова проснулась. Нет, конечно, сам гипервизор то ни при чем, тут виновата вообще органищация работы со стеком в ядре (насколько я понимаю).
Romka_Kharkov, Что там рассказывать? Что HVM использует перекомпилированый лайттпд а апач просто ставит и даже не убирает его из автозагрузки?! Вроде все сказано.
latin1 ни о чем не говорит? Вы тикеты по Русски пробовали отправить? HVM это законченный продукт вроде бы (для забугра).
Я не говорю, что оно без танцев с бубном работает, но по умолчанию HVM создает конфиги, которые загружают то же ядро, которое использует хост-система.
P.S. Поражает меня это желание носом натыкать :(
Ггг... Хостеры, а на такой пиар... Фигли тут делать, разве что окончательно тему зафлудить, да самим попиариться? )))
Грубо говоря - да. Причина - много лишнего кода, много левых функций. И еще - гораздо проще засобачить свой код, чем разбираться в чужом и исправлять ошибки проектирвоания. Например, знаете ли вы, что apache, устанавливаемый hyperVM просто жрет лишнюю память зря? Знаете ли вы, что локализация затруднена из-за выбора кодировок базы данных? Знаете ли вы, что в этой панели управления гостеваяоперационная система не может загрузиться со своим ядром без конкретных танцев с бубном? Знаете ли вы, что в Open-source не все исходные коды? Это так, маленькая толика. про секурность там тоже отдельный разговор...
Плохого ничего. Но в данном случае XEN засобачил смену мака для сетвеой. Сделал его таким же, как и у своего бриджа... Результат - сервер недоступен. Думаете, ребут и все нормализуется? Нифига, у нас реалтек :).
Мало того, что на посики причин ушла тонна времени, так оказалось, что это самый натуральный баг в ядре rhel... Лечится очень просто - вклуюением LAN boot ROM в БИОС. Загружаться с сети не обязательнов общем... Но вот так. И на поиски этой шняги ушло несколько дней.
нет, вы не совсем правы. Нормального решения нет... Для массового хостинга. Когда у вас один-два клиента это одно, а когда вот дохрена - совсем другое. И у меня рук не хватит всем клиентам перезагружатЬ, переставлять ОС и т.п. Пусть они сами делают это через панель... Очень удобно это - автоматизация. Но вот если панель глючная - вот это плохо. ИМХО, нормальный продукт было бы не плохо организовать...
Руки, руки, только руки. На ПО надеяться вообще нелья... По сабжу директадмин наиболее лучший. Перспективы же у всех обалденные... Все личное ИМХО
Ага. Все верно, за исключением: софт все же серверный рассчитывается на серверное железо. Кто же знал, что у меня из-за глюка ничтожного будет такая проблема. Собственно, и сетевка то не интеграшка ))). Вот он один из минусов XEN: его хоть и очень гибкая, но местами бредовая работа с сетью.
Дело не в том. У меня стоит десктопный проц под виртуалки. Ну и сама платформа десктопная. Она ни чем не хуже серверной, за одним небольшим исключением: заточена она все же под другие вещи. Серверное оно более тщательно разрабатывается. И лучше масштабируется...
Ну и это тоже... )
Да нет, просто смежное. Понятное дело, что HyperVM совсем не ксен. Но в общем тут такой прикол получился: в новых ядрах CentOS (и RH) появился старый баг... В общем НИКОГДА!!! Не запускайте XEN на realtek...
И то, что я не посмотрел, что там поменялось в ядре в общем - то тут ни при чем. Я бы его один хрен не увидел....
А проблема в том, что реалтек может менять аппаратный MAC. И сохранять его измененным даже после перезагрузки...
Да. Из-за того, что накосячили при обновлении. Проблема решена, возникла из-за бага в ядрах RedHat xen и из-за того, что realtek умеет менять аппаратный MAC-адрес, сохраняя его измененным после перезагрузки. Скоро поднимемся.
Raistlin добавил 27.06.2010 в 04:45
В 3 часа по МСК поднялись все ВДС. Вируальный хостинг частично поднялся, частично восстанавливается из бекапов (полетела ФС).
Raistlin добавил 27.06.2010 в 05:10
Поднялись полность. Клиентам, у которых сохранились ограничения или наблюбдаются какие-либо сбои в работе сайтов прошу незамедлительно сообщать о проблемах на admin@hostace.ru, 408108152 или оставлять тикеты.
