У инициатора CentOS iscsi есть сеанс, но нет блочного устройства
Я установил пакет scsi-target-utils в CentOS и использовал его для обнаружения. Открытие действительно дало мне активный сеанс. Я перезапустил службу iscsi, но не вижу новых устройств (fdisk -l). В / var / log / messages я вижу, что мое соединение сейчас работает.
Я не уверен, как отладить это дальше. Может кто-нибудь направить меня на исправление этого?
открытие:
iscsiadm -m discovery -t sendtargets -p 192.168.0.155
возвращает:
192.168.0.155:3260,-1 iqn.2009-02.com.twinstrata:cloudarray:sn-1d07c1b62d4ec8f3
Просто чтобы убедиться, что это действительно работает:
iscsiadm -m session
возвращается
tcp: [1] 192.168.0.155:3260,1 iqn.2009-02.com.twinstrata:cloudarray:sn-1d07c1b62d4ec8f3
перезапуск, как говорят инструкции сделать:
service iscsi restart
вывод записывается в / var / log / message
Stopping iscsi: Sep 20 12:14:22 localhost kernel: connection1:0: detected conn error (1020)
[ OK ]
Starting iscsi: Sep 20 12:14:22 localhost kernel: scsi1 : iSCSI Initiator over TCP/IP
Sep 20 12:14:22 localhost iscsid: Connection1:0 to [target: iqn.2009-02.com.twinstrata:cloudarray:sn-1d07c1b62d4ec8f3, portal: 192.168.0.155,3260] through [iface: default] is shutdown.
Sep 20 12:14:22 localhost iscsid: Could not set session2 priority. READ/WRITE throughout and latency could be affected.
[ OK ]
[root@db iscsi]# Sep 20 12:14:23 localhost iscsid: Connection2:0 to [target: iqn.2009-02.com.twinstrata:cloudarray:sn-1d07c1b62d4ec8f3, portal: 192.168.0.155,3260] through [iface: default] is operational now
Запустил команду входа в систему:
iscsiadm -m node -T iqn.2009-02.com.twinstrata:cloudarray:sn-1d07c1b62d4ec8f3 -p 192.168.0.155 -l
Нет ошибок, нет регистрации.
Затем я сравнил вывод команды "fdisk -l|egrep dev" как с сеансом iscsi, так и без него. Нет никакой разницы. Я полагаю, я мог бы просто посмотреть в / etc / mtab. Любые идеи о том, как я могу получить устройство iscsi?
5 ответов
TwinStrata требовал номер моей клиники. Это находится здесь:
less /etc/iscsi/initiatorname.iscsi
Как только произошла смена сервера, я перезапустил службу iscsi клиента и увидел /dev/sda.
У меня была такая же проблема, и она оказалась целевой.
В моем случае (целью был NetApp) я забыл сопоставить группу инициатора с LUN.
Я столкнулся с очень похожей ситуацией, и я ценю советы, найденные здесь. В моем случае я изменил IQN в файле /etc/iscsi/initiatorname.iscsi и перезапустил iscsi несколько раз, но гайка все еще не могла подключиться.
Ответом для меня было перезапустить iscsid (обратите внимание на "d"), в частности, мне пришлось перезапустить iscsi и iscsid:
# service iscsi stop
# service iscsid stop
# service iscsid start
# service iscsi start
У меня была такая же проблема. Я бы пришел к выводу, что это все о целевой конфигурации.
Все сообщения журнала выглядели хорошо, за исключением того, что ничего не было установлено в /dev/. У меня была Windows Server 2012 R2 в качестве цели, и я пытался предоставить существующий виртуальный диск (VHDX) для Ubuntu. Этот VHDX ранее был предоставлен и использовался VMWare ESXi в своем собственном формате VMFS, и похоже, что Ubuntu по какой-то причине не может справиться с этим после установления соединения. Как только я создал новый виртуальный диск и новую цель для него с точно такими же настройками, создание нового сеанса с помощью iscsiadm, наконец, дало мне блочное устройство. После тестирования других сценариев я понял, что то же самое происходит с целями, которые создаются из копий файлов VHDX, которые импортируются как виртуальные диски iSCSI. Но они явно не работают, потому что расширение их (они были плохо подготовлены) приводит к ошибке в диспетчере сервера. Так что, если цель как-то сломана, open-iscsi не даст вам блочного устройства для нее.
Кажется, что единственное решение состоит в том, чтобы повторить всю конфигурацию (и да, не забудьте установить идентификатор инициатора в конфигурации цели, как указано в принятом ответе) при возникновении этой проблемы.
Точно так же, как примечание о том, что считается сломанной целью: я наконец обнаружил, что моя цель была сломана, потому что файлы VHDX на томах ReFS не могут использоваться, если их бит FileIntegrity установлен в значение Enabled=True. К сожалению, только Hyper-V выдает ошибку при попытке скопировать файл VHD/VHDX на том ReFS, но не диспетчер серверов в разделе для настройки целевого диска iSCSI. Папка, созданная целевым мастером iSCSI для новых дисков (называемая iscsivirtualdisks), имеет свой бит FileIntegrity, установленный на "Включить", и, следовательно, все файлы, созданные в этой папке (файлы VHDX, которые вы копируете), также получат для этого бита значение "Enabled = True". Я бы классифицировал это как ошибку в диспетчере сервера.
Вам необходимо войти в систему после обнаружения.
iscsiadm -m node -T iqn.2009-02.com.twinstrata:cloudarray:sn-1d07c1b62d4ec8f3 -p 192.168.0.155:3260 -l
См. Настройка системы в качестве инициатора iSCSI, который постоянно монтирует цель iSCSI.
Как использовать iSCSI Targets в Linux
Как я могу подключиться к цели iSCSI из консоли Linux?