I have now established a work-around on the VMware Workstation 17.0.2 (Windows 11) host and applied additional tuning to my existing Fedora Linux 38 guest installation:
a) enable Fedora 38 init ramdisk for booting not only nvme
cat << EOF > /etc/dracut.conf.d/scsi.conf
add_drivers+=" vmw_pvscsi mptbase mptscsih mptspi mptsas "
EOF
dracut -f -v
halt -p
b) switch controller for existing disk in VMware Workstation
- remove existing NMVe hard disk (this only unlinks it, the backing store remains, your data is safe)
- add new hard disk of type SCSI, pick the original backing store VMDK
- start VM
c) tune for access (optional)
add "noatime" and "ssd" to the btrfs mounts in /etc/fstab
reboot
d) validate
Have plenty of software and data on your virtual hard disk
cd /
rg 1 | wc -l
//exp: no system hangs, obviously no NVMe timeouts
//act: ... exactly as expected, returns a number in the millions
This works much much better than before. Incidentally, it seems as if a (software CI) task which previously took 55 seconds to complete now takes 5% less time (non-scientific measurement) - but really, the important part for me: no 30 second pausing / stalls due to NVMe controller timeouts.
Based on the above, I can only suggest to ignore the VMware recommendation to pick NVMe and to go for SCSI as a fast and robust choice.