Portanto, após a atualização para o CentOS 6.2, aparentemente não consigo mais fazer login em meus destinos iSCSI. Eu tenho várias interfaces em sub-redes diferentes no sistema, e primeiro pensei que tinha a ver com o fato de que eu posso não estar ligando interfaces corretas, o que parece ser o caso quando se olha para o netstat, já que isso está claramente errado: / p>
[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
Em seguida, fui em frente e desativado todos, mas uma interface, e assim como resultado netstat parece estar correto, mas o problema com o login permanece. Tenho certeza de que o alvo nunca vê um pacote, porque não vejo nada por SYN_SENT. Eu sei que o problema está no meu cliente, porque o destino está atendendo vários sistemas, nenhum dos quais é o CentOS 6.2. Neste ponto, estou bastante confiante de que algumas coisas mudaram entre o CentOS 6.0 / 6.1 e 6.2. Então, se alguém tiver algum pensamento ou se deparar com isso, eu gostaria muito de ouvir seus pensamentos.
[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
Saída de ip addr show para as duas interfaces envolvidas:
[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
Atualização 01/06/2012:
Esta questão está ficando ainda mais interessante no dia em que parece. Eu fui algumas semanas atrás e peguei um instantâneo desse sistema antes de atualizar para o 6.2. Eu criei um novo sistema a partir do instantâneo e reconfigurei informações de interface e chaves de host, bem como informações de interface do iniciador iSCSI e do iscsi para corresponder aos novos MACs. Não mudou mais nada.
Depois, tentei me conectar aos meus alvos e sem problemas. Não posso dizer que isso foi inesperado. Em seguida, fui em frente e comparei configurações sysctl de ambos os sistemas e houve diferenças após a atualização, mas nada aparentemente relevante para iSCSI ou IP que poderia contribuir para isso. Eu também notei que, por padrão, agora duas sessões por conexão foram ativadas após a atualização, mas eu mudei de volta para 1 sessão em /etc/iscsi/iscsid.conf.
No sistema problemático, podemos ver que a interface de origem está aparentemente errada, mas mesmo quando desativo a interface 10.10.100, os problemas persistem. Então, embora isso possa ser relevante, não pude validá-lo com certeza. Escusado será dizer que mais pesquisas são necessárias. Algo é claramente diferente entre os lançamentos. O sistema de trabalho está no 6.1, e o não funcionamento é 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
Atualização 01/08/2012:
Acredito que consegui descobrir a resposta para o meu problema. É bastante obscuro e duvido que isso aconteça com qualquer outra pessoa em breve. Acontece que definir iface.iscsi_ifacename e iface.hwaddress no arquivo de configuração de interfaces não é legal. Quando um adiciona manualmente um destino iscsi, como abaixo, todas as configurações do arquivo de configuração da interface são copiadas no arquivo de configuração do nó, que é criado pelo comando abaixo. O resultado são os parâmetros iface.iscsi_ifacename e iface.hwaddress juntos no mesmo arquivo de configuração. Esses parâmetros são aparentemente mutuamente exclusivos, o que não faz exatamente sentido, ou talvez exista um descuido no caminho de código. Talvez eu investigue mais.
# 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
Observe que, abaixo, eu comentei iface.hwaddress e iface.ipaddress , depois dos quais adicionei novamente os destinos, com o mesmo comando acima. Tudo funciona muito bem.
[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
Mais uma vez, as chances de isso acontecer com outra pessoa são quase nulas, então é provável que você perca tempo digitando isso. Mas, se alguém encontrar esse problema, espero que este post ajude.