Desde hace quizás un mes comencé a tener errores de iscsi y fallas de montaje. Esto coincidió aproximadamente con la actualización del 20.04.3. Tratando de ir al grano, emití los siguientes comandos:
root@cor8910:~# iscsiadm -m descubrimiento -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 descubrimiento -t sendtargets -p readynas1 172.16.0.2:3260,1 iqn.1994-11.com.netgear:readynas1:7f8962cc:ubuntu18.04.5
El resultado anterior es correcto. Sin embargo, al emitir iscsiadm -m node -o show obtengo 4 registros BEGIN RECORD 2.0-874
nodo.nombre = iqn.2011-09.nas-8B-3E-60:thunderbird. . . nodo.conn[0].dirección = 172.16.7.2 nodo.conn[0].puerto = 3260
#finalizar registro #Comenzar registro 2.0-874 node.name = iqn.2011-09.nas-8B-3E-60:vmguests. . node.conn[0].address = readyNAS1 #END RECORD Ese es MALO ya que la dirección de conexión es readyNAS2, no 1, y debe tener un punto decimal BEGIN RECORD 2.0-874
nodo.nombre = iqn.2011-09.nas-8B-3E-60:vmguests. . . node.conn[0].address = 172.16.7.2< br/> node.conn[0].port = 3260
#END RECORD Esto es correcto, pero ¿por qué la dirección tiene puntos decimales y por qué los hosts anteriores eran sinónimos? COMENZAR 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 EL REGISTRO COMENZAR EL REGISTRO 2.0-874
node.name = iqn.1994-11.com.netgear:readynas1:7f8962cc:ubuntu18.04.5 ... node.conn[0].address = readynas1 #end record El último también está bien. No puedo deshacerme de ese registro de nodo incorrecto. El documento que busqué en Google indica un /var/lib/iscsi que ubuntu no tiene.
root@cor8910:~# ls -al /etc/iscsi/nodes/ total 20
drw------- 4 raíz raíz 4096 9 de octubre 15:31 iqn.1994-11.com.netgear:readynas1:7f8962cc:ubuntu18.04.5 drw------- 3 raíz raíz 4096 9 de octubre 15: 31 iqn.2011-09.nas-8B-3E-60:thunderbird
drw------- 4 raíz raíz 4096 9 de octubre 15:31 iqn.2011-09.nas-8B-3E-60:vmguests
Creo que el problema puede haber estado en la subcarpeta predeterminada que moví a un lugar más seguro. Sin embargo, la carpeta Thunderbird todavía no se inicia sesión ni se monta a través de fstab. los demás lo hacen. Una vez iniciado, puedo emitir un iscsiadm para iniciar sesión y montar manualmente el lun de Thunderbird donde apunta el perfil de Thunderbird.
Me gustaría poder corregir lo que esté mal, pero a falta de descubrir lo que está mal, si purgué open-iscsi y lo reinstalé, ¿eso resolvería el problema? ¿Cómo sabe la configuración en el caso de la unidad NAS ultra 4 de Netgear 'readyNAS2' para referirse a ella mediante punto decimal donde el NAS 214 de Netgear 'readyNAS1' está recogiendo el sinónimo del archivo host para su dirección?
Después de haber pensado en los pros y los contras, eliminé iscsiadm y lo reinstalé. En realidad, esto funcionó bien, se encontraron objetivos estáticos y el inicio de sesión se realizó rápidamente. Sin embargo, al reiniciar y después de la reinstalación, el problema volvió a ocurrir y descubrí que hay algo en el inicio que crea los nodos estáticos de manera incorrecta. Según man iscsiadm, el único tipo de descubrimiento es sendtarget, iss. NO ESTÁTICO, sin embargo, parece construirse, usarse y fallar.
Respuesta1
Aparentemente, open-iscsi es muy sensible a qué comandos se emiten y en qué orden se emiten. La clave para resolver esto es conseguir un entorno "virgen" para probar. Creé una máquina virtual con la última versión iso 20.04.3 y procedí para configurar open-iscsi. Como no tenía un /etc/hostsarchivo redefinido en la VM, no había sinónimos para direcciones decimales con puntos. Creo que esto bien pudo haber sido parte del problema.
Probé la secuencia de comandos que se muestran arriba sin éxito. No fracasó, ni siquiera lo intentó. Luego encontré esta URL. Es importante leerlo lenta y cuidadosamente y seguirlo meticulosamente.https://www.hiroom2.com/2018/05/05/ubuntu-1804-open-iscsi-en/Si bien esto se escribió para 18.04, funcionó perfectamente en la VM. Reproduje esos resultados en mi escritorio de "producción" con resultados idénticos.
Preste especial atención en la secuencia de instrucciones a
Si se conectó al destino iSCSI antes de cambiar node.startup a automático, deberá conectarse nuevamente al destino iSCSI después de cambiar node.startup a automático.