In my limited experience this is often from overloaded virtualization platform where this VM is located on. Can be vmware or proxmox, on proxmox its sometimes when VM is being live migrated to other virtualization host. Can also happen when backend storage where this VM is located is busy with other hosts.

EDIT: none of the VMs where I have ever seen this had btrfs, it was always ext4 mentioned in follow up error message, so pretty much filesystem agnostic issue. If this is on hardware however, then I don't know whats going on there.

NFS client code occasionally triggered this in the (distant) past, but that's just how it is when 'hard' mount option is chosen and the server becomes inaccessible for a prolonged time. The solution there is to get a reliable, sufficiently capable server and network (NOT to use 'soft' mounts as that can lead to silent data corruption) (and avoid cross-ocean mounts ;-}

But yes, running a VM on a grossly overloaded (over-committed memory?) host might trip timeout warnings as this as well.

> If this is on hardware however, then I don't know whats going on there.

It is. Bare metal install on the server in my closet, with plenty of resources (CPU/memory) to spare.