O TwinStrata exigiu o número de iqn do meu clinet. Está localizado aqui:
less /etc/iscsi/initiatorname.iscsi
Uma vez que a mudança do servidor foi feita, reiniciei o serviço iscsi do cliente e pude ver / dev / sda.
Instalei o pacote scsi-target-utils no CentOS e usei-o para realizar uma descoberta. A descoberta me deu uma sessão ativa. Eu reiniciei o serviço iscsi, mas não vejo novos dispositivos (fdisk -l). Eu vejo em / var / log / messages que minha conexão está operacional agora.
Não sei como depurar isso ainda mais. Alguém pode me direcionar para consertar isso?
descoberta:
iscsiadm -m discovery -t sendtargets -p 192.168.0.155
retorna:
192.168.0.155:3260,-1 iqn.2009-02.com.twinstrata:cloudarray:sn-1d07c1b62d4ec8f3
Apenas para verificar se realmente funcionou:
iscsiadm -m session
retorna
tcp: [1] 192.168.0.155:3260,1 iqn.2009-02.com.twinstrata:cloudarray:sn-1d07c1b62d4ec8f3
reiniciando conforme as instruções dizem:
service iscsi restart
saída escrita para / 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
Executou um comando de login:
iscsiadm -m node -T iqn.2009-02.com.twinstrata:cloudarray:sn-1d07c1b62d4ec8f3 -p 192.168.0.155 -l
Nenhum erro, nenhum registro ocorreu.
Em seguida, comparei a saída de "fdisk -l | egrep dev" com a sessão iscsi e sem. Não há diferença. Eu suponho que eu poderia apenas olhar em / etc / mtab. Alguma idéia de como eu posso obter um dispositivo iscsi?
Você precisa fazer o login no destino após a descoberta.
iscsiadm -m node -T iqn.2009-02.com.twinstrata:cloudarray:sn-1d07c1b62d4ec8f3 -p 192.168.0.155:3260 -l
Veja: Configure um sistema como um iniciador iSCSI que monta persistentemente um alvo iSCSI
Como usar destinos iSCSI no Linux
Como posso me conectar ao iSCSI target no console do Linux?
Eu me deparei com uma situação muito semelhante e agradeço as dicas encontradas aqui. No meu caso, eu mudei o IQN no arquivo /etc/iscsi/initiatorname.iscsi e reiniciei o iscsi várias vezes, mas a porca ainda não pôde se conectar.
A resposta para mim foi reiniciar o iscsid (observe o "d"), especificamente, tive que reiniciar o iscsi e o iscsid:
# service iscsi stop
# service iscsid stop
# service iscsid start
# service iscsi start
Eu tive esse mesmo problema. Eu concluiria que é tudo sobre a configuração de destino.
Todas as mensagens de log ficaram boas, exceto que nada foi montado em / dev /. Eu tinha um Windows Server 2012 R2 como alvo e estava tentando fornecer um disco virtual (VHDX) existente para o Ubuntu. O VHDX foi previamente fornecido e usado pelo VMWare ESXi com seu próprio formato VMFS, e parece que o Ubuntu não pode lidar com isso por algum motivo depois que a conexão foi estabelecida. Uma vez que criei um novo disco virtual e um novo alvo para ele com as mesmas configurações, criar uma nova sessão com o iscsiadm finalmente me deu um dispositivo de bloco. Depois de testar outros cenários, percebi que a mesma coisa acontece com os destinos criados a partir de cópias de arquivos VHDX importados como discos virtuais iSCSI. Mas esses são obviamente quebrados, porque estendê-los (eles foram thin provisioned) dá um erro no Gerenciador de Servidores. Então, se um alvo for quebrado de alguma forma, o open-iscsi não lhe dará um dispositivo de bloqueio para ele.
A única solução parece ser refazer toda a configuração (e, sim, não se esqueça de configurar o ID do iniciador na configuração do alvo, conforme indicado na resposta aceita) quando se deparar com este problema.
Apenas como uma nota sobre o que conta como destinos quebrados: Eu finalmente descobri que meu destino estava quebrado, porque os arquivos VHDX em volumes ReFS não podem ser usados se o bit FileIntegrity estiver definido como Enabled = True. Infelizmente, apenas o Hyper-V apresenta um erro ao tentar copiar um arquivo VHD / VHDX para um volume ReFS, mas não o Gerenciador de Servidores na seção de configuração de disco de destino iSCSI. A pasta criada pelo assistente de destino iSCSI para novos discos (chamados iscsivirtualdisks) tem seu bit FileIntegrity configurado como Enable e, portanto, todos os arquivos criados nessa pasta (arquivos VHDX copiados) também terão esse bit definido como Enabled = True. Eu classificaria isso como um bug no Gerenciador de Servidores.
Eu tive esse mesmo problema e acabou sendo um problema de destino.
No meu caso (o alvo era um NetApp) eu tinha esquecido de mapear o grupo de iniciadores para o LUN.