You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@crail.apache.org by "David Crespi (JIRA)" <ji...@apache.org> on 2019/03/02 15:15:00 UTC
[jira] [Updated] (CRAIL-93) Using Crail with NVMf, the Default NQN
also attaches the port number to the name.
[ https://issues.apache.org/jira/browse/CRAIL-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Crespi updated CRAIL-93:
------------------------------
Environment: I'm running crail nodes with docker containers, on a Ubuntu 18.04 base. (was: I'm running crail nodes are docker containers, on a Ubuntu 18.04 base.)
Description:
This is the version I'm actually using: v1.1-2-gf0afadc
I'm set up to use spdk on the backend to crail. When attempting to attach, it appears that crail needs two subsystems to achieve the connection.
1) subsystem NQN: nqn.2017-06.io.crail:cnode
2) subsystem NQN: nqn.2017-06.io.crail:cnode4420
19/03/01 17:46:45 INFO crail: CrailHadoopFileSystem fs initialization done..
19/03/01 17:46:45 INFO crail: Connecting to NVMf target at Transport address = /192.168.2.104:4420, subsystem NQN = nqn.2017-06.io.crail:cnode4420
It appears that the initial connect/discovery of the subsystem uses #1, but using the
crail commands (crail fs -mkdir /test) uses #2.
Both have to have a valid namespace attached as well.
It also appears that when using my own subsystem NQN (NVMF_NQN) name, crail wants to generate its own Host NQN. A new one every time. First, how do you learn of that
NQN, and 2nd, it would be great to disable it if spdk has "allow any hosts" set. It refuses
to connect to spdk.
was:
This is the version I'm actually using: v1.1-2-gf0afadc
I'm set up to use spdk at the backend to crail. When attempting to attach, it appears that crail is needed two subsystems to achieve the connection.
1) subsystem NQN: nqn.2017-06.io.crail:cnode
2) subsystem NQN: nqn.2017-06.io.crail:cnode4420
19/03/01 17:46:45 INFO crail: CrailHadoopFileSystem fs initialization done..
19/03/01 17:46:45 INFO crail: Connecting to NVMf target at Transport address = /192.168.2.104:4420, subsystem NQN = nqn.2017-06.io.crail:cnode4420
It appears that the initial connect/discovery of the subsystem uses #1, but using the
crail commands (crail fs -mkdir /test) uses #2.
Both have to have a valid namespace attached as well.
It also appears that when using my own subsystem NQN (NVMF_NQN) name, crail wants to generate its own Host NQN. A new one every time. First, how do you learn of that
NQN, and 2nd, it would be great to disable it if spdk has "allow any hosts" set. It refuses
to connect to spdk.
> Using Crail with NVMf, the Default NQN also attaches the port number to the name.
> ---------------------------------------------------------------------------------
>
> Key: CRAIL-93
> URL: https://issues.apache.org/jira/browse/CRAIL-93
> Project: Apache Crail
> Issue Type: Bug
> Affects Versions: 1.2
> Environment: I'm running crail nodes with docker containers, on a Ubuntu 18.04 base.
> Reporter: David Crespi
> Priority: Critical
>
> This is the version I'm actually using: v1.1-2-gf0afadc
> I'm set up to use spdk on the backend to crail. When attempting to attach, it appears that crail needs two subsystems to achieve the connection.
> 1) subsystem NQN: nqn.2017-06.io.crail:cnode
> 2) subsystem NQN: nqn.2017-06.io.crail:cnode4420
> 19/03/01 17:46:45 INFO crail: CrailHadoopFileSystem fs initialization done..
> 19/03/01 17:46:45 INFO crail: Connecting to NVMf target at Transport address = /192.168.2.104:4420, subsystem NQN = nqn.2017-06.io.crail:cnode4420
> It appears that the initial connect/discovery of the subsystem uses #1, but using the
> crail commands (crail fs -mkdir /test) uses #2.
> Both have to have a valid namespace attached as well.
>
> It also appears that when using my own subsystem NQN (NVMF_NQN) name, crail wants to generate its own Host NQN. A new one every time. First, how do you learn of that
> NQN, and 2nd, it would be great to disable it if spdk has "allow any hosts" set. It refuses
> to connect to spdk.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)