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)?

Thanks,
Shailesh.

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, dat...@gmail.com 
> <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 open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Reply via email to