Я установил пакет 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?
TwinStrata потребовал номер iqn моего клиента. Это находится здесь:
less /etc/iscsi/initiatorname.iscsi
Как только произошла смена сервера, я перезапустил клиентскую службу iscsi и увидел / dev / sda.
Я столкнулся с очень похожей ситуацией, и я ценю советы, найденные здесь. В моем случае я изменил IQN в файле /etc/iscsi/initiatorname.iscsi и несколько раз перезапустил iscsi, но все равно не смог подключиться.
Для меня ответом был перезапуск iscsid (обратите внимание на букву «d»), в частности, мне пришлось перезапустить и iscsi, и iscsid:
# service iscsi stop
# service iscsid stop
# service iscsid start
# service iscsi start
После обнаружения вам необходимо войти в систему.
iscsiadm -m node -T iqn.2009-02.com.twinstrata:cloudarray:sn-1d07c1b62d4ec8f3 -p 192.168.0.155:3260 -l
Видеть: Настройте систему как инициатор iSCSI, который постоянно подключает цель iSCSI
Как использовать iSCSI Target в Linux
Как я могу подключиться к цели iSCSI с консоли Linux?
У меня была такая же проблема. Я бы сделал вывод, что все дело в целевой конфигурации.
Все сообщения журнала выглядели хорошо, за исключением того, что ничего не смонтировано в / 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 установлен на Enable, и, следовательно, для всех файлов, созданных в этой папке (файлы VHDX, которые вы копируете туда), этот бит также будет установлен на Enabled = True. Я бы классифицировал это как ошибку в диспетчере серверов.
У меня была такая же проблема, и она оказалась целевой проблемой.
В моем случае (целью было NetApp) я забыл сопоставить группу инициаторов с LUN.