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
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
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?
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:
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.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.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
?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 runinvoke-rc.d open-iscsi restart
it works perfectly. But the syslog has this: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.
Does your init script have
in the info section?
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.
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.
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
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...
https://hackpad.com/iSCSI-target-<>-initiator-Debian-6-1UkHDzhuNGI
Liked your guide
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?
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 :-)