我的Xen服务器是openSUSE 11.1，在我们的iSCSI SAN群集中使用open-iscsi。 SAN模块位于启动器所连接的虚拟IP后面的IP故障转移组中。
如果主SAN服务器出现故障，辅助节点将扮演目标angular色。 这一切都由LeftHand SAN / iQ软件处理，并在大多数情况下运行良好。
我遇到的问题是，有时我的一些Xen DomU将在IP故障转移后使其根文件系统变为只读。 这是不一致的，每次发生故障转移时都会发生一个不同的子集。 他们都运行相同的openSUSE 11.1软件镜像。
每个DomU的根文件系统通过Dom0中的open-iscsi进行挂载，然后Xen使用标准块设备驱动程序将其展示给DomU。
确切的症状是，作为运行touch /test的根返回错误“只读文件系统”。 但是， mount的输出显示为正在读写。 当然，domU上的所有其他I / O也是在这个时候失败，所以机器很难下来。 只需从Dom0重新启动xm ，无需重新连接iSCSI会话，一切都可以正常工作。
在Dom0端，故障切换期间的系统日志消息如下所示：
kernel: connection1:0: iscsi: detected conn error (1011) iscsid: Kernel reported iSCSI connection 1:0 error (1011) state (3) iscsid: connection1:0 is operational after recovery (1 attempts)
我很难搞清楚在什么层面来debugging这个问题，在DomU内核中是什么东西？ 或在Dom0或Xen级别？ 我认为可能有某些参数需要调整，以增加某种超时，但我不知道在哪里看。
我真的不认为这是一个open-iscsi的问题，因为连接的块设备仍然可以从Dom0读取和写入。
我最终通过使用open-iscsi文档中的以下build议和设置来解决此问题：
8.2 iSCSI settings for iSCSI root --------------------------------- When accessing the root parition directly through a iSCSI disk, the iSCSI timers should be set so that iSCSI layer has several chances to try to re-establish a session and so that commands are not quickly requeued to the SCSI layer. Basically you want the opposite of when using dm-multipath. For this setup, you can turn off iSCSI pings by setting: node.conn[0].timeo.noop_out_interval = 0 node.conn[0].timeo.noop_out_timeout = 0 And you can turn the replacement_timer to a very long value: node.session.timeo.replacement_timeout = 86400
如上所述build立到每个LUN的连接后，故障转移就像一个魅力，即使需要几分钟的时间发生。
这听起来像在dom0上运行的iSCSI启动器的问题。 发起者不应该快速地向堆栈发送SCSI故障。 您可能需要在iscsi.conf中设置ConnFailTimeout，这个设置决定了在连接失败之前多长时间发生错误，并将错误发送到SCSI堆栈。
我也会研究这个故障切换实际上要花多长时间，可能会比预期的花费更长的时间。 如果是这样的话，由于ARP相关的问题，VIP故障转移可能会花费太长的时间。
dom0中是否有任何消息指出故障转移时的任何types的读/写错误或scsi错误？ 如果是这样，看起来这个写错误正在传递给domU。 domU不会“知道”它是一个iSCSI设备，所以它的行为就好像底层磁盘已经消失并以只读方式重新装入文件系统（请参阅mount（1））手册页 – errors=continue / errors=remount-ro / errors=panic ）
从dom0的angular度来看，它不会变为只读 – 这种只读行为是文件系统的语义，而不是块设备的语义。
你提到“所有其他I / O失败” – 你的意思是domU还是dom0？
通常，在设置高可用性iSCSI解决scheme时，我使用多path而不是虚拟IP接pipe – 这样可以更好地查看主机，并且没有iSCSI会话突然消失，然后需要重新启动 – 它始终存在，只有两个。 这是这个环境中的一个选项吗？
嗯…部分问题还在于你没有运行/作为RO。 最佳实践安全明智的状态，你应该有“/”挂载，任何需要rw的文件系统应单独挂载（即/ var和/ tmp）。 如果/ etc下有需要写入的目录，则应将其移动到/ var / etc / path并链接到/ etc。
“/”只能在单用户模式下安装RW。
结合其他build议，以这种方式设置可以防止上述情况下的段错误。