Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Need help with open-iscsi under OpenVZ
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

Need help with open-iscsi under OpenVZ

zserozsero Member
edited January 2013 in General

I'm trying to set up a iSCSI connection between two VPS-es (the storage box VPS by @Prometeus @Maounique). I've finished setting up the target, however now I'm at the point of setting up the initiator and I'm puzzled.

The OS is Debian 6 32-bit in OpenVZ container. Just after installing open-iscsi when I try to start iscsid -f I have the following error:

iscsid: Missing or Invalid version from /sys/module/scsi_transport_iscsi/version. Make sure a up to date scsi_transport_iscsi module is loaded and a up todate version of iscsid is running. Exiting...

I tried googling this problem and it seems to me that I need to recompile the kernel with this scsi_transport_iscsi module. Also, as far as I know, I cannot change the kernel in OpenVZ.

Is it really the case? I mean that the only way to have iSCSI with OpenVZ is if the kernel is supporting it, but you cannot change the kernel? What can I do now?
1. Ask Prometeus to re-compile the host-kernel on my node?
2. Ask Prometeus to move me to a KVM node?
3. Or I'm understanding something wrong?

Comments

  • jarjar Patron Provider, Top Host, Veteran
    edited January 2013

    I don't know about previous ones (or feel like checking), but scsi_transport_iscsi is in 2.6.32-042stab068.8. Ask them if this is a module they feel comfortable enabling. I have no idea if OpenVZ and ISCSI play nicely together, but it's in at least the latest kernel. Tell me if this is obvious just not to me, but what benefit on an OpenVZ vps would this have over other solutions like SSHFS?

  • zserozsero Member
    edited January 2013

    In the meanwhile I signed up for their new KVM based plan, since it was the same price or even a bit cheaper than my original OpenVZ plan. Prometeus credited my leftover from the original package, all in about 7 minutes since opening the ticket.

    So now I'm on KVM, with fully upgraded Debian stable, but that module is still missing from the kernel. Kernel is 2.6.32-5-686. So what's next?

    The debian wiki says:

    The module in iscsi_tcp is shipped in Debian's standard kernel since etch. So you'll just have to install open-iscsi, configure 6 lines in /etc/iscsi/iscsid.conf:

    Yes, you're right, I didn't think about SSHFS, but now I'd really like to configure iSCSI, since I've spent so much time reading about it.

    Update: I'm trying to use SSHFS (if there is nothing wrong with using it in a permanent setting), but it tells me connection reset by peer both in and out of the IPv6 node. Do you think that SSHFS cannot connect over IPv6? You were right, connecting between to IPv4 nodes using SSHFS was pretty much 2 lines.

  • jarjar Patron Provider, Top Host, Veteran

    Obvious question first to get it out of the way, did you run "modprobe scsi_transport_iscsi" on the KVM?

  • Ah, got SSHFS over IPv6. Stupid sshfs detects the first : as the end of the host. So sshfs can connect to IPv6, but you need to put the address in /etc/hosts first manually.

    Update: also, after some googling, it seems that I can use [i:p:v:6]:/path and then it's OK. It's a pity that it's not documented anywhere at all.

  • @jarland said: Obvious question first to get it out of the way, did you run "modprobe scsi_transport_iscsi" on the KVM?

    OK, thanks, modprobe works! After killing iscsid and restaring it now it runs! How can I make it load at startup? Just append it to /etc/modules?

  • @zsero said: but you need to put the address in /etc/hosts first manually

    Don't forget that after you reboot your /etc/hosts will be overwritten. But you can probably chattr +i

  • For SSHFS the [IPv6:address] way works perfectly. So finally no need for hosts file.

    However I still couldn't make open-iscsi to auto-connect on startup. It's strange, since if I manually run invoke-rc.d open-iscsi restart it works perfectly. But the syslog has this:

    Jan 8 11:32:18 ssdkvm iscsid: cannot make a connection to 2a00:... (-1,101)

    I think it might happen because the IPv6 network might not be up when open-iscsi tries to start. Do you have any idea how should I fix it? Remove it from rcS.d and append a line to rc.local?

    Also does anyone have any experience with bug reporting to Debian? The modprobe line is missing from the init script, while the other 2 modprobes are present, I thought I might report it, but I don't know how friendly are the Debian devs.

  • @zsero said: Do you have any idea how should I fix it?

    Does your init script have

    Required-Start:    networking

    in the info section?

  • zserozsero Member
    edited January 2013

    It has this, I'd guess $network is networking:

    BEGIN INIT INFO Provides: open-iscsi iscsi Required-Start: $network $remote_fs Required-Stop: $network $remote_fs sendsigs Default-Start: S Default-Stop: 0 1 6 Short-Description: Starts and stops the iSCSI initiator services and logs in to default targets END INIT INFO

    In the meanwhile disabling rcS.d and appending to rc.local seems to have fixed it. Very strange.

  • MaouniqueMaounique Host Rep, Veteran

    There will always be problems for early adopters.
    Tho IPv6 is really old now after many years of coming into existence, the implementation is not really a priority of many ppl.
    I was stunned to find out canonical main repositories are not dual stack even tho Ubuntu has a solid IPv6 implementation for years.
    Other than that, NFS crashes the kernel on OVZ for a long time in spite of their numerous attempts to fix it.
    I dont know about iSCSI but we have enough problems with OVZ instability as it is, the main reason for Xen and KVM on storage plans was just this, to allow free choice regarding how customers want to mount the space.

    @zsero said: In the meanwhile disabling rcS.d and appending to rc.local seems to have fixed it. Very strange.

    That might be because rc.local is done after all the others are already in place.

  • @Maounique said: That might be because rc.local is done after all the others are already in place.

    It was already one of the last ones, the other ones being not network related. Actually the only thing what fixed it with no errors in syslog was sleep 5 + start in rc.local. I think something on the IPv6 interfaces takes a while to load up, and the normal scripts doesn't detect it.

    After spending a crazy amount of time with this, I'll write some guide about it. Here is a very non-verbose version:
    https://hackpad.com/iSCSI-target-<>-initiator-Debian-6-1UkHDzhuNGI

  • MaouniqueMaounique Host Rep, Veteran
    edited January 2013

    @zsero said: I think something on the IPv6 interfaces takes a while to load up, and the normal scripts doesn't detect it.

    If you put the IPv6 by hand, it should be rather quick, if it is on autoconfigure for the MAC, then it might take a while, tho, not anywhere near that long...

    @zsero said: After spending a crazy amount of time with this, I'll write some guide about it. Here is a very non-verbose version:

    https://hackpad.com/iSCSI-target-<>-initiator-Debian-6-1UkHDzhuNGI

    Liked your guide :)

  • @Maounique said: If you put the IPv6 by hand, it should be rather quick, if it is on autoconfigure for the MAC, then it might take a while, tho, not anywhere near that long...

    sleep 5 is just a failsafe, i'd guess 2-3 second would be enough. In my interfaces, ipv4 is present, but there is no ipv6. So how does this work? It gets ipv6 from the file and ipv6 from DHCP?

  • MaouniqueMaounique Host Rep, Veteran

    You can look at your /112 and put an IP by hand.
    Aside from those we have a router that gives IPV6 based on MAC addresses to be there just in case.
    The ones put in config files should be fast, those you get from autoconfig will be slower as it takes some time after the IF is up, then send request, then get reply, then config...

  • OK, I see. I think I'm going to stay with the sleep 5 version, it's universal and seems to be very reliable. And I'm not planning on rebooting this system so often :-)

Sign In or Register to comment.