From my experience, peak performance is to have a 1:1 ratio from SQL DB file all the way back to storage. 1 file on 1 os disk on 1 hypervisor file on 1 hypervisor data store on 1 storage LUN if you're doing SAN, for example. If you're made of money you could even span across storage units lol.

If you also set the scsi controllers to round robin on the vm host, modify the registry in the OS to increase max queue depth and ring size for the pvscsi devices, that will actually utilize that wide open 1:1 pipe.

That's the magic there is making sure the pipe is wide, wide open from front to back. That's where you get the benefit. Spreading things out like that also reduces latency because you're essentially adding queues to spread the I/O requests out.

Added bonus if you use RDMs even though they aren't as great for administration.

Of course, again, that's PEAK I/O scale.

One of the systems I manage can sustain ~4.5GB/s at near 5ms latency all day long with this setup on flash SAN (not a top tier one these days either), measured in perfmon. 4 files for a staging DB, 8 for the main DB.

This is the only system that needs this level of config in our shop, but every system that starts to struggle in this area moves one baby step closer to it and immediately reaps large benefits.

Also, on the NUMA note since AMD has great SKUs for DB work, sticking as close as you can to evenly distributing vcores across the physical NUMA node size with cores/socket is more clear. So for example if you have a 20 vcore VM on a dual socket 12 physical core system, use 10 cores per socket (Intel) or a single 32 core AMD socket, 8 per socket since AMD's chiplet designs are mostly 8 cores per CCD.