Панель управления сервером

без комментариев. Показывал знакомым ембеддерщикам. Смеялись.

Ну hasp. Так стоит та 1с с хаспом на тех терминальных серверах, работает, жрать не просит...

Прокидывать PCI - таки да, проблема. Ровно один раз надо было в каком-то совершенно экзотичном случае....

Значит они не знают, с какими задачами я работаю. Всё просто, правда? Рад за их некомпетентность. Они, наверное, не знают, что сам по себе x86 от виртуалок мало отличается. И не знают о том, как именно разграничивается процессорное время в XEN. Видимо, они просто занимаются embedded-системами, а не разрабатывают узкоспециализированные задачи для отрасли. Между прочим, QNX ведёт себя вполне достойно, и я _точно_ знаю, когда будет тот или иной сигнал. При условии достаточного количества ресурсов. А ваш KVM умеет работать с HPET? Дайте им вот эту ссылку, пусть почитают: https://sites.google.com/site/realtimexen/home

Вышло недавно, но я уже с этим работаю. А вот ваш KVM нервно курит в сторонке.

Мы с вами сейчас выясняем, почему я не буду работать с KVM, или вы пытаетесь натыкать меня носом? Я сказал: у меня противоположный опыт. последний раз я тестировал его полгода назад. И дал вам ссылочку на то, что в KVM еще предстоит сделать, а в том же XEN уже давно реализовано.

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

Уймитесь, за мной такие вещи никто никогда не чинил. И это не один год прошёл.

Не суждено вам мне такие вещи говорить обосновано, поэтому лучше промолчите.

Радоваться, что у них "мозгов" на апдейты системных вещей не хватает. Апдейт панели ispmanager - это в 99% апдейт только кода панели. ПО к обновлению панели отношения не имеет.

Не обновляет ISPManager данные в системных приложениях. А правильный путь подобного обновления - это добавить функционал в панель, не влияя на работу существующего. Просто научить панель видеть и работать с системными пользователями другого формата и отображать их. К примеру, в списке пользователей базы ввести дополнительную колонку "хост" и спокойно редактировать. Тогда старые вещи будут продолжать работать.

Но человеку, который умеет рассуждать о том, о чём толком ничего не знает, это не известно.

Myhand, не нужно со мной разговаривать в таком ключе. Вам нужно сначала дорасти до серьёзной работы и такого объёма, который делаем мы, а потом уже обсуждать наши действия.

Естественно. В первую очередь жизненный опыт. Т.к. зачастую системы строятся не на железе за много миллионов, а на "том, что есть". И железо не всегда бывает приятным. KVM значительно моложе XEN и имеет значительно больше проблем, на мой взгляд, но это дело вкуса. Кроме того, XEN нативно включен в ядро Linux, а сам Dom0 тоже является виртуализированным, что означает минималистичность самого ксена и отсутствие потенциальных проблем из-за кривизны кода в самом ядре.

Железо - адекватно задаче, не так ли? Если задача допускает использование железа, не проходящего под формализованные требования - ну тогда что спрашивать с гипервизора?

Вменяемое железо стоит существенно меньше даже одного миллиона )

Вот тут что-то непонятное ты сказал. Ксен нативно в ядре + ядро с кривым кодом = кривой ксен? )))))

Гм. Т.е. Это не баг, а фича? Или это? А, может, вот это?

---------- Добавлено 16.02.2012 в 13:38 ----------

Да нет. Сам гипервизор он поверх ядра. А вот ядрышки уже пересобирать под ксен не надо. просото поставить гипервизор и поменять конфиг загрузчика. Т.е. на сам гипервизор никакой модуль ядра повлиять _НЕ МОЖЕТ_. А вот на kvm - запросто.

В каждом конкретном случае надо разбираться. Прекрасно работающий из коробки установщик 64-битной семерки под kvm+libvirt из актуального centos6 могу показать, равно как и работу с usb флешкой. Что там в убунте люди делают и зачем вручную флаги для qemu подбирают - не ведаю.

alw, Вот confirmed могу найти статус... Причем в багтрекере ядра. Мне просто лень...

Вы проблемы переименовали в "глюки" - и теперь их "нет"? Остроумно, не сути не меняет. Почитайте форумы того же ispmanager, предыдущую ссылку я взял фактически наугад - там мульены таких же горе-редакторов, которым постоянно достается из-за того, что они ковыряют потроха сего чуда енженерной мысли.

Я в этом не уверен - обычно не спрашиваю за кем чиню, да и не знаю всех в вашей команде.

Вот и хорошо. Мы создали руками отдельный логин, который не имел отношения к ispmanager (может специально, с другим паролем даже). А она молча в цатом релизе его "подключила". А потом кто-то в панельки поменял пароль у пользователя user - и поменяется он и у user@localhost и для @remote (почему? для тех кто в танке - потому, что это так сделалано сейчас для user@localhost и user@%, это одна сущность для панельки), к изумлению ничего не подозревающих пользователей.

Вы под стол пешком ходили, когда я уже работал системным администратором на хостинге с количеством клиентов - порядка на два больше вашего. Вы не поверите, компании даже в голову не приходило рекламировать свои услуги на форумах :D

Предупреждал ведь: не хвастайтесь пятилетним опытом работы техподдержкой - приличные люди засмеют ;)