我正在将一些 Linux 服务器迁移到虚拟化环境中，其文件系统从 LVM 卷安装，而这些文件系统又通过 iSCSI 托管在远程 NAS 上。我能够启动它们并且它们运行完美，没有任何问题。
然而，NAS服务器是基于Windows的，当微软发布补丁时，它会自动应用它们并重新启动。当它重新启动时，所有虚拟服务器的文件系统都会检测到错误并进入只读模式。我尝试将它们重新挂载为读/写，但内核将文件系统标记为写保护，因此失败。我找到的恢复的唯一方法是关闭 virt，fsck 其 LVM 卷，然后重新启动它。
virt 使用以下形式的 fstab 条目挂载这些 LVM 卷：
/dev/xvda2 / ext3 noatime,nodiratime,errors=remount-ro 0 1
或者
/dev/xvda2 / ext4 errors=remount-ro 0 1
虚拟主机操作系统还具有来自 NAS 服务器（甚至在同一卷组中）的 LVM/iSCSI 挂载，尽管存在这些中断，该 LVM/iSCSI 仍会继续以读/写模式工作。其 fstab 条目为：
/dev/mapper/nas6-dom0 /mnt/nas6 ext4 _netdev 0 0
这让我怀疑errors=remount-ro从来宾的 fstab 条目中删除将提供容错能力，但我对此有点不安 - 如果文件系统中出现实际错误，我希望允许继续写入 fs 可以让事情在短期内变得更糟。
解决此问题的最佳实践是什么，以便虚拟来宾能够在 NAS 自行重新启动后继续运行？
答案1
还有一种方法可以Recovery Timeout在连接建立后实时更改参数：
echo 86400 > /sys/class/iscsi_session/session28/recovery_tmo
替换session28为您的会话 ID。
答案2
根据开放式 iSCSI 文档:
8.2 iSCSI 根的 iSCSI 设置
当通过 iSCSI 磁盘直接访问根分区时，应设置 iSCSI 计时器，以便 iSCSI 层有多次尝试重新建立会话的机会，并且命令不会快速重新排队到 SCSI 层。基本上你想要的与使用 dm-multipath 时相反。
对于此设置，您可以通过设置关闭 iSCSI ping：
节点.conn[0].timeo.noop_out_interval = 0
node.conn[0].timeo.noop_out_timeout = 0
您可以将 replacement_timer 设置为非常长的值：
节点.session.timeo.replacement_timeout = 86400
该replacement_timeout设置默认为 120 秒，而 NAS 重新启动只花了两分半钟多一点的时间，因此超过了此超时，iSCSI 会话以及所有挂起的 I/O 请求都被丢弃，从而导致虚拟服务器出现磁盘故障并进入只读模式。
如上所述更改超时设置应该可以防止将来出现这种情况，至少对于 NAS 中断长达 24 小时来说是这样。如果下降的时间超过这个时间，无论如何都有更大的问题需要处理。