Sorry for the crosspost, but I don't know where the problem might
be. I doubt that it's a ZFS problem (due to the log), but I'm including
that list to, just for completeness. Please keep To/Cc intact when replying
(unless it can be confirmed that one specific software here is 'at fault' :).
For now, I'll assume that it's a problem with VBox, but I just wanted to
make sure I covered all the bases, hence the crosspost.
Hardware/software setup:
Hardware: AMD Athlon 7750 (dualcore, 3GHz), 8GB mem.
Hostname: Celia
IP: 192.168.69.8
Kernel: AMD64, v3.1.6, patched with iscsi-kern-use-aligned.patch
Userland: Debian GNU/Linux Lenny 32bit
Open-iSCSI: v2.0.872, patched with iscsi-tools-use-aligned.patch
IET iSCSI Target: SVN r466.
VirtualBox: 4.1.8-75467~Debian~lenny (64bit)
ZFS on Linux: 0.6.0-rc6, patched with iSCSI share support (via ZVOL)
System description:
The disks etc is running on the physical host. In that, there's a 64bit
chroot which hoses the VirtualBox installation. This chroot also hoses the
iscsid.
The iSCSI target is added to VBox using the following command (running inside
the chroot):
VBoxManage -nologo storageattach "Debian kFreeBSD amd64" \
--storagectl "SATA Controller" --port 0 \
--type hdd --medium iscsi --server 192.168.69.8:3260 \
--target iqn.2011-12.com.bayour:storage.debian.kfreebsd.64 --lun 0
The host is then started (with a install ISO attached as CD/DVD) and a RDP
client is attached to the RDP port.
All iscsiadm commands and options work just fine from within the chroot.
Problem description:
As soon as an installation (Debian GNU/kFreeBSD 64bit) starts to mkfs it's
disk I get _a lot_ of the following info in syslog on the physical machine:
Dec 23 19:10:18 Celia kernel: [ 986.241070] iscsi_trgt:
check_segment_length(1873) data too long 3 9728 8192
and after a short while, the whole (physical) machine freezes up, requiring
a physical reset. Nothing, except this is shown at the console. It just starts
'mid sentence'.
Tests:
This can be replicated on any host, any target. However, attaching any target
using open-iscsi directly on any virtual machine (instead of via VBox), works
fine.
Also, attaching the target inside the chroot and fdisk/mkfs the device also
works. I don't have any other physical machine to test this on (yet), so I
can't say for sure that would work, but it seems reasonable..
Default medium type for a iSCSI target in VBox is 'Normal', but I've also
tested 'Writethrough'. 'Immutable' doesn't seem to work at all (host
stuck in 'Starting'.
I've tried this with and without first logging in to the target, but same
thing happens.
Before I start digging into the magic SysRQ, is there something obvious I'm
doing wrong?
Excuses:
I guess I _could_ fiddle with bootable iSCSI support on the hosts, but that
doesn't seem to be as future proof. My new 6core Phenom, 16GB mem (with a
32GB option further down the line - after all this christmas crapp is done
with :) is on it's way in the mail. This machine will have only a 60GB SSD
disk for the OS and VirtualBox, the rest is going to be iSCSi devices with
the old (current) server acting only as file storage (and 'rescue teleport'
just in case).
So I _will_ be using teleporting, and it seems that using iSCSI on VBox (as
opposed to on the host) is ... 'better' (?).
In any way, it's a _lot_ easier to manage and administrate in my use-cases,
so I'd prefer this way (converting a 'normal' install on VDI to iSCSI bootable
will be a lot of work - I create/recreate a lot of hosts for testing).
------------------------------------------------------------------------------
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create
new or port existing apps to sell to consumers worldwide. Explore the
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
_______________________________________________
VBox-users-community mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/vbox-users-community
