Поэтому после обновления до CentOS 6.2 я, похоже, больше не могу войти в свои цели iSCSI. У меня есть несколько интерфейсов в разных подсетях в системе, и сначала я подумал, что это связано с тем, что я могу не связывать правильные интерфейсы, что, похоже, имеет место при просмотре netstat, поскольку это явно неверно:
[root]⌘ netstat -na|grep .90
tcp 0 1 10.10.100.60:42354 10.10.8.90:3260 SYN_SENT
tcp 0 1 10.10.100.60:40777 10.10.9.90:3260 SYN_SENT
Затем я отключил все интерфейсы, кроме одного, и поэтому netstat кажется правильным, но проблема с входом в систему остается. Я уверен, что цель никогда не видит пакет, потому что я ничего не вижу SYN_SENT. Я знаю, что проблема в моем клиенте, потому что цель обслуживает несколько систем, ни одна из которых не является CentOS 6.2. На данный момент я почти уверен, что некоторые вещи изменились между CentOS 6.0 / 6.1 и 6.2. Так что, если у кого-то есть какие-то мысли, или натолкнулся на это, я бы очень хотел услышать ваши мысли.
[root]⌘ iscsiadm --mode node --targetname iqn.2011-12.dom.homer:01:lab-centos-servers-00001 --portal 10.10.8.90:3260,2 --interface=sw-iscsi-0 --login
Logging in to [iface: sw-iscsi-0, target: iqn.2011-12.dom.homer:01:lab-centos-servers-00001, portal: 10.10.8.90,3260] (multiple)
iscsiadm: Could not login to [iface: sw-iscsi-0, target: iqn.2011-12.dom.homer:01:lab-centos-servers-00001, portal: 10.10.8.90,3260].
iscsiadm: initiator reported error (8 - connection timed out)
iscsiadm: Could not log into all portals
[root]⌘ netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
10.10.8.0 0.0.0.0 255.255.255.0 U 0 0 0 eth2.7
10.10.9.0 0.0.0.0 255.255.255.0 U 0 0 0 eth3.7
10.10.100.0 0.0.0.0 255.255.252.0 U 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth2
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth3
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth2.7
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth3.7
0.0.0.0 10.10.100.1 0.0.0.0 UG 0 0 0 eth0
Выход ip addr show для двух задействованных интерфейсов:
[root]⌘ for i in 2.7 3.7; do ip addr show eth$i; done
6: eth2.7@eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
link/ether 00:0c:29:94:5b:8d brd ff:ff:ff:ff:ff:ff
inet 10.10.8.60/24 brd 10.10.8.255 scope global eth2.7
inet6 fe80::20c:29ff:fe94:5b8d/64 scope link
valid_lft forever preferred_lft forever
7: eth3.7@eth3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
link/ether 00:0c:29:94:5b:97 brd ff:ff:ff:ff:ff:ff
inet 10.10.9.60/24 brd 10.10.9.255 scope global eth3.7
inet6 fe80::20c:29ff:fe94:5b97/64 scope link
valid_lft forever preferred_lft forever
Обновление 01.06.2012:
Кажется, этот вопрос с каждым днем становится все интереснее. Я вернулся несколько недель назад и сделал снимок этой системы до обновления до 6.2. Я создал новую систему из моментального снимка и перенастроил информацию об интерфейсе и ключи хоста, а также информацию об инициаторе iSCSI и интерфейсе iscsi в соответствии с новыми MAC. Больше ничего не менял.
Затем я попытался подключиться к своим целям, и никаких проблем не было. Не могу сказать, что это было неожиданно. Затем я продолжил и сравнил настройки sysctl из обеих систем, и после обновления были различия, но ничего, казалось бы, относящегося к iSCSI или IP, не могло этому способствовать. Я также заметил, что теперь по умолчанию после обновления были включены два сеанса на каждое соединение, но я снова изменил его на 1 сеанс в /etc/iscsi/iscsid.conf.
В проблемной системе мы видим, что исходный интерфейс кажется неправильным, но даже когда я отключаю интерфейс 10.10.100, проблемы сохраняются. Итак, хотя это может быть актуально, я не мог подтвердить это наверняка. Излишне говорить, что необходимы дальнейшие исследования. Что-то явно отличается между релизами. Рабочая система на 6.1, нерабочая на 6.2.
::Working System::
tcp 0 0 10.10.8.210:39566 10.10.8.90:3260 ESTABLISHED
tcp 0 0 10.10.9.210:46518 10.10.9.90:3260 ESTABLISHED
[root]⌘ ip route show
10.10.8.0/24 dev eth2.6 proto kernel scope link src 10.10.8.210
10.10.9.0/24 dev eth3.7 proto kernel scope link src 10.10.9.210
10.10.100.0/22 dev eth0 proto kernel scope link src 10.10.100.210
169.254.0.0/16 dev eth0 scope link metric 1002
169.254.0.0/16 dev eth2.6 scope link metric 1006
169.254.0.0/16 dev eth3.7 scope link metric 1007
default via 10.10.100.1 dev eth0
::Non-working System::
tcp 0 1 10.10.100.60:44737 10.10.9.90:3260 SYN_SENT
tcp 0 1 10.10.100.60:55479 10.10.8.90:3260 SYN_SENT
[root]⌘ ip route show
10.10.8.0/24 dev eth2.6 proto kernel scope link src 10.10.8.60
10.10.9.0/24 dev eth3.7 proto kernel scope link src 10.10.9.60
10.10.100.0/22 dev eth0 proto kernel scope link src 10.10.100.60
169.254.0.0/16 dev eth0 scope link metric 1002
169.254.0.0/16 dev eth2.6 scope link metric 1006
169.254.0.0/16 dev eth3.7 scope link metric 1007
default via 10.10.100.1 dev eth0
And the result is still same:
[root]⌘ iscsiadm: Could not login to [iface: sw-iscsi-0, target: iqn.2011-12.dom.homer:01:lab-centos-servers-00001, portal: 10.10.8.90,3260].
iscsiadm: initiator reported error (8 - connection timed out)
iscsiadm: Could not login to [iface: sw-iscsi-1, target: iqn.2011-12.dom.homer:02:lab-centos-servers-00001, portal: 10.10.9.90,3260].
iscsiadm: initiator reported error (8 - connection timed out)
iscsiadm: Could not log into all portals
Обновление 01.08.2012:
Я считаю, что смог найти ответ на свою проблему. Это довольно неясно, и я сомневаюсь, что это случится с кем-нибудь еще в ближайшее время. Оказывается, установка iface.iscsi_ifacename и iface.hwaddress в файле конфигурации интерфейсов недопустим. Когда кто-то вручную добавляет цель iscsi, как показано ниже, все настройки из файла конфигурации интерфейса копируются в файл конфигурации узла, который создается следующей командой. Результат - параметры iface.iscsi_ifacename и iface.hwaddress вместе в одном файле конфигурации. Эти параметры кажутся взаимоисключающими, что не совсем понятно, или, возможно, в кодовом пути есть недоработка. Возможно, я буду исследовать дальше.
# iscsiadm -m node --op new -T iqn.2011-12.dom.homer:01:lab-centos-servers-00001 -p 10.10.8.90,3260,2 -I sw-iscsi-0
# iscsiadm -m node --op new -T iqn.2011-12.dom.homer:02:lab-centos-servers-00001 -p 10.10.9.90,3260,2 -I sw-iscsi-1
Обратите внимание, ниже я закомментировал iface.hwaddress и iface.ipaddress, после чего я повторно добавил цели той же командой, что и выше. Все работает нормально.
[root]⌘ cat *
# BEGIN RECORD 2.0-872.33.el6
iface.iscsi_ifacename = sw-iscsi-0
iface.net_ifacename = eth2.6
#iface.hwaddress = XX:XX:XX:XX:XX:XX
#iface.ipaddress = 10.10.8.60
iface.transport_name = tcp
iface.vlan_id = 6
iface.vlan_priority = 0
iface.iface_num = 0
iface.mtu = 0
iface.port = 0
# END RECORD
# BEGIN RECORD 2.0-872.33.el6
iface.iscsi_ifacename = sw-iscsi-1
iface.net_ifacename = eth3.7
#iface.hwaddress = XX:XX:XX:XX:XX:XX
#iface.ipaddress = 10.10.9.60
iface.transport_name = tcp
iface.vlan_id = 7
iface.vlan_priority = 0
iface.iface_num = 0
iface.mtu = 0
iface.port = 0
# END RECORD
Опять же, шансы, что это случится с кем-то еще, ничтожно малы, так что, скорее всего, вы потеряете время, набирая это. Но, если кто-то столкнется с этой проблемой, я надеюсь, что этот пост поможет.
Обнаружена та же проблема, но в новой установке CentOS 6.2. Время входа iSCSI истекает после создания моста для KVM через адаптер Ethernet. До этого (без создания моста) iSCSI входил без проблем.
Кажется, iscsiadm пытается подключиться к определенному iface.hwaddress (но их два: интерфейсы eth1 и br1 в моей настройке) и использует eth1. Время соединения истекло.
Удаление iface.hwaddress и добавление iface.net_ifacename (как предлагается) с правильным именем интерфейса (br1) делает свое дело. Задача решена.