It looks like you were right :( iscsid.socket gets activated right after the
yum install. I will re-run our tests to confirm that disabling iscsid.socket
fixes the container's iscsid process and does not break anything else on the
host.
Thank you very much for your help
Serguei
-Original
- Original Message -
> For sure there is no any other iscsd process running. What I could see, that
> even if iscsi-initiator-utils are just installed on the host, the process is
> not active, it still does not work. To make it work it needs to be yum
> removed..
> Is there anything other
For sure there is no any other iscsd process running. What I could see, that
even if iscsi-initiator-utils are just installed on the host, the process is
not active, it still does not work. To make it work it needs to be yum
removed..
Is there anything other than just service starting scripts
- Original Message -
> Hi Chris,
>
> Thank you for your reply. Our iscsid container runs in host namespace as well
> it has visibility to host pids running, and host networking. So in our case
> container looks more like a nice wrapper for iscsd process. Iscsid process
> has full
Hi Chris,
Thank you for your reply. Our iscsid container runs in host namespace as well
it has visibility to host pids running, and host networking. So in our case
container looks more like a nice wrapper for iscsd process. Iscsid process has
full privileged access to the host's components
Hi,
The issue with containers has been that the interface between iscsid and the
kernel is not aware of network namespaces, and will not work if not using the
root/host network. I have a partial fix (kernel patch set) that needs
finishing, making the iSCSI netlink protocol namespace aware and
Hi,
We'd need to know what version of the iSCSI tools you're using, distro vendor
and package version or built from upstream sources.
This should have been fixed about a year ago in the upstream source.
Thanks,
Chris
- Original Message -
> Hi,
> I am running iscsiadm on CentOS 6.6.
> I
