Hi, first of all I'm truly sorry about sending you all back and forth and you have
been most patient.
Secondly I would like you to split your patch to 2 parts.
The getSessionInfo() changes are good and I would have ACKed them if they where posted on
their own.
Again, discovery will use the interface passed in iface. There is no need to do all the
looping and there is no need for the config values. Accepting your patch means that the
transport in the interface given in the parameter is ignored.
I do know that there is no way to currently select iser in the UI and backend.
This, although unfortunate, does not mean we need to start hacking things in to VDSM.
My problem with accepting this change is that it is now supported by VDSMs interface.
This will make things hard for us to support in the future.
I completely sympathize with your strong will to not start poking in the Engine and UI.
In any case, there is a way I can meet you half way. I would rather it'd be fixed
properly but I do get that time constraints might force us to fix this in a less than
optimal manner.
The fix as I see it:
In HSM when there is no initiator name passed, hsm will not only try
iface('default') but also iface('iser').
Doing it this way will mean that the fallback is only supported by the old API and is
implemented at the API level and not the iscsi abstraction layer.
I would have done it myself and sent the patch if I had a set up to test it in.
Note that you will need the OK of someone in the ovirt management to approve this API
semantic change and it's supportability. I'm just an annoying developer, I
don't have veto powers.
----- Original Message -----
From: "Roi Dayan" <roi.dayan(a)gmail.com>
To: "VDSM Project Patches" <vdsm-patches(a)lists.fedorahosted.org>
Cc: "Roni Luxenberg" <rluxenbe(a)redhat.com>, "Itzik Brown"
<ItzikB(a)mellanox.com>
Sent: Tuesday, March 6, 2012 9:03:24 AM
Subject: Re: iSER patch for VDSM
Hi,
I attached a new patch for iser using the iface option.
I also needed to change getSessionInfo() which read session and
connection information
from /sys/devices/platform/host*/ but with iser we don't have this
location (we are checking this).
so the patch also modifies the top of getSessionInfo() to point to
the right session and connection directories.
We still have a problem we didn't figure out yet.
the discovery and login works fine. falling from iser to tcp works
fine.
but we dont see any luns for iser targets.
there are no errors in the vdsm.log file.
i see the output of devices in the log file which shows this after
connecting to tcp target and iser target:
{'devList': [{'GUID': '1965edbcc16c00d0f04b00506',
'capacity': '836411326464',
'devtype': 'iSCSI',
'fwrev': '3.14',
'logicalblocksize': '512',
'partitioned': False,
'pathlist': [{'connection': '192.168.20.123',
'initiatorname': 'iser',
'iqn': 'rhev-iser1',
'port': '3260',
'portal': '1'}],
'pathstatus': [{'lun': '1',
'physdev': 'sdd',
'state': 'active',
'type': 'iSCSI'}],
'physicalblocksize': '512',
'productID': 'MR9265-8i',
'pvUUID': 'HrI8Dk-5KcS-Mfnw-gcXu-CRst-EtfQ-8YC3MX',
'serial': 'SLSIMR9265-8i',
'vendorID': 'LSI',
'vgUUID': 'PAa3E1-LcIN-zJjG-s0r4-8ZZE-i1zB-mZYYjM'},
{'GUID': '1977bdbcc1670e70e04b00506',
'capacity': '955898658816',
'devtype': 'iSCSI',
'fwrev': '3.14',
'logicalblocksize': '512',
'partitioned': False,
'pathlist': [{'connection': '192.168.20.123',
'initiatorname': 'default',
'iqn': 'rhev-iscsi2',
'port': '3260',
'portal': '1'}],
'pathstatus': [{'lun': '1',
'physdev': 'sde',
'state': 'active',
'type': 'iSCSI'}],
'physicalblocksize': '512',
'productID': 'MR9265-8i',
'pvUUID': '',
'serial': 'SLSIMR9265-8i',
'vendorID': 'LSI',
'vgUUID': ''}]}
the output of devices seems ok but the gui doesn't show we have any
luns and no errors.
any idea where to look?
Thanks,
Roi
On Tue, Mar 6, 2012 at 12:14 PM, Roi Dayan < roid(a)mellanox.com >
wrote:
Hi,
I changed the patch.
I'll send it later today after I'll test it.
In the new patch I'm not doing changes to header digest and I'm using
the iface option.
I add another binding with:
iscsiadm -m node -p portal -T target -I iser -o new
in a normal case I usually del the default binding with:
iscsiadm -m node -p portal -T target -I default -o delete
but for some reason I don’t see it after adding the target with iser
interface.
Maybe the reason is VDSM doesn't specify target portal group (tpgt)
when adding also the default binding.
e.g.
Without tpgt:
iscsiadm -m node -p ip:port -T target -I default -o new
with tpgt:
iscsiadm -m node -p ip:port,1 -T target -I iser -o new
When falling back to tcp I delete the iser binding.
Thanks,
Roi
-----Original Message-----
From: Dan Kenigsberg [mailto: danken(a)redhat.com ]
Sent: Tuesday, March 06, 2012 8:58 AM
To: VDSM Project Patches; Roi Dayan
Cc: Saggi Mizrahi; Itzik Brown
Subject: Re: iSER patch for VDSM
On Mon, Mar 05, 2012 at 04:30:26PM +0000, Roi Dayan wrote:
> Hi,
>
> With "the new code supports iser" do you mean the iface iser in
> iscsiadm?
> I want to use, I don’t want to create a new one.
> I did a fallback since I don’t have in the gui anywhere to choose
> between iser and iscsi.
> Now I see it doesn't help me anyway since if I want to use the iser
> iface in iscsiadm, I need to set this iface when doing discovery
> since it can't be changed later with op update.
>
> With a talk with Ayal Baron I was told I can currently submit the
> patch to vdsm-patches without gerrit And to have a fixme comment
> about the fallback (which doesn't really help right now since I
> need discovery anyway).
>
> From you're answer I understand it is possible to choose iser iface
> from the gui?
> How I do that?
> I only have fields for ip,port,chap.
I'm afraid you cannot. I'll try to explain Saggi's text, hopefully
without introducing mistakes of my own: Vdsm's connectStorageServer
accpets a parameter named initiatorName, which is abused and passed
as-is to iscsiadm's -I argument.
This can be abused in order to pass the special "iser" interface to
iscsiadm.
HOWEVER, I don't think that initiatorName has ever been used by ovirt
Engine.
Since I have very little knowledge of iscsiadm (and when it comes to
iser even less), maybe you would agree to give me a more detailed
explanation of your patch.
A casual read of the man page makes we wonder: could a simple
iscsiadm -m discoverydb -t st -p ip:port -I iser --discover
do the trick for discovery? Could HeaderDigest mangling be avoided?
BTW, Saggi, does it make sense to have our API accomodate
discovery/login over multiple interfaces?
Regards,
Dan.
_______________________________________________
vdsm-patches mailing list
vdsm-patches(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/vdsm-patches
--
Roi
_______________________________________________
vdsm-patches mailing list
vdsm-patches(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/vdsm-patches