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
> 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.