> I created a 20GB sparse file with: dd of=testfile count=0 bs=4K
> seek=5M
> and added it with the createvirtdev  (I'm not sure if creating the
> sparse file is necessary, is it?)

> I first tested with Windows 2k3 x64 and MS's initiator and it worked
> good.

> getting some errors with vmware ESX 3.5.  the first error on the
> target is:
> Feb  8 09:33:21 file1 kernel: [  898.900540] iscsi_handle_scsi_cmd:
> 1479: ***ERROR*** R_BIT or W_BIT set when Expected Data Transfer
> Length is 0. Bad iSCSI Initiator.

> after about 50 automatic retries it did finally connect without this
> error, though I also get these errors on every connect but it seems to
> work anyway:
> Feb  8 09:33:23 file1 kernel: [  900.901910] iscsi_find_param_from_key:
> 789: ***ERROR*** Unable to locate key "X-com.cisco.PingTimeout".
> Feb  8 09:33:23 file1 kernel: [  900.901916] iscsi_find_param_from_key:
> 789: ***ERROR*** Unable to locate key "X-com.cisco.sendAsyncText".
> Feb  8 09:33:23 file1 kernel: [  900.901921] iscsi_find_param_from_key:
> 789: ***ERROR*** Unable to locate key "X-com.cisco.protocol".

> I was also getting regular errors, but only after creating a vmfs on
> the LUN, on my esx vmkernel log with no corresponding error on the
> target and it works despite these errors:
> Feb  8 08:51:26 esx1 vmkernel: 5:09:22:35.154 cpu2:1122)iSCSI: bus 0
> target 3 trying to establish session 0x9e180a0 to portal 0, address
> 127.0.0.1 port 3261 group 1
> Feb  8 08:51:26 esx1 vmkernel: 5:09:22:35.154 cpu2:1122)iSCSI: session
> 0x9e180a0 to iqn.2003-01.org.linux-iscsi.file1.i686:sn.ab90cd162ef1
> failed to connect, rc -5, I/O error
> Feb  8 08:51:26 esx1 vmkernel: 5:09:22:35.154 cpu2:1122)iSCSI: session
> 0x9e180a0 connect failed at 46575518
> Feb  8 08:51:26 esx1 vmkernel: 5:09:22:35.154 cpu2:1122)<5>iSCSI:
> session 0x9e180a0 iSCSI: session 0x9e180a0 retrying all the portals
> again, since the portal list got exhausted
> Feb  8 08:51:26 esx1 vmkernel: 5:09:22:35.154 cpu2:1122)iSCSI: session
> 0x9e180a0 to iqn.2003-01.org.linux-iscsi.file1.i686:sn.ab90cd162ef1
> waiting 60 seconds before next login attempt

> I then noticed in the esx config that it thought the path had failed
> for the lun, so I did a rescan and here's the log from ESX:
> Feb  8 09:00:50 esx1 vmkernel: 5:09:31:59.393 cpu1:1037)ScsiScan: 395:
> Path 'vmhba32:C0:T2:L0': Vendor: 'iSCSI   '  Model: 'DISK
> '  Rev: '0   '
> Feb  8 09:00:50 esx1 vmkernel: 5:09:31:59.393 cpu1:1037)ScsiScan: 396:
> Type: 0x0, ANSI rev: 4
> Feb  8 09:00:50 esx1 vmkernel: 5:09:31:59.394 cpu1:1037)ScsiScan: 395:
> Path 'vmhba32:C0:T4:L0': Vendor: 'SBEi-INC'  Model: 'FILEIO'  Rev:
> 'v2.8'
> Feb  8 09:00:50 esx1 vmkernel: 5:09:31:59.394 cpu1:1037)ScsiScan: 396:
> Type: 0x0, ANSI rev: 2
> Feb  8 09:00:50 esx1 vmkernel: 5:09:31:59.395 cpu1:1037)WARNING:
> ScsiUid: 550: Path 'vmhba32:C0:T4:L0' : supports ANSI version
> 'SCSI-2' (0x2). In order to be used with ESX a device must support the
> SCSI 3 protocol.
> Feb  8 09:00:50 esx1 vmkernel: 5:09:31:59.395 cpu1:1037)ScsiScan: 516:
> Path 'vmhba32:C0:T4:L0': No standard UID: Failure
> Feb  8 09:00:50 esx1 vmkernel: 5:09:31:59.403 cpu0:1035)SCSI: 861:
> GetInfo for adapter vmhba32, [0x3f8bdd80], max_vports=0,
> vports_inuse=0, linktype=0, state=0, failreason=0, rv=-1, sts=bad001f
> Feb  8 09:00:50 esx1 vmkernel: 5:09:31:59.404 cpu0:1035)iSCSI: session
> 0x9e180a0 replacement timed out, failing to queue 0x3d20bd80 cdb 0xa0
> and any following commands to (0 0 3 0), iqn.2003-01.org.linux-
> iscsi.file1.i686:sn.ab90cd162ef1
> Feb  8 09:00:50 esx1 vmkernel: 5:09:31:59.419 cpu1:1036)SCSI: 861:
> GetInfo for adapter vmhba32, [0x3f8bdd80], max_vports=0,
> vports_inuse=0, linktype=0, state=0, failreason=0, rv=-1, sts=bad001f
> Feb  8 09:00:50 esx1 vmkernel: VMWARE SCSI Id: Supported VPD pages for
> vmhba32:C0:T2:L0 : 0x0 0x80 0x83
> Feb  8 09:00:50 esx1 vmkernel: VMWARE SCSI Id: Device id info for
> vmhba32:C0:T2:L0: 0x1 0x1 0x0 0x18 0x69 0x53 0x43 0x53 0x49 0x0 0x0
> 0x0 0x34 0x71 0x6a 0x43 0x48 0x39 0x4e 0x4d 0x33 0x76 0x41 0x65 0x72
> 0x72 0x69 0x49
> Feb  8 09:00:50 esx1 vmkernel: VMWARE SCSI Id: Id for vmhba32:C0:T2:L0
> 0x20 0x20 0x20 0x20 0x44 0x49 0x53 0x4b 0x20 0x20
> Feb  8 09:00:50 esx1 vmkernel: VMWARE SCSI Id: Supported VPD pages for
> vmhba32:C0:T4:L0 : 0x0 0x80 0x83
> Feb  8 09:00:50 esx1 vmkernel: VMWARE SCSI Id: Device id info for
> vmhba32:C0:T4:L0: 0x2 0x1 0x0 0x22 0x53 0x42 0x45 0x69 0x2d 0x49 0x4e
> 0x43 0x46 0x49 0x4c 0x45 0x49 0x4f 0x3a 0x73 0x6e 0x2e 0x61 0x62 0x39
> 0x30 0x63 0x64 0x31 0x36 0x32 0x65 0x66 0x31 0x3a 0x30 0x5f 0x30
> Feb  8 09:00:50 esx1 vmkernel: VMWARE SCSI Id: Id for vmhba32:C0:T4:L0
> 0x73 0x6e 0x2e 0x61 0x62 0x39 0x30 0x63 0x64 0x31 0x36 0x32 0x65 0x66
> 0x31 0x3a 0x30 0x5f 0x30 0x46 0x49 0x4c 0x45 0x49 0x4f

> and now, for seemingly no reason again, the path has failed, and the
> target server seems to have crashed though the console is logging
> reserve and releases from the esx server.

> I was running iometer from a win2k3 guest on esx 3.5 with a 2nd
> virtual disk added that's on the LIO virtdisk lun which is on an XFS
> mounted LVM volume on a 3ware7504 RAID5 of 4 older 120GB IDE disks.
> IOMeter test is 4 workers of max 64 sectos, 16 outstanding io per
> target, 32K block size, 75% read sequential and it was holding very
> steady at 113MB/s total and 3600 IOps.  this is actually a bit better
> than I would have expect from these disks, guessing some target side
> caching is in play?