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, [email protected] > <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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
