суббота, 5 февраля 2011 г.

SCSI reservation conflicts

Интересная статья базы знаний – Resolving SCSI reservation conflicts.

Ситуация: группа ВМ стала недоступна (в окне клиента vSphere стали окрашены серым). В первую очередь надо проверить – не потерялось ли хранилище, где эти ВМ располагаются, и если да – то почему.

Что и как проверяем:

1) Какие LUN доступны серверу

esxcfg-scsidevs -c


На выходе получаем что-то вроде:



[root@esx1 log]# esxcfg-scsidevs -c
Device UID Device Type Console Device Size Multipath PluginDisplay Name
eui.2a8b90791004d4a5 Direct-Access /dev/sdc 15000MB NMP image_2
eui.bf5171a8c0712479 Direct-Access /dev/sdd 20000MB NMP LUN_1
eui.cce68068a7c4dae7 Direct-Access /dev/sde 10000MB NMP LUN_3
mpx.vmhba0:C0:T0:L0 Direct-Access /dev/sda 15360MB NMP Local VMware, Disk (mpx.vmhba0:C0:T0:L0)
mpx.vmhba32:C0:T0:L0 CD-ROM /dev/sr0 658MB NMP Local NECVMWar CD-ROM (mpx.vmhba32:C0:T0:L0)


Если LUN не в списке – пробуем rescan. Если не найдется – проверяем доступность путей, самой СХД и настройки презентования этого LUN.





2) Если LUN в списке, но хранилище и ВМ на нем недоступны – проверяем на блокировку LUN, SCSI Reservation конфликт.


Для этого обратимся к файлам журналов



cd /var/log 
cat dmesg
(еще можно глянуть
tail -f /var/log/vmkernel )



Если в этих двух лог-файлах будет присутствовать словосочетание RESERVATION CONFLICT – значит проблему недоступности LUN мы нашли. Ну а рядышком будет указано какой именно LUN или несколько подвержены этой блокировке.



Предлагаемое решение:



Узнать идентификатор VMFS на этом LUN, и сбросить блокировку.



Команда



esxcfg-info | egrep -B16 "s Reserved|Pending"


покажет нам что то вроде:



 |----Name............................................eui.2a8b90791004d4a5
|----External Id.....................................eui.2a8b90791004d4a5
|----Type............................................Direct-Access
|----Vendor..........................................ROCKET
|----Model...........................................IMAGEFILE
|----Revision........................................0001
|----Display Name....................................image_2
|----Path Plugin.....................................NMP
|----Console Device................................../dev/sdc
|----Devfs Path....................................../vmfs/devices/disks/eui.2a8b90791004d4a5
|----Size............................................15728640000
|----Block Size......................................512
|----Number of Blocks................................30720000
|----SCSI Level......................................4
|----Queue Depth.....................................1394632052
|----Is Pseudo.......................................false
|----Is Reserved.....................................false
|----Is Local........................................false
|----Pending Reservations............................0



я выделил интересные нам строки.



Ненулевой Pending Reservations укажет на пробленое хранилище, а Devfs_Path – сообщит идентификатор хранилища.



Далее снимем блокировку:



vmkfstools --lock lunreset vmfs/devices/disks/eui.2a8b90791004d4a5



Затем rescan и все должно стать ок.



Я проверял команды на ESX и ESXi версии 4.1 – вроде бы все работает.

4 комментария:

  1. я так понял, что если на хосте и на массиве активна фича VAAI AcceleratedLocking, то подобной проблемы быт не должно

    ОтветитьУдалить
  2. А если reservation conflict возникает в гостевой ОС?

    ОтветитьУдалить
  3. упоминаемый здесь конфликт - это конфликт обращения к одному LUN нескольких хостов. Притом именно хостов ESX(i), и обращении к LUN c VMFS.
    Для виртуальных машин(гостевых ОС) такая схема работы с хранилищами нехарактерна, так что там если что-то подобное и будет - то совсем по другому поводу.

    ОтветитьУдалить

Примечание. Отправлять комментарии могут только участники этого блога.