操作系统安装在虚拟机环境中，如VMWare或KVM。 networking共享磁盘卷（例如，iSCSI磁盘）用作OS系统分区。 这个操作系统中运行的stream量很大。 如果共享磁盘卷由于networking问题或其他原因暂时不能被访问两三分钟，并且在这段时间之后再次联机，会发生什么情况？ 操作系统是会崩溃还是会继续运行没有数据损坏？
我用Linux客户操作系统testing了我的情况。 在非访问期间，Linux桌面挂起，我无法操作。 但是当系统卷可以被再次访问时，我可以再次使用桌面，并查找以前的任务继续运行。
虽然我的testing看起来很成功，但我不能确定它总是好的。 我知道操作系统将重试IO，所以如果磁盘在短时间内不返回IO也许没有关系。 但操作系统也使用交换分区来换出内存中的一些页面。 如果交换操作由于磁盘而暂停，是否会产生严重的后果？
scsi磁盘的默认超时时间是30秒，但是你可以通过改变/ sys / block / disk / device / timeout来改变它，例如使用echo 180> / sys / block / disk / sda / timeout将超时时间增加到180秒。
如果我理解正确，从操作系统的angular度来看，客户操作系统的系统分区是本地的，而且它只是VMWare的远程分区？
在不知道的情况下，我对VMWare的经验是，在这段时间内，它宁愿暂停虚拟机。 实际上，我在VMWare ESXi上遇到了一个问题，那就是当增加可扩展分区的大小时，存储（包含所有虚拟机，并且是本地的！）已经满了。 所有的虚拟机都暂停了。 我不得不删除一个快照来释放一些空间，但我不确定它们是否继续直接运行（或重新启动后）。 虽然不是一个关键的服务器，我只是一个开发人员，而不是系统pipe理员:)
如果您在2-3秒内丢失了磁盘，那么您可能没有问题，操作系统将在可用之后继续运行。 虽然它会在日志中大声呻吟和呻吟。
如果你失去了几分钟的磁盘操作系统可能会或可能不会内核恐慌/蓝屏但除非你真的很幸运，你会失去数据，系统将变得非常不稳定。
是的，I / O子系统将重试…但不会重试几分钟。
我想这将取决于虚拟化层。 FWIW，我刚刚使用VirtualBoxtesting了它，它只是冻结，这对所有意图都可能是一个崩溃。 我没有其他系统要testing，我也不相信这种行为是一致的。 我怀疑这将取决于连接断开时操作系统实际上在做什么。
这真的是一个相当复杂的问题，答案取决于你的主机configuration。 首先，iSCSI层有它自己的超时期限和重试次数。 控制块设备的device-mapper-multipath也是一样，在guest OS中有QEMU磁盘层和磁盘控制器驱动程序。 不要过多细节，如果您预期使用不稳定的存储，将风险控制在最低限度要安全得多。 这可以通过禁用QEMU磁盘cachingfunction（cmd行中的cache=none ）来实现，并且使用werror=stop来使guest werror=stop在遇到IO错误时暂停，而不是无限期地推送该IO。 如果你不使用这些存储设备，那么在存储器不稳定的情况下，你可能冒着图像损坏和数据丢失的风险，尽pipe在某些情况下，如果客户操作系统检测到IO错误（例如，如果你使用传播），它可能会简单地重新挂载它的FS r / o模式。
无论如何，避免磁盘访问瓶颈通常会更好，特别是涉及虚拟机时。 iSCSIstream量的多path和单独networking是实现这一目标的常用手段。
这取决于很多设置。 OS被devise为在一段时间内重试I / O。 I / O子系统的操作系统和设置以及其下面的所有图层需要多长时间。
例如，考虑在VMware ESXi上运行的Linux VM。 Linux VM认为它在SCSI磁盘上运行，实际上它是由VMwarepipe理的VMFS文件系统上的VMDK文件。 VMFS文件系统实际上位于SAN上的iSCSI LUN上的networking中。 许多图层，每个图层都有自己的设置和超时。 在这种情况下，您必须检查VMware iSCSI启动器和Linux SCSI子系统上的超时。
在这样的分层系统中，增加默认超时是明智的，因为临时失败的可能性更大。 VMware实际上自己照顾一些这个。 就我所知，VMware的软件iSCSI发起者有相当长的超时时间。 Linux的默认超时时间有点短：
$ cat /sys/block/sda/device/timeout 30
一旦在虚拟机上安装了VMware工具，就可以将虚拟磁盘的超时提高到180秒的安全值。 我不确定为Windows VM设置了哪个值。
更长的超时时间不能保证。 具有高磁盘I / O活动的客户操作系统在超时值的持续时间内可能无法容忍持续的读取和/或写入请求。 Windows客人可能会冻结或BSOD。 Linux客户机可能会在其根卷上进行只读操作，这需要重新启动才能修复。
虽然操作系统可能在磁盘I / O中断后仍然存在，但是在OS平台上运行的应用程序可能不会。 应用程序本身实现响应超时值，这些值可能会被应用程序本身的平台或虚拟化pipe理员硬编码和不可configuration。
个人经验：我曾经升级了我的SAN固件并重新启动了SAN。 这种重新启动速度足以满足VMware ESXi以及我的Linux和Windows VM的超时。 通常所有的虚拟机运行良好。 但是，这次单个虚拟机不喜欢这个延迟，并且很难崩溃。 没有任何回应。 很难，我无法杀死虚拟机，不得不重新启动整个VMware主机。