Re: iscsi-initiator problems

[Brad Spencer <brad%anduin.eldar.org@localhost>]

   Hi All,

   I *almost* have iscsi-initiator working. Here are my observations when 
   mounting a target with:

       iscsi-initiator -u pod -h maat /iscsi

     o The process remains in the foreground, which doesn't seem right.

     o The mounted file in /iscsi/pod.zabrico.com/target2/storage doesn't
       seem to be usable because:

       - dd'ing anything to that node yields,

        "dd: /iscsi/pod.zabrico.com/target2/storage:
            Function not implemented"

       - Attempting to vnconfig it yields,

         "vnconfig: /dev/rvnd2d: VNDIOCSET: Invalid argument"


   So my next step is to figure out what is the best way to use the shared 
   targets. The intent is to use the as Xen virtual disks. Or as LVM PVs. 
   I'm running -current on the initiator side (5.99.41).

   Any help would be great. Thanks,

   Louis




Hello....  I am doing this too, and what I found was that it appears that
a "feature" was introduced that prevents vnd from trying to use files that
it thinks have holes in it.

I did the following to src/sys/dev/vnd.c around line 1118:

#ifdef NONONO
                if (!error && vattr.va_bytes < vattr.va_size)
                        /* File is definitely sparse, reject here */
                        error = EINVAL;
#endif

This is all probably very wrong to do, as you will very likely panic if
you try vnconfig'ing a file that actually is sparse.  Either vnd.c should
be fixed to deal with files with holes in them, or the '-f', force the
operation, flag should be passed in the ioctl to have meaning on
configure.  That flag already exist for unconfiguring, so it would not
seem a big leap.

Or... better yet, rump or whatever is actually responsible should be
worked on to provide "proper" values for the files.  You can see the
problem simply by doing a 'ls -s' against the "storage" file.

None the less, this will allow vnconfig to be usable on the storage
"file" presented by the initiator.  I was then able to disklabel, put ffs
or lfs file systems on the vndX device without issue, mount them and use
them.  I think I was also able to use rump_ffs to do something simular...
[or not, don't exactly remember, I might have triggered a locking panic].
I also use gpt and wedges and that all worked fine and was pretty neat.

What I wasn't able to do was use the ntfs-3g fuse filesystem that is
available in pkgsrc.  That did panic the system.  I have some storage that
could be presented from a MS-WINDOWS 7 Xen HVM.  It it gpt based, which
NetBSD dealt with fine, but I wasn't able to mount it, but I could 'dd'
it.

Now...  one may be asking why don't you just do 'xm block-attach ...' in
Xen DOM0 to add the device to the DOMU...  Very good question...  the
answer is I couldn't get that to work.  The "hot plugin" attach event is
noticed by the DOMU, not a problem, however the /dev/xbd device comes back
as 'Not configured' when you try to use it.  It will be available if you
reboot the DOMU, but that is kind of not the point of dynamically
attaching the device.


In any case, NetBSD/xen is certainly one of the neatest things I have
worked with ever and really appreciate all of the work that has gone into
it.




-- 
Brad Spencer - brad%anduin.eldar.org@localhost - KC8VKS
http://anduin.eldar.org  - & -  http://anduin.ipv6.eldar.org [IPv6 only]