Bug 219556

The problem could lie with the preview in VirtualBox - it stays blank (black) on the machine where VBoxSVC consumes 100% CPU.

After some experimentation, the problem turned out to have a quite different cause.

On both hosts, the same emulated harddisk is available: on the AMD machine directly via a vmdk file pointing, on the Intel machine via iSCSI.

However, the file holding the emulated harddisk was not available. On the AMD machine, this only caused VirtualBox to note that the machine cannot be started. On the Intel machine however, the file seems to get exported as a zero-sized disk; this in turn seems to trip up VBoxSVC.

So there are two issues: One, VBoxSVC gets confused about the announced but not really existing iSCSI target, and second, the iSCSI daemon blindly announces to export a file (with zero size) which does not exist (and cannot be created, its path not being available).

I think the bigger problem lies with the iSCSI subsystem announcing a target which does not exist. I'll try to reassing the issue to the base system.

Comment 3 Edward Tomasz Napierala 2017-05-27 07:09:36 UTC

I think it's a feature, not a bug.  A nonexisting file is a valid LUN, but without backing media (think an empty DVD drive).  SCSI compliant clients are supposed to know how to handle this.

Hmmm... but if I then make the backing file available (by mounting the filesystem on which it resides), this fact is not reflected when I run 'ctladm devlist'. The same goes for the client: Attaching the disk using 'iscsictl -A' indeed first shows that the disk is not ready:

da0: Attempt to query device size failed: NOT READY, Logical unit not ready, manual

But after mounting the backing file, this does not change.

-- Martin

Comment 5 Edward Tomasz Napierala 2017-05-30 09:21:51 UTC

You need to notify CTL that something has changed by doing "service ctld reload".  Could you check whether it works and report back?  Thanks!

This indeed works, I do not even need to rescan the bus on the client. The following message is logged when trying "dd if=/dev/da0 of=/dev/null bs=1m count=1" on the client after making the target available:

May 31 19:43:46 mizar kernel: (da0:iscsi1:0:0:0): Capacity data has changed

However, I then proceeded to remove the target from the configuration. On the client this leads to the message

May 31 17:44:41 mizar iscsid[4380]: hal.xyzzy (iqn.1995-06.xyzzy.hal:disk1): target returned error: Not found
May 31 19:44:41 mizar kernel: WARNING: hal.xyzzy (iqn.1995-06.xyzzy.hal:disk1): connection error; reconnecting
May 31 19:44:41 mizar iscsid[4220]: child process 4380 terminated with exit status 1

But device da0 on the client still exists. If I now do dd if=/dev/da0 of=/dev/null bs=1m count=1" on the client again, I get a non-interruptible hang until I make the target available again, and even then the hang only terminates after a timeout of 60 seconds:

May 31 19:45:42 mizar iscsid[4387]: hal.xyzzy (iqn.1995-06.xyzzy.hal:disk1): target returned error: Not found
May 31 19:45:42 mizar kernel: WARNING: hal.xyzzy (iqn.1995-06.xyzzy.hal:disk1): login timed out after 61 seconds; reconnecting
May 31 19:45:42 mizar iscsid[4220]: child process 4387 terminated with exit status 1
May 31 19:46:43 mizar kernel: WARNING: hal.xyzzy (iqn.1995-06.xyzzy.hal:disk1): login timed out after 61 seconds; reconnecting

The dd then succeeds.

Comment 7 Edward Tomasz Napierala 2017-05-31 19:37:06 UTC

This too is expected: by default, the initiator will handle errors by just reconnecting until it succeeds.  You don't want your iSCSI disks to disappear because of transient network problems, right?  ;-)

You can disable this behaviour by changing the kern.iscsi.fail_on_disconnection sysctl to 1, as described in man.freebsd.org/iscsi.

Thanks for all the pointers!

-- Martin