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