Sql-server – Multiple volumes vs single volumes for SQL Server CHECKDB performance

There is nothing inherently wrong with the current configuration however you have not included info that would be relavent, such as whether the host is overcommitted on RAM/CPUs. What problem are you trying to solve - performance and/or HA/DR? Assuming you are not overcommitted:

• Make sure the SQL Server instance(s) have sensible max memory settings. Ensure resource is allocated to accomodate that. If money is no object, use resource pools.
• VMware (in my opinion) is a better choice than HyperV, but it isn't a big deal which you choose.
• If you have enough memory to hold all the databases on the instance(s) which are virtualized, your main concern after that is CPU pressure, which is easy to measure. If you don't (which seems to be the case from your description), you're relying on storage for IO much more, so using the SSDs is obviously a good approach.
• I'd suggest the contractor DBA you are working with is coming up with ideas designed to keep him/her in a job as opposed to solving a problem. Either that or they have no experience of VMware. Or both. You can still allocate resources in VMware in much the same way as with HyperV. Striping tables is not necessarily a performance improvement, depending on the nature of your storage array and the IO requirements of the other VMs.
• If your SQL instance is Enterprise edition, you ought to use a physical box.
• WHen you say "6 CPUs" are you talking about an 8 socket box with unpopulated sockets or a single socket populated with 6 cores? If it is the latter, your performance issues will almost certainly be caused by processor availability, as VMware will only use all cores allocated to a VM once they all become available.

Bottom line - it seems that the host is under resourced for memory and CPU cores, which won't go away with HyperV. If you have need for more than 128GB of memory (based on amount of data in all databases) a physical box for the SQL server would be a good choice.

I wouldn't bother with anything fancy like table partitioning until you have sorted your resource issues.

I didn't want to duplicate @Nic's information, so this will be supplementary to his suggestions.

The operating system returned error 665 ...

Common issue with sparse files on NTFS. Just wait, this answer gets much better.

After doing some research we did a hotfix for the product that seemed like it may help with the issue... We went through the process of getting this applied, however, it did not resolve the issue.

That's what I would expect. This is because the hotfix adds support for the /L option (large attribute descriptor) for the NTFS filesystem. Here's the awesome part, you can only enable it by formatting the volume with this option. So, of course it didn't help as the volume isn't formatted with this option.

You could create a new volume, format with /L, copy the files over or you could attempt to use 3rd party applications to try and compact the files (which should compact the metadata as well) and see if that works. Additionally, a larger NTFS allocation unit size will result (for SQL Server) much less NTFS metadata fragmentation.