Странное поведение операционок с lvm на сервере Intel Modular Server

Question

[iNatalia]

Добрый день.

Имеется сервер intel Modular Server с 4 лезвиями. На одной из них требуется развернуть ubuntu с kvm и машинки на lvm.
Ставлю с нуля убунту (13.10) — вроде ставится, лвм создается (дефолтная конфигурация, когда /boot вне lvm, а остальное под лвм), но после перезагрузки — бизибокс, отсутствие волюмгрупп в /dev/mapper. То же с дебианом (Визи). Centos (6.4) встает, с LVM в / не пробовали, потом отдельно созданный раздел LVM на неразмеченном пространстве создался, диски создаются тоже через virt-manager, но при установке на них виртуальных машин, они оказываются read-only.

Посоветуйте решение этой непонятной ситуации. Очень нужна убунта, пробовала решение отсюда: unix.stackexchange.com/questions/11125/lvm-devices-under-dev-mapper-missing, не помогло. И вообще, даже дистрибутив себя странно ведет, из 5 раз он видит жесткие диски только 1 раз, все остальное время он их не узнает. То же с live CD убунты — первый раз увидел диск и созданные волюм группы, а дальше ни в какую.

Comments

[iNatalia]

После всех мытарств ситуация пришла к следующему положению: диск инициализируется в течение 12-13, может 15 минут после начала загрузки операционной системы. Иными словами, команды vgscan, vgchange -ay завершаются успешно только через 12-13 минут после выхода в бизибокс после начала загрузки ОС. Насколько это нормально? как уменьшить задержку?

Answer 1

[smartly]

В дебиане после установки ядра инсталер спрашивает, какие драйвера использовать для initrd. Все или некоторые. Попробуйте ответить «все».
Но вообще похоже, что не видит самих винтов, а не LVM на нём.

Answer 2

[merlin-vrn]

Посмотрите при загрузке с диска с убунтой — какие-то предупреждения в dmesg относительно контроллера были? Что там за драйвер? И убедитесь, что этот драйвер есть либо внутри ядра, либо внутри initramfs и подгружается при её запуске.

У меня был случай, что приходилось добавлять pciid карточки в new_id, чтобы драйвер её узнал и завёл, но, правда, на матери супермикро.

Comments

[iNatalia]

Специфического драйвера для убунты на сайте интела нет. :( и вообще там только драйвер для винды.

[merlin-vrn]

Нет-нет, я не про драйвер на сайте производителя, я именно про драйвер в ядре. Но вы уже описали драйвер — mptscsih. Мне этот драйвер незнаком. Я вроде бы заводил LSISAS1064E через megaraid_sas (хотя могу ошибаться, было года три назад, когда я столкнулся с 1064).

12-13 минут на инициализацию диска — это совершенно ненормально. Есть ли у вас утилита от LSI — MegaCLI — для работы с LSI MegaRAID из линукса? Она бинарная, вроде бы можно было поставить deb прямо на livecd убунты и смотреть, что про нас думает контроллер.

А dmesg центоси (в которой работает) можете привести? Сравним их. Не надо грепать по ios0, это не показывает нам много интересного — например, инициализацию самого драйвера.

[iNatalia]

rghost.ru/49690403 это дмесг центоса, там все проходит гладко в плане нахождения дисков

Answer 3

[merlin-vrn]

Собственно, всё интересное в дмесге:

Fusion MPT base driver 3.04.20
Copyright (c) 1999-2008 LSI Corporation
Fusion MPT SAS Host driver 3.04.20
  alloc irq_desc for 42 on node 0
  alloc kstat_irqs on node 0
mptsas 0000:04:00.0: PCI INT A -> GSI 42 (level, low) -> IRQ 42
mptbase: ioc0: Initiating bringup
ioc0: LSISAS1064E B3: Capabilities={Initiator}
mptsas 0000:04:00.0: setting latency timer to 64
scsi0 : ioc0: LSISAS1064E B3, FwRev=01210000h, Ports=1, MaxQ=483, IRQ=42
mptsas: ioc0: add expander: num_phys 25, sas_addr (0x5001e67211fa52ff)
mptsas: ioc0: attaching ssp device: fw_channel 0, fw_id 0, phy 11, sas_addr 0x500015500002040a
scsi 0:0:0:0: Direct-Access     Intel    Multi-Flex       0310 PQ: 0 ANSI: 5
scsi 0:0:0:1: Direct-Access     Intel    Multi-Flex       0310 PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 251658240 512-byte logical blocks: (128 GB/120 GiB)
sd 0:0:0:1: [sdb] 524288000 512-byte logical blocks: (268 GB/250 GiB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 97 00 10 08
sd 0:0:0:1: [sdb] Write Protect is off
sd 0:0:0:1: [sdb] Mode Sense: 97 00 10 08
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, supports DPO and FUA
sd 0:0:0:1: [sdb] Write cache: enabled, read cache: enabled, supports DPO and FUA
 sda:
 sdb: sda1 sda2
sd 0:0:0:0: [sda] Attached SCSI disk
 sdb1
sd 0:0:0:1: [sdb] Attached SCSI disk
dracut: Scanning devices sda2  for LVM logical volumes vg_server2/lv_swap vg_server2/lv_root 
dracut: inactive '/dev/vg_server2/lv_root' [50.00 GiB] inherit
dracut: inactive '/dev/vg_server2/lv_home' [38.02 GiB] inherit
dracut: inactive '/dev/vg_server2/lv_swap' [31.48 GiB] inherit
EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: 
dracut: Mounted root filesystem /dev/mapper/vg_server2-lv_root

Отсюда видим, что в центоси не ругается mptscsih, как в убунте. На всякий случай поясню, что драйвер всё-таки mptsas, mptscsih — это библиотека, которая обязательно есть в обоих случаях и называется «Fusion MPT SCSI Host driver». Просто в центоси он почему-то не ругается.

Из лога убунты (выше):

mptbase: ioc0: Initiating bringup
ioc0: LSISAS1064E B3: Capabilities={Initiator}
scsi0: ioc0: LSISAS1064E B3, FwRev=011e0000h, Ports=1, MaxQ=277, IRQ=30
mptsas: ioc0: add expander: num_phys 25, sas_addr (0x5001e67211fa52ff)
mptsas: ioc0: attaching ssp device: fw_channel 0, fw_id 0, phy 12, sas_addr 0x5000155000020409

FwRev другой, MaxQ другой (что бы это ни значило). FwRev — это, судя по названию, версия фирмвари, причём в логе из центоси само число больше — более новая?
В связи с этим вопрос: в на одной и той же машине эти логи получили?

Кстати, looks like редхат имел похожую проблему ещё года четыре назад: bugzilla.redhat.com/show_bug.cgi?id=483424#c12. Я так и не понял, получилось у них или нет.

Comments

[iNatalia]

Спасибо за ответ, прошу прощения за задержки с ответами, уезжала в командировку и сервер, соответственно, бросила.
Оба лога получены на одном и том же Intel Modular Server, но на разных лезвиях (по составу железок лезвия разные), но они все равно используют один и тот же контроллер.
Более того, контроллер в четверг решил вести себя странно и потерялся из виду для всех лезвий, так что реанимировали все это дело почти полдня. Вмваря во время глюка также очень медленно работала с дисками. Потом все само и заработало. В логах одна странная ошибка, про которую гугл не имеет ни малейшего понятия.
Пока решили заказать второй контроллер, а убунту я уже боюсь грузить, т.к. есть подозрение, что контроллер глюканул после одной из манипуляций с биосом лезвия. :(