VirtualBox

Ticket #6741 (closed defect: fixed)

Opened 4 years ago

Last modified 4 years ago

ISCSI support is broken

Reported by: ddn Owned by:
Priority: major Component: other
Version: VirtualBox 3.2.0 Keywords:
Cc: Guest type: other
Host type: Windows

Description

installed Virtualbox last 3.2.0 64 bit on windows 7 64 bit with 8 gigs of RAM and 500 gb RAID stripe disk. host system is connected throught ethernet 802.3 to HP MSA 2012i (iscsi storage subsystem). If i use Microsoft iSCSI initiator (win7 have this) im connected to iscsi storage and see presented disk. If i try to add scsi disk from virtualbox using command: VBoxManage addiscsidisk --server 192.168.1.20 --target iqn.1986-03.com.hp:storage.msa2012i.0844d74ef4.a

Oracle VM VirtualBox Command Line Management Interface Version 3.2.0 (C) 2005-2010 Oracle Corporation All rights reserved.

iSCSI disk created. UUID: 1c274e54-6516-49a8-8d5c-0c16298aa4e0

BUT i didnt see connection! virtual disk manager says: Could not open the medium VD: error VERR_VD_ISCSI_INVALID_TYPE opening image file '192.168.1.20|iqn.1986-03.com.hp:storage.msa2012i.0844d74ef4.a' (VERR_VD_ISCSI_INVALID_TYPE)

But from Windows7 microsoft initiator sees the disk!. Now i launch wireshark. I see that VirtualBox success in login stage but didn't try to negotiate with iSCSI storage used parameters! He simply wait for presented LUNS...

Microsoft iSCSI initiator ask iSCSI storage about used parameters. Wireshark Sniffer sees packets containing: HeaderDigest=None DataDigest=None ErrorRecoveryLevel=0 InitialR2T=Yes ImmediateData=No MaxRecvDataSegmentLength=1048576 MaxBurstLength=262144 FirstBurstLength=65536 MaxConnections=1 DataPDUInOrder=Yes DataSequenceInOrder=Yes DefaultTime2Wait=0 DefaultTime2Retain=20 MaxOutstandingR2T=16

Attachments

broken.pcap Download (3.2 KB) - added by ddn 4 years ago.
virtualbox broken session
working.pcap Download (50.1 KB) - added by ddn 4 years ago.
working with microsoft iscsi
iscsilunparseerr1.jpg Download (31.1 KB) - added by ddn 4 years ago.
adding_lun_param_error

Change History

comment:1 follow-up: ↓ 3 Changed 4 years ago by klaus

If you have a packet trace why don't you attach it? I would expect it to be just a couple of KB in size for such an early failure.

comment:2 Changed 4 years ago by ddn

okay, will attach soon normal trace (with microsoft iscsi initiator) and broken (with vbox initiator).

Changed 4 years ago by ddn

virtualbox broken session

Changed 4 years ago by ddn

working with microsoft iscsi

comment:3 in reply to: ↑ 1 Changed 4 years ago by ddn

Replying to klaus:

If you have a packet trace why don't you attach it? I would expect it to be just a couple of KB in size for such an early failure.

attached sniff sessions

comment:4 Changed 4 years ago by aeichner

The target presents the disk as an enclosure device (0x0d) and not as a disk according to the packet trace. This is the reason for the error.

comment:5 Changed 4 years ago by aeichner

Actually the target presents two LUNs. The first one is the enclosure device. The second LUN (0x21) contains the disk. You can try to add the the SCSI disk using the --lun parameter to set the LUN to use.

comment:6 Changed 4 years ago by aeichner

  • Priority changed from blocker to major

Changed 4 years ago by ddn

adding_lun_param_error

comment:7 Changed 4 years ago by ddn

aeichner, thanks for replying but after using:

VBoxManage addiscsidisk --server 192.168.1.20 --target iqn.1986-03.com.hp:storage.msa2012i.0844d74ef4.a --lun 1

i got something REALLY strange (see attached screenshot). Is this a vboxmanage string to integer parsing error (bug) ?

comment:8 Changed 4 years ago by aeichner

Looks like a formatting bug. The LUN value is correctly stored in the configuration here. The --lun parameter is not 1 for the target but 33 (0x21 is hexadecimal). Using 33 as the lun to use should fix the problem.

comment:9 Changed 4 years ago by ddn

Good! Its working now. thanks you for help!

P.S. Is this moment should be documented in VBox manual?

comment:10 Changed 4 years ago by frank

  • Status changed from new to closed
  • Resolution set to fixed

Should be already properly documented.

comment:11 Changed 4 years ago by klaus

BTW, if you wonder what funny number VirtualBox shows as the LUN, please read the iSCSI specification. This is the encoded form of the LUN (a 64bit value), and the people writing the spec really did a great job placing the data fields in the 64bit value field so that it looks almost like one got the byte ordering wrong.

Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use