It depends on many settings. The OS is designed to retry I/O for a while. How long depends on the OS and settings of its I/O subsystem and all the layers below it.
For example, consider a linux VM running on VMware ESXi. The Linux VM thinks it is running on a SCSI disk, which is actually a VMDK file on a VMFS filesystem managed by VMware. The VMFS filesystem is actually located across the network on an iSCSI LUN on a SAN. Many layers, each with their own settings and timeouts. In this case you have to check the timeouts on both VMware's iSCSI initiator and Linux's SCSI subsystem.
In such a layered system it's smart to increase the default timeouts since there is a bigger chance of something failing temporarily. VMware actually takes care of some of this by itself. The VMware software iSCSI initiator has reasonably long timeouts as far as I know. Linux's default timeouts are a bit short:
$ cat /sys/block/sda/device/timeout
30
Once you install VMware-tools on the VM, it takes care of raising the timeouts of the virtual disks to a safer value of 180 seconds. I'm not sure which value it sets for Windows VM's.
A longer timeout is no guarantee though. A guest OS with high disk I/O activity may not be able to tolerate sustained read and/or write requests for the duration of the timeout value. Windows guests may freeze or BSOD. Linux guests may go read-only on their root volumes which requires a reboot to fix.
While the OS may survive the disk I/O interruption, application(s) running on the OS platform may not. Applications themselves implement response timeout values which are likely going to be hard coded and non-configurable by a platform or virtualization administrator in the application itself.
A personal experience: I once upgraded my SAN firmware and rebooted the SAN. This reboot is fast enough to fall within the timeouts of both VMware ESXi and my Linux and Windows VM's. Usually all VM's kept running fine. However, this time a single VM didn't like the delay and crashed hard. No response whatsoever. So hard that I was unable to kill the VM and had to reboot the entire VMware host.