| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
-i does not exist in session mode. -P 1 will print the
sid info.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1. Current status:
Using iscsiadm one cannot do any network configuration for qla4xxx
adapters.
However an iface is created for the qla4xxx ports using the hwaddress.
\# ls /etc/iscsi/ifaces/
iface.example iface0 qla4xxx.00:0e:1e:04:8b:2a
qla4xxx.00:0e:1e:04:8b:2e
This allows user to issue sendtargets via the qla4xxx iscsi offload.
2. Current Proposal:
Current proposal is to allow iscsiadm to configure the network settings
for qla4xxx ports.
This implementation is based on discussions at
- http://marc.info/?l=linux-scsi&m=127066184916180&w=2
- http://groups.google.com/group/open-iscsi/browse_thread/thread/d8e8c2df71c95d69/8f731d95d46141a0?lnk=gst&q=iscsi+hba#
2.1 Changes in iscsiadm/iscsid
2.1.1 Add a new event: ISCSI_UEVENT_SET_IFACE_PARAMS
2.1.2 New structure/enum to represent a single network parameter
- enum iscsi_net_param;
- struct iscsi_iface_param_info;
2.1.3 Added new parameters in iface
2.1.4 Change in operations
Add two new operations to iscsiadm
apply: Apply the single iface settings
applyall: Apply the iface settings of all iface having the same MAC
address
2.2 Changes in sysfs network representation
The new sysfs directory would look like this:-
/sys/class/iscsi_iface/-|
_______________________|
|
|- ipv4-iface-<host_no>-<iface_no>/ <-- for ipv4
|- bootproto
|- enabled
|- ipaddress
|- subnet
|- gateway
|- mtu
|- port
|- vlan
|- vlan_enabled
|- vlan_priority
|- ipv6-iface-<host_no>-<iface_no>/ <-- for ipv6
|- enabled
|- ipaddr_autocfg
|- ipaddress
|- link_local_addr
|- linklocal_autocfg
|- mtu
|- port
|- router_addr
|- vlan
|- vlan_enabled
|- vlan_priority
3. Flow:
3.1 User space code:
- If user specify --op=update, then just update the iface
config file
- If use specify --op=applyall then ifaces for the host
passed in.
and build up the net config buffer.
- Note: If --op is "apply" then only settings for single
iface is read,
the iface provided with -I option is only read.
- The net config buffer will look like this.
----------------------------------------------------------------|
| iscsi_net_param { |
| iface_num = 0; |
| len = 4; |
| param = ISCSI_NET_PARAM_IPV4_ADDR; |
| iface_type = ISCSI_IFACE_TYPE_IPV4; |
| param_type = ISCSI_NET_PARAM; |
| value[0] = ipaddress[0]; |
| value[1] = ipaddress[1]; |
| value[2] = ipaddress[2]; |
| value[3] = ipaddress[3]; |
| } |
----------------------------------------------------------------|
| iscsi_net_param { |
| iface_num = 0; |
| len = 4; |
| param = ISCSI_NET_PARAM_IPV4_GW; |
| iface_type = ISCSI_IFACE_TYPE_IPV4; |
| param_type = ISCSI_NET_PARAM; |
| value[0] = ipgateway[0]; |
| value[1] = ipgateway[1]; |
| value[2] = ipgateway[2]; |
| value[3] = ipgateway[3]; |
| } |
-----------------------------------------------------------------
| |
| iscsi_net_param { |
| iface_num = 1; |
| len = 4; |
| param = ISCSI_NET_PARAM_IPV4_ADDR; |
| iface_type = ISCSI_IFACE_TYPE_IPV4; |
| param_type = ISCSI_NET_PARAM; |
| value[0] = ipaddress[0]; |
| value[1] = ipaddress[1]; |
| value[2] = ipaddress[2]; |
| value[3] = ipaddress[3]; |
| } |
-----------------------------------------------------------------
-----------------------------------------------------------------
| iscsi_net_param { |
| iface_num = 0; |
| len = 4; |
| param = ISCSI_NET_PARAM_IPV4_GW; |
| iface_type = ISCSI_IFACE_TYPE_IPV4; |
| param_type = ISCSI_NET_PARAM; |
| value[0] = ipgateway[0]; |
| value[1] = ipgateway[1]; |
| value[2] = ipgateway[2]; |
| value[3] = ipgateway[3]; |
| } |
-----------------------------------------------------------------
| iscsi_net_param { |
| iface_num = 1; |
| len = 1; |
| param = ISCSI_NET_PARAM_IFACE_ENABLED; |
| iface_type = ISCSI_IFACE_TYPE_IPV4; |
| param_type = ISCSI_NET_PARAM; |
| offset = 0; |
| value[0] = 0; /* 0 = disable, default = 1 = enable */ |
| } |
-----------------------------------------------------------------
Each netconfig parameter has different size requirement for value field.
e.g.: IPv4 address requires 4 bytes, IPv6 address requires 16 bytes etc.
The memory allocated for each netconfig parameter is size of
iscsi_net_param + length required for that parameter.
The multiple IO Vector mechanism is used to send netconfig
parameter from user space to kernel using Netlink interface.
IO Vector 0 is used for Netlink message header.
IO Vector 1 is used for iSCSI User Event (ev).
- The ev will be sent down with event type =
ISCSI_UEVENT_SET_NET_CONFIG
IO Vector 2 onwards, each vector consists of the struct
iscsi_net_param
with parameter name followed by its value.
The total size will be addition of all the IO vector sizes.
3.2 Kernel space code:
- Once event is received, the buffer will look like struct
iscsi_net_param
with parameter name followed by its value, then next parameter
and
its value and so on.
- the scsi_transport_iscsi would call the adapter's
transport->set_net_config - In set_net_config each
individual param can be decoded and set into the
hardware.
4. qla4xxx configuration:
iscsid, creates the iface for qla4xxx, based on the hwaddress.
To display
the iface related to qla4xxx execute following
\# iscsiadm -m iface
qla4xxx.00:0e:1e:04:8b:2e
qla4xxx,00:0e:1e:04:8b:2e,<empty>,<empty>,<empty>
qla4xxx.00:0e:1e:04:8b:2e.ipv6
qla4xxx,00:0e:1e:04:8b:2e,<empty>,<empty>,<e
mpty>
qla4xxx.00:0e:1e:04:8b:2a
qla4xxx,00:0e:1e:04:8b:2a,20.15.0.66,<empty>,<emp
ty>
qla4xxx.00:0e:1e:04:8b:2a.ipv6
qla4xxx,00:0e:1e:04:8b:2a,2001:DB8:1111:2222::8888,<empty>,<empty>
qla4xxx.00:0e:1e:04:8b:2a.ipv6.1
qla4xxx,00:0e:1e:04:8b:2a,2001:DB8:4444:5555::9999,<empty>,<empty>
To setup network configuration there can be two methods
4. 1. User can manually modify the iface file, and issue an "apply"
command.
---------------------------------------------------------------------------
\#cat /etc/iscsi/ifaces/
iface.example iface0 qla4xxx.00:0e:1e:04:8b:2a
qla4xxx.00:0e:1e:04:8b:2e
Example:
\# cat qla4xxx.00:0e:1e:04:8b:2a
iface.iscsi_ifacename = qla4xxx.00:0e:1e:04:8b:2a
iface.transport_name = qla4xxx
iface.hwaddress = 00:0e:1e:04:8b:2a
iface.state = enable
iface.iface_num = 0 (default)
iface.bootproto = static
iface.ipaddress = 192.168.2.2 (decimal)
iface.subnetmask = 255.255.255.0 (decimal)
\# vi qla4xxx.00:0e:1e:04:8b:2a.ipv6
(If file does not exist, the one can create it)
iface.iscsi_ifacename = qla4xxx.00:0e:1e:04:8b:2a.ipv6
iface.transport_name = qla4xxx
iface.hwaddress = 00:0e:1e:04:8b:2a
iface.ipaddress = 1111:2222::7777:8888 (hex)
iface.iface_num = 0
\# iscsiadm -m iface -H 00:0e:1e:04:8b:2a --op=applyall
This will find the ifaces on the host with MAC address
00:0e:1e:04:8b:2a and apply the settings to the hardware..
Note, this will read all the iface belonging to the same MAC
address.
Note2, Instead of a MAC address the host number can be
passed in.
4.2. User can use iscsiadm to specify the values and then apply
--------------------------------------------------------------
\# ls /etc/iscsi/ifaces/
iface.example iface0 qla4xxx.00:0e:1e:04:8b:2a
qla4xxx.00:0e:1e:04:8b:2e
\# iscsiadm -m iface -I qla4xxx.00:0e:1e:04:8b:2a -o update
\
-n iface.ipaddress -v 192.168.1.2
\# iscsiadm -m iface -I qla4xxx.00:0e:1e:04:8b:2a -o update
\
-n iface.gateway -v 192.168.1.1
\# iscsiadm -m iface -I qla4xxx.00:0e:1e:04:8b:2a -o update
\
-n iface.subnet_mask -v 255.255.255.0
\# iscsiadm -m iface -H 00:0e:1e:04:8b:2a -o applyall
Setting up multiple IP:
First interface (default, no need to set iface_num, it is 0
by default)
\# iscsiadm -m iface -I qla4xxx.00:0e:1e:04:8b:2a -o update
\
-n iface.ipaddress -v 192.168.1.2
Create the second one if it does not exist
\# iscsiadm -m iface -I qla4xxx.00:0e:1e:04:8b:2a.1 -op=new
\# iscsiadm -m iface -I qla4xxx.00:0e:1e:04:8b:2a -o update
\
-n iface.iface_num -v 1 (Mandatory)
\# iscsiadm -m iface -I qla4xxx.00:0e:1e:04:8b:2a -o update
\
-n iface.ipaddress -v 192.168.1.3
\# iscsiadm -m iface -H 00:0e:1e:04:8b:2a --op=applyall
Note: If there are common settings for multiple interfaces
then the
settings from 0th iface would be considered valid.
Note: To apply settings for a single iface, just say
--op=apply
Signed-off-by: Lalit Chandivade <lalit.chandivade@qlogic.com>
Signed-off-by: Harish Zunjarrao <harish.zunjarrao@qlogic.com>
[formatting fixes and addition of host param for applyall]
Signed-off-by: Mike Christie <michaelc@cs.wisc.edu>
Signed-off-by: Vikas Chaudhary <vikas.chaudhary@qlogic.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
You can now pass in hostnames as the portal argument.
If you had:
iscsiadm -m node -P 1
Target: iqn.2008-09.com.meanminna:3
Portal: 20.15.0.12:3260,1
Iface Name: default
Then you can do
iscsiadm -m node -T iqn.2008-09.com.meanminna:3 -p somehostname -l
and iscsiadm will match this.
For discovery mode we already support hostnames, but we do not support
mixing. So if you used a hostname for discovery:
iscsiadm -m discoverdb -t st -p somehostname -D
Then when you run other discovery commands you have to use the hostname.
iscsiadm -m discoverydb -t st -p somehostname -o update -n someval -v
val
will work, but
iscsiadm -m discoverydb -t st -p 20.15.0.12 -o update -n someval -v val
would not.
For node mode, you do not have any control what the target returns
(and it probably returns a address) but for discovery you can pass
in what you want, so I think this should be ok.
|
|
|
|
|
|
|
|
|
| |
The rp_filter behavior changed upstream and this affects the
iface iscsi session binding feature. When upgrading kernels
the session login may fail when using iface binding. To fix
this the sysctl rp_filter setting may need to be changed.
See the README's iface prep section for details.
|
|
|
|
|
| |
This renames discovery2 mode to discoverydb to reflect
it works on the discovery db where discovery mode does not.
|
|
|
|
| |
discovery2 mode should be used instead of discovery mode.
|
|
|
|
|
|
|
| |
This patch has isns discoveryd use the isns discovery
rec settings instead of the iscsid.conf ones, so
that the set up the is the same as ST and to give us
freedom in the future to add more settings.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I really screwed up the old discovery mode record handling.
This adds a discovery2 mode, which adds back the old
features that got killed over time, and supports the new
ones.
iscsiadm -m discovery2 -t st -p ip:port --discover
will discover targets like before. Note that you must pass
in the --discover argument. This will try to read a record
for [-t st -p ip:port]. If found it will use those settings.
If not found then it will create a record using iscsid.conf
discovery.* settings and use them.
Note that
iscsiadm -m discovery2 -t st -p ip:port
will no longer perform discovery (yuou must pass the --discover
arguement), because the type and portal [-t st -p ip:port]
is now used as the record id. So the above command will
now print out the record values.
What is being added is discovery record support.
iscsiadm -m discovery2 -o new -t st -p ip:port
will create a record for [-t st -p ip:port]. You can then
use
iscsiadm -m discovery2 -o -t st -p ip:port -o update \
-n name -v value
to set the settings for the discovery record with id
[-t st -p ip:port].
You can also then do more advanced commands like before
iscsiadm -m discovery2 -t st -p ip:port -o new -o delete --discover
will do discovery and add new portals and delete portals that
are no longer returned.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We may need to have different CHAP settings for each
discovery portal. This patch has us use the discovery
records instead of the iscsid.conf method of specifying
the sendtargets info.
If the discovery record has
discovery.sendtargets.use_discoveryd = Yes
then iscsid will use that record to do sendtargets
discovery.
The poll interval can be set with
discovery.sendtargets.discoveryd_poll_inval.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We recently added the ability to use and update discovery
records. when this was done, we had
iscsiadm -m discovery -t st -p ip:port
use the record value if found. This will break compat with
older releases and it is a little strange because
iscsiadm -m discovery -p ip:port [ -o ... | -l ]
works on or uses the discovery record.
So this patch reverts iscsiadm behavior so that
iscsiadm -m discovery -t st -p ip:port
uses the iscsid.conf settings, and adds a new --discover|-D
command that can be used to force discovery.
iscsiadm -m discovery -p ip:port --discover
will force discovery using the record with the ID ip:port.
|
|
|
|
|
|
| |
With this patch, if the sendtargets or isns
daemon detects that a target is no longer sent
it will logout the session.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds the following params to iscsid.conf
discovery.daemon.isns.addresses
discovery.daemon.isns.poll_interval
These work like SendTargets where if you the param iscsid will do
discovery and log into the portals found.
This also adds iSNS SCN support. Like the other code it only supports
login of new targets.
Some notes:
- It does not appear to work with the Microsoft iSNS server
shipping with Windows 2008 rc. I have not tested 2003.
The server does not seem to be sending any SCNs and at the
same time when we register for SCNs it tells us the operation
was successful. From the Microsoft docs it appears that
the server does not support SCN events.
- Linux-isns is not working with our code. The Linux-isns
code appears to be sending iSNS SCN pdus with an incorrect
format.
- It is working with open-isns.git.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This replaces the native isns code with open-isns's libisns.
I included the open-isns code in the open-iscsi tarball
to make distribution easier since some distros use different
isns clients and may not want to carry open-isns.
This is based on open-isns commit
5e09f36d3446e41de0b8361601ffec4cd140d513.
Changes in iSNS behavior/use:
- To do discovery you must pass the ip and optionally the
port to iscsiadm:
iscsiadm -m discovery -t st -p 10.15.0.9
This command accepts the same ops as sendtargets so you can
add/remove/update the node records that are created.
It also supports ifaces properly now.
- isns.address and isns.port in iscsid.conf are no longer
used.
- ESI is temporarily not supported. This will be fixed in the
next patch when SCNs support is added.
- The iscsiadm isns discovery command is not marked as stable.
Signed-off-by: Mike Christie <michaelc@cs.wisc.edu>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The default behavior for iscsiadm discovery mode is to store
the portals found in the node DB. This adds a op "nonpersistent"
to run iscsiadm discovery in a nonpersistent mode. In thos
mode iscsiadm will not access the node DB.
iscsiadm -m discovery -t st -p ip -o nonpersistent
will just print out the portals found.
icssiadm -m discovery -t st -p ip -o nonpersistent -l
will print out the portals found and login. If this command
is run to logout you must run in session mode.
iscsiadm -m session -u
would logout all the sessions.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
iscsiadm is not using the discovery record settings. This has
iscsiadm -m discovery -t st -p ip:port
search for a discovery setting for ip:port. If found it will
use those values for discovery. Previously it would always
use the iscsid.conf settings.
To change the discovery settings for a record you can do
iscsiadm -m discovery -p ip:port -o update -n setting_name -v value
like in node mode.
Or you can completely remove the discovery record and targets found
through it by doing
iscsiadm -m discovery -p ip:port -o delete
then run the discovery command which will then use the iscsid.conf
values and create a new discovery record.
|
|
|
|
|
| |
The README said that we auto bind all ifaces in /etc/iscsi/ifaces
but we only autobind ones with the transport name tcp.
|
|
|
|
|
| |
Add some info using cxgb3i and cxgb3i to the README and
also add some info on the host mode.
|
|
|
|
| |
Run spell checker over README.
|
|
|
|
| |
Fix up spelling of interface in README found by Ulrich.
|
|
|
|
|
| |
The wiki is down and probably dead for good. This removes a bad
link to it.
|
|
|
|
|
| |
There is a new module, libiscsi_tcp, that is installed. This
updates the README.
|
|
|
|
|
|
|
|
|
|
|
| |
Patch and info from Andrew Moise:
Okay, patch is attached. I wound up doing some things differently
than I mentioned -- the trouble with KERNEL_TARGET turned out to just
be because I hadn't installed the needed headers, and I added the
dpkg-divert script as a Makefile target instead of a snippet of code
in the docs that people have to cut and paste. I also mentioned the
ib_iser situation (which I hope I described accurately).
|
|
|
|
|
| |
Since we do not support MCS, we just want to use the node.startup
setting. We still support node.conn[0].startup for compat reasons.
|
|
|
|
| |
Document how to set the scsi command timer in the README.
|
|
|
|
|
|
|
|
|
|
|
| |
Some values like target name or ip address should be changed.
This adds some checks in idbm.c for this.
Some values like iface bind info should only be modified in
iface mode. This patch adds some checks to iscsiadm.c for this.
This also adds a log message if we have to log out a session
before deleting its record.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of overwriting existing node records, you can modify the
behavior by passing in different ops.
Pass -o new to add new nodes.
Pass -o delete to delete stale ones.
Pass -o update to update the records of existing nodes.
And pass combos of different ops for different behavior.
Signed-off-by: Mike Christie <michaelc@cs.wisc.edu>
|
|
|
|
| |
iface configs are in /etc/iscsi/ifaces
|
|
|
|
|
| |
2.6.14 and .15 support is only for testing. The support
is still broken and in development, but the basics work.
|
| |
|
|
|
|
|
| |
The ipv6 example in the README used the -T argument but forgot
to pass in a target name.
|
|
|
|
|
|
| |
In the man page we document that the isns iscsiadm and iscsid.conf
interface are unstable but not in the README. This just adds
the warning to the README.
|
|
|
|
|
|
| |
of checks so users cannot really mess things up - hopefully
git-svn-id: svn://svn.berlios.de/open-iscsi@861 d7303112-9cec-0310-bdd2-e83a94d6c2b6
|
|
|
|
|
|
| |
info and add a work around for older ql4xxx drivers
git-svn-id: svn://svn.berlios.de/open-iscsi@854 d7303112-9cec-0310-bdd2-e83a94d6c2b6
|
|
|
|
| |
git-svn-id: svn://svn.berlios.de/open-iscsi@851 d7303112-9cec-0310-bdd2-e83a94d6c2b6
|
|
|
|
|
|
| |
targets are not handling it well) and use the iface argument instead of the actual values
git-svn-id: svn://svn.berlios.de/open-iscsi@845 d7303112-9cec-0310-bdd2-e83a94d6c2b6
|
|
|
|
|
|
| |
iface (driver and hardware are bound). Also merge the -D and -I arguments so they are now -I driver,hwaddress. Also add some basic qla4xxx support. We can rescan/scan it and perform sendtargets through it but it stores the targets it finds in Flash and then logs into all of them autmatically (when we do discovery and later when reload the driver). So qla4xxx support is mostly to make sure we have the --interfae argument right. We will have to decide how to set other params, manage nodes, and if we should move scanning to the kernel and then also move some error recovery code to the kernel (today qla4xxx is calling block directly and is not able to export it iscsi state yet (the beginnings to fix that is in the git tree but we still need to reduce some code duplcation)). qla4xxx behavior and functionality is going to change as we learn more about the hw (what format the flash data is supposed to be in for example).
git-svn-id: svn://svn.berlios.de/open-iscsi@816 d7303112-9cec-0310-bdd2-e83a94d6c2b6
|
|
|
|
|
|
| |
else we get the old style by default
git-svn-id: svn://svn.berlios.de/open-iscsi@811 d7303112-9cec-0310-bdd2-e83a94d6c2b6
|
|
|
|
|
|
| |
we just wanted to add a new nic entry for every existing node this was a pain. This patch makes it so the new op will traverse the db and add new records if there is a pattern match. TODO: fix up the iterators and merge group login/logout functionality
git-svn-id: svn://svn.berlios.de/open-iscsi@810 d7303112-9cec-0310-bdd2-e83a94d6c2b6
|
|
|
|
|
|
| |
targetname, portal) and iscsiadm will match the values passed in with node db entries or running sessions (depends on the mode) and execute the op on it
git-svn-id: svn://svn.berlios.de/open-iscsi@807 d7303112-9cec-0310-bdd2-e83a94d6c2b6
|
|
|
|
|
|
| |
and node mode takes the node record id values or nothing
git-svn-id: svn://svn.berlios.de/open-iscsi@805 d7303112-9cec-0310-bdd2-e83a94d6c2b6
|
|
|
|
| |
git-svn-id: svn://svn.berlios.de/open-iscsi@802 d7303112-9cec-0310-bdd2-e83a94d6c2b6
|
|
|
|
| |
git-svn-id: svn://svn.berlios.de/open-iscsi@783 d7303112-9cec-0310-bdd2-e83a94d6c2b6
|
|
|
|
| |
git-svn-id: svn://svn.berlios.de/open-iscsi@780 d7303112-9cec-0310-bdd2-e83a94d6c2b6
|
|
|
|
|
|
| |
portal :))
git-svn-id: svn://svn.berlios.de/open-iscsi@770 d7303112-9cec-0310-bdd2-e83a94d6c2b6
|
|
|
|
| |
git-svn-id: svn://svn.berlios.de/open-iscsi@766 d7303112-9cec-0310-bdd2-e83a94d6c2b6
|
|
|
|
| |
git-svn-id: svn://svn.berlios.de/open-iscsi@765 d7303112-9cec-0310-bdd2-e83a94d6c2b6
|
|
|
|
| |
git-svn-id: svn://svn.berlios.de/open-iscsi@764 d7303112-9cec-0310-bdd2-e83a94d6c2b6
|
|
|
|
| |
git-svn-id: svn://svn.berlios.de/open-iscsi@735 d7303112-9cec-0310-bdd2-e83a94d6c2b6
|
|
|
|
| |
git-svn-id: svn://svn.berlios.de/open-iscsi@734 d7303112-9cec-0310-bdd2-e83a94d6c2b6
|
|
|
|
| |
git-svn-id: svn://svn.berlios.de/open-iscsi@733 d7303112-9cec-0310-bdd2-e83a94d6c2b6
|