El 14/11/2025 a las 03:17, Eric Green escribió:
This isn’t a qcow2 issue. This is a file system timeout issue in the virtual
machine. Your NFS failover event is taking longer than 30 seconds, which is the
default block device timeout for Linux block devices. Your Linux system then
switches the file system to read only mode which sends everything to heck in a
handbasket. On Windows VMs it does the blue screen of death and reboots to an
OS Not Found prompt.
Hi, we made a work around this problem using NFS 4.1 and a block storage
replication under, with hearbeat so NFS can't see this problem.
You can either increase the block device timeout on Linux or speed up your
failover.
VMware ESXi handled this situation by pausing the virtual machine when it
detected NFS delays. I don’t know that qemu/kvm has that ability, it pauses the
VM when migrating a VM to a different physical server but not when there are
delays in the underlying NFS. CloudStack can only use functionality provided by
the hypervisor.
Get Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: Marty Godsey<[email protected]>
Sent: Thursday, November 13, 2025 3:25 PM
To:[email protected] <[email protected]>
Subject: QCOW2 on NFS shared storage
Hello everyone.
So, I am learning, or reading at least, that QCOW2 file format, running a
shared NFS storage that’s HA, does not to like to failover.
I have an HA NAS running NFS 4.1 and everything works fine until I test the
failure scenario of a failover on the storage nodes. When I do this, the entire
VM locks up and must be hard reset to recover.
Is this true? Do people not use QCOW2 on HA NFS storage? Are there time outs I
can set, etc..
Thank you for all the input.
Marty
