+7 (495) 320-70-49
- Назад
- Телефоны
- +7 (495) 320-70-49
- Заказать звонок
info@proxmox.su
Москва, Бакунинская улица, 69с1
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

Виртуальные устройства в LVM: ошибки ATA, Proxmox Виртуальная Среда

Darkhunter

Guest

20.10.2015 15:21:00

Привет, у меня есть три Proxmox-сервера, и на некоторых виртуалках появляются ошибки, связанные с ata:
Код:
Oct 19 22:54:07 hsotname kernel: [3699830.334837] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
Oct 19 22:54:07 hsotname kernel: [3699830.417547] ata1.00: failed command: WRITE DMA
Oct 19 22:54:07 hsotname kernel: [3699830.418078] ata1.00: cmd ca/00:08:28:22:80/00:00:00:00:00/e1 tag 0 dma 4096 out
Oct 19 22:54:07 hsotname kernel: [3699830.418078] res 40/00:01:00:00:00/00:00:00:00:00/a0 Emask 0x4 (timeout)
Oct 19 22:54:07 hsotname kernel: [3699830.420693] ata1.00: status: { DRDY }
Oct 19 22:54:07 hsotname kernel: [3699830.424753] ata1: soft resetting link
Oct 19 22:54:07 hsotname kernel: [3699830.580393] ata1.01: NODEV after polling detection
Oct 19 22:54:07 hsotname kernel: [3699830.581356] ata1.00: configured for MWDMA2
Oct 19 22:54:07 hsotname kernel: [3699830.581360] ata1.00: device reported invalid CHS sector 0
Он испорчен? Что можно с этим сделать?

DJSnoopy

Guest

30.12.2015 17:53:00

Привет, команда Proxmox. У нас на Debian 8 таких же ошибки. Конфигурация — qcow2 с LVM внутри виртуальной машины. Код ошибки:

[So Dez 27 05:17:44 2015] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[So Dez 27 05:17:44 2015] ata1.00: failed command: WRITE DMA
[So Dez 27 05:17:44 2015] ata1.00: cmd ca/00:80:b8:4e:ce/00:00:00:00:00/eb tag 0 dma 65536 out res 40/00:01:00:00:00/00:00:00:00:00/a0 Emask 0x4 (timeout)
[So Dez 27 05:17:44 2015] ata1.00: status: { DRDY }
[So Dez 27 05:17:44 2015] ata1: soft resetting link
[So Dez 27 05:17:45 2015] ata1.01: NODEV after polling detection
[So Dez 27 05:17:45 2015] ata1.00: configured for MWDMA2
[So Dez 27 05:17:45 2015] ata1.00: device reported invalid CHS sector 0
[So Dez 27 05:17:45 2015] ata1: EH complete

После этого у нас возникало несколько проблем:
- 9 раз ВМ просто переставала работать, и надо было нажимать сброс или перезагружать по несколько раз, пока она не оживала
- 1 раз был kernel panic после этого

Причём, похоже, поломка не в железе — ведь проблема появляется и после миграции на другой узел. Странно, что все Debian 7 ВМ работают нормально, а ошибка уходит только в последних Debian 8.

pveversion:
proxmox-ve-2.6.32: 3.4-166 (текущий ядро: 2.6.32-43-pve)
pve-manager: 3.4-11 (текущая версия: 3.4-11/6502936f)
pve-kernel-2.6.32-39-pve: 2.6.32-157
pve-kernel-2.6.32-37-pve: 2.6.32-150
pve-kernel-2.6.32-43-pve: 2.6.32-166
lvm2: 2.02.98-pve4
clvm: 2.02.98-pve4
corosync-pve: 1.4.7-1
openais-pve: 1.1.4-3
libqb0: 0.11.1-2
redhat-cluster-pve: 3.2.0-2
resource-agents-pve: 3.9.2-4
fence-agents-pve: 4.0.10-3
pve-cluster: 3.0-19
qemu-server: 3.4-6
pve-firmware: 1.1-5
libpve-common-perl: 3.0-24
libpve-access-control: 3.0-16
libpve-storage-perl: 3.0-34
pve-libspice-server1: 0.12.4-3
vncterm: 1.1-8
vzctl: 4.0-1pve6
vzprocps: 2.0.11-2
vzquota: 3.1-2
pve-qemu-kvm: 2.2-14
ksm-control-daemon: 1.1-1
glusterfs-client: 3.5.2-1

pvperf:
root@server14:/var/lib/vz# pveperf /var/lib/vz
CPU BOGOMIPS: 55203.24
REGEX/SECOND: 946969
HD SIZE: 2605.33 GB (/dev/mapper/pve-data)
BUFFERED READS: 130.43 MB/sec
AVERAGE SEEK TIME: 17.61 ms
FSYNCS/SECOND: 811.25
DNS EXT: 53.06 ms
DNS INT: 50.92 ms

(xxx) vmXXX.conf:
#[hostname]
#[IP]
#
boot: cdn
bootdisk: ide0
cores: 2
ide0: local:110/vm-110-disk-1.qcow2,format=qcow2,cache=writethrough,size=201G
ide2: server16:iso/systemrescuecd-x86-4.6.1.iso,media=cdrom,size=459502K
memory: 4096
name: [FQDN]
net0: e1000=CE:C8:FE:B3:56:F8,bridge=vmbr0,firewall=1
numa: 0
onboot: 1
ostype: l26
smbios1: uuid=d5bc6275-b25a-4523-b927-0d0098a7cb74
sockets: 1

Железо:
AMD Opteron™ Processor 6176, 12 ядер
Supermicro H8SGL
Adaptec 5405Z с ZMCP
2 x HGST HDN724030AL в RAID 1

Всё обновлено до последних версий. У кого-нибудь есть такие же проблемы? Или кто-то уже решил их?
С уважением, Михаил

DJSnoopy

Guest

30.12.2015 23:01:00

И снова полный крах ВМ из-за ошибок хранилища... Нужна помощь, пожалуйста. Код: kernel: [242495.848207] ata1.00: исключение Emask 0x0 SAct 0x0 SErr 0x0 действие 0x6 заморожено
kernel: [242495.849075] ata1.00: неудачная команда: FLUSH CACHE
kernel: [242495.849772] ata1.00: cmd e7/00:00:00:00:00/00:00:00:00:00/a0 tag 0
kernel: [242495.849772] res 40/00:01:00:00:00/00:00:00:00:00/a0 Emask 0x4 (таймаут)
kernel: [242495.851831] ata1.00: статус: { DRDY }
kernel: [242500.892182] ata1: соединение медленно реагирует, пожалуйста, подождите (готов=0)
kernel: [242505.876134] ata1: устройство не готово (errno=-16), принудительный хардрезет
kernel: [242505.876246] ata1: мягкая перезагрузка соединения
kernel: [242506.033244] ata1.00: настроено на MWDMA2
kernel: [242506.033252] ata1.00: повторная попытка FLUSH 0xe7 Emask 0x4
kernel: [242506.033620] ata1.00: устройство сообщил о неверном секторе CHS 0
kernel: [242506.033632] ata1: обработка ошибки завершена
kernel: [255097.832155] ata1.00: исключение Emask 0x0 SAct 0x0 SErr 0x0 действие 0x6 заморожено
kernel: [255097.833034] ata1.00: неудачная команда: FLUSH CACHE
kernel: [255097.833744] ata1.00: cmd e7/00:00:00:00:00/00:00:00:00:00/a0 tag 0
kernel: [255097.833744] res 40/00:01:00:00:00/00:00:00:00:00/a0 Emask 0x4 (таймаут)
kernel: [255097.835810] ata1.00: статус: { DRDY }
kernel: [255102.876126] ata1: соединение медленно реагирует, пожалуйста, подождите (готов=0)
kernel: [255107.860130] ata1: устройство не готово (errno=-16), принудительный хардрезет
kernel: [255107.860153] ata1: мягкая перезагрузка соединения
kernel: [255108.017093] ata1.00: настроено на MWDMA2
kernel: [255108.017113] ata1.00: повторная попытка FLUSH 0xe7 Emask 0x4
kernel: [255108.017537] ata1.00: устройство сообщил о неверном секторе CHS 0
kernel: [255108.017550] ata1: обработка ошибки завершена
kernel: [309438.824333] ata1.00: исключение Emask 0x0 SAct 0x0 SErr 0x0 действие 0x6 заморожено
kernel: [309438.825198] ata1.00: неудачная команда: FLUSH CACHE
kernel: [309438.825921] ata1.00: cmd e7/00:00:00:00:00/00:00:00:00:00/a0 tag 0
kernel: [309438.825921] res 40/00:01:00:00:00/00:00:00:00:00/a0 Emask 0x4 (таймаут)
kernel: [309438.827996] ata1.00: статус: { DRDY }
kernel: [309443.868140] ata1: соединение медленно реагирует, пожалуйста, подождите (готов=0)
kernel: [309448.852147] ata1: устройство не готово (errno=-16), принудительный хардрезет
kernel: [309448.852175] ata1: мягкая перезагрузка соединения
kernel: [309449.009123] ata1.00: настроено на MWDMA2
kernel: [309449.009129] ata1.00: повторная попытка FLUSH 0xe7 Emask 0x4
kernel: [309449.009532] ata1.00: устройство сообщил о неверном секторе CHS 0
kernel: [309449.009545] ata1: обработка ошибки завершена
Это происходит только в ВМ. На хост-системе никаких ошибок нет. С уважением, Майкл

Andre Cunha

Guest

30.08.2016 22:43:00

У меня похожие проблемы (происходят время от времени, я понимаю, что происходит сбой связи с диском (.raw) на NFS-сервере или высокий расход RAM на хосте Proxmox. Иногда виртуальная машина не повреждается, иногда переходит в режим только для чтения, но пару раз система крашилась, и установка, таблица разделов и сами разделы повреждались). В приведённом ниже случае система оставалась в порядке после сбоя (проблем с сетью к NFS-серверу не зафиксировано). Думаю, это баг Proxmox-хоста при высокой загрузке raw-диска (около 90%). Мне нужен способ защитить диск виртуальной машины в таких случаях, чтобы избежать риска повреждения диска.

Код:
# more /etc/debian_version
7.1

Aug 12 19:06:57 drive kernel: [1886649.976714] ata3: жёсткий сброс соединения
Aug 12 19:07:07 drive kernel: [1886659.488315] ata3: SATA-соединение установлено на 1.5 Гбит/с (SStatus 113 SControl 300)
Aug 12 19:07:07 drive kernel: [1886659.496664] ata3.00: настроено для UDMA/100
Aug 12 19:07:07 drive kernel: [1886659.496664] ata3.00: устройство сообщило о недопустимом секторе CHS 0
Aug 12 19:07:07 drive kernel: [1886659.496664] ata3: обработка ошибок завершена
Aug 12 19:07:59 drive kernel: [1886711.779164] ata3: жёсткий сброс соединения
Aug 12 19:08:09 drive kernel: [1886721.948317] ata3: SATA-соединение установлено на 1.5 Гбит/с (SStatus 113 SControl 300)
Aug 12 19:08:09 drive kernel: [1886721.949215] ata3.00: настроено для UDMA/100
Aug 12 19:08:09 drive kernel: [1886721.949215] ata3.00: устройство сообщило о недопустимом секторе CHS 0
Aug 12 19:08:09 drive kernel: [1886721.949215] ata3: обработка ошибок завершена

...

Aug 18 04:55:46 drive kernel: [2353978.632080] ata3: SATA-соединение установлено на 1.5 Гбит/с (SStatus 113 SControl 300)
Aug 18 04:55:46 drive kernel: [2353978.635310] ata3.00: настроено для UDMA/100
Aug 18 04:55:46 drive kernel: [2353978.635310] ata3.00: устройство сообщило о недопустимом секторе CHS 0
(повторяется несколько раз)
Aug 18 04:55:46 drive kernel: [2353978.635310] ata3: обработка ошибок завершена
Aug 18 05:00:31 drive kernel: [2354263.845084] ata3: жёсткий сброс соединения
Aug 18 05:05:31 drive kernel: [2354520.808093] Загруженные модули: nfsd nfs nfs_acl auth_rpcgss fscache lockd sunrpc loop snd_pcm snd_page_alloc snd_timer i2c_piix4 snd soundcore i2c_core processor psmouse evdev serio_raw joydev pcspkr thermal_sys button ext4 crc16 jbd2 mbcache usbhid hid sd_mod crc_t10dif sg sr_mod cdrom uhci_hcd ehci_hcd usbcore ata_generic ahci libahci e1000 floppy usb_common ata_piix libata scsi_mod [последний выгруженный: scsi_wait_scan]
...
Aug 18 05:05:31 drive kernel: [2354263.856067] [<ffffffffa003e911>] ? sata_link_resume+0x57/0x132 [libata]
Aug 18 05:05:31 drive kernel: [2354263.856067] [<ffffffffa0042533>] ? sata_link_hardreset+0x101/0x1bd [libata]
Aug 18 05:05:31 drive kernel: [2354263.856067] [<ffffffffa0049007>] ? ata_eh_reset+0x3ed/0x9bf [libata]
Aug 18 05:05:31 drive kernel: [2354263.856067] [<ffffffffa00499ac>] ? ata_eh_recover+0x2c6/0xfde [libata]
Aug 18 05:05:31 drive kernel: [2354263.856067] [<ffffffffa004262d>] ? sata_std_hardreset+0x3e/0x3e [libata]
Aug 18 05:05:31 drive kernel: [2354263.856067] [<ffffffffa004e848>] ? sata_pmp_error_handler+0x9d/0x7ef [libata]
Aug 18 05:05:31 drive kernel: [2354263.856067] [<ffffffffa004a991>] ? ata_scsi_port_error_handler+0x232/0x53d [libata]
Aug 18 05:05:31 drive kernel: [2354263.856067] [<ffffffffa0046dab>] ? ata_scsi_cmd_error_handler+0xdd/0x116 [libata]
Aug 18 05:05:31 drive kernel: [2354263.856067] [<ffffffffa004ad28>] ? ata_scsi_error+0x8c/0xb5 [libata]
Повторяется несколько раз
...
Aug 18 05:05:31 drive kernel: [2354563.492100] Загруженные модули: nfsd nfs nfs_acl auth_rpcgss fscache lockd sunrpc loop snd_pcm snd_page_alloc snd_timer i2c_piix4 snd soundcore i2c_core processor psmouse evdev serio_raw joydev pcspkr thermal_sys button ext4 crc16 jbd2 mbcache usbhid hid sd_mod crc_t10dif sg sr_mod cdrom uhci_hcd ehci_hcd usbcore ata_generic ahci libahci e1000 floppy usb_common ata_piix libata scsi_mod [последний выгруженный: scsi_wait_scan]
Aug 18 05:05:31 drive kernel: [2354563.721396] ata3: SATA-соединение установлено на 1.5 Гбит/с (SStatus 113 SControl 300)
Aug 18 05:05:31 drive kernel: [2354563.724761] ata3.00: настроено для UDMA/100
Aug 18 05:05:31 drive kernel: [2354563.724761] ata3.00: устройство сообщило о недопустимом секторе CHS 0 (несколько раз)
Aug 18 05:05:31 drive kernel: [2354563.724761] ata3: обработка ошибок завершена

В другом случае, на одной виртуальной машине с debian 8.5 система полностью крашнулась, при этом ВМ осталась онлайн, но разделы стали доступными только для чтения. После перезагрузки ВМ таблица разделов и сами разделы потерялись. Пришлось переустанавливать систему.

Вопрос: как это решить? Или хотя бы как не допустить повреждения дисков в таких случаях?

С уважением, Андрей

zedicus

Guest

06.04.2017 17:36:00

Эта самая проблема до сих пор актуальна даже в Proxmox 4.4. Однако обходной путь с переносом Debian-виртуальной машины с LVM-хранилища действительно «решает» проблему. Я перешёл с RAID 5 на два зеркальных массива, чтобы иметь возможность создавать разные типы хранилищ для ВМ. Поскольку это происходит только в очень специфическом случае, я не думаю, что Proxmox (или Debian) когда-либо займутся этой проблемой.

David Harvey

Guest

06.04.2017 21:29:00

Привет, zedicus и все остальные,
Знаете ли вы, вызывает ли такое же поведение LVM под файловой системой (в отличие от прямого доступа через proxmox)? Мне кажется, я заметил то же самое на Ubuntu VM после переустановки на 5beta и изменения настроек хранения, как описано ниже. По сути, я изменил слишком много вещей сразу, чтобы можно было сразу понять, в чём причина.

Было: 4.2 Swraid/md0 /luks /ext4/точка_монтажа/VM
Стало: 5beta Hwraid/sdb/luks/lvm vg /lv/ext4/точка_монтажа/VM (там я и заметил ошибку)

За ночь я просто перешёл к тому, что считал более разумным: Hwraid/sdb/luks/lvm vg/VM. Посмотрим, поможет ли, но по твоему посту меня это вряд ли утешит. Завтра, наверное, попробую сменить контроллер гостевого диска (SCSI -> SATA) — ради науки.

Я надеялся перейти к Lv/drbd/lvm VG/VM, но это еще более на LVM завязанная схема!

Кто-нибудь, кто это читает, сталкивался с этим и знает обходные пути или распространённые причины такого поведения?

zedicus

Guest

07.04.2017 17:14:00

Я тестировал только прямое подключение LVM к Proxmox. Однако я ТЩАТЕЛЬНО проверял LVM с Proxmox и пробовал менять всё — от типа диска, который видела виртуальная машина, до физических жестких дисков, на которых располагался LVM. И хотя кое-что казалось полезным, проблема всё равно оставалась. Странно, что если LVM был почти в простое, виртуальная машина с Debian не показывала никаких проблем. Проблемы начинались только тогда, когда на LVM начиналась активность (например, восстановление резервной копии виртуальной машины). В этот момент Debian VM, работающая на LVM, начинала глючить и в итоге становилась непригодной для работы.

У меня были некоторые проблемы с версией 5 beta, но я недостаточно тестировал, чтобы точно сказать, связана ли она с этой же проблемой. Как только я начал замечать странности в 5 beta, я откатился к ветке 4.x, так как у меня был ограниченный срок, но я хотел хотя бы посмотреть, что изменилось в 5 beta.

Моё временное решение — небольшой полностью отдельный диск с файловой системой, смонтированной в Proxmox как папка. Пробросить его в Proxmox как директорию и поставить Debian туда. Понимаю, что это не идеально, и этот диск вовсе не имеет отказоустойчивости в отличие от аппаратного RAID 5, на котором стоит LVM. Но, как я уже говорил, мой срок подходил к концу, и нужно было что-то делать.

Надеюсь, теперь, когда система работает, я смогу продолжить тесты с LVM и разработать план миграции для старых Debian-инсталляций, которые у меня есть.

zedicus

Guest

27.09.2017 23:59:00

Итак, я наконец-то занялся диагностикой этой проблемы. Хотя, скорее всего, большинству это уже не особо важно. Но баг по-прежнему воспроизводится даже на актуальной версии 4.4.

Итак, что и почему. Как уже говорилось, в виртуальных машинах на LVM напрямую появляются ATA ошибки (причём не всегда одни и те же ошибки). При этом никакого эффекта не даёт смена кэша, ядра, которое использует ВМ, и я даже перекручивал настройки хоста, прежде чем добраться до сути.

Если на диски, на которых размещён LVM, идёт достаточно высокая нагрузка, и ВМ подключается к этому LVM через SATA-драйвер, то ВМ начинает считать, что диск работает медленно или не отвечает, и генерирует ATA ошибки — как если бы на физическом ПК была плохая или плохо подключённая дата-лінія или какая-то другая прерывистая проблема.

Да, знаю, зачем вообще использовать LVM и назначать гостевой ОС SATA вместо VirtIO? Ну, при восстановлении это требует дополнительных действий, да и некоторые ядра (уже древние по современным меркам) не очень дружат с VirtIO. В некоторых гостевых системах можно назначить IDE-устройство — и это работает. Например, WinXP отлично шел на LVM при назначении диска как IDE.

Кстати, использование VirtIO не решает проблему полностью, но драйвер VirtIO в гостевой ОС способен справиться с «зависанием» и выдаст ошибку таймаута задачи. И это нормально, потому что это не уничтожит файловую систему, как постоянные ATA ошибки в Linux.

Если у вас LVM настроен, и вы назначаете SATA-диски ВМ без проблем, это не значит, что у вас какой-то волшебный инсталлятор или я где-то ошибся — просто вы ещё не создали такую нагрузку, чтобы ВМ ушла в таймаут по виртуальной шине.

Мне пришлось придумать тест, при котором и хост, и ВМ одновременно грузят одни и те же диски под запись на 100% на достаточно длительное время (от 15 минут до более двух часов), чтобы вызвать ошибки и надёжно воспроизвести проблему.

Короче говоря, если у вас LVM, подключённый напрямую к хосту, всё, что на нём лежит, должно быть через VirtIO. Если нужно, чтобы ВМ использовали SATA, IDE или другой вариант подключения диска, то следует создать файловую систему отдельно и пробросить её в Proxmox как каталог.

Надеюсь, кому-то это ещё пригодится. (Кстати, некоторые пользователи создают впечатление, что проблема касается только Debian. Но я могу показать, что у большинства ОС есть эта проблема, просто у Debian она проявляется гораздо ярче и заметнее, чем у Windows или других версий Linux и BSD.)

manu

Guest

03.10.2017 10:20:00

Хороший анализ! Тайм-ауты при выполнении команд WRITE DMA привели к тому, что ядро переключило смонтированный том в режим "только для чтения" (что потребовало перезагрузки), или же у вас просто зависла виртуальная машина?

troycarpenter Guest	#10 0 03.10.2017 22:19:00 Хорошая работа. У меня была похожая проблема. Сейчас я перехожу на хранилище ceph, потому что точно не понимал, в чем именно была причина проблемы.

zedicus Guest	#11 0 26.11.2017 05:58:00 Нет, это никогда не приводило к переходу гостевой системы в режим только для чтения. Проблема постепенно разрушала файловую систему гостя, пока тот не переставал загружаться. Мне было интересно, не решит ли проблему использование ceph или даже ZFS. Но я считал, что это добавит лишние уровни, поэтому никогда не рассматривал их как решение этой проблемы.

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры