I will share my ganesha.conf in another message to clarify the "same path" that I was referring to. Sadly, I may have spoken too soon earlier today since something happened later that leads me to believe the issue is not yet resolved. Of course, I could be dealing with multiple issues related to different workloads that result in similar failures. I am certain that something significant did change though simply by my changing the path as I described earlier today. Before that, and going back months, I had been unable to ever successfully boot a linux vm that had its root disk image on this nfs-ganesha proxy fsal storage. After making this path change, not only was I able to boot that test vm, I was able to boot several other linux guests without a hint of any i/o errors on /dev/vda. However, sometime later today I decided to try booting a Windows 10 guest on this same proxy path. Well, that was the end of my joy. The Windows guest hung during boot, and all of the linux guests that were using this nfs-ganesha proxy path and had been working fine up until this point had their root filesystems go read only. I had to restart the nfs-ganesha service and reboot all of the linux guests to recover. I'm next going to repeat some tests with this and other Windows guests but using a different ganesha server with access to the same back-end storage path, to avoid impacting the happily running linux guests. Todd