startup setting lost on rediscovery
nolan
I'm working with build 754 on RHEL5 and have some issues. I'm new to
open-iscsi.
After I set the startup value of a node to automatic and do a
sendtargets discovery (on the same portal) again, the node startup
setting gets switched back to the original value.... manual. Is this
as expected or am I doing something wrong somewhere. Is this a bug? Is
a fix available?
Thanks,
Nolan.
Mike Christie
How are you setting the node value? When you do discovery, iscsiadm will
read the values in iscsid.conf and overwrite the existing node values
(the values in /etc/iscsi/nodes or /var/lib/nodes). So if you set the
iscsid.conf value then it should get picked up when you do discovery. If
you set the nodes db value by doing:
iscsiadm -m node -T targetname --op update -n node.conn[0].startup -v
automatic
then reran discovery, the value you had just set with iscsiadm is going
to get reset to the iscsid.conf value.
nolan
Hi Mike,
Ok. How about the fact the startup methods might be different for
various nodes and we wouldn't want them to be overwritten (to the
common one in iscsid.conf,) since some nodes might need to be logged
in while booting, by the initd startup scripts. This also holds good
for CHAP settings? Are we forcing a common authentication method =
CHAP and CHAP username/password accross all nodes?
So, assuming that I've set some nodes to automatic startup mode
(default is manual), (and also some have CHAP usernames/passwords
etc,) then, on a discovery, all my settings would get overwritten and
any node that was booting earlier would not be able to boot again.
So I think a better way to go would be, to pick up the default values
from the iscsi.d scripts but leave the node values that were changed,
untouched. If someone has changed something then they know how to
change it back or they can simply to a delete of the node and
rediscovery to get default settings back.
Also for any change to iscsid.conf the new default settings will take
place only for newer discovery nodes... not the ones already present
in the DB, which is exactly what it means... i.e. the default settings
to use if one is already NOT present.
Any thoughts? I can work on a patch if needed.
Thanks,
Nolan.
Mike Christie
If I understand you right it is either a pain in the butt or ok. If a
session is running then we do not reset those values being used by the
session. We only reset the node db values, so on a later iscsiadm login
command they would be used.
> for CHAP settings? Are we forcing a common authentication method =
> CHAP and CHAP username/password accross all nodes?
No. So the above means we are just forcing people to reset the values
after they have done rediscovery :)
>
> So, assuming that I've set some nodes to automatic startup mode
> (default is manual), (and also some have CHAP usernames/passwords
> etc,) then, on a discovery, all my settings would get overwritten and
> any node that was booting earlier would not be able to boot again.
It would be able to boot again if you set the values again :) And if you
are actually logged in, then we do not reset the values that the session
is currently using. Just the db ones. So I mean we do not have a resync
a running session from new values capability yet so the new values are
not picked up and used by a running session.
But if you are going to say having to reset your values sucks, I will
agree with you there.
>
> So I think a better way to go would be, to pick up the default values
> from the iscsi.d scripts but leave the node values that were changed,
> untouched. If someone has changed something then they know how to
> change it back or they can simply to a delete of the node and
> rediscovery to get default settings back.
>
> Also for any change to iscsid.conf the new default settings will take
> place only for newer discovery nodes... not the ones already present
> in the DB, which is exactly what it means... i.e. the default settings
> to use if one is already NOT present.
Yeah, that is fine. Too bad you did not ask about this a month ago. It
would have been a lot easier :) I asked on the list if they wanted this
and no one responded. So when I did the code to clear out old values,
since we overwrite the old ones, I just blew away all of them and
rewrote the new values.
So if you are looking for place to start to add this functionality you
are talking about look here:
/*
* we got a response so clear out the current
* db values
*
* TODO: should we make whether rm the current
* values configurable (maybe a --clear option)
*/
in discovery.c
As you can see from the code, I actually proposed that we pass in a new
argument to the discovery command. Something like
iscsiadm -m discovery -t st -p my_portal --clear
We actually probably want the reverse so we do not mess up users
expecting the old behavior. If no argument is passed in then we do the
old behavior and overwrite values with iscsid.conf ones. If the new
argument is passed in then we do not overwrite the old values.
Mike Christie
> Yeah, that is fine. Too bad you did not ask about this a month ago. It
> would have been a lot easier :) I asked on the list if they wanted this
> and no one responded. So when I did the code to clear out old values,
> since we overwrite the old ones, I just blew away all of them and
> rewrote the new values.
>
> So if you are looking for place to start to add this functionality you
> are talking about look here:
> /*
> * we got a response so clear out the current
> * db values
> *
> * TODO: should we make whether rm the current
> * values configurable (maybe a --clear option)
> */
> in discovery.c
>
> As you can see from the code, I actually proposed that we pass in a new
> argument to the discovery command. Something like
>
> iscsiadm -m discovery -t st -p my_portal --clear
>
> We actually probably want the reverse so we do not mess up users
> expecting the old behavior. If no argument is passed in then we do the
> old behavior and overwrite values with iscsid.conf ones. If the new
> argument is passed in then we do not overwrite the old values.
>
Actually, maybe we can make this a little more generic and easier for
the user but harder to code :)
We could do something like
iscsiadm -m discovery -t st -p ip:port --sync=[DB | SESSION]
DB - sync iscsid.conf with node db values (basically what we do today)
SESSION - this would sync the DB and then have any running session that
is affected also use the new values.
iscsiadm -m node -T my_target -p ... --sync=[DB | SESSION]
DB - sync a node db record with iscsid.conf values (basically a
--op=delete then a --op=new)
SESSION - have running session use new db values (basically a relogin
with the new values).
So the above is a little confusing as to what values to what when, so
hopefully you can give some comments on what would work best.
nolan
> hopefully you can give some comments on what would work best.- Hide quoted text -
>
> - Show quoted text -
Hi Mike,
Ok. But tell me something, what about the users expecting the old
behavior. This change would fail for them right?
Hence, how about another option, --sync=[None|DB|Session]
--sync=None - will not update the DBM
--sync=DB - will update node rec for all nodes of that portal (same as
not providing the --sync option today)
--sync=Session - will update the current session, (but do we want to
relogin? I think we should leave that to the user, don't you? So I
think it's better if we just ptovide the first 2 options. Let the user
change a node setting, log out and log in to the node, to take effect)
By the way, for a session, where are the settings stored? They utilise
the same settings as the node being used, right? Also, I've noticed
that, we can have sessions running and delete their node recs, and in
that case, when we ask for details about a session (iscsiadm -m
session -r 0) we do not get anything. Is this a defect? Are we not
storing the session settings somewhere? How to get those?
I can work on the new options and send a patch for you to test and
checkin. This will be my first contribution to the community. Is that
ok?
--
I'm unable to get access to the svn repository, svn says that the
server cannot be found. I'm on windows, and can access the svn
repository through the browser.
I've tried:
D:\open-iscsi-trunk>svn checkout http://svn.berlios.de/svnroot/repos/open-iscsi/
trunk
svn: PROPFIND request failed on '/svnroot/repos/open-iscsi/trunk'
svn: PROPFIND of '/svnroot/repos/open-iscsi/trunk': could not connect
to server
(http://svn.berlios.de)
D:\open-iscsi-trunk>svn checkout svn://svn.berlios.de/open-iscsi/trunk
svn: Can't connect to host 'svn.berlios.de': A connection attempt
failed because
the connected party did not properly respond after a period of time,
or establi
shed connection failed because connected host has failed to respond.
Also, I'm working on a small tool similar to the Microsoft Initiator
GUI that will work with the iscsiadm to get information. Does the
group have plans for such a GUI? Also, I think we should drive towards
a C/C++ API set for the initiator. What are the thoughts on that?
-Nolan.
Mike Christie
Yeah, what I wrote above does not cover everything. We would have to do
this in a way that keeps the old behavior for other users so it would be
reverse.
>
> Hence, how about another option, --sync=[None|DB|Session]
>
> --sync=None - will not update the DBM
> --sync=DB - will update node rec for all nodes of that portal (same as
> not providing the --sync option today)
> --sync=Session - will update the current session, (but do we want to
> relogin? I think we should leave that to the user, don't you? So I
I am not sure what you mean by we would update the session but not
relogin? If you mean just update the values being used by the running
session in the kernel but not use them until we look at them again
(which would be when there is an error and we relogin), then that is
probably not so useful. Users want what they had with linux-iscsi where
they could change a value then have the running session use it right away.
> think it's better if we just ptovide the first 2 options. Let the user
> change a node setting, log out and log in to the node, to take effect)
So the reason that we want to be able to grab new params and sync up a
session without having to do a login and logout command is because the
devices accessed through a session would be destroyed when you do a
logout command. That means if you had a FS mounted, to just pick up new
settings you have to unmount the FS, logout, login, and remount. In
sync=Session mode, we would grab the new params, block the session
(quiesce the session IO temporarily), relogin with the new params, then
unblock the session and so upper layers would not see any disruption in
service (well they would see IO take a little longer) if we just wanted
to use some new values.
> By the way, for a session, where are the settings stored? They utilise
> the same settings as the node being used, right? Also, I've noticed
> that, we can have sessions running and delete their node recs, and in
> that case, when we ask for details about a session (iscsiadm -m
> session -r 0) we do not get anything. Is this a defect? Are we not
> storing the session settings somewhere? How to get those?
So we have what open-iscsi calls node values which you can see when you do
iscsiadm -m node -T my_target -p ip:port
These are the values stored in the db (/etc/iscsi/nodes/). When you do a
login command, iscsiadm reads those values and uses them to login. So
for example it reads the MaxRecvDataSegmentLength or Chap values from
the node db, then uses them to create a session. The session is then
what is running in the kernel and logged into some target and is what we
access /dev/sda through.
So then we have session mode which you can see when you do
iscsiadm -m session
These are the values currently being used for the session. So if for
exaxmple we had MaxRecvDataSegmentLength = 128K in the node db, but the
target made us negotiate for only 64K you would see the value we are
using/negotiated. Also for session mode, I am working on displaying both
the requested and negotiated values. That is not done yet.
iscsiadm -m session -r ID
is then a weird case where people wanted to be able to get the node
record info for a running session in one nice and easy command. For
example some apps wanted to traverse sysfs and then get the node record
for a running session then use it for something like the boot info. So
if you delete the node record, and run that command you do not get what
you want.
>
> I can work on the new options and send a patch for you to test and
> checkin. This will be my first contribution to the community. Is that
> ok?
that is fine. I was going to say if you want I would do it for you if
you tell me what you want and would test. But if you want to hack on it
that would be cool.
>
> --
> I'm unable to get access to the svn repository, svn says that the
> server cannot be found. I'm on windows, and can access the svn
> repository through the browser.
>
> I've tried:
>
> D:\open-iscsi-trunk>svn checkout http://svn.berlios.de/svnroot/repos/open-iscsi/
> trunk
> svn: PROPFIND request failed on '/svnroot/repos/open-iscsi/trunk'
> svn: PROPFIND of '/svnroot/repos/open-iscsi/trunk': could not connect
> to server
> (http://svn.berlios.de)
>
> D:\open-iscsi-trunk>svn checkout svn://svn.berlios.de/open-iscsi/trunk
> svn: Can't connect to host 'svn.berlios.de': A connection attempt
> failed because
> the connected party did not properly respond after a period of time,
> or establi
> shed connection failed because connected host has failed to respond.
>
Not sure about that. I think you may just want to do
svn checkout svn://svn.berlios.de/open-iscsi
you do not want the repos or trunk in the path.
A lot of times berili is flakey. If you follow their svn instructions
and it does not work let me know.
> Also, I'm working on a small tool similar to the Microsoft Initiator
> GUI that will work with the iscsiadm to get information. Does the
> group have plans for such a GUI? Also, I think we should drive towards
On the GUI, people had worked on it but dropped off. Distros are mostly
doing their own thing. For exmaple suse has yast2 support, and Red Hat
has or is adding something to I think it is called Conga which I think
may be a little more generic in that it was to be used for LVM, gfs and
other storage management but I am not 100% sure on that. You should to
some searching on google.
> a C/C++ API set for the initiator. What are the thoughts on that?
>
IMA? There has been interest in that and some people had been working on
making a open-iscsi plugin. I guess if those people are on the list, it
would be nice time to pop in. If they do not and you want to work on it
let me know and I will forward you to them.
nolan
I basically want the sync feature where I could continue to have the
node settings and not have them overwritten through --sync=None.
That's all I want for now. --sync=Node is already the default, and --
sync=Session would be a little difficult to code right now.
I'm new to the code, and it would make sense that you take up this
initiative and make the code changes, and let me know when the new
release will be available.
I'm still having trouble checking out the latest code : - (
Can I write to anyone about this at svn.berlios.de?
- Nolan.
> > D:\open-iscsi-trunk>svn checkouthttp://svn.berlios.de/svnroot/repos/open-iscsi/
> let me know and I will forward you to them.- Hide quoted text -
>
> - Show quoted text -- Hide quoted text -
nolan
I didn't get a reply to this email. And I still have issues with
downloading the latest code.
-Nolan
Mike Christie
> Hi Mike,
>
> I didn't get a reply to this email. And I still have issues with
> downloading the latest code.
>
Sorry, busy at work.
> -Nolan
>
>
> On Jun 1, 3:51 pm, nolan <nolandso...@gmail.com> wrote:
>> Mike,
>>
>> I basically want the sync feature where I could continue to have the
>> node settings and not have them overwritten through --sync=None.
>> That's all I want for now. --sync=Node is already the default, and --
>> sync=Session would be a little difficult to code right now.
>>
>> I'm new to the code, and it would make sense that you take up this
>> initiative and make the code changes, and let me know when the new
>> release will be available.
I can do this. We will try to do it for the next release. I am trying to
finish testing on what we have so I can release what is in svn right now.
>>
>> I'm still having trouble checking out the latest code : - (
>> Can I write to anyone about this at svn.berlios.de?
>>
I have no idea.
nolan
This is regarding the modified startup settings (in general any
settings such as CHAP, etc) on a node getting lost when a rediscovery
is being done, see the original thread.
Will you be working on this anytime soon? By when can this be made
available? That would be nice!
Summary:
--sync=Node - sync settings with node... already the default
--sync=Session - syncs settings into a session
--sync=None - does not sync settings at all
-Nolan.
On Jun 7, 9:34 pm, Mike Christie <micha...@cs.wisc.edu> wrote:
> nolan wrote:
> > Hi Mike,
>
> > I didn't get a reply to this email. And I still have issues with
> > downloading the latest code.
>
> Sorry, busy at work.
>
> > -Nolan
>
> > On Jun 1, 3:51 pm, nolan <nolandso...@gmail.com> wrote:
> >> Mike,
>
> >> I basically want the sync feature where I could continue to have the
> >> nodesettingsand not have them overwritten through --sync=None.
> >>>settingsyou have to unmount the FS, logout, login, and remount. In
> >>> sync=Session mode, we would grab the new params, block the session
> >>> (quiesce the session IO temporarily), relogin with the new params, then
> >>> unblock the session and so upper layers would not see any disruption in
> >>> service (well they would see IO take a little longer) if we just wanted
> >>> to use some new values.
> >>>> By the way, for a session, where are thesettingsstored? They utilise
> >>>> the samesettingsas the node being used, right? Also, I've noticed
> >>>> that, we can have sessions running and delete their node recs, and in
> >>>> that case, when we ask for details about a session (iscsiadm -m
> >>>> session -r 0) we do not get anything. Is this a defect? Are we not
> >>>> storing the sessionsettingssomewhere? How to get those?
Mike Christie
> Hi Mike,
>
> This is regarding the modified startup settings (in general any
> settings such as CHAP, etc) on a node getting lost when a rediscovery
> is being done, see the original thread.
>
> Will you be working on this anytime soon? By when can this be made
> available? That would be nice!
I have no idea when it will be available. I am finishing up some stuff
for work then will work on it.