Назад | Перейти на главную страницу

KVM Гость на основе LVM… ядро: ошибка ввода-вывода буфера на устройстве. Неудачный диск?

В настоящее время настраивается небольшой узел KVM для запуска нескольких виртуальных машин для малого бизнеса. На сервере есть 2 диска в программном массиве md RAID 1, затем я установил его как PV в настройке LVM. Все гости и хосты используют CentOS 6.4 64bit.

В / Раздел гостевых систем KVM представляет собой образы дисков, но с одним конкретным гостем, у которого будут более высокие требования к вводу-выводу, я добавил к виртуальной машине второй жесткий диск, который является логическим томом из пула хранения хоста.

Сегодня вечером я выполнял довольно интенсивный ввод-вывод на этом LV в гостевой системе, извлекая многотомный архив данных 7z объемом 60 ГБ. 7z проскочил примерно 1/5 пути с E_FAIL. Я пытался переместить несколько файлов на этом LV диск и получил ответ «невозможно переместить ... файловая система только для чтения». Все устройства смонтированы rw. Я заглянул в /var/log/messages и увидел следующие ошибки ...

Nov 22 21:47:52 mail kernel: Buffer I/O error on device vdb1, logical block 47307631
Nov 22 21:47:52 mail kernel: lost page write due to I/O error on vdb1
Nov 22 21:47:52 mail kernel: Buffer I/O error on device vdb1, logical block 47307632
Nov 22 21:47:52 mail kernel: lost page write due to I/O error on vdb1
Nov 22 21:47:52 mail kernel: Buffer I/O error on device vdb1, logical block 47307633
Nov 22 21:47:55 mail kernel: end_request: I/O error, dev vdb, sector 378473448
Nov 22 21:47:55 mail kernel: end_request: I/O error, dev vdb, sector 378474456
Nov 22 21:47:55 mail kernel: end_request: I/O error, dev vdb, sector 378475464
Nov 22 21:47:55 mail kernel: JBD: Detected IO errors while flushing file data on vdb1
Nov 22 21:47:55 mail kernel: end_request: I/O error, dev vdb, sector 255779688
Nov 22 21:47:55 mail kernel: Aborting journal on device vdb1.
Nov 22 21:47:55 mail kernel: end_request: I/O error, dev vdb, sector 255596560
Nov 22 21:47:55 mail kernel: JBD: I/O error detected when updating journal superblock for vdb1.
Nov 22 21:48:06 mail kernel: __ratelimit: 20 callbacks suppressed
Nov 22 21:48:06 mail kernel: __ratelimit: 2295 callbacks suppressed
Nov 22 21:48:06 mail kernel: Buffer I/O error on device vdb1, logical block 47270479
Nov 22 21:48:06 mail kernel: lost page write due to I/O error on vdb1
Nov 22 21:48:06 mail kernel: Buffer I/O error on device vdb1, logical block 47271504
Nov 22 21:48:06 mail kernel: end_request: I/O error, dev vdb, sector 378116680
Nov 22 21:48:06 mail kernel: end_request: I/O error, dev vdb, sector 378157680
Nov 22 21:48:06 mail kernel: end_request: I/O error, dev vdb, sector 378432440
Nov 22 21:51:25 mail kernel: EXT3-fs (vdb1): error: ext3_journal_start_sb: Detected aborted journal
Nov 22 21:51:25 mail kernel: EXT3-fs (vdb1): error: remounting filesystem read-only
Nov 22 21:51:55 mail kernel: __ratelimit: 35 callbacks suppressed
Nov 22 21:51:55 mail kernel: __ratelimit: 35 callbacks suppressed
Nov 22 21:51:55 mail kernel: Buffer I/O error on device vdb1, logical block 64003824
Nov 22 21:51:55 mail kernel: Buffer I/O error on device vdb1, logical block 64003839
Nov 22 21:51:55 mail kernel: Buffer I/O error on device vdb1, logical block 256
Nov 22 21:51:55 mail kernel: Buffer I/O error on device vdb1, logical block 32
Nov 22 21:51:55 mail kernel: Buffer I/O error on device vdb1, logical block 64
Nov 22 21:51:55 mail kernel: end_request: I/O error, dev vdb, sector 6144
Nov 22 21:55:06 mail yum[19139]: Installed: lsof-4.82-4.el6.x86_64
Nov 22 21:59:47 mail kernel: __ratelimit: 1 callbacks suppressed
Nov 22 22:00:01 mail kernel: __ratelimit: 1 callbacks suppressed
Nov 22 22:00:01 mail kernel: Buffer I/O error on device vdb1, logical block 64003824
Nov 22 22:00:01 mail kernel: Buffer I/O error on device vdb1, logical block 512

Их было намного больше, полный отрывок здесь http://pastebin.com/vH8SDrCg
Обратите внимание на момент, когда возникает ошибка ввода-вывода при «обновлении суперблока журнала», а затем том повторно монтируется как доступный только для чтения из-за прерванного журнала.

Итак, пора посмотреть на хозяина.

cat /proc/mdstat возвращается UU для обоих массивов RAID 1 (boot и основной PV).
mdadm --detail показывает state: clean и state: active соответственно
Типичные команды LVM pvs, vgs и lvs все возвращают следующую ошибку:

  /dev/VolGroup00/lv_mail: read failed after 0 of 4096 at 262160711680: Input/output error
  /dev/VolGroup00/lv_mail: read failed after 0 of 4096 at 262160769024: Input/output error
  /dev/VolGroup00/lv_mail: read failed after 0 of 4096 at 0: Input/output error
  /dev/VolGroup00/lv_mail: read failed after 0 of 4096 at 4096: Input/output error
  VG         #PV #LV #SN Attr   VSize   VFree  
  VolGroup00   1   4   1 wz--n- 930.75g 656.38g

/var/log/messages на хосте показывает это:

Nov 22 21:47:53 localhost kernel: device-mapper: snapshots: Invalidating snapshot: Unable to allocate exception.
Nov 22 22:11:04 localhost kernel: Buffer I/O error on device dm-3, logical block 0
Nov 22 22:11:04 localhost kernel: Buffer I/O error on device dm-3, logical block 1
Nov 22 22:11:04 localhost kernel: Buffer I/O error on device dm-3, logical block 2
Nov 22 22:11:04 localhost kernel: Buffer I/O error on device dm-3, logical block 3
Nov 22 22:11:04 localhost kernel: Buffer I/O error on device dm-3, logical block 0
Nov 22 22:11:04 localhost kernel: Buffer I/O error on device dm-3, logical block 64004095
Nov 22 22:11:04 localhost kernel: Buffer I/O error on device dm-3, logical block 64004095
Nov 22 22:11:04 localhost kernel: Buffer I/O error on device dm-3, logical block 0

Краткая самопроверка с smartctl ничего не обнаружено ни на одном из физических дисков. В данных SMART тоже не было тревожных счетчиков ошибок, больше всего в 0 помимо часов работы, времени разгона, температуры. Даже время работы было относительно низким, около 150 дней. В настоящее время у меня ведутся длительные самопроверки.

Итак, исходя из всего этого, какова вероятность того, что это начало отказа диска?
Стоит запустить fsck или badblocks в хосте?
Я не хочу вызывать полную панику ядра на данном этапе. Я бы подумал mdstat к этому моменту, примерно через 1 час после события, показал бы отказавший элемент массива.

Эта машина является выделенным сервером, поэтому у меня нет физического доступа. Вскоре я проверю консоль через DRAC, но ожидаю увидеть кучу ошибок ввода-вывода на консоли. У меня нет доступа к виртуальному носителю, поэтому я не могу загрузить systemrescuecd для ремонта, поэтому я немного опасаюсь перезагружаться на этом этапе.