Xen DomU и RTC (тик-так)

[dimbor]

Доброго времени года!
Как известно, счастливые трусов не надевают часов не наблюдают. Угораздило к ним не отнестись.
Xen 4.1.1, Dom0 3.0.4-gentoo-r1, DomU - такой же.
В биосе сидит локальное время, в Dom0 при соответствующей настройке все ОК.
Но тут позвал себе в гостя - гостя, и стало стыдно. Время отличается на четыре часа, торопится жить.
При запуске гостя не отрабатывает hwclock, не находит /dev/rtc.
Ядро при старте говорит:

Код: Выделить всё

platform rtc_cmos: registered platform RTC device (no PNP device found)
...
rtc_cmos rtc_cmos: rtc core: registered rtc_cmos as rtc0
rtc_cmos: probe of rtc_cmos failed with error -38

Собрано:

Код: Выделить всё

CONFIG_HPET_EMULATE_RTC=y
CONFIG_RTC_LIB=y
CONFIG_RTC_CLASS=y
# CONFIG_RTC_HCTOSYS is not set
# CONFIG_RTC_DEBUG is not set
CONFIG_RTC_INTF_SYSFS=y
CONFIG_RTC_INTF_PROC=y
CONFIG_RTC_INTF_DEV=y
# CONFIG_RTC_INTF_DEV_UIE_EMUL is not set
# CONFIG_RTC_DRV_TEST is not set
CONFIG_RTC_DRV_CMOS=y

По логам видно, что ему явно чего-то не хватает. Подскажите пожалуйста, чего?
Конечно понятно, что ntpd/adjtime было бы решением, но жирно и криво.

[dimbor]

Хотя с другой стороны, DomU при старте считает, что в Dom0 обязательно UTC и пересчитывает его в LOCAL. По идее достаточно его от этого отучить. Опять же, как?

[vr13]

а управляющий интерфейс xen какой - xend или libxl?

с вторым имеется много проблем, в т.ч с часами. в моем случае проблема, идентичная вашей была с hvm-виндой и pv-freebsd. вернулся на xend и нормализовалось

[Bluetooth]

А банальная опция localtime не срабатывает?

[dimbor]

а управляющий интерфейс xen какой - xend или libxl?

xl конечно, а xend куда-то исчез из пакета use-флажком выключили по умолчанию. Собрать-то его в принципе можно, но на 4.0.1 через xm DomU у меня не поднимался в принципе. Краем уха слышал, что он deprecated. Имеет ли смысл пробовать еще раз?

А банальная опция localtime не срабатывает?

Опа! С воодушевлением узнал о наличии этой опции (впрочем, как и о многих других - бо зелен еще в виртализации). Но она утонула не сработала, увы.
Но все равно, спасибо за информацию.

Вот за что люблю линух - куда ни ткнись, обязательно упрешься в задницу, которой можно посвятить остаток жизни. Не хочу!;)
Наверное пока стоит попробовать emerge ntpclient, не гигабайтный же он.

[Bluetooth]

xl конечно, а xend куда-то исчез из пакета use-флажком выключили по умолчанию. Собрать-то его в принципе можно, но на 4.0.1 через xm DomU у меня не поднимался в принципе. Краем уха слышал, что он deprecated. Имеет ли смысл пробовать еще раз?

xend deprecated? Оппа. Отстаю от жизни :)

Имеет ли смысл пробовать еще раз?

Я бы однозначно попробовал.

Наверное пока стоит попробовать emerge ntpclient, не гигабайтный же он.

главное - чтобы он ставил правильное время до того, как будут стартовать сервисы, а то они еще и запнуться могут от скачка времени.

[vr13]

а управляющий интерфейс xen какой - xend или libxl?

xl конечно, а xend куда-то исчез из пакета use-флажком выключили по умолчанию. Собрать-то его в принципе можно, но на 4.0.1 через xm DomU у меня не поднимался в принципе. Краем уха слышал, что он deprecated. Имеет ли смысл пробовать еще раз?

да, имеет. с libxl пока действительно много проблем, часы - одна из них. localtime (кстати, изначально сделанная для hvm) в libxl является deprecated (или вообще не работает). еще замечено, что с libxl некорректно считается свободная память - если не использовать dom0 balooning). еще много чего - если посмотреть xen-users ml.

обещают, что с libxl разберутся в 4.1.2, хотя мне кажется, что это им кажется

поэтому - пока xend. для себя сделал некоторую комбинацию старого и нового: убрал из xend конфигурацию сети - "(network-script network-bridge)": теперь мосты стартуют в системе dom0, ну и за одно - подчистил конфигурации всех domU от питоновского синтаксиса, как это рекомендуется в libxl migration guide (соответственно - переключение между libxl и xend делается /etc/init.d/xend start/stop - если не использовать поставляемый автоматический старт domU при запуске системы - /etc/init.d/xendomains) - что делаю время от времени при выходе очередного патча. каждый раз убеждаюсь, что старый интерфейс пока еще лучше нового

еще нюанс (субъективное мнение - вполне вероятно, что кажется): лучше пользоваться ядрами 2.6.34-xen-sources для dom0 и pv-domU (специфично для gentoo). pv-ops ядра 3.0.x значительно медленнее

[dimbor]

обещают, что с libxl разберутся в 4.1.2, хотя мне кажется, что это им кажется

Ага, и мне кажется, что неспроста кажется, что кажется.

А мой опыт противоположен вышеописанному. Когда был за шкирку вброшен в паравиртуальные дела одним уважаемым товарищем (да, TheLT, теперь икай), хотелось видеть в Xen надежный инструмент в исследовании вражеских технологий, которые умники запихали в модуль ядра, и рушится оно теперь, и даже без бонуса в виде синего экрана нет.
Вместо инструмента получился как обычно конструктор без каких либо гарантий, и нужно теперь тратить время на его исследования. Через xend не получилось поднять даже уже готовую, присланную по просьбе виртуалку. Ни с нулевым gentoo-sources-2.6.39, ни ваниль 2.6.34. На xl пошло. Но еще был очень нужен старт гостя с раздела, а не образа. Посему образовался 3.0.4. К 3.0.6 пока боюсь подступиться - сущности умножатся безмерно. И так плюс ко всему там, где xen есть, гость стартует раза с третьего.
А там куда хотел поставить ксен на взрослый сервер, нулевой не поднимается из-за каких то маловнятных проблем с aacraid. Пичаль! Но хоть теперь есть, кому поплакаться

главное - чтобы он ставил правильное время до того, как будут стартовать сервисы, а то они еще и запнуться могут от скачка времени.

Воткнул в postup() сетевого интерфейса. В логах чудеса теперь, но вроде пашет.

[vr13]

[А там куда хотел поставить ксен на взрослый сервер, нулевой не поднимается из-за каких то маловнятных проблем с aacraid.

а какие проблемы с этим scsi? помнится, это (aacraid) работало еще во времена xen3 и ядер 2.6.18 на машинках ibm серии x3600

[dimbor]

а какие проблемы с этим scsi? помнится, это (aacraid) работало еще во времена xen3 и ядер 2.6.18 на машинках ibm серии x3600

У меня x3400, стоял там долгие годы альт на том самом 2.6.18 и жрать не просил. Потребовалась виртуализация, составил я туда Dom0, выгадал двое суток, приехал в тот зад, где сервер установлен, записал, пересобрал систему и ксен. Не грузилось вообще. После обновления всевозможных биосов загрузилось ядро непосредственно. Через ксен ни в какую - кирдык на этапе определения дисковой подсистемы. Сунулся было в условиях цейтнота смотреть, как этот ксен собирается. Успел обнаружить, что для 64-битных систем походу используется 32-битный гипервизор. Это несколько пошатнуло сложившуюся картину мира. От изумления быстренько накатил на будующий Dom0 сервисы а ля старая система, оставил его standalone и убрался не солоно хлебавши.
С системой мониторинга на втором сетевом адаптере этой железки тоже не срослось. Вроде он даже пингуется, но и только. По ночам туда не наездишься. Эта дура еще и грузится минут пять, надо в засаде сидеть - очень большой расход сигарет . А вторая такая свободная железяка для экспериментов отсутствует.
В сети нарыл, что проблема имеется, но каждый буржуй ее решал, кто во что горазд, и не каждый решил. Т.ч. пока застыл в ожидании неизвестно чего.

[vr13]

определения дисковой подсистемы. Сунулся было в условиях цейтнота смотреть, как этот ксен собирается. Успел обнаружить, что для 64-битных систем походу используется 32-битный гипервизор. Это несколько пошатнуло сложившуюся картину мира. От изумления быстренько накатил на будующий Dom0 сервисы а ля старая система, оставил его standalone и убрался не

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

Код: Выделить всё

# xm info|grep xen_caps
xen_caps               : xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p

наоборот (имеется в виду 64бит гипервизор) - поддерживает

Код: Выделить всё

# xm info|grep xen_caps
xen_caps               : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64

ну, либо моя картина мира не соответствует действительности

а по поводу aacraid, попробуйте поставить другой adaptec-контроллер, вместо CONFIG_SCSI_AACRAID
в моем случае - с этим контроллером тоже были грабли, которые обошлись таким образом. что точно поставилось не помню, этого сервера уже не существует. вероятнее всего, загрузился с какого-нить rescue cd и посмотрел на название модуля

[dimbor]

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

Действительно, ерунду сказал. А все потому, что нашел в ядре ксеновском буквы ELF32 и с чего-то решил, что ядрам режим работы проца должен GRUB переключать . На самом деле не уверен даже, что там что-либо надо переключать, т.к. архитектурные знания оборвались на расширенном режиме процессора i386 . Как-нить теперь надо загуглить чой-нибудь популярное на эту тему, чтобы быстро поднятый авторитет упавшим не считался.

а по поводу aacraid, попробуйте поставить другой adaptec-контроллер, вместо CONFIG_SCSI_AACRAID
в моем случае - с этим контроллером тоже были грабли, которые обошлись таким образом. что точно поставилось не помню, этого сервера уже не существует. вероятнее всего, загрузился с какого-нить rescue cd и посмотрел на название модуля

С болванки-то как раз aacraid у меня цеплялся по умолчанию. Если только подобрать модуль методом тыка. Спасибо за идею. Попробую, только вот эти поросята свою отчетность посдают и прекратят мучить Астралом