Hello, re: XenServer. The initiator is the same but I suspect your issue with the disk timeout value on Linux. When the connection drops Linux gets the error and mount RO. In VMware for example the VMware tools sets Windows Disktimeout to 60 seconds to not give up so quickly.
I suspect if you do the same in your Lilnux VM, increase the Disk Timeout you will likely ride out transitory network issues and SAN controller failovers. Which is where I see this occur all the time. This is from a Dell PS Series document. that shows one way to set the value http://downloads.dell.com/solutions/storage-solution-resources/(3199-CD-L)RHEL-PSseries-Configuration.pdf Starting on Page 14. Disk timeout values The PS Series arrays can deliver more network I/O than an initiator can handle, resulting in dropped packets and retransmissions. Other momentary interruptions in network connectivity can also cause problems, such as a mount point becoming read-only as a result of interruptions. To mitigate against unnecessary iSCSI resets during very brief network interruptions, change the value the kernel uses. The default setting for Linux is 30 seconds. This can be verified using the command: # for i in $(find /sys/devices/platform –name timeout ) ; do cat $i ; done 30 30 To increase the time it takes before an iSCSI connection is reset to 60 seconds, use the command: # for i in $(find /sys/devices/platform –name timeout ); do echo “60” > $i; done To verify the changes, re-run the first command. # for i in $(find /sys/devices/platform –name timeout ); do cat $i; done 60 60 When the system is rebooted, the timeout value will revert to 30 seconds, unless the appropriate udev rules file is created. Create a file named /lib/udev/rules.d/99-eqlsd.rules and add the following content: ACTION!=”remove”, SUBSYSTEM==”block”, ENV{ID_VENDOR}==”EQLOGIC”, RUN+=”/bin/sh – c ‘echo 60 > /sys/%p/device/timeout’” To test the efficacy of the new udev rule, reboot the system. Test that the reboot occurred, and then run the “cat $i” command above. # uptime 12:31:22 up 1 min, 1 user, load average: 0.78, 0.29, 0.10 # for i in $(find /sys/devices/platform –name timeout ) ; do cat $i ; done 60 60 Regards, Don On Tue, Apr 21, 2020 at 11:20 AM <[email protected]> wrote: > Wondering myself. > > On Apr 21, 2020, at 2:31 AM, Gionatan Danti <[email protected]> > wrote: > > > [reposting, as the previous one seems to be lost] > > Hi all, > I have a question regarding udev events when using iscsi disks. > > By using "udevadm monitor" I can see that events are generated when I > login and logout from an iscsi portal/resource, creating/destroying the > relative links under /dev/ > > > So running “udevadm monitor” on the initiator, you can see when a block > device becomes available locally. > > > > However, I can not see anything when the remote machine simple > dies/reboots/disconnects: while "dmesg" shows the iscsi timeout expiring, I > don't see anything about a removed disk (and the links under /dev/ remains > unaltered, indeed). At the same time, when the remote machine and disk > become available again, no reconnection events happen. > > > As someone who has had an inordinate amount of experience with the iSCSi > connection breaking ( power outage, Network switch dies, wrong ethernet > cable pulled, the target server machine hardware crashes, ...) in the > middle of production, the more info the better. Udev event triggers would > help. I wonder exactly how XenServer handles this as it itself seemed > more resilient. > > XenServer host initiators do something correct to recover and wonder how > that compares to the normal iSCSi initiator. > > But unfortunately, XenServer LVM-over-iSCSi does not pass the message > along to its Linux virtual drives and VMs in the same way as Windows VMs. > > > When the target drives became available again, MS Windows virtual > machines would gracefully recover on their own. All Linux VM > filesystems went read only and those VM machines required forceful > rebooting. mount remount would not work. > > > > I can read here that, years ago, a patch was in progress to give better > integration with udev when a device disconnects/reconnects. Did the patch > got merged? Or does the one I described above remain the expected behavior? > Can be changed? > > Thanks. > > -- > You received this message because you are subscribed to the Google Groups > "open-iscsi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/open-iscsi/13d4c963-b633-4672-97d9-dd41eec5fb5b%40googlegroups.com > <https://groups.google.com/d/msgid/open-iscsi/13d4c963-b633-4672-97d9-dd41eec5fb5b%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > -- > You received this message because you are subscribed to the Google Groups > "open-iscsi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/open-iscsi/9D54680A-F97E-4465-BA6C-566562C5DC91%40eyeconsultantspc.com > <https://groups.google.com/d/msgid/open-iscsi/9D54680A-F97E-4465-BA6C-566562C5DC91%40eyeconsultantspc.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/open-iscsi/CAK3e-EbA-d6NeDETJ0EMHeAw3HGko_uCB_f6gsiqdjmEeYz6fw%40mail.gmail.com.
