Инициатор iSCSI CentOS имеет сессию, но нет никакого блочного устройства
Это может часто вызываться сервисами, запускаемыми в неправильном порядке после обновления. Иногда запуск сервиса служб удаленных рабочих столов зафиксирует его, но другие времена, там слишком много других сервисов, которые также перестали работать, и перезагрузка требуется.
TwinStrata потребовал номер iqn моего клинета. Он находится здесь:
less /etc/iscsi/initiatorname.iscsi
После изменения сервера я перезапустил клиентскую службу iscsi и увидел /dev/sda.
I had this same issue and it turned out to be a target problem.
In my case (target was a NetApp) I had forgotten to map the initiator group to the LUN.
Вам необходимо войти в систему после обнаружения.
iscsiadm -m node -T iqn.2009-02.com.twinstrata: cloudarray: sn-1d07c1b62d4ec8f3 -p 192.168.0.155:3260 -l
См .: Настроить систему как инициатор iSCSI, который постоянно монтирует цель iSCSI
Как использовать цели iSCSI в Linux
Как я могу подключиться в цель iSCSI из консоли Linux?
Я столкнулся с очень похожей ситуацией и ценю советы, найденные здесь. В моем случае я изменил 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 установлен на Enable, и, следовательно, для всех файлов, созданных в этой папке (файлы VHDX, которые вы копируете туда), этот бит также будет установлен на Enabled = True. Я бы классифицировал это как ошибку в диспетчере серверов.