Thanks for the reply. Does that mean that we need to disable the iscsid 
running on the host or can they co-exist (one running on the host and other 
running in container)?


On Monday, October 29, 2018 at 10:57:06 AM UTC-7, The Lee-Man wrote:
> On Monday, October 29, 2018 at 10:40:07 AM UTC-7, 
> <javascript:> wrote:
>> Thanks for the reply. We are facing issues when we run iscsiadm in the 
>> container and iscsid on the host. At that time, iscsiadm can't reach to 
>> iscsid at all and all iscsiadm commands fail.
>> If we run iscsiadm and iscsid in the same container, it works but we 
>> don't know if this is how it is designed to run. So few specific questions;
>> 1. If we run iscsid in container, do we need to shut the the iscsid that 
>> is running on host?
>> 2. iscsid running in the container, requires kernel module iscsi_tcp to 
>> be part of the container image. Is this ok?
>> 3. What is the standard topology for dealing with iscsi from 
>> containerized environments?
>> Appreciate your help here.
>> Thanks,
>> Shailesh.
>> You need to run either "iscsid and iscsiadm" or "iscsistart" in each 
> container. The "iscsistart" command is meant to be used as a replacement 
> for the iscsid/iscsiadm pair at startup time.
> Yes, using iscsi_tcp (the iscsi transport) is required. I guess that means 
> it's ok.
> I have no idea about what is standard in a containerized environment for 
> topology. Generally, iscsi doesn't use any directory service (since people 
> don't like iSNS).

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 post to this group, send email to
Visit this group at
For more options, visit

Reply via email to