Sorry. I thought I replied to the original. Basically, iscsiadm is racey. For
the operations you listed, the behavior is not defined.
On Aug 23, 2015, at 11:53 PM, Manish Singh wrote:
> Hi All,
>
> Can anyone reply on above queries?? It will be really helpful if
Hi All,
Can anyone reply on above queries?? It will be really helpful if someone
explains the behavior.
--
You received this message because you are subscribed to the Google Groups
open-iscsi group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
Hi Mike,
Thanks a lot for your response.
I have query regarding the thread-safety of iscsiadm commands:
1 Suppose we run discovery for targets and are deleting the targets in
parallel,
Command1: iscsiadm -m discovery --type sendtargets -p x.x.x.x
Command2: iscsiadm -m node -o
On 08/18/2015 10:55 PM, Manish Singh wrote:
Hi Donald,
As for executing discovery command, the etherent inerfaces need to be up
and running. In our test environment this may not always exists. It may
happen that the etherent interfaces may be dwon during running the
discovery command.
Hi Donald,
As for executing discovery command, the etherent inerfaces need to be up
and running. In our test environment this may not always exists. It may
happen that the etherent interfaces may be dwon during running the
discovery command.
But, as i was investigating more about it. I found
Hello Manish,
No restarting the iSCSI daemon does not update the node files. There are
iscsiadm commands that will do so on the fly.
This is taken from the Dell Tech Report TR1062. Configuring iSCSI and
MPIO for RHEL v5.x. Which is 99% the same for RHEL v6.x.
A search for Dell TR1062