Há talvez um mês, comecei a ter erros de iscsi e falhas de montagem. Isso coincidiu aproximadamente com a atualização de 20.04.3. Tentando ir direto ao ponto, emiti os seguintes comandos:
root@cor8910:~# iscsiadm -m descoberta -t sendtargets -p readynas2 172.16.7.2:3260,1 iqn.2011-09.nas-8B-3E-60:thunderbird 172.16.7.2:3260,1 iqn.2011-09 .nas-8B-3E-60:vmguests
root@cor8910:~# iscsiadm -m descoberta -t sendtargets -p readynas1 172.16.0.2:3260,1 iqn.1994-11.com.netgear:readynas1:7f8962cc:ubuntu18.04.5
A saída acima está correta. No entanto, ao emitir iscsiadm -m node -o show recebo 4 registros BEGIN RECORD 2.0-874
node.name=iqn.2011-09.nas-8B-3E-60:thunderbird . . . node.conn[0].endereço = 172.16.7.2 node.conn[0].porta = 3260
#end record #Begin record 2.0-874 node.name = iqn.2011-09.nas-8B-3E-60:vmguests . . node.conn[0].address = readyNAS1 #END RECORD Esse é RUIM porque o endereço de conexão é readyNAS2 e não 1 e deve ser pontilhado decimal BEGIN RECORD 2.0-874
node.name=iqn.2011-09.nas-8B-3E-60:vmguests . . . node.conn[0].address = 172.16.7.2< br/> node.conn[0].port = 3260
#END RECORD Este está correto, mas por que o endereço é decimal com pontos e por que os hosts anteriores eram sinônimos? INICIAR REGISTRO 2.0-874
node.name = iqn.1994-11.com.netgear:readynas1:7f8962cc:ubuntu18.04.5 ... node.conn[0].address = 172.16.0.2 FINALIZAR REGISTRO COMEÇAR REGISTRO 2.0-874
node.name = iqn.1994-11.com.netgear:readynas1:7f8962cc:ubuntu18.04.5 ... node.conn[0].address = readynas1 #end record O último também está bom. Não consigo me livrar daquele registro de nó incorreto. O documento que pesquisei no Google indica um /var/lib/iscsi que o Ubuntu não possui.
root@cor8910:~# ls -al /etc/iscsi/nodes/ total 20
drw------- 4 root root 4096 9 de outubro 15:31 iqn.1994-11.com.netgear:readynas1:7f8962cc:ubuntu18.04.5 drw------- 3 root root 4096 9 de outubro 15: 31 iqn.2011-09.nas-8B-3E-60:thunderbird
drw ------- 4 root root 4096 9 de outubro 15:31 iqn.2011-09.nas-8B-3E-60:vmguests
Acho que o problema pode estar na subpasta defaults, que movi para um local mais seguro. No entanto, a pasta Thunderbird ainda não foi logada e montada via fstab. os outros fazem. Uma vez inicializado, posso emitir um iscsiadm para fazer login em todos e montar manualmente o Thunderbird lun onde o perfil do Thunderbird está apontando para ele.
Eu gostaria de poder corrigir o que está errado, mas na ausência de descobrir o que está errado, se eu limpasse o open-iscsi e o reinstalasse, isso resolveria o problema? Como a configuração sabe, no caso da unidade NAS ultra 4 da Netgear 'readyNAS2', como se referir a ela por decimal pontilhado, onde o NAS 214 da Netgear 'readyNAS1' está selecionando o sinônimo do arquivo host para seu endereço?
Depois de pensar nos prós/contras, limpei o iscsiadm e reinstalei-o. Na verdade, isso funcionou bem, alvos estáticos foram encontrados e o login ocorreu rapidamente. No entanto, após a reinicialização, após a reinstalação, o problema ocorreu novamente e descobri que há algo na inicialização que cria os nós estáticos incorretamente. De acordo com man iscsiadm o único tipo de descoberta é sendtarget, arens. SEM ESTÁTICA, mas parece construir, usar e falhar.
Responder1
Aparentemente, o open-iscsi é muito sensível a quais comandos são emitidos e em que ordem eles são emitidos. A chave para descobrir isso é obter um ambiente 'virgem' para testar. para configurar o iscsi aberto. Como não tinha um /etc/hostsarquivo redefinido na VM não havia sinônimos para endereços decimais pontilhados. Acho que isso pode muito bem ter sido parte do problema.
Tentei a sequência de comandos descrita acima sem sucesso. Não falhou, nem tentou. Então me deparei com este URL. É importante lê-lo devagar e com atenção e segui-lo meticulosamente.https://www.hiroom2.com/2018/05/05/ubuntu-1804-open-iscsi-en/Embora tenha sido escrito para 18.04, funcionou perfeitamente na VM. Reproduzi esses resultados em minha área de trabalho de 'produção' com resultados idênticos.
Preste atenção especial na sequência de instruções para
Se você se conectou ao destino iSCSI antes de alterar node.startup para automático, será necessário conectar-se ao destino iSCSI novamente após alterar node.startup para automático.