iSCSI w/ QNAP targets give block i/o error

[Ralph Schmieder]

Running vbox 3.1.2 on Mac OS 10.6.2 on MacBook Pro C2D w/ 4GB and also on Ubuntu Karmic 64bit version on a Atom 330 w/ 4GB. Both host platforms show the same behavior.

Goal: Attach a VBox HDD via iSCSI on a QNAP 439 Pro as a target. The iscsi daemon reports the following as a version information:

[~] # /sbin/iscsid --version
iscsid version 2.0-871

Problem: The HDD is seen within the guest but gives a lot of errors seen by the kernel log like the following (please see the kern.log file for additional information):

Feb  1 22:58:19 kernel: [   31.047487] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
Feb  1 22:58:19 kernel: [   31.047734] ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 4096 in
Feb  1 22:58:19 kernel: [   31.047856]          res 40/00:02:00:24:00/00:00:00:00:00/b0 Emask 0x4 (timeout)
Feb  1 22:58:19 kernel: [   31.048002] ata1.00: status: { DRDY }
Feb  1 22:58:19 kernel: [   36.090995] ata1: link is slow to respond, please be patient (ready=0)
Feb  1 22:58:19 kernel: [   41.072801] ata1: device not ready (errno=-16), forcing hardreset
Feb  1 22:58:19 kernel: [   41.073107] ata1: soft resetting link
Feb  1 22:58:19 kernel: [   41.415493] ata1.00: configured for UDMA/33

I've tried all different host adapters for the VM (various IDE, various SCSI and SATA) but the result is pretty much the same. Eventually the installer comes to a halt and it seems like the HDD is defect (lots of I/O errors).

Using the same Ubuntu version as the iSCSI initiator works just fine. However, I'd like to add the VBox initiator as an additional virtualization layer and present the iSCSI target as a plain IDE drive to the virtual host.

The QNAP and the VBox host are both connected to a Gigabit switch, I've attached the SYSLOG of the Ubuntu guest up to the point where the installer prompts to select the language. The trace has been done with tcpdump and is roughly started at the same time as the VM.

The QNAP software is the latest available as of today which is 3.2.2 Build 0128T.

[Ralph Schmieder]

tcpdump, kern.log, VBox.log

[Klaus Espenlaub]

The QNAP iSCSI target behaves a little odd - it appears to ignore the first command. There's no reply whatsoever, and when the guest eventually retries reading sector 0 of the disk it seems to get the data fine.

That iSCSI target is somewhat similar to OpenSolaris COMSTAR - it loves that NOP-In/NOP-Out liveness check which VirtualBox can't handle 100% yet. Will need to dig deeper, as I'd assume that there is some subtle misunderstanding between VirtualBox and that target.

[Ralph Schmieder]

As a heads up: the exact same behavior is still present in the current versions of the involved componente: Tested w/ VirtualBox 3.2.4 r62467 on Mac OS 10.6.3 and 3.2.7 Build 0526T on the QNAP 439 Pro storage system. Was wondering if there is any ETA...?

[Ralph Schmieder]

Problem Fixed

Again as a heads up: Updated all both VirtualBox and QNAP 439 Pro storage system to latest available release (VirtualBox 3.2.6 r63112 and QNAP 3.3.0 0629T). With this combination the errors have disappeared and the iSCSI runs like a champ. It is not clear to me, however, what actually resolved the issues. Both release notes were talking about some fixes WRT iSCSI as the previous releases did as well. Anyway, either a fix in VB or in the QNAP did something good and made the problem go away. Hope it will be gone for good ;)

[Sander van Leeuwen]

Thanks for the feedback.